Getting To No Without Being The Roadblock

Each week in the?Tech Exec: The Week That Was?newsletter I share my thoughts on a topic that I've worked on or discussed with a client, colleague, or within the CTO community. This week we look at how to say no to a product / feature request without being seen as a roadblock.

Sometimes we just want to say no but don’t want to be seen as the roadblock for ideas. I was faced with this when asked to add a ChatGPT feature to an existing product. So I said yes, and got the requester to say no instead. The workflow to get there is simple.

Why Care?

As a tech leader your role is not to say yes to building everything that the business wants, or to follow the latest hype. It is to build value that aligns with the business vision and focus. To do this we need to guide priorities and direction based on our expertise, which inevitably means learning how to say no.

The Request

"It would be really cool if a user could click on a product and ChatGTP provides them with all the data on that product. Can we do that?"

How would you respond? Say yes, because of course we could build it, and hey, it would be pretty cool? Or say no, because for this product the use-case is a terrible idea that will divert focus from work that really adds value? Instead, take a deep breath and ask yourself:

Is the request clear?

The answer to “Is the request clear?” is initially almost always no. Could you build out the request without asking any other questions, and be 100% confident that you have built what they actually wanted? What you want to get at this stage is enough context so that you can decide if you should be progressing the request or not. Even if you know straight away that it isn’t a good idea for the business, asking more questions at this point gives you additional context for framing your rationale and also to demonstrate that you are collaborative rather than a roadblock. Just asking some clarifying questions can sometimes be enough for the requester to realize themselves that it isn’t something worth pursuing.

Some possible clarifying questions for this ChatGPT request:

• Which types of user will get additional value from this?
• What type of product information should be included? How detailed and accurate should it be?
• Should the product data that is shown be consistent between users and requests?
• How up to date does the data need to be?

When you have sufficient clarity on the request you can move to the next question:

Do I have enough knowledge to provide advice?

If you already have enough knowledge of the technology and business to know if and how you could implement the request then you can skip this step. If not, do the research to understand the technology so that you can provide advice to the business.

For this request, I already knew just enough about how ChatGPT worked that I could move on to the next step immediately during the conversation. I still did more research later so that I could better explain if asked more about it.

Had I not known enough, I’d have said something like “There’s some really cool things happening with ChatGPT. Let me dig in a little more to figure out how this would work best for us”.

Feasible and Valuable?

The next question to ask in the decision workflow is “Is it feasible to build a solution that will provide value for the business?” Given enough time and resources pretty much everything is feasible, but just because we can do something doesn’t mean that we should. To provide value for the business it should also align with the business vision and focus, and not be a path to bankruptcy.

Until you can answer this question for yourself you will need to ask more questions and do more research.

So, should we create that ChatGPT feature? For this request there was a requirement for full and accurate data, so given ChatGPT uses a Large Language Model (LLM) that essentially make stuff up, the answer is a pretty clear no.

Getting to No

The goal at this point is to gain acceptance that we shouldn’t move forward with the idea, at least at this time. Get the requester to own the decision not to move forward, otherwise you are likely to be asked about it again! The easiest way I’ve found of doing this is to frame questions in a way to get them to say no, after being clear about the recommendation.

With our ChatGPT example, I said something like “Yes, we certainly could build a ChatGPT integration. The way that it works is by constructing text by choosing the next most likely word, based on its huge training set. Given this, and the fact that the training set won’t necessarily have the latest data, we cannot guarantee that the information that we will provide will be accurate. This doesn’t seem to fit with out promise of providing the full picture to our users, so I’d recommend that we do not go down this path. Would you still like us to prioritize this work?”

Collaboratively Rephrase Request

If the requester decides not to pursue this request then you can breath a sigh of relief and move on. However, if they would still like to continue this is your chance to work with them to rephrase the request and start the workflow again.

ChatGPT Everything?

I found this article by Colin F. to be really useful in understanding LLMs and the limitations of ChatGPT: https://www.dhirubhai.net/feed/update/urn:li:activity:7024930359033176064?updateEntityUrn=urn%3Ali%3Afs_feedUpdate%3A(V2%2Curn%3Ali%3Aactivity%3A7024930359033176064).

What have been your experiences in dealing with requests that you think are not valuable or a priority? Please share your thoughts in the comments below, and?subscribe to?Tech Exec: The Week That Was?to get notified when the next article drops.

If you would like to discuss exec coaching or fractional CTO services contact [email protected].