Why I stopped using product roadmaps and switched to GIST planning
Over the years I created my fair share of product strategies, roadmaps and project gantts. I don’t use them anymore. Here’s why:
See the problem? Yeah, it’s a waterfall (different from the famous project waterfall), meaning there’s almost no room for agility - changes at the top cause huge ripple effects of replanning and project cancellations at the bottom. It’s also a ton of work to do this type of planning (just getting all stakeholders to agree is a massive undertaking), yet ROI is very low. The plans quickly go out of sync with reality - the longer they are the more they are wrong. It took me awhile to realize that my yearly roadmaps and multi-quarter project gantts were already outdated the day I published them. And then there was the impact on innovation. As the roadmap allows only for a few big projects we had to prioritize and kill many potentially good ideas upfront. In top-down orgs the winner ideas come from management or from high-status individuals. In bottom-up orgs getting your idea to win became a very big deal, hence pitching, salesmanship and hype are now mandatory product management skills. To me it all felt very mid-20th century.
So, what’s the alternative?
This is a planning system that I started using while working at Google and further adapted over the years based on the principles of Lean Startup and Agile Development. I’ve introduced it to multiple companies and the results are very consistent — lightweight plans that are built for change, lower management overhead, improved team velocity and autonomy, better cross-company alignment and ultimately better products and solutions.
The system is called GIST after its main building blocks: Goals, Ideas, Step-projects, and Tasks. Each has a different planning horizon and frequency of change, and may use different tools to track, but together they constitute all the core planning any company and team needs to do.
I will do a longer post on each part of the system. Below is an overview.
“If you tell people where to go, but not how to get there, you’ll be amazed at the results” George S. Patton.
Most strategy plans commit a cardinal sin - they specify solutions (use technology X, partner with channel Y, launch country Z) rather than objectives. Any modern army general will tell you this is backwards - you give the troops objectives and let them figure out ways to accomplish them (the principle of Mission Command). This method is more empowering, requires less managerial overhead and is far more robust - solutions may come and go based on the situation in the field, but the objectives stay the same.
Goals embody this same principle - they describe the company strategy in terms of desired outcomes: where we want to be, by when, and how will we know that we got there. Whenever anyone in the org is is wondering “why are we doing this project?” a goal should give the answer. I became most familiar with goals at Google where every quarter we meticulously spelled out our goals in the form of Objectives and Key Results (OKRs), but there are others good tools as well. Some think this is one of the keys to why Google became so successful.
If you want to have good ideas you must have many ideas. Most of them will be wrong, and what you have to learn is which ones to throw away -- Linus Pauling
Ideas describe hypothetical ways to achieve the goals. There can be many ideas to achieve any given objective, but at most only 1 in 3 will deliver a positive result (often the ratio is far worse). The ideas of experienced leaders, product managers and designers don’t have a better success ratio than the average.
For these reasons in GIST we never kill ideas upfront, put them into a prioritization deathmatch, favor management ideas, or choose the ideas that are most hyped/pitched/politicized. This is what we do instead:
“Think Big but Start Small” Google - The 8 pillars of innovation
It’s tempting to pick a promising idea, turn it into a 9-18 month project and start executing. This is a common mistake and a very costly one - spending quarters, or even years on a yet unproven idea is likely throwing good money in the bin because most ideas just aren’t worth the investment.
Instead we break the bigger project behind the idea into small step-projects, each no more than 10 weeks long, and execute them one at a time.
In accordance with Lean-Startup’s Build-Measure-Learn principle, each step-project is actually an experiment that puts a somewhat more complete version of the idea in front of more users for a longer duration of time. A simple progression could be - mockup -> prototype → MVP → dogfood → beta → Launch. The end product is usually profoundly better than the one we imagined initially, as I explained in this post.
Because step-projects are so small we avoid all the nasty side effects of long projects and we are able to test many more ideas in parallel with lower investment and with quicker learning. Ideas that don’t work get dropped early, ideas that do get more investment. No need for pitching or politics. It’s hard to overstress how liberating and enjoyable it is to be able to come up with an idea and see it come to life and tested in a matter of weeks no matter who you are in the org.
Finally, each step-project is broken down to bite-size activities which we call here Tasks. This part of the system is well covered by agile planning tools, kanban boards and other modern dev project management techniques. Nothing needs to change at this level. The only difference is that the layers above are now agile as well and ready for change.
Planning with GIST is multi-tiered and iterative:
In the example above the team is working in parallel on four ideas pertaining to two goals. Idea 2 already had step 1 and 2 complete successfully. Idea 3 failed already in its first step-project and is therefore dropped, making room to do more work on the other 3 ideas.
Roadmaps are usually used for these purposes:
GIST is not a radical new idea - rather an amalgamation of ideas and methods that have been around for years, but often live in separation.The key difference is that it addresses all layers of the planning stack and creates a living system that is built for change.
The key principles are: