Skip to main content

Feature-driven Roadmap vs Experiment-driven Roadmap

November 12, 2020

4 minute read

Someone asked me the other day:

I’m wondering if roadmaps can cover experimental features, and how to balance that with launchable features?

I’d actually like to turn that around and make the point that the roadmap should entirely be driven by experiments, rather than features. Let me explain:

Feature Driven Roadmap

A roadmap that outlines a bunch of features to be built will result in… a bunch of features being built! That may be good or bad for the product, but typically any outcome that’s reached as a result of a feature-driven roadmap is reached somewhat unintentionally. 

Experiment Driven Roadmap

An experiment-driven roadmap is intentionally in its design. Each experiment, like any good scientist would expect, should be started with a hypothesis and expected outcome. With an experiment-driven roadmap, you’re essentially betting that if you run enough experiments, enough of them will work, and you’ll hit the overall outcomes you were hoping for. You’re stating upfront what you expect the outcomes to be.

Now an experiment on a roadmap can be a lot of things. Sometimes an experiment is to add a new feature. You bet that if you add this feature here, then people will pay you there. That’s something you can outline upfront, and measure success on. Ideally, you’re finding ways to minimize the work that has to go into that experiment to test that it’s going to work out for you. That’s why we don’t build the whole feature up front, and have a bunch of lean tactics for testing things at all the stages before you start spending precious development time on it. 

But an experiment doesn’t have to be a new feature at all. Sometimes it might be just changing a feature. Or taking a feature away. That’s a pretty sure bet for at least simplifying your user experience! 

And lots of experiments aren’t feature-related at all. You might experiment with positioning, as in how you talk about your product or what it does, or with pricing and packaging. You can often make a huge impact on your outcomes by not touching any features at all and still hit those all important business goals! 

The Lean Roadmap

The lean roadmap in ProdPad is designed to be experiment-driven. Each of the cards on the roadmap are initiatives, or problems to be solved. Each is connected to the objective, as well as to key results, so you know ahead of time what you’re measuring and what success looks like. Each of these cards then include any number of ideas, or what we consider to be experiments. Potential solutions or things you’ll try in order to solve the problem outlined on the card. 

Experiment-driven roadmap card
A roadmap card in ProdPad with multiple ideas attached

The roadmap isn’t a list of features, a list of things to do, it’s a product strategy. You don’t start at the top and work your way down. It’s a map of the problems you might solve and the ways you might go about solving them. As you try each experiment, you reflect the results back into the roadmap, whether it was a Success or a Failed Experiment. If you rack up enough successes, you might be able to move on to the next card early. If nothing’s working, you might need to work with your team to come up with other ways you might solve the problem, new experiments to try. 

If your experiments work, you might end up with features you can launch out there to the world! Each launchable feature should have a history of experiments that led to its creation, each experiment giving you further confidence that the final feature will in fact deliver on the outcome that was outlined in the experiment outline from the beginning.

Key Takeaways

So instead of thinking about your features as experimental or launchable, turn that around and think about your experiments as either features or something outside of that box. Your roadmap can and should include your experiments and help you track your path to the outcomes you’re looking for. 

How about you? How do you show experiments on your roadmap or elsewhere in your product workflow? Let us know in the comments below 👇

Sign up to our monthly newsletter, The Outcome.

You’ll get all our exclusive tips, tricks and handy resources sent straight to your inbox.

How we use your information

2 thoughts on "Feature-driven Roadmap vs Experiment-driven Roadmap"

  1. Hey Janna! I really liked how you applied the lens of ‘Initiatives as Experiments’ vs thinking of them as features. However, I may have a little follow-up thought here. An experiment by virtue of the word itself means a control and variation. In this case, taking it a level further, how do you propose testing these out? Is this a full launch and you compare before and after? Or is this a scaled launch, with first targeting a smaller segment? Curious to hear your thoughts around that.

    P.S. Loved the article and the way you articulated.

    1. Thanks for your input Ritika! 

      You’re absolutely right, an experiment should have a way to compare results between the expected and the actual, so you can actually see if an impact was made. There are actually a lot of ways of achieving this, and it’s important to remember that an experiment doesn’t need to be ‘launched’ in order to be tested.

      After all, you might be able to test quite a number of things with using basic protoypes or surveys or other ways to gather information. I always recommend starting with the smallest/cheapest test possible that tests the risky elements of whatever is being put forward. Most of the time, this means you can get away with not launching something straight away, but as early experiments start giving back more info, you can get closer to experiments that involve actually launching things and trying them in Beta or behind feature flags, or whatever is appropriate at that stage.

      I hope this helps! Happy experimenting 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *