Any time you’re planning, spend some time working backwards. Ask “what’s the key state I’m aiming for?”, then ask “what unlocks or enables that?”. And repeat.

A value stream with question marks in it

It doesn't matter whether you're planning a tiny meeting or a huge project. By working backwards you're more likely to meet your goal. This is also a great coaching technique.

The problem with working forwards

If you work forwards you anchor your plans to the start rather than end point. You might plan the first few steps clearly then hope to adapt as you go. Or you might take a standard process—double diamond or design sprint—and see where it takes you.

But there are problems with this approach:

  • Team alignment: You and your collaborators might have different opinions on the nature of the end state you're aiming for.
  • Guidance: Your plan might not even get you to the end state. A tiny error in a rocket’s start angle means a huge difference where it finishes. A clear end state works like a guidance system.
  • Efficiency: Even if your plan gets you to the right place, you might over-deliver and take longer than needed. For instance you might research more areas than necessary, or design more scope than the MVP requires.
  • Trust: If you justify your actions only by pointing to a standard design process your collaborators might have a hard time seeing the intrinsic value of each step.

First pick an end state

This technique relies on having a clear end state. And bad news: that's a whole challenge that's outside the scope of this article. Just make sure it's something clear and valuable.

If your project is naturally open-ended, (e.g. product discovery), see the addendum about planning exploratory projects.

Now make a plan

Begin with the end in mind by writing it down.

Confidence in risky features X,Y,Z

Then ask: what does this end state depend on? Just focus on the necessary inputs to this final state.

Test features X,Y,Z with users

Now work backwards again. In the example below the next two things can be done in parallel with no dependency between them. So maybe you can delegate one to someone else.

Prototype features X,Y,Z and recruit people who might use X,Y,Z

Keep going until you find something you can do immediately, and you should have a plan that achieves the end state without over-delivering and taking more time than necessary.

Select concepts to test

You don't need to abandon design sprints or the double diamond. You can use them as inspiration. If you work backwards you'll know how to adjust those processes to the specifics of your project.

Now check this plan with your collaborators. Do they agree with the end state? Do they agree with each link in the chain being just enough to enable the next?

When to apply this mindset

  • Plan meetings by asking “what do we want to get out of this meeting?” and work backwards from there.
  • Plan workshops by asking “what will the output of this workshop be used for?” and then make the workshop laser-focussed on delivering exactly that value.
  • Plan user research by asking “what do we need to learn, with what confidence and how quickly?” and work backwards to decide how you can learn that.
  • Plan design projects by asking “what decisions will this design be used to make?” To get an estimate? To get something prioritised? To get feedback from users? To unblock engineering? The answer will help you decide the design's scope and detail.
  • Develop products or features like Amazon does by starting with a press release. This helps clarify the intended value, scope, and roll-out plan. This is similar to Readme-driven development from Github founder Tom Preston-Werner.
  • Innovate like Steve Jobs and “start with the customer experience and work backwards to the technology”.


You can help others plan by leading them through this technique. You ask the questions (“what's the end state?” “what's necessary to unlock that?”) and the coachee figures out the answers for themselves. You should end with a more robust plan for the coachee. And you'll learn how they perceive the project.

Why does this work?

Working backwards creates a pull-based system. Control flows from right to left. The final action signals that it needs something from the previous action, and so on. This is the foundation of lean manufacturing where items are produced on demand with very little waste.

In contrast, if you work only forwards you’re using a push-based system with control flowing the other direction. You do some action, and the result informs and constrains the next action. This could be appropriate if you haven't determined an end state and want to keep your options open. But you might research or design more than you actually need. Or fail to research an important aspect. See the addendum for a better approach.

In conclusion

Thinking of your plans as a value stream1 where each action unlocks the next downstream action can help you shed waste all along the chain. It will help you and your team get more aligned on the destination as well as the journey to get there.

Addendum: Planning exploratory projects

The principles of this article still apply when planning something with uncertainty built-in. The plan can reflect that uncertainty by leaving intentional question marks and varying the granularity. Here's an exaggerated example.

Exploratory planning

If your ultimate target is “happier users” you'll realise this depends on “understand why users aren't happy”. Now you've got a key milestone to treat as a sub-project with a detailed plan. Everything else can be left low detail until you've learned more. It's still in context of the higher-order plan pulling you towards happier users in this case.

See the Toyota Improvement Kata for a more codified version of this2. The key milestone above could form a target condition.

  1. See “The place of UX” from Basecamp's Ryan Singer for another take on UX as a component in a value chain. 

  2. Or What is Good Product Strategy? from Melissa Perri for a Product Management take on the Toyota Kata.