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:

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. 

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 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. 

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.

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

The post Feature-driven Roadmap vs Experiment-driven Roadmap appeared first on ProdPad | Product Management Software.