The Golden Path [AKA key user journey or the steel thread] is the key set of steps that a user takes to find a product's real value. This path should be the ideal default and shouldn't focus on exceptions or errors.

During a Google Ventures Design Sprint, stakeholders map out the Golden Path. This is the bedrock of a good prototype and the tests you'll run to validate your problem/solution statement.

It's imperative that we get this right, and I spend a painstaking amount of time on it.

Why?

Because you have to nail the core value before you can diverge, detail the solution, and innovate. Once you nail this, you can diverge easily in the next steps of the Design Sprint as you iterate screens, design elements, and other minute details. If this isn't ironed out, aligned on, I’ve discovered that we tend to get further, and further away from the crux of the solution we are building. The core golden path prototype helps product leaders test 3 things:

a. Why will we win in the market place? Represented by testing the golden path prototype with experts, advisors and even investors. Sell your vision before you build it.

b. Is this useful? Test with buyers and decision makers. Sell your solution before you make it.

c. Is this usable? Given usefulness is it easy to use and does the problem resonate with users?

What is this article all about?

I refer to what Albert Einstein said with such clarity: “Any darn fool can make something complex; it takes a genius to make something simple. While I’m no genius, simplifying the - Golden Path is a crucial first step to building a prototype, minimum feature sets, and eventually launching the product or the feature.  

The key difference in a golden path vs a design centric customer journey map is in the fact that a golden path is a lightweight journey so you don't focus a whole lot on thinking, doing feeling part of customer journies - you leave that to testing and observing vs excruciating effort spent on user research.

Common mistakes when designing the key user journey

I frequently find that we (and by that I mean all entrepreneurs trying to launch the next earth-shattering solution) often do the following:

•   Do solution-based designing instead of a user/job-story-based designing

•   Start left to right (with a non-trivial first-step like Log In) instead of imagining the end outcome or critical user moments

•   Complicate what each step is supposed to do as opposed to simplifying it

An example. In a recent interview with a candidate for a product manager role, I asked her to map out the user journey for a food delivery app. Unsurprisingly, she started with: “Log in.”

What’s wrong with that? “Log in” keeps the solution at the center of your key user journey. It doesn’t add any real value to the user.

So, where do we start? Work Backwards!!

Working backwards is the bedrock of Amazon's business - starting with the end in mind is simple change in mindset.

Not sure how to use this within this context?

Remember Dr. Strange from Infinity Wars. He “is meant to be the best of us,” after all. [SPOILER ALERT]

Towards the end of the Infinity Wars movie, when asked what he was doing, he said:

“Went forward in time to view alternate futures, to see all the possible outcomes of the coming conflict”

In those few seconds, he saw 14,000,605 alternate futures, and he identified the one in which they won.

Now imagine if he had started with Thor not regaining his power, or Star-Lord not finding out about Gamora’s death. How many paths would he have to go explore significantly before figuring out (1) which path actually leads to the desired outcome, and then (2) what is crucial to tread that path?

He didn't start at “Log in;” he started with the end state, the outcomes.

And that is where we should be starting. With the end state, the ideal outcome we want. Otherwise, we waste precious stakeholder time by going down rabbit holes that ultimately might not lead to the right outcome.

Deconstructing Avengers’ Golden Path to victory

Step 1: Create a story-based narrative with the user at the center. You start with a backstory. Give your user context so that you don’t deviate. For a food delivery app, it is: Aliyah had a long day at work and didn't have time to cook dinner. For Avengers,

“Thanos has wiped out half the earth’s population. The Avengers are scattered. Thanos has all the infinity stones and it is critical to reverse the damage."

Step 2: Identify the main job to be done. Next, you get clarity and alignment on the main thing that has to be done. For a food delivery application, this is: “Get food delivered.”

Reverse (Verb) the damage (Object) that Thanos has unleashed (Qualifier)

Step 3:  Work backwards; begin with the end in mind. Start with the outcome, right side first. This is unnerving because we are automatically tuned to start on the left, with what we know. We know “Log in.” At this stage, the exact end state might be undetermined fully; and that’s alright. It will be close enough because your product exists to create one critical value: what is that? For a food delivery app. it is - Order food.

For Avengers, it is: “Kill Thanos with finality.”

Step 4: Figure out a non-trivial starting point. Now, you can come back to the left and work your way to that conclusion. What we know, and our entrepreneurial team knows heuristically, is this: the only way to overpower Thanos is to get to the stones and use them to finish him off, once and for all. For that, the living Avengers will need the stone. What’s Step No. 1? This is where End Game starts: Unite the living Avengers.

For the food delivery app, this will be: identify food to order.

Step 5: Outline each step using Verb, Object, and Qualifier. One after the other, detail each step that'll get you to the end outcome. For clarity, each step should be written with the user in the first person and using the simple syntax of Verb + Object + Qualifier. That, too, the Qualifier should be used only when essential. For example, “Acquire stones” doesn't need a qualifier. Kill Thanos (well, he’s been killed before and he keeps coming back!!) so permanently is pretty crucial to the storyline.

Identify timeline moments with infinity stones → Travel back in time → Acquire stones → Build gauntlet → Bring people back to life

With the starting point and the end state, you can simply use Crazy 8 to identify the steps to solve the problem.

For the food delivery app, this might look like:

Select restaurant → Add food to the cart → Make payment → Get confirmation from restaurant → Track delivery

While Crazy 8-ing these steps [Refer to my notes on Crazy 8 here], your stakeholders might argue: Is getting confirmation really that important? Is tracking the actual delivery critical to the value you are offering? A simple voting exercise can help you get alignment there, allowing you to move on to the next step.

Lessons learned, internalized, and replicated with success innumerable times‍

Step 6: Find the “Aha!” moments. Like starting with the outcome, the design phase for the screens should also start with the most crucial moments. You want to identify those moments because they will create and deliver the maximum stickiness with your users. For a food delivery person, it might be the ability to filter based on cuisine preference. For Avengers, I know it was when Iron Man snapped his fingers to bring all the other Avengers back.

Step 7: Diverge, reimagine, sketch, and prototype the solution for the aha moments. Proceed at will! Voila, sketch, and prototype the aha moments to follow up with the rest of the steps to test your product with investors, customers, and your mom.