PM Handbook @jabondano

Frameworks

Automations

Digital Marketing

PM Lectures & Videos

APIs

Explore

Frameworks

GIST vs Roadmaps

The GIST Board and Other GIST Tools

Why you should stop using product roadmaps and try the GIST Framework

Itamar Gilad⁠

⁠

Why I Quit Product Roadmaps

Over the years I created my fair share of product strategies, product roadmaps and project gantts. I don’t do them anymore. I found a better alternative which I’ll explain below.

First, here’s what I used to do:

⁠

The planning waterfall, and especially roadmaps, are a ton of wasted work.

⁠

This form of planning is a ton of work — 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 product roadmaps and project gantts were already outdated the day I published them. Also, it’s a waterfall (different from the famous

project waterfall⁠

), meaning that there is almost no room for agility — changes at the top cause huge ripple effects of replanning and project cancellations at the bottom. Agile development addressed project waterfall, but didn’t change planning waterfall. And then there’s the impact on innovation and culture. As product roadmaps allow only for a few big projects to be funded you have 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.

⁠

GIST, the alternative to product roadmaps.

⁠

I will do a longer post on each part of the system. Below is an overview.

⁠

Upcoming Workshops

To learn more about this and other product / strategy topic join one of my public workshops or get in touch to setup a workshop on your own company offices — see details in

my product management workshops page⁠

⁠

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 why Google is so successful.

⁠

Example of Goals in the form of Objectives and Key Results

If you prefer to receive posts like these by email

sign up to my newsletter⁠

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 (Impact and effort alone are

not enough⁠

!).

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 put 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 12-month 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, and adjusted daily.

⁠

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 product roadmaps?

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

Work planning — hopefully by now I convinced you don’t want and don’t need product 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 product 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 product 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 solutions or vague strategy statements.

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.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.