Draft for Ashley’s editorial review. Examples are illustrative unless otherwise attributed.
Plans that start at the beginning drift
Most plans begin with what is available today: the channels we already use, the features already on the roadmap, the campaign we ran last year. Each step makes sense on its own, yet the sequence rarely arrives anywhere specific. Activity accumulates. The outcome stays vague.
Reverse engineering flips the direction. You begin with a clear description of the result you want, then ask, step by step, what must be true just before it. The plan becomes a chain of necessary conditions rather than a list of things you could do.
Write the finish line as a scene
Describe the outcome as something you could observe, not a slogan. “Grow retention” is a wish. “By the end of March, most new customers who start a project in their first week finish it and start a second one” is a finish line. It names who, what behavior, and by when.
Add how you would know. Which record, conversation, or measure would show this has happened? If you cannot name one, the outcome is not yet defined well enough to plan backward from it.
Start with the finish line. Then ask what had to be true the day before.
Ask “what had to be true the day before?”
From the finish line, take one step back. For customers to start a second project, they must have finished the first and seen a reason to continue. For them to finish the first, they needed a clear starting point, enough guidance to reach a useful result, and few reasons to stall.
Keep asking until you reach something you can influence this week. Write each condition on its own line. The result is a backward chain from outcome to present, and it often reveals that the real constraint is several steps earlier than the problem everyone is discussing.
Separate conditions from tactics
A condition is a state of the world: “new customers know what a finished first project looks like.” A tactic is one way to create it: a sample project, a short video, or a check-in call. Keep them apart. When a tactic fails, the condition stays on the map, and you can try another route to it.
Mark each condition with what you know. Have you observed it, heard it reported, or are you assuming it? Assumptions near the start of the chain deserve the earliest tests, because everything downstream depends on them.
Choose the first move
Look at the earliest condition that is both uncertain and important. That is your first move. Design the smallest test that would show whether you can create that condition, name a signal you would expect to see, and set a date to review it.
Reverse engineering does not guarantee the outcome. It makes the path explicit, so every result, good or bad, teaches you something about a specific link in the chain instead of leaving you wondering what went wrong.
