How do you decide what to build next?

Starting right at the heart of product work

It’s pretty much exactly like this. Right?

Honestly, I try not to. Ok that’s not entirely accurate, but it’s not my job to apparate the roadmap out of thin air, or determine what to build out of a siloed vision of the future.

Vision helps, to be sure, but ultimately, it’s my job to codify priorities and ensure the team knows the answers to (or how to answer) three questions:

1. Where do we want to go? This is far and away the most important question, and the one that involves the most communication and planning. It starts with leadership (which often includes me) analyzing opportunities and threats. Some of these are new, and come from market research and partner conversations. Many of them aren’t, and come from conversations with customers, the team, advisors, and investors (in that order). After a kind of catch-ball review, we reach a committed conclusion. I try to keep this high level, because as implementation details inevitably vary the plans, it’s critical that the team understands what, broadly, we’re still trying to accomplish. The answer to this question alone is my ideal product roadmap, but more on that later.
2. How close are we? This is where much of what we typically think of as a PM’s toolkit lives. User surveys and A/B testing are used sparingly, if ever. These tools are better for measuring more nuanced facets of a product with a much larger user base than I typically work in. Direct measurement based on a testable hypotheses and actual, frequent conversations with customers are the workhorse of determining how close we are to where we want to be going. Once you know the gap, you can start to contemplate the last question.
3. How do we expect to get there? I like this question more than “what should we build next” because it allows me to incorporate the team’s strengths, weaknesses, and values. Let’s say you’re trying to solve a problem with your search results, and your first thought is to incorporate machine learning to improve the results over time. If you commit to this solution before having any ML engineers, all of a sudden you have a staffing problem, and your customers will have to wait weeks to months for you to solve it. On the other hand, if you approach your team’s current strengths as a creative constraint, you might try changing the sort order of search results to favor recency. You ship it in one day and, surprise!, it solves the bulk of the problem. It won’t (and shouldn’t) always work out this way, but I find it a better place to start.

The answer to “how do we expect to get there” then starts to look less like a roadmap and more of a set of things we’re doing today. In fact, the Basecamp folks put it pretty well, in my opinion.

Like functional specs earlier in the development phase, product road maps are fraught with trouble. The due diligence process is usually twice as shallow, which means that you’ll inevitably end up promoting illusions of agreement. When all we have to agree on is a slogan, like “Meetings Tab, 4th Quarter”, it becomes an empty imagination box that’ll fit wildly different expectations. Disappointment, however, is sure to ensue when only one set of expectations can actually be met.

Long roadmaps are at best speculation and at worst miscommunication. And the Basecamp founders expound on this even more in ReWork, which I love and highly recommend.

Put another way, the ideal product roadmap is, ultimately, just the company’s strategic direction plus the current implementation phase. Focus deeply on the “how” only for the present. For the future, stay focused on the “why.”