A Hero’s Journey: Building a Product
When we decide to create a product, we have to figure out the ‘why.’ What problems are we trying to solve? Why are we solving them? How is it different? Does this align with the goals of the business?
Establishing a Purpose
Bob wants to disrupt the way we approach tires for vehicles.
I am tired of cars with rubber wheels, they have to be changed too often, they are too expensive and cause massive environmental issues. I want to build a car that does not rely on rubber wheels!
Well Bob… that’s pretty aggressive. Magnetic drive isn’t quite there yet and car manufacturers won’t exactly get rid of wheels.
I want to create a wheel that goes against the status quo, that eliminates waste completely, matches the lifespan of the vehicle, and will be cheap to manufacture.
Nice Bob, that was beautiful… but a hell of a statement. What do you have in mind?
I’m in ‘magic land’ right now, we can worry about ‘the what’ later.
A Hero’s Journey
We are easily entertained by stories; we can often relate to them. Difficult concepts can be more easily understood in the context of a story allowing the audience to commit the data to memory. Designing product to a narrative is no different. You have a hero; the hero has goals and encounters conflict and discovers ways in which to achieve them. Breaking down the hero’s goals into stories and the stories into requirements is the first step to discovering opportunities and building out the narrative of your product.
Ok, back to Bob…
I need a team and I need a story.
Bob has a vision and it needs to be broken out before an engineer touches CAD, a scientist enters a lab, or a designer touches a pencil (or stylus…)
What are the end goals? What are my narratives for driving executionWho is involved and what are they doing?
If a slab is the foundation of a home, goals are the foundation of a project. We return to these when we question our motives and decision making. These goals align to established business values and the wants and needs of the marketplace.
These goals are then broken into stories.
If a hero’s journey is to save the queen, then his goal is normally greeted with a call to action, a conflict, a failure, a resurrection, and the journey home. These goals provide narratives into our hero’s journey, we break down these goals into stories and look for opportunities — like a missing scale in a dragon’s skin, begging patiently for an arrow.
Now we take the stories and attach requirements.
A Hero’s Journey Breakdown
Defining these requirements is often difficult and requires deep immersion into the hero’s wants and needs. Creating exhaustive narratives and documenting the hero’s journey from beginning to end will reveal details and insights easily overseen by making assumptions or being a ‘product expert.’ This will also illustrate and further define the business value and begin to shape out the wants and needs of the marketplace.
Let’s step away from Bob’s new tire idea and look at something we are more familiar with. The Amazon experience.
Our ‘Hero’s Journey’ we’ll now refer to as a ‘Hero Flow’
A Hero Flow is the quickest way to achieve success for a use case. All other flows are considered secondary and tertiary (and so on) use cases — with slight differences in accomplishing a story.
Here are two Hero Flows broken out into a narrative accomplishing the same story. Which one tells you more about Sarah’s requirements for a successful experience?
Sarah needs to buy a product. She will need a login screen, a marketplace screen, a product details screen and a payment and processing screen.
It’s Wednesday at 8:56pm and Sarah has 4 minutes to order a tent she forgot to buy for the weekend using Amazon Prime… because at 9:00pm all orders are processed the next day. She logs in to to her Amazon account using her normal credentials. She then goes to the search bar on top of the screen and types in ‘4 person tents’, she presses enter and a new page full of tents shows up. She navigates till she sees one in her price range, she quickly notices they are all incredibly expensive and filters her results using the filter control panel on the left side of the screen. After the page refreshes, she scans the page again. She clicks on the ‘Brown Coleman 4 Person Instant Cabin’ and to her amazement it comes in her favorite color — green. She quickly changes it to green and clicks add to cart and proceeds to checkout. It’s 8:58pm, “holy guacamole” says Sarah, all of her payment and shipping fields are pre-populated with the information she gave months ago, with no time to waste she clicks ‘Place your order.’ Something didn’t work… she reads ‘Payment failed, please select another form of payment’ — she’s flustered at this point, anxiety kicks in, and what’s worse… she may miss the beginning of Game of Thrones, but then remembers there’s three minutes of recap before the show starts… but did she leave the stove on? Did she leave Kevin home alone? “I have to focus” says, Sarah. She quickly navigates to ‘Payment Options’ and luckily she has a debit card on file, selects the radio button next to her debit card ending in 8938 and clicks ‘Update Payment.’ She clicks ‘Place your oder’ again — Success! She looks at the clock and to her relief it reads ‘8:59’. Just as she is getting up to get a late dinner she received an SMS notification reading ‘Your order has been processed, you will receive the package Friday.”
Now let’s create a requirements document for Sarah’s experience using the two stories just told.
And that’s just one story. Creating multiple stories will lead to better experiences — not only will everyone on your team understand Sarah better, they will know what the product needs to accomplish for Sarah. This will also illustrate the business value and begin to shape out the wants and needs of the marketplace.
The How: Development & Design
Our story is built. Now what? We have to prioritize our hero’s requirements, this will shape out the roadmap for development and begin the shape out an MVP. An MVP is the most efficient way for our hero to slay the dragon and rescue the queen. The MVP also meets the business’s immediate goals with the intension of building out scalable features that will continue to add value to the product. In other words, our hero needs at least a sword and shield for any chance of success with the intension of finding armor.
Cool we have, requirements… now what?
In order to move forward we must establish a prioritization of requirements that will shape out a roadmap for development and meet the business’s goals.
How many requirements do we want to define in an MVP? Wait… what is an MVP?
An MVP is the quickest and most efficient way to slay the dragon and rescue the queen. But seriously, an MVP (Minimal Viable Product) is a product brought to market built with a minimal amount of features to gather validated learning about the product and its continued development. The MVP also meets the business’s immediate goals with the intension of building out scalable features that will continue to add value to the product. In other words, our hero needs at least a sword and shield for any chance of success.
Here is our MVP that matches our business requirements.
The green squares are MVP requirements. The translucent squares are now features with the intent of implementation in future releases (v2.0+). These will continue to add to and exceed business value.
For production to begin, we now have to take the MVP and v2.0+ features and prioritize them. This reintroduces our Hero’s Journey — or Hero Flow.
The Hero Flow’s requirements can now assist us in creating a screen inventory. In addition to our Hero’s Flow, we have to establish secondary paths and points of deviation the user might take on their journey. Our Hero may choose to rescue the Queen and avoid the dragon all together. Remember the ‘search filter’ and ‘debit card’ pivots in Sarah’s Amazon journey? These pivot areas are where the user’s experience varies. All of these use cases provide scalable areas for the v2.0+ features to be road mapped and design for future implementation.
Sweet, so the MVP and v2.0+ features are defined.
However, he decided to bring a team along after hearing about previously failed solo efforts. Now with a team, numerous communication channels will be in effect. The team must all understand the product being built and all the requirements behind it.
Now that we understand that, let’s break down the development and design effort…
Our hero and his trusted team of knights have slayed the dragon and saved the Queen.
Understanding the impact of user centered design and the importance of user narratives facilitated our success.
We are constantly trying to understand the world around us, and we create stories to explain these experiences. We must strive to create these stories. Without stories the product or service becomes a series of memorized actions. These memorized actions are prone to error and worse prone to miscommunication.
FYI… Bob’s magic tires has completely disrupted the tire industry — they have eliminated waste, matched the lifespan of the vehicle, and are cheap to manufacture… in case you were wondering.