Over the years I created my fair share of product strategies, 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:
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 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 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?
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.
Tickets are available for my Lean Product Management workshops:
Join me to learn how to use the modern tool-set of product management from strategy, through planning and execution.
“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.
“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:
“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 article 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.
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.
I believe you don’t. Roadmaps are usually used for these purposes:
Are you using GIST planning your company? If yes, I’d love to hear about your experiences as part of the research for my future book. I’d appreciate it very much if you could fill out this short survey.
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.
Update: as many folks us about tools to manage GIST, I published this post that covers some of the more common ways: https://medium.com/@itamargilad/the-gist-board-a-new-way-to-do-planning-and-execution-47ad3c0dd5d5
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.
If you prefer to receive posts like these by email sign up to my newsletter.
In this workshop I will walk you through the principles and tools of lean product management — how modern-day PMs drive business results and optimize for high impact. Early-bird tickets are available now.