How to build a roadmap for early market products selling to technology enthusiasts and visionaries

I failed to build the right type of roadmap multiple times. I have got it wrong with a startup of 4 and with a team of 12 product managers and 180 engineers. There are many things to get wrong, and it all starts with failing to understand the maturity of your product and the type of roadmap you need.

We have all seen what a product roadmap looks like. A bunch of features spread over a timeline with a promise to deliver them someday. If your role is a startup founder, product manager, software developer or somebody who needs to guide a team on what to build, it’s inevitable to dive into the world of roadmaps.

It’s hard to ignore the constant stream of thought leadership and know-how on how to build a roadmap. Roadmap companies are teaching you how to build the most agile, lean, aligned, detailed, and communicated roadmap connected to strategy AND execution at the same time. Timelines, milestones, releases, personas, segments, initiatives, OKRs, epics, features, stories, requirements, and checklist are all there. Ready to pivot together and deliver the most complicated visual graph you will ever produce.

But nobody is telling you when, how and why to build a roadmap.

A product roadmap communicates the direction, strategy, and tactics of your product, but building one is not easy and sometimes not needed. The definition of roadmap changes as your product matures, and you might easily mess up your product by building the wrong type of roadmap with a bunch of artifacts and details that you don’t need.

Before you build any kind of roadmap, you need to understand the maturity of your product and market.

Understand the maturity of your product first

How mature is your product? When I say “mature” I don’t mean how much time you have spent building it. You might have a product in the works for years which still is very immature and rarely used. To determine the maturity of your product, it’s best to ask the question: Who are you selling to?

Determining the type of customer to whom you are selling today is not just a good indication of the maturity of your product, but it can also reveal the maturity of your market category. And we know that nobody is bigger than the market, so it’s important to acknowledge that and be honest about it. The easiest way to do that is to look at the technology adoption lifecycle by Geoffrey Moore that goes along the lines of this.

1. You have some customers, and you are doing a lot of sales demos and presentations, but feasibility is often discussed and customers are buying despite lack of reference and proven ROI. Almost zero of your customers found you, you found them. Your product is in the Early Market category and your customers are Visionaries.

2. You got several big logo customers, but most of the deals don’t close, and those that do close are for pilot projects rather than full-scale adoption. It’s because a) your product is not 100% ready to sell itself without you dropping the word “roadmap” or “coming soon” during a sales call to save the day and b) your customers are asking for several strong references in their industry or even more scary — references from their competitors. Your product is in the Chasm and you are trying to sell to Pragmatists.

3. A specific segment of customers is actively buying your product, and sending you over their friends to buy your product as well. Your sales are growing 50%+ year over year, and you are constantly introducing and winning new customer segments. Congratulations! Your product is in the Mainstream Market and you are selling to Pragmatists.

4. Your growth is slowing and is mainly driven by renewals and repurchasing from existing customers. They view your product as a reliable and safe choice compared to newer technologies that look attractive but risky and unproven. You are in the Mainstream Market and you are selling to Conservatives.

5. The last one is pretty obvious. The customer is your grandfather who refuses to buy a smartphone for years until there are no more feature phones on the market, and he is forced to ACCEPT one as a present for Christmas. You are in the Mainstream Market and you are selling to Skeptics.

With that knowledge, let’s figure out what are the most important aspects of your product roadmap.

Procrastinate putting your “killer” features on your roadmap when selling to technology enthusiasts

When you manage to acquire your first customers they are most likely technology enthusiasts and you are in a hackathon mode. You are searching for your product/solution fit. You move fast and break things. This is the most productive phase of your product lifecycle and you can afford to make big swings and take giant leaps in your vision. Don’t waste your time to build a timeline roadmap and never, ever, ever put your “killer” feature anywhere near a roadmap. One of the important pitfalls to avoid is to resist the temptation to put future improvements of your “killer” feature in a roadmap. Because as soon as you set that on the roadmap, your innovation will stall and you will get into your delivery rhythm.

