ZEMOSO PRODUCT STUDIO
June 14, 2022
6 min read

How to remix Amazon’s Working Backwards with Google’s Venture’s User Journey: The Dr. Strange Way

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.

Google Ventures Design Sprint: The Golden Path
Example of a lightweight Golden path from GV design sprint

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

No alt text provided for this image

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.

No alt text provided for this image
ZEMOSO PRODUCT STUDIO

How to remix Amazon’s Working Backwards with Google’s Venture’s User Journey: The Dr. Strange Way

June 14, 2022
6 min read

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.

Google Ventures Design Sprint: The Golden Path
Example of a lightweight Golden path from GV design sprint

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

No alt text provided for this image

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.

No alt text provided for this image
Recent Publications
Actual access control without getting in the way of actual work: 2023
Actual access control without getting in the way of actual work: 2023
March 13, 2023
Breaking the time barrier: Test Automation and its impact on product launch cycles
Breaking the time barrier: Test Automation and its impact on product launch cycles
January 20, 2023
Product innovation for today and the future! It’s outcome-first, timeboxed, and accountable
Product innovation for today and the future! It’s outcome-first, timeboxed, and accountable
January 9, 2023
From "great potential" purgatory to "actual usage" reality: getting SDKs right in a product-led world
From "great potential" purgatory to "actual usage" reality: getting SDKs right in a product-led world
December 6, 2022
Why Realm trumps SQLite as database of choice for complex mobile apps — Part 2
Why Realm trumps SQLite as database of choice for complex mobile apps — Part 2
October 13, 2022
Testing what doesn’t exist with a Wizard of Oz twist
Testing what doesn’t exist with a Wizard of Oz twist
October 12, 2022
Docs, Guides, Resources: Getting developer microsites right in a product-led world
Docs, Guides, Resources: Getting developer microsites right in a product-led world
September 20, 2022
Beyond methodologies: Five engineering do's for an agile product build
Beyond methodologies: Five engineering do's for an agile product build
September 5, 2022
Actual access control without getting in the way of actual work: 2023
Actual access control without getting in the way of actual work: 2023
March 13, 2023
Breaking the time barrier: Test Automation and its impact on product launch cycles
Breaking the time barrier: Test Automation and its impact on product launch cycles
January 20, 2023
Product innovation for today and the future! It’s outcome-first, timeboxed, and accountable
Product innovation for today and the future! It’s outcome-first, timeboxed, and accountable
January 9, 2023
From "great potential" purgatory to "actual usage" reality: getting SDKs right in a product-led world
From "great potential" purgatory to "actual usage" reality: getting SDKs right in a product-led world
December 6, 2022
Why Realm trumps SQLite as database of choice for complex mobile apps — Part 2
Why Realm trumps SQLite as database of choice for complex mobile apps — Part 2
October 13, 2022
ZEMOSO PRODUCT STUDIO
June 14, 2022
6 min read

How to remix Amazon’s Working Backwards with Google’s Venture’s User Journey: The Dr. Strange Way

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.

Google Ventures Design Sprint: The Golden Path
Example of a lightweight Golden path from GV design sprint

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

No alt text provided for this image

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.

No alt text provided for this image

Recent Publications

ZEMOSO ENGINEERING STUDIO

Testing what doesn’t exist with a Wizard of Oz twist

October 12, 2022
7 min read
ZEMOSO ENGINEERING STUDIO

Beyond methodologies: Five engineering do's for an agile product build

September 5, 2022
6 min read
ZEMOSO ENGINEERING STUDIO

How we built a big data platform for a futuristic AgriTech product

June 3, 2022
8 min read
ZEMOSO NEWS

Zemoso Labs starts operations in Waterloo, Canada

May 25, 2022
5 min read
ZEMOSO ENGINEERING STUDIO

Honorable mention at O’Reilly’s Architectural Katas event

May 17, 2021
5 min read
ZEMOSO ENGINEERING STUDIO

Product dev with testable spring boot applications, from day one

May 4, 2021
5 min read
ZEMOSO ENGINEERING STUDIO

When not to @Autowire in Spring or Spring Boot applications

May 1, 2021
5 min read
ZEMOSO ENGINEERING STUDIO

Efficiently handle data and integrations in Spring Boot

January 24, 2021
5 min read
ZEMOSO ENGINEERING STUDIO

Our favorite CI/CD DevOps Practice: Simplify with GitHub Actions

October 25, 2020
5 min read
ZEMOSO ENGINEERING STUDIO

How to use BERT and DNN to build smarter NLP algorithms for products

February 14, 2020
12 min read
ZEMOSO ENGINEERING STUDIO

GraphQL — Why is it essential for agile product development?

April 30, 2019
12 min read
ZEMOSO ENGINEERING STUDIO

GraphQL with Java Spring Boot and Apollo Angular for Agile platforms

April 30, 2019
9 min read
ZEMOSO ENGINEERING STUDIO

Deploying Airflow on Kubernetes 

November 30, 2018
2 min read
ZEMOSO PRODUCT STUDIO

How to validate your Innovation: Mastering Experiment Design

November 22, 2018
8 min read
ZEMOSO PRODUCT STUDIO

Working Backwards: Amazon's Culture of Innovation: My notes

November 19, 2018
8 min read
ZEMOSO ENGINEERING STUDIO

Product developer POV: Caveats when building with Spark

November 5, 2018
2 min read

Want more best practices?

Access thought-leadership and best practice content across
the product development lifecycle

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

© 2023  Zemoso Technologies
Privacy Policy

Terms of Use
LinkedIn Page - Zemoso TechnologiesFacebook Page - Zemoso TechnologiesTwitter Account - Zemoso Technologies

© 2021 Zemoso Technologies
Privacy Policy

LinkedIn Page - Zemoso TechnologiesFacebook Page - Zemoso TechnologiesTwitter Account - Zemoso Technologies
May 25, 2023