The Subtle Art of Maybe

Fielding Internal Feature Requests

Product management is all about tradeoffs. For everything you say yes to, you’re saying no to any number of things you’re ignoring to focus on that one objective.  If you say yes to everything, you’ve actually said yes to nothing.  I’ve learned that myself the hard way in my career.  So we need to get good at saying no to stakeholders.

In PM communities online, I’ve seen a lot of variations on the same question:

How do I say no to a feature request from [some particular stakeholder]?

The best way I’ve found to say no to stakeholders is to instead say maybe.  

But this is not a passive response that kicks the can down the road, amplifying the eventual disappointment and frustration the stakeholder will experience when you finally tell them no. Instead, it’s a structured and rigorous “maybe” — which explains what it would take for the maybe to become a yes.  And it’s an offer to partner with the stakeholder, to work toward a yes.

How to Say Maybe

You already have ways of deciding what to build and prioritizing the work. You probably don’t make roadmap decisions based on your mood or rolling dice.  The right way to make roadmap decisions varies by context; like almost everything in PM, it depends.  But your organization probably has certain norms about how value is estimated and work is prioritized. And you probably add on your own judgment and considerations about your specific product and its role in your company’s strategy.  

Telling a stakeholder “maybe” involves giving visibility to your process for prioritization and roadmapping.  It may even involve explaining how software development works, how teams within your organization depend on each other to coordinate effort and deliver larger pieces of value for the business, and how inefficient it is to constantly shuffle the roadmap, abandon in-progress work, and allow team morale to wane as a result. 

It’s not just saying “maybe”.  Instead, it’s saying “Maybe, but in order to prioritize the feature you’re asking for, we would need to convince ourselves that it’s valuable enough to adjust the team’s existing roadmap and make room for it.”

I’ve found great success by saying or writing something like this in response to feature requests from stakeholders:

Thanks for suggesting this! I’d love to work with you to try to build a business case to get this onto the roadmap. We’ve already got our roadmap filled in for the next N months/quarters, but it’s certainly possible to make tradeoffs, if the business case is strong enough to displace existing commitments. We’ll just need to be able to quantify the value of this work, so we can show why it’s more important than other planned work. Do you have a sense of how we can quantify the value in terms of increased revenue, increased customer retention, lower customer acquisition costs, savings in labor costs, etc.? And where we can find data to build a model to arrive at that $ value?

The implicit subtext is this:  “I want to help you on this and appreciate you, but we’re both going to have to do work to justify this. And the ball is now in your court.”

When to Say No (or Yes)

This was my go-to response for a few years at a past company, a Fortune-100 enterprise, to out-of-band feature requests (i.e. coming from some stakeholder, and not obviously important to prioritize, given the product direction at the time). The most common outcome was that I never heard from them again about that request.

Most of the time, I never had to give an explicit no, because the stakeholder who made the request arrived at “no” on their own.  They knew that there was no real case to be made for displacing work already on the roadmap, in order to turn the “maybe” into a “yes” — so they arrived at “no” without me needing to be the one to say it. 

If the stakeholder is optimistic that there’s a strong enough business case to be built to prioritize the work they’re asking my team to do, then I’m happy to engage and help with that.  If I’m also optimistic that it’s very valuable work, then I’ll even do most or all of the leg work myself. But if I’m not yet seeing their vision, the more skeptical I am, the more I’ll delegate the legwork to them.  And I may become more convinced as we make progress — in which case I’ll stop delegating and start to drive it forward on my own as much as possible. 

If we end up working to build a business case, at some point the decision should become obvious to both of us.  If at some point we’ve both lost interest, it’s another implicit “no”.  

If and when the “return” of the in-draft business case starts to look strong, then I will work with my team to estimate the “investment” side of the equation — the development effort, impact on infrastructure costs, tech-debt implications, etc. — to round out our business case and provide a sense of ROI to inform the final decision. In our decision-making process, we need to also weigh the estimated effort against the anticipated value, to understand the expected return on investment (ROI). Considering ROI enables us to see beyond immediate benefits and consider short-term costs and long-term implications. 

If we complete the work to estimate the quantified value of the work and the cost of unlocking it — then it’s an easy decision for us both to agree on:

• YES — “Yes, let’s build this (Feature X) next quarter instead of Feature Y, because X is expected to drive 40% greater annualized revenue lift than Y would!”

• NO — “No, this (Feature X) won’t be as valuable as Features Y and Z that are occupying our roadmap for the rest of this year. Here’s our current roadmap, if you want to click the links under each item to see the business case that’s driving each of those, for comparison’s sake.  But I’ll keep it in the bullpen for when we start planning next year, to see if it would make sense to do this work then!”

Educating Stakeholders

For the eventual yes or no to make sense, you may need to help the stakeholder understand aspects of the situation that they’re entirely unaware of, even if they feel obvious to you.  

Changing your team’s roadmap with little or no notice can feel chaotic and frustrating for some teams, and that’s a very real cost for your company that needs to be considered.  Changing your team’s roadmap may also have implications for other teams who are doing work that depends on yours, meaning that disrupting your team’s roadmap may disrupt other teams and cause frustration, if not waste work that has already been done toward upcoming deliverables. And there may be other factors on your mind as well, which you’ll need to help the stakeholder understand and appreciate, so they can understand your eventual roadmap decision about their request.

An Easy “No”

An example I recall from my own career, where someone made a request for a change that had no real justification, was at a large, global e-commerce company I worked for. Someone from the Gift Card Ops team wanted work done to enable a special, new kind of gift-card promotional campaign in their specific geographic business unit (one of several geographies my platform supported). The folks asking for it wanted it because it was going to move the needle for their KPIs, purely around the gift card program in their geography, but it paled in comparison to the global features my team was already planning for the next year — which would drive much higher revenue lift or keep us compliant with regulatory changes (i.e. allow us to keep operating our business in the EU). It wasn’t like it was a waste of time, but the opportunity cost of doing what they wanted would have been way too high.

When I gave this stakeholder a structured, rigorous “maybe” — she thanked me and then never mentioned it again. I never needed to tell her no, because she arrived at the answer herself.  And we continued to have a very positive and collaborative working relationship going forward, as a result. 

An Eventual “Yes”

I also recall a counterexample from my career, where our CEO and primary salesperson suggested that we build a pivot-table functionality into our data-analysis product.  He explained that he’d used our existing export functionality to pull various reports and build such a pivot table in Excel, to show a current sales prospect when he presented their proof-of-concept (POC) implementation of our product.  Rather than saying yes or no, I asked if he could continue making these spreadsheet files, one for each sales prospect we presented a POC to, and we would add a “Download Pivot Table” button into the product, which would allow the user to download the manually-created Excel workbook as a static file. I explained that this Wizard-of-Oz experiment would allow us to gauge the value such a feature would offer before spending time to build it into the product. 

Our CEO agreed, and within a month of presenting these manually-built Excel pivot tables, it became obvious what a valuable feature it would be to build — and we had learned how it could be refined to work better for our users, based on feedback from sales prospects who had been shown or had used the Excel pivot table we provided. 

The result was an obvious and unanimous “yes” to a very well understood scope of work that we were able to confidently and quickly deliver as a native feature of our product, to great success going forward.

The Results

Either way the decision goes, it’s not so much me who is saying no (or yes). Instead, it’s the reality of what’s best for my product and our business as a whole (which we both clearly share an understanding of), which is resulting in a “no” to the feature request.  The stakeholder may feel frustrated, but by this point the frustration won’t be with me as the PM.  I was the PM who was game to help make it happen, if it made sense for our business!  

And if this feature request was among the many that are obviously not valuable enough to find a place on the roadmap, the stakeholder will likely not come back with another feature request, until she has one that she thinks is actually valuable enough to the business as a whole, to actually be worth building the business case. 

If you’re trying to figure out how to say no to a stakeholder, is there a way to frame a structured and rigorous “maybe” instead?