There is more to identifying who’s problem you’re trying to solve – you need to also have a sense for the context in which they experience the problem. Problem statements solve for someone, and good problem statements also solve for somewhen.
The Situation
The situation your customer finds themselves in changes your customer’s goals and their definition of success at achieving those goals. Consider Amazon’s first mobile app, developed ~15 years ago. Amazon at the time made it possible for shoppers to shop for and buy most anything. Part of shopping is evaluating things they might buy – reading reviews, comparing features, etc. For the ‘everything’ store, how do you build an ‘everything’ app? “How do we enable all of our customers to do all these things on their mobile phones?”
The next question feels obvious after you ask it, but so often, people do not. “Of all those things (we know) people want to do, when do they want to do them?” I was working at another Amazon-owned company a couple years after Amazon had launched their mobile app and learned the story of the approach Amazon took with their mobile app. As told to me, this was the story of the spear-fisher. The level of focus applied to creating this app was not something I had seen before.
To get a handle on what it means to focus within the context of a shopping app where anyone can buy anything anytime, you need to dive into a model of understanding consumer behavior. “Shopping” is too broad and vague to describe it, just as “moving” would be too broad and vague to describe both crawling and running. You can think about consumers as having one of a couple different shopping intents. Someone when shopping can have a specific purchase intent or a nonspecific purchase intent. A nonspecific purchase intent could be something like “I need a new pair of shoes to wear to the upcoming formal event.” A specific purchase intent could be “I need a new pair of Jimmy Choo Didi 45s to wear for the upcoming formal event.”
When modeling someone’s purchasing decision-making process, you find that people with nonspecific purchase intent start with an understanding of the need they are trying to satisfy (new shoes for the event) and want to know what their choices might be. Those consumers will then discover what might be good choices, compare those choices, and choose one. Someone with specific purchase intent has already made this choice – and at the time of shopping is bypassing any comparison or discovery activities. They just need to complete the transaction, they’ve already made the decision.
Folks within the Amazon space at the time had personified the idea of someone with specific purchase intent as a spear-fisher. You can imagine a guy knowing he needs a new bar of soap, walking into and through the store directly to the personal care section, grabbing a package of soap (the same brand as he already uses), and proceeding to the check-out counter. Hyper-efficient shopping for the spear-fisher. The process was optimized as a transaction. Success is defined in terms of how easy it was to find the soap, and how long the entire process took. Contrast this with a different shopping experience, of a guy wandering through the store casually, becoming inspired by the skin-care products positioned at the end-caps of the aisles, reacting to in-store promotions, and imagining possible purchases for a new skin care regimen. This process might be optimized by creating inspiration, or reinforcing a positive self-image. Discovery of the perfect product becomes more important than efficiency of transaction.
This is the same person, in two totally different frame of mind. Sometimes this person is a spear-fisher.
For Amazon, the specific scenario driving the original mobile app was supporting the spear-fisher. Just as Amazon started with books, they started in the mobile space with supporting spear-fishing. When the person is looking for inspiration, they could continue to do it on the website from their computer. The description for a successful experience was described to me at the time as follows: A spear-fisher gets in line at the coffee shop, and remembers something they needed to purchase (specific buying intent). By the time the place their coffee order, they will have launched the Amazon app, found the product they wanted, and completed the purchase transaction. Optimizing for efficiency in the transaction, not discovery or decisioning about what to purchase.
This provides amazing clarity of purpose. With this articulation of a somewhen you know how to decide if particular features should be included or excluded. Product-comparison features could be excluded. Comparison is helpful to someone when they are making comparisons or discovering alternative products. Searching by product name would be more helpful than searching by product category. Searching through previous orders would be exceptionally helpful for someone making a routine repeat purchase of consumable items. Need to restock your preferred daily vitamin?
When in line in the coffee shop, Amazon targeted the specific context in which the consumer found themselves, and not simply the consumer. In the prioritization 2×2 introduced previously), we discussed the trap of trying to be all things to all people at all times.
We explored escaping the trap by focusing on solving a problem for only some of the people. In this situation with the spear-fisher, you are not isolating for “some of the people” because spear-fishing is not an identity, it is a contextually relevant condition. Spear-fishing is “some of the time.”
A good problem statement template creates space for describing this context.
The Problem of… It is hard to purchase something from Amazon while waiting in line and away from my computer
Affects Whom… All existing customers when they have specific buying intent
The Impact of Which is… People consider purchasing from brick and mortar retailers while away from their computer
The Benefits of a Solution are… An increase in share-of-wallet from Amazon customers
This problem statement draft captures the situation described above, and provides clarity of purpose to the team envisioning different ways to address the problem. This draft still suffers from many mistakes. For example, this problem statement describes a situation when it should describe the reason why being difficult is a problem. This draft also fails to quantify either the impact or the potential benefit of solving the problem, making it unusable for shaping product strategy – lacking the needed information to prioritize solving this problem relative to doing something else.
When people talk about being data-driven in their product investments, what they unfortunately are more commonly referring to is evaluating the results of investments and not proactively evaluating the (data-informed) potential direction of investment. Both are needed. I don’t have any of the data which would have shaped Amazon’s investment decision to originally build an app for spear-fishing, but a semantically improved problem statement would look like this – and these numbers are all fictional.
The Problem of… consumers don’t consider buying from Amazon when away from their computer because the mobile shopping experience is frustrating
Affects Whom… All existing customers with specific buying intent when away from their computer
The Impact of Which is… Amazon is excluded as the potential retailer in $100B of specific-purchase-intent transactions per year
The Benefits of a Solution are… An increase in revenue of $10B per year as existing customers shift ‘transactional’ purchases from brick and mortar retailers to Amazon
You can imagine with this example the improvements to product thinking which come from writing problem statements. What if the original problem statement for the ‘everything’ mobile app had been written like this:
The Problem of… consumers don’t consider buying from Amazon when away from their computer because the mobile shopping experience is frustrating
Affects Whom… All potential customers when away from their computers
The Impact of Which is… Amazon is excluded as the potential retailer in $1T of spontaneous consumerism transactions per year
The Benefits of a Solution are… An increase in revenue of $100B per year as spontaneous purchases shift from brick and mortar retailers to Amazon
The level of ambition is audacious, and magnitude of the scope of corresponding work is commensurate. All of the scope we could previously cleave from the deliverables is back on the table – account creation, product comparison, cross-selling and recommendations, bundling and upselling… What this problem statement lacks is focus. Desirable to the customer, for sure. Valuable to the business, absolutely. Feasible to execute, not so much.
Narrowing the scope of the problem to be solved to some of the people (existing Amazon customers) allows the team to immediately remove from scope any of the account-creation functionality. This allows the mobile team to avoid both the initial and ongoing costs (and delays, and opportunity costs) of building account creation functionality. Around that time, there likely would have been three teams – building natively for Apple, Android, and Symbian mobile phones. Plus the team building the web experience. Every broad area of functionality would either require a “write once, run everywhere” solution, or multiple independent implementations. At that time, the “run everywhere” experiences were noteworthy in their lack of polish and quality in comparison with native applications.
Narrowing the scope of the problem to be solved to some of the time (when people have specific purchase intent) further reduced the scale of ambition for the project. Each area of functionality ultimately competes for scarce resources, and teams are forced to make choices which compromise the business case, compromise the functionality, compromise the quality, and compromise the customer’s experience. The last three have a knock-on effect of further compromising the business case, by undermining its premise. Too much scope causes delays (first-order undermining), and cutting corners during the delay result in a degraded product (second-order undermining through invalidating the hypotheses which built the case).
The shaping of purpose within a well-structure problem statement also enables the team (and in a healthy environment encourages the team) to debate potential value props. Consider functionality associated with upselling – convincing someone to purchase a more expensive, better alternative to the product they have already selected. There are potential profit benefits associated with convincing someone to buy a “better” version of a “good” product. Amazon has had a feature presented as “people who looked at this product ultimately purchased this other product.” The potential benefit of increasing profits in this way apply when solving for the spear-fisher, just as they do in other consumer contexts.
Providing Focus
With a clear problem statement, you can decide to solve for this adjacent opportunity now and update the problem statement accordingly. You can decide to address this opportunity later with an additional problem statement. This is a healthy discussion. Clear problem statements – especially in the context of a product roadmap – help the teams understand the choices and direct their energies towards achieving the outcomes articulated. Clear problem statements provide focus.
One thought on “Problem Statements Solve for SomeWhen”