Work backwards

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.

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.

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

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.

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.

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”.

Coaching

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 stream¹ 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.

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 this². The key milestone above could form a target condition.

---