Let’s say you’re working for a company which has clear and well-defined KPIs as for how it measures its success.

First – you are lucky! Many companies I’ve seen and worked with try to avoid declaring well defined KPIs as their north stars (but that’s a post for another time). This clear definition allows you to work on a coherent roadmap that will serve this KPI. Sweet!

But then the head of sales comes to you and tells you something in this spirit:

 

Bob: “What’s up? Listen – Walmart (codename for a big & strategic customer) has asked us to add this feature where they can do X, Y and Z. You know what I’m talking about, right? We discussed it last week.”

You: “Yeah, I recall, but listen – this feature is fully customized to them and brings zero value to all of our other dozen customers”.

Bob: “But it’s Walmart dude…”

You: “And still, with all due respect, the feature doesn’t serve our other customers and won’t help us increase our goals with regard to the KPI and hence it’s not on the roadmap. Sorry.”

Bob: “Seriously? Fine. You go and tell the CEO that we’ll be losing Walmart because you don’t want to prioritize this feature… good luck”

 

Now… this imaginary conversation can go on and on – but you got the drift. You probably can also guess how this is going to end, right?

Most likely that you will go to spec out and prioritize this feature for the upcoming sprint.

 

Strategic customers, or as I like to call them – ‘big whales’ are important to the growth of a company. Especially a small one which is struggling to raise funding and wants some big names in its portfolio of customers. Another reason to fish big whales is that they are paying very well and can become a great source of revenue. That’s another thing that is super important for young companies.

 

But as you understand by now – unless the company’s strategy is focused purely on the top 500 fortune companies, then having a big whale swimming in your pond can create a lot of havoc.

 

You see – the problem with big whales is that they know they are big whales… 🙂

And because they are self aware – they expect to be treated as such. This usually translates to having a dedicated customer success representative for each of the whales, and as a result – a dedicated stream of customized feature requests that serve nobody else but them.

 

Those feature requests will pile up on your desk, and if not addressed in a timely manner – you’ll get a call like the one above.

 

Now, I will tell it upfront – the main responsibility to manage big whales falls directly on the CEO, and not you. But on the same breath – most CEOs I’ve met will prefer to avoid confronting their big whales at any cost. It means that it will fall on you to manage such scenarios and you’ll need to navigate this very carefully. Yeah… life can be unfair sometimes, but like any good entrepreneur – you should try to steer it in your favor and get some upside from this.

Ok. So let’s get back on the scenario we’d like to focus on today – you have a big whale asking for a customized feature that serves no other customer but them. What should you do?

 

Your Options

Here are the options, as I see them:

1. Ignore the request. Meaning – you decide not to act upon it and not let it interfere with the roadmap. 

The pros:

• The roadmap gets promoted uninterrupted
• The main company KPI will maintain the good trend (assuming you did a good job crafting the roadmap)

The cons:

• The big whale will be upset and may eventually decide to leave the pond (if you take this approach several times)
• Your CEO, your superiors, sales and customer success may be mad at you and eventually they may say that you are not a ‘team player’
• Your superior may decide that next time – there isn’t gonna be dialog. They are simply going to force your hand and that’s it.

 

2. Accept the request. Prioritize it for the next sprint and get it implemented.

Pros:

• You made a lot of your colleagues happy.
• You made the customer happy. Less chances of churn.

Cons:

• The roadmap took a hit. After all – implementing it must come at the expense of another feature.
• The R&D guys may be unhappy about the context switches (though you can minimize that if you plan it properly)
• Doing it often enough – you lose track of your roadmap, strategy and plans. You become enslaved to the big whales requirements.

 

3. Negotiate & discuss. You reach out to the big whale directly. You have a conversation about their feature request. You’re trying to convince them to let go, or otherwise generalize the feature request to something that can also serve other customers.

Pros:

• If you manage to find a common ground – this is the biggest win because everyone wins – your roadmap, the big whale and mainly you – the hero.

Cons:

• The coordination and the meeting itself consume precious time. The big whale will certainly won’t agree to do it for each and every request of theirs.
• If you failed to find a common ground – it’d be very hard to turn them down now, after they allocated and devoted time to you.

4. Explain the costs and sacrifices involved to your colleagues and superiors.

Pros:

• If you manage to convince them that the cost is too high – they may do the ‘fight’ for you and take the feature request off the table.
• If you failed to convince them and you were discussing with one of your superiors – then in some aspect you’ve rolled out the accountability to their doorstep, because they can no longer claim that they didn’t know what was at stake (you are protecting yourself here, but not providing any true value to the company – so it’s a semi-pro).

Cons:

• If you failed to convince them it’d be somewhat harder to turn down this feature request since a proper discussion about the price and its alternatives has already taken place.

 

Ok. I understand my options, but which one should I pick?

 

Here is the thing:

By itself, choosing any of the options – once or twice – won’t have a big and long-term impact anyway (well… most likely. Depending on the request). Meaning, for example – if, over the course of your job, you decided a couple of times to turn down the big whale’s request, and on the other times you agreed – then everybody will probably be at peace with it, including the big whale itself.

 

Second – I know that having a big whale attached to your company can be a pain in the a@#s. Don’t let it affect you emotionally. It’s crucial that you take your emotions out of the process and deal with each request rationally.

 

So keeping the above two in mind provides you with a lot of flexibility in your decision making process. My advice to you is to evaluate each feature request that lands on your table independently of any other feature requests coming from this source.

Evaluate it rationally. Ask yourself:

1. How is it aligned with the company’s KPIs?
2. How is it aligned with your roadmap?
3. How much effort does it take to implement?
4. How many complications does it embed in your existing flows?
5. How much future legacy code which serves only this customer is put into your system?

 

The last question is of high importance. I’ve seen more than once how features that were implemented only for one customer made it very hard for the engineering team to upgrade their architecture later down the road. The need to support a unique feature that was promised to a single customer incurred huge costs when the team tried to migrate to a new infrastructure.

Hence, I’d treat 4 and 5 above with extra weight in my decision making process.

 

Once you evaluate the above – it should make it much easier for you to make a decision whether you accept this feature request or not. And if you decide to turn it down – it should be much easier to explain. At least to the internal stakeholders.

From time to time though – try to cater to such requests if possible as it will help build a name for yourself as a true professional who doesn’t always say ‘no’ or ‘yes’ automatically, and can also provide the rationale behind his/her decisions.

 

Last – like many other scenarios – it may not be your call at the end of the day. Especially if the CEO and the leadership are not confident enough with confronting their strategic customers. I’ve seen companies where such feature requests are automatically getting the top priority and sometimes even break a sprint in the middle. This is almost always a very bad strategic approach from your leadership and sadly – you have only two options here – accept this reality and take this strategy as a major consideration in your planning process OR start looking for another employer.

 

That’s it for today.

If you found this post/series useful – feel free to let me know on the comments section. If you think others can benefit from it – feel free to share it with them.

 

Thank you, and until next time 🙂