If you have been a product manager for a while you will probably recognise some version of the following:

“I know we have the roadmap but we really need

{Important Thing for key customer(s)}

by {Timeline, usually really short, likely ASAP}

so that {Benefit to Business, e.g. upsell, renewal, happier customer, lower risk of churn etc}

Well meaning person within your organisation

No matter how carefully you understand user or customer needs and prioritise, these sorts of situations will likely come up. So, as a product manager how do you deal with them?

Every organisation and situation is different but here is an approach/framework I use:

• Context
• Cost of saying “No, not now”
• Effort
• Opportunity Cost

Diving deeper into each of these:

Context – Every situation is slightly different but I find it is worth considering:

• Do you understand the underlying need of this request? What problem is it solving?
• What customer/set of customers does this request relate to and who is it coming from?
  • Does it relate to one of your organisation’s most important customers/customer segments?
  • Could there be benefits for others if you were to do this work?
  • Is the person making the request likely to have validated/be open to you validating it directly with the customers?
• Where are you and the product development on your current initiatives/work? E.g heads-down in the final week before a big launch or soon to kick off new streams of work. If it’s the latter, it might be easier to consider.

Cost of saying “No, not now”

• If you say no, what might the impact be both internally (the requester, their boss, their team etc) and externally (the customer)?
• If the ‘cost’ of saying no is quite low, you might not need to go any further, though you should always give some rationale for saying no, e.g. “Thanks for raising this with me, I’ll add it to our ideas board. To manage your expectations, this is not something we are going to immediately tackle because {other important things you are doing}”.

Effort

• At a high-level, e.g. t-shirt size, what would it take to solve this problem for the customer/set of customers?
  • This is where more digging will be required. That could mean talking with an engineering leader/designer and the customers themselves.

Opportunity Cost

• If you go solve the problem requested, what are you stopping doing or not picking up instead?
  • You and the people you work with should understand that there is a cost to doing something new, you either drop something you were already working on or delay starting something you planned. It doesn’t mean you shouldn’t pay that cost sometimes, but everyone should understand there is a ‘cost’ and what it is.
  • This is to align expectations and avoid situations where someone senior, not aware of this request and the context, comes along and asks: “When are you delivering {the thing you decided not to do/deprioritised to look into this new problem}?”.

I will go into a couple of examples below where I walk through my approach:

Example 1: Increased rate limit usage

• Context
  • One of our biggest customers at the time wanted a higher API rate limit to send us more traffic. This traffic was directly tied to revenue, the more requests that were sent to us, the more revenue the company would receive. Other big customers could also likely benefit from higher rate limits.
  • Trust between the commercial team and the product development team was low at this point, because deadlines had been pushed back in the past.
  • As a product development team we had almost finished some replatforming work which would make the increased volume of requests possible to serve.
• Cost of saying no
  • Quite high. There was a risk of not being able to ‘grow’ with the customer and disappointing the commercial team again.
• Effort
  • Our commercial team had done their homework and organised for our tech lead and I to chat with the customer to make sure we heard first hand what they were after.
  • Our tech lead and I went away, spoke to some of the other engineers and worked out whether we could do this and when. It turned out we only had a little more replatforming and load testing to do then this was the sort of request we wanted to enable.
  • I came back to the commercial team and said we could make it happen by the end of the current quarter (we were mid-way through). They were happy with that.
• Opportunity Cost
  • Doing this work would mean delaying a couple of initiatives that were slated to kick-off. I made our product and engineering leadership aware of the trade off and invited them to challenge it. They agreed with the decision and were grateful for the transparency.

Outcome: On the last day of the quarter (phew!) we shipped the updated rate limit and informed the commercial team and customer. Their usage increased and soon after they renewed their contract at a higher usage limit resulting in a large increase in revenue.

What went well here:

• The ask, the higher rate limit, was in-line with replatforming work that was already underway. This was a tangible customer facing result that could be achieved after a lot of “under-the-hood” work.
• The commercial team quickly facilitated talking directly with the customer’s technical team to understand and clarify the ask and context.
• Once we understood this, the tech lead and I gathered a couple of senior engineers on the team to talk it over and come to a decision.
• I communicated that to everyone involved.
• Most importantly, we delivered the improvement when we said we would and ultimately, it resulted in usage, an increase in revenue and a way of enabling it for more customers in the future.

Example 2: Potential mobile app

• Context
  • Our company was invited to a potentially very lucrative request for proposal (RFP) process with a large client
  • Different members of the product team, me included, were invited in to look at the requirements and where we fell short to see if we could address them
  • One of those areas was offering a mobile app. We didn’t have a mobile app so we needed to look into what it might take to meet that requirement.
• Cost of saying no
  • As this opportunity was so large, we had no option but to evaluate what it might take to add a mobile app.
  • If this deal came off, we would have to act on it in a short time frame, it would be part of the contract.
• Effort
  • This was the thing to dig into with our engineers. The requirements were quite detailed which helped and I used this with the team to go through what we thought it might take.
• Opportunity Cost
  • If we won the client and needed to build the mobile app it would have meant switching folks off of existing work and delaying things we were due to start.

Outcome:

• We didn’t win the deal so there was no need to follow-through immediately with the mobile app.

However, what could have been improved:

• As a result of asking some of the team to look into this, I actually ended up distracting nearly the entire engineering team for a week, in the end, for nothing.
• This was my fault, I wasn’t clear with our senior engineers how speculative this opportunity was and that it shouldn’t eat up a lot of time to evaluate or need to involve lots of the team –> a lesson learned on communication and time-boxing.

—

There you have it. One way of dealing with those inevitable asks that come to you and your teams. As you have seen, I haven’t always got it right.

I hope you found this post useful and I’m happy to hear about other approaches too!