Should you build it? And if so, when?

Whether a successful product-focused company has one, a hundred, or thousands of engineers, they all face the same challenge: the demand for their precious development capacity outstrips supply. If the reverse - your supply exceeds demand - then your product (and possibly your company) is dying, even if you don’t know it yet.

The axiom that demand always exceeds supply seems to also generate a near-continuous stream of angst and anxiety within a company. The company continually asks: Why can’t development work faster? Are you gold-plating that feature? Why isn’t this project finished yet? And so on.

The only way I’ve found to reduce this company anxiety is to

  1. Ensure you have broad agreement on what’s most important;
  2. Over-communicate your plan for what product developers will work on and how their work will directly address what’s most important;
  3. As changes arise to the plan, over-communicate those changes and then repeat the previous steps.

Doing this is critical as an effective product leader within your organization. It’s so deceptively simple that I’ve purposely used the phrase “over-communicate” twice to underscore the importance of broadly sharing and engendering support for the work to be performed. If you don’t feel that you’ve over-shared, you haven’t shared enough. Insufficient sharing only results in anxiety (or worse, resentment) among your key stakeholders.

What’s Most Important

There’s an art to effectively communicating and efficiently executing the plan, but those are worthless if you’re not working on the right things.

The trick is to ensure that you’re working on what’s most important, and that your key stakeholders agree.

Since demand outstrips supply, you’ll have to make tradeoffs. One way to approach this decision process is to put your customer in the center, and then compare the competing work on three axes: 

  • The importance of the problem you’re solving; 
  • The effectiveness of your proposed solution; and 
  • The ability to drive customer demand.

Measure each of these on a scale of 1-10 (with larger numbers representing greater importance or effectiveness) to produce a spider graph using the template at right. At its simplest, the features or products that encompass the greatest area are the most valuable ones to pursue.

Note: it’s possible to use this rubric for your entire product backlog, but the time required to correctly score these features makes this method most effective for the key possibilities of your roadmap. 

Problem Importance

Correctly identifying the problem’s importance is useful, but discussion with your customers and your organization’s thought leaders can be even more valuable. These discussions help educate you, and inform them. This brewing-and-stewing process provides the insights you need to correctly evaluate the idea and, most importantly, guide future product evolution.

Solution Effectiveness

While “effectiveness” is a subjective measure, it is also easier to test than ever before: we have customer access, usability tests, validation boards, MVPs, and much more. Since developing these product capabilities likely require significant time and effort, they are the most deserving of validation before implementation.

Customer Demand

This third dimension represents your ability to market to your customers – in other words, your ability to raise their awareness that they have a problem that needs to be solved and the effectiveness of your solution. 

Consider a fledgling product newly emerged into the world. It could be the best solution possible, but it’s useless if no one can find out about it. The same is true of established products with many customers. If you can’t persuade your customers that a new capability or feature addresses a pressing problem they have, they won’t adopt it. In these cases, if you’re sure you’ve expertly solved a real problem, then the best-case scenario is that you’ve prematurely invested. It’s likely a problem they’ll eventually want solved, but it’s an investment that would have been better spent on more pressing customer needs. Score it accordingly.

(a note on effort estimates)

In the past, I might have had the third axis measure time or effort instead of customer demand. After all, when you’re faced with a supply-and-demand problem, you want to be judicious with your finite resources.

However, what trumps scarcity is customer demand (or lack thereof) - and that's why the third spot is taken by it.

But, effort is also absent to force us away from misguided estimates. At worst, our estimates are grossly inaccurate; at best, they're educated guesses - though still inaccurate. As DHH of Basecamp writes, "This model [of guessing] has been broken since the dawn of computer programming, yet we keep thinking it’s going to work. That’s one definition of insanity."

Not focusing on estimates forces us to focus on the customer and their needs. In a way, it frees us to make the best decision without worrying prematurely about the cost. And when it comes time to reconcile that cost, we again sidestep the guessing approach and instead allocate a budget to the feature: a budget that commensurate with the features value to our business. The result is a constraint that guides the development approach and corresponding trade-offs.


With the scored results, you’re ready to build (or, more likely, update) your product roadmap. For the most promising ideas, allocate the amount of effort and time to be spent on their development, and the best timing for their delivery. This then becomes the vehicle for the next level of discussions and negotiations.

As noted earlier, if you don’t feel that you’ve over-communicated, then you likely haven’t communicated enough.

I’d love to hear how well this model worked for you. If you have a different perspective, please share in the comments.