‍

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 on 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:

• Why will we win in the marketplace? This is represented by testing the Golden Path prototype with experts, advisors, and even investors. Sell your vision before you build it.
• Is this useful? Test with buyers and decision-makers. Sell your solution before you make it.
• Is this usable? Given that it is useful, is it also 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 in 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. You don't have to focus a whole lot on the thinking, doing, and feeling parts of customer journeys. You leave that to testing and observation, rather than spending excruciating effort on user research upfront.

‍

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 from 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 achieve instead of simplifying it

For 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 backward is the bedrock of Amazon's business — starting with the end in mind is a simple change in mindset.

Not sure how to use this within this context?

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

Towards the end of the Infinity War 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.

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.

‍Start with a backstory. Give your user context so that you don’t deviate. For a food delivery app, it could be: Aliyah had a long day at work and didn't have time to cook dinner. For Avengers, ‍

“Thanos has wiped out half of 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, get clarity and alignment on the main task that needs to be completed. 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 naturally inclined to start on the left, with what we know. We know “Log in.” At this stage, the exact end state might be not be fully determined, 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 the 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 Stones. What’s Step No. 1? This is where Endgame starts: Unite the living Avengers.

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

Step 5: Outline each step using verb, object, and qualifier format.  

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. The Qualifier should be used only when essential. For example, “Acquire Infinity Stones” doesn't need a qualifier. "Kill Thanos permanently (because every time he's killed, he keeps coming back!)" is pretty crucial to the storyline.

Identify timeline moments with Infinity Stones → Travel back in time → Acquire Infinity 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.

Similar to starting with the outcome, the design phase for the screens should begin 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 app. user, 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 back all the other Avengers.

Step 7: Diverge, reimagine, sketch, and prototype the solution for the "Aha!" moments.

Proceed at will! Voila, sketch, and prototype the "Aha!" moments to and then continue with the remaining steps to test your product with investors, customers, and your mom.

‍