Wandering product roadmaps

In an early stage startup, especially one that’s on the edge of a new market or technology, building a product roadmap seems to be a futile exercise. The market is moving fast, the technology is moving fast, the customers & developers are moving even faster.

In addition, your every meeting, whether with a prospect, customer, competitor, investor, or even prospective employee, changes the roadmap. Life is fast, and your product roadmap is evolving faster than the rest of your company can keep up.

But a fast product roadmap, a B2B SaaS product, and a mid-market or enterprise clientele don’t mix well.

The answer my friend is to become schizophrenic, and keep multiple product roadmaps. Yes, it sounds crazy. No, it’s not new. Enterprise software companies have been doing this for decades.

The goal in the rest of this article is to briefly describe the role of each roadmap, and how they fit together.

Coarse Problem Roadmap (18–24 months max)

This roadmap is to capture the high level mission & vision of the founders, communicate that effectively to investors, prospective employees, and other key stakeholders.

Typically, the biggest problems for founders are caused because their startup is solving the wrong problem for customers.

Solving a problem that’s worth a lot when solved, where there’s a clear owner + budget, and where an outcome can be delivered by a startup, end-to-end, is critical in building towards product-market fit.

The first step is identifying the right problems to solve, and a good order in which to prioritise them. Either by tractability, or by what the customer will pay for first, or even by whatever you like to solve first. Just put the problems in a priority order.

This roadmap is for your investors, for your senior team, for aligning your team’s Vision in a V2MOM for instance, or for building your greatest deck ever.

The value of solving these problems across all the customers in that market sets an upper bound for what you can earn — roughly a bottom-up TAM. So if you want to be bootstrapped and get to $1M-$10M in revenue, solving this problem roadmap should be worth $50M+ (i.e., TAM of $50M+). And if you want to get VC funded, it should be a TAM of $500M+ to match VC economics.

This roadmap should be furiously iterated early on, and relatively fixed once you get founder/employee/investor/customer commitments on it.

This is the roadmap that needs founders to take into account a ton of others factors (thanks to Pallav Nadhani):

1. Growing an existing market vs Category creation
2. Create value and capture now Vs create value and capture in the future
3. Competitive Scenario: switch vs new (greenfield vs brownfield)
4. Potential to build further adjacent products for same customer
5. Access to prospects/users/customers for validation

Customer Benefit Roadmap (8-18 months max)

This is for your sales team to share with customers who have already signed, or are close to signing. Typically for mid-market to enterprise. Think $50K+ ACV where the buyer is a Director/VP, and the product usage spans multiple years. NOT for SMB.

It will have a very narrow set of benefits that the entire company is committed towards. How you achieve those is not fully specced out, but the broad contours must be visible both to your lead engineer, and to your sales guys. You will essentially be playing here to ensure your next year renewal, and to increase the 2nd year contract value with that customer.

Don’t make promises you can’t keep. Don’t make promises you want to keep a secret from your competitors. This deck WILL get shared. This should be very pretty, iterated once in 6m at most.

This roadmap should also be carefully considered from a team messaging perspective, and a timeline perspective. Stay conservative, and have as little as is enough to give people confidence in the future. The internal risk is that people will get attached to this roadmap. Ideally, since only your PM & Sales lead are working on this, everyone else can stay uncommitted on this one.

Fine-grained problem roadmap (12–16 weeks)

[[ This is for larger teams. If you’re smaller, fold it into the next one ]]

Your product manager identifies specific sub-problems to solve for your customers, maps the RoI in solving the problem, the business benefit to your startup in solving that problem, the metrics to track to verify success of both.

1. RoI for the customer should be quantified as well as possible — $, hrs, etc.
2. Metrics should be specified well and instrumented before the feature goes into production. Input metrics, consumption metrics, output metrics.
3. Business benefit to startup. Can be increased TAM, i.e., new market, increased ARPU, reduced churn, increased referrals, etc. These may not directly benefit the customer, for instance adding referral popup on ‘customer success event’

Fine-grained feature roadmap (4–8 weeks)

Finally the classic product roadmap, but not more than 4–8 weeks of visibility, i.e. 2–4 sprint cycles at most. Here is where the devs, UX, and PMs work together to identify different solutions to a particular problem that’s in the problem roadmap, see how they vary in impact and effort. This may include multiple different approach wireframes. A choice is made through quick iterations between the UX->Dev->PM. And since most of the thinking is still in the problem domain, with an expectation of multiple solution possibilities, there is little attachment to a specific solution. This picked solution then goes into the fine-grained feature roadmap for the sprint, and gets into the product.

You want this roadmap to be short for 90% of your features. For the 10% that are cross-product, solving BIG problems, it’s ok to have specs across a longer time.

Pitfalls

Any roadmap tends to get outdated over time. People get attached to and fall in love with designs, solutions, and features. Exposing roadmaps creates expectations within the team and with customers. You will lose credibility if you walk back the roadmap one too many times. Take care in setting expectations before revealing your roadmap. No roadmap in a startup is set in stone.

When this works well

Imagine a specific customer asks for a particular problem to be solved earlier. Your sales person agrees to solve it, in the next quarter time-frame. This moves from your coarse problem roadmap to your fine-grained problem roadmap. When it comes to the fine-grained feature roadmap, your PM now maps the problem in more detail, works with multiple customers, specs everything around the problem. Whooops, that customer has already churned out for unrelated reasons. You are not attached to the solution yet, so it gets kicked back into the coarse problem roadmap.

As a founder you keep trying to understand the market better. Let’s say a new platform arises in your market, providing access to the market in a coherent way, that was not possible before. Since the Coarse Problem Roadmap keeps you in the problem domain, you see the possibility of solving some of your problems with the new platform, with the solution becoming easier/faster/cheaper to implement. You move this into the fine-grained problem roadmap for your PM to pick up. Many founders who get stuck in the ‘solution-domain’ would see this platform as a competitor, rather than as a partner.

So there you have it. Keeping different Problem, Benefit, Feature roadmaps, help you navigate B2B SaaS PMF while keeping customers, PMs, and developers sane.

Inspired by

Rethinking the Product Roadmap

The Problem Roadmap: Only build what matters to customers

___

Thanks to Pallav Nadhani, Paras Kuhad, Paras Chopra, Nitin Goyal, for reading drafts and suggesting changes

_________

Upekkha is an accelerator for B2B SaaS startups to help get founders from $100K ARR -> $1M ARR

This story is published in The Startup, Medium’s largest entrepreneurship publication followed by 336,210+ people.

Subscribe to receive our top stories here.