“Make it easier” is not a product strategy
Without understanding specifically how a product is hard to use, teams will always fail to provide real value to the customer.
It’s impossible to make every decision top-down and ahead of time. Newly discovered details or changing circumstances require team contributors to make their own decisions — and those decisions need to be coherent in the context of the work as a whole.
For that to happen, every team member needs to understand the reasoning behind decisions made by others in the past — how that decision fits into the strategy and brings us closer to the outcome we want. That reasoning is often called the “north star” of the product: the answer to the question of “how is our work meant to provide value for the customer?”
A common answer is some variation of “make it easier.” This answer is common because it doesn’t take a lot of thinking to get there: we think customers want X, and so making it “easier to do X” will provide value to the customer. And thus thousands of PRDs, press releases, and changelogs become graced with the sentence, “now it’s easier:” easier to log in, easier to connect with your friends, easier to find relevant content.
So why are the products still so frustrating to use? Because “make it easier” is only a starting point, and when teams stop there, they set themselves up to fail.
“Make it easier” feels like a nice laconic way to describe a strategy, but it’s not. It is not actionable, it doesn’t help create alignment, prioritize work, or serve any other functions of a north star. Fortunately, that ambiguity can only survive in the brevity of the phrase; if we place “make it easier” within a robust methodology we can see exactly where it falls short.
“Make it easier” is an absence of a product hypothesis
I take a hypothesis-driven design approach to product strategy. The template for a high-level product hypothesis has four sections, with each section informing the following:
- the user’s end goal
- the friction users experience while achieving that goal
- the missing customer benefit that we could provide to overcome those frictions
- the proposed solution that delivers that benefit
The reason for this sequence is to make each section of the hypothesis testable. We must already understand the user’s goal when we look at problems, so we can evaluate the magnitude of the pain they cause. Similarly, we need to clearly frame the problem we are solving before we can identify the capabilities we want to provide. Understanding which capabilities are necessary lets us intentionally plan what we will build. The hypothesis establishes a shared context we can use to identify the specific actions a user needs to be able to take, and the concrete benefits they need to receive from those actions — which is what makes a product.
Let’s take a mission statement like “make it easier to discover content” and fill out the product hypothesis that it implies:
- The end goal of users is to discover content
- The problem with discovering content is that it’s hard to do
- The benefit we will provide is making it easier
- The proposed solution to make it easier is…
And that’s when you run into an issue. Because “make it easier” is just a starting point, we don’t have a shared context of what makes it hard to discover content. “Make it easier” can’t guide our decisions to pick between different solution ideas, because they are all providing different capabilities, solving different problems, and possibly even dealing with different types of content or different user segments.
If leadership throws “make it easier to discover content” over the fence, they shift the responsibility onto the teams to figure out what the business’s strategy actually is. Which leads to ambiguity, lack of alignment, and political contests between different power centers advocating for their ideas because of who came up with them rather than the value they bring to the company.
Research vs Validation
When companies treat “make it easier” as a starting point, they can use research to fill out the rest of the product hypothesis, starting with the user goal. But when companies treat it as a strategy, they fall into the pattern of validation instead.
A lot of people confuse the two. But validation is not research; the former looks for divergent interpretations of evidence and the latter looks for signals that our preferred interpretation is correct. When you validate, you come up with the answer first, then ask customers to agree to it — and end up with misleading conclusions.
“Would this make it easier” is especially unreliable because it commits the two cardinal sins of user research: asking participants to imagine a hypothetical future behavior and asking them to choose between improving a product they use and…nothing.
In those circumstances, anyone will say yes — which is good enough for validation, but not very helpful as data. If you were to run the same test with another idea, you would probably get the same results — yes, your customers think it would make using the product easier. This feedback is useless for the main role of product management: saying no.
Applying the product hypothesis
The stages of the product hypothesis go in order because every stage helps us prioritize between competing areas. Which customer need is the most important? Which pain is the biggest blocker to achieving that need? What is the one most helpful thing to relieve that need? What is the one best feature we could build that provides that thing?
In addition to prioritization, rooting the features in concrete needs lets us have a frank conversation with interview participants about cost. Beyond just A/B testing solutions against one another, or comparing the pain of two problems, we can make “nothing” a reasonable response:
Would you rather we made it easier to discover new content…if it meant leaving fewer posts from people you already know in your timeline? …if it meant a steeper learning curve navigating the platform? …if you had to share your location? …if it cost five dollars?
Of course, as with all interview questions, the “yes” or “no” is not the interesting part. It’s just a catalyst to a conversation. Why this one and not that one? Was it a hard choice? What factors did you consider when making your decision?
With just a little bit of research, you can turn “make it easier” into a real north star, and validation into useful research.
