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 do them anymore.

Here’s what I used to do:

Yeah, it’s a waterfall (different from the famous project waterfall), meaning that there’s almost no room for agility — changes at the top cause huge ripple effects of replanning and project cancellations at the bottom. We mostly solved project waterfall with Agile development, but we’re still stuck with planning waterfall which is just as bad. It’s 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 fancy roadmaps and project gantts were already outdated the day I published them. And then there was the impact on innovation and culture. As roadmaps allow 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. 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?

GIST

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.

Goals

“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 company Y, launch country Z) rather than goals. 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 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). Some believe that OKRs are one of the reasons for Google’s was so successful.

Example of Goals in the form of Objectives and Key Results

Ideas

“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. The key word here is hypothetical — there can be many ideas how to achieve a given objective, but at most 1 in 3 ideas 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:

• Collect all ideas in an Idea Bank, most commonly a spreadsheet or a database — all ideas are welcome and the bank can hold hundreds of ideas indefinitely.
• Prioritize using evidence — I like Sean Ellis’s ICE prioritization, but there are other methods as well.
• Put as many ideas as possible to the test in order of priority — that’s the job of Step-projects.

Step-projects

“Think Big but Start Small” — Google’s 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. For example: mockup → prototype → MVP → dogfood → beta → Launch

In accordance with Lean-Startup’s Build-Measure-Learn principle, each step-project is actually an experiment that tests the idea. In a successful progression we will in each step-project a somewhat more complete version of the idea in front of more users for a longer duration of time.

A real-world example of a project composed of step-projects

The end product is usually profoundly better than the one we imagined initially (see this post for an explanation why).

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 work get more investment. No need for pitching or politics. The ability come up with an idea and see it come to life and tested in a matter of weeks is incredibly liberating and enjoyable for everyone involved. You’ll never want to do another long death-march project again.

Tasks

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.

The planning cycle

Planning with GIST is multi-tiered and iterative:

• Goals are typically set for an horizon of one or more years — this is where we want to encourage long-term thinking. They are defined at the beginning of the year and evaluated and adjusted every quarter — we don’t want to pursue stale goals.
• Ideas are constantly collected and prioritized. We never stop looking for new ideas.
• Step-projects are defined at the beginning of the quarter. The team picks the goals and ideas it wishes to pursue this quarter, and defines step-projects accordingly. The quarterly step-project list (typically stored in a spreadsheet or database tool) is evaluated and reprioritized every 1–2 weeks, in sync with task iterations planing.
• Tasks are planned in 1–2 week iterations in per the teams’ preferred dev method, for example Scrum sprint planning.

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.

Do you still need roadmaps?

I believe you don’t. Roadmaps are usually used for these purposes:

• Work planning — hopefully by now I convinced you don’t want and don’t need roadmaps for this.
• Internal communication — My experience has been that coworkers and board members readily understand and embrace the language of goals, ideas and step-projects — it’s not a hard transition and they appreciate the realism and authenticity. Of course the entire planning system should be visible to anyone in the company and to the board.
• External communication — with customers and partners the expectation of a “formal roadmap” might be highest. As always it’s our job to move the discussion from features to underlying needs. With GIST you can give answers like “We have a goal to deal with in-product collaboration by end of Q3. I can’t say exactly how it will work yet — we’re considering a number of ideas and keeping things agile, but we should have an MVP by end of Q2. Would you like to be an early tester and give us feedback?” With any luck this will do the trick better than any roadmap chart.

Final Notes

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. It attempts to addresses all layers of the planning stack and creates a living plan that is built for change.

Key principles:

• No split of ideation, planning and execution — they all happen concurrently all the time
• Goals rather than vague strategy statements or solutions.
• Idea banks rather than product backlogs.
• Short sub-quarter step-projects rather than long multi-quarter/multi-year projects.
• No betting on just a few big ideas that take forever to implement — we test many ideas quickly and pursue the ones that work.
• Iterations — we revisit every part of the plan regularly and systematically and stay agile at all levels.

Itamar Gilad (itamargilad.com) is a product consultant and speaker helping companies build high-value products. Over the past 15 years he held senior product management roles at Google, Microsoft and a number of startups.

Why I stopped using product roadmaps and switched to GIST Planning was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.