A roadmap helps you iterate over existing ideas. Innovation happens when you are building a product, not a roadmap. It’s easy and convenient to get yourself busy with hundreds of incremental iterations on top of one core idea. But if you want to be on the forefront, you need to combine iterations with reinventions.

To illustrate that, when we were building Darvin.ai (now Progress Kinvey NativeChat), we had to figure out a way to sell our product beyond technology enthusiasts. Developers wanted a way to easily create “smart” chatbots, and most of the (500+) competitors had a visual drag & drop way to build the intelligence. We could have easily jogged down a roadmap after our first 3 Google Sprints on what to build, but we knew that we didn’t have a killer feature that will help us stand out among the crowd and help us win customers in the long-term.

One of the most productive things we did at that stage was to procrastinate building a roadmap. We knew that if we build a roadmap we will be busy delivering on it. And the first features that come up from your customer validation are the obvious ways to solve the customer problems. But remember, you and 50 other product managers talk to the same type of customers at the same time.

And because your first ideas are the most conventional, it’s only through a huge amount of input from customer conversations and procrastination that you will arrive at a different station than your competitors.

While procrastination is a vice for productivity, I’ve learned — against my natural inclinations — that it’s a virtue for creativity. — Adam Grant

After 2 months of hacking and building a few chatbots the “regular” way, we identified that the biggest selling point of our competitors was their biggest weakness. Using drag & drop, you end up creating a decision tree that the chatbot needs to follow. So instead we created a patent-pending CognitiveFlow™ technology (Jan 31, 2018, US 62/624,594) that uses a declarative programming language to create conversational intelligence for a chatbot without the need to build decision trees using drag & drop or imperative languages such as .NET, Java or JavaScript. Or in more simple words, no need to predefine your chatbot conversations step by step, but rather focus on the outcome of a conversation only.

Decide on speed vs. quality for every feature when you get to visionary customers

You have identified a problem that resonates with your future customers and you believe there is a significant market opportunity to build a successful business on top of it. At that stage, it’s meaningful to have 4–6 weeks outlook ahead on what you plan to build.

But let’s be honest, your MVP is most likely a single killer feature with some administrative fillers around it. If you put a roadmap together it will be a combination of two things:

• Future ideas and improvements on top of your “killer” feature.
• A laundry list of administrative and supporting features such as multi-tenancy, better onboarding, integrations and so on.

Again, it might sound strange and very counter-intuitive but you still don’t need the first one, but you kinda need the second one. Keep hacking your killer feature as much as possible until your product is selling faster than you can build it. As for the rest of the features you have to make a tradeoff.

The most tricky thing is to decide how much you should invest to call a feature “done” at this stage.

Do you ship it rock-solid (done, done) with zero technical debt which usually takes 3 to 4 times your initial estimate? Or do you ship it, test it, and throw it away? At Payhawk, we use both approaches at the same time using a very simple rule of thumb. When a given feature is planned for implementation, the team decides on a speed vs. quality grade.

Speed — We have low confidence in how customers expect this feature to work, so let’s build this feature in a hackathon mode. Ship it fast, get quick feedback and throw it away.

Quality — We are pretty certain on how customers expect this to work, invest more time and ship it with almost no-technical debt.

Tip: For our roadmap, we use productboard with a custom Speed/Quality driver that is reviewed before a feature is scheduled for implementation.

Why is the speed vs. quality grade so important? Product people and engineers alike hate to ship things that are half-baked. You will not only keep your team on the same page but encourage everyone to experiment along the way. Use this roadmap approach until you get to a repeatable business model and you build enough customer success stories. Today, many successful products don’t do “marketing launches” until they are past that phase.

But our customers, investors or sponsors want a roadmap

If you are selling to early markets and your customers are insisting on a timeline roadmap before they buy, it means you are not solving a burning problem for them. Get back to the drawing board (but hang on for this post, we are almost done) and hack your way to an MVP that solves a burning problem of your audience.

If you are working for an existing organization trying to bootstrap a new product, the senior management will constantly ask you for one. You can always stick to a horizon roadmap that has no dates and doesn’t include anything for your “killer” feature. If there is a big pressure for a detailed timeline roadmap, you can always send them this article and quit.