It’s easy to think we know how to solve the current problem our team, product or business is facing. We have experience and expertise in our domain. We’ve seen what the competition is doing and feel we know exactly how to offer a competitive solution that will set us up for market success. We instruct our teams to build the solution we have in mind and wait for happy customers to roll in, moving our charts and graphs up and to the right.
The team works for multiple weeks, sometimes months. And we launch, fingers crossed, looking daily (sometimes hourly) to see if our predictions were correct. But the customers don’t come at the level we predicted, and the numbers don’t move quite in the directions we’d hoped.
Why does this happen? And, perhaps more importantly, could this have been avoided? Let’s take a look.
If you step back to a high level, there are basically two ways to solve a problem:
Method 1: We implement the HIPPO (the highest paid person’s opinion)
This is the default method of working in many organizations. Whoever has the biggest job title gets to dictate their solution to the team. The team builds the best version of that idea and ships it leaving the entirety of their success dependent on one person’s point of view. This happens mostly in organizations who have not fully moved into agile ways of working and who lack psychological safety.
While someone who has ascended to a position of leadership, in most cases, has the experience and expertise to back up their points of view, the reality is that they are just as likely to be wrong as anyone else. Why? Because there is an infinite combination of code, copy, design, business model, and value proposition you could put together to solve the business problem you’re currently facing. In addition, one blanket solution for all of your users often ignores the nuances of context of use and meaningful differences between different segments of your target audience (or as my friend Jeff Patton likes to put it, “the differences that make a difference.”)
Let’s take a look at an example. Let’s assume your job is to transport school age kids safely, quickly and economically from one place to another. How would you do it? Immediately, I can think of at least 3 options to solve this problem:
Solution 1: School bus
In the United States this is often the default solution to the problem. Kids board the bus and it takes an entire group from one place to another. In suburban settings where there are fewer sidewalks and distances are greater this solution can make a lot of sense.
Solution 2: A line of (sometimes tethered) kids walking together
In urban settings many kids can walk from school to another location as a group. However, in some cases the kids are too young to be able to make it there safely and consistently on their own. In this case, kids are often lined up and walk together from place to place. This keeps the group together, ensures they are all accounted for and eliminates the need for a vehicle, driver, insurance etc. In some cases, these kids will be attached to (or asked to hold) a tether or rope of some kind to ensure the group stays complete and pointed in the same direction.
Solution 3: Transport kids in cargo bikes
There are some places in the world where biking is the preferred mode of transportation. These cities (usually) have been converted to accommodate all kinds of bikes performing all kinds of functions. In this context piling a few kids into the container of a cargo bike is acceptable and, in fact, promoted. It’s efficient, good for the environment, safe and exercise for the person turning the pedals.
So which of these solutions is the right one? Are these the only 3 options available to us?
In a situation where we are implementing the HIPPO we don’t get a say in it. We have to go with the top-down directive we were provided. As a team we could work to optimize it to the best of our abilities to the context of use but if the boss wants to implement a fleet of large school buses in a bike-friendly city like Copenhagen or Amsterdam, that’s what we’ll work towards regardless of the context of use or the needs of our target audience.
Method 2: Empathy, experimentation, learning, agility
Instead of trying to guess what the best combination of features, value proposition and business model is going to make our customers successful we start with understanding them, their needs and their context of use for our products and services. Where do they live? How much money do they make? How far do they have to travel between places? What’s the public infrastructure like in those places? What are the current commonly accepted ways to travel and transport in their city or country? These are the questions a truly agile team would start with.
The team would then go observe these folks getting their kids from place to place. They’d identify where the infrastructure supports their needs and where it has gaps. The team would speak with parents and teachers who have to go through this process daily. Using those findings the team would come up with some hypotheses — testable ideas that might help our target audience be more successful. Without investing too heavily in these ideas the team would build experiments to see if there is merit to any of these hypotheses. Those that don’t meet our success thresholds — in other words, those that don’t make our customers more successful — are discarded while the team pursues the ideas that resonated more effectively.
As the chosen solution is scaled up new feedback and insight comes in forcing the team to further adjust their solution. This process of shipping, sensing and responding continues for the life of the service the team has built ensuring that, as the customer behavior and expectations evolve, the system is optimized along with them.
Solutions are infinite. Problems are unique.
It’s easy to fall into a specific solution quickly. We saw it somewhere before. It worked in another context. Another company built it up into a multi-billion dollar business. It’s more difficult to remember that the context in which that solution was implemented, the way it was launched, the audience it targeted, the timing of its launch and many other factors may have contributed to its success. The pace of change is far too fast these days to assume that just because it worked (or didn’t) in the past it will do so again now. Every day we have new ways to solve the same problems we’ve been solving for our customers for years.
Focus on the problem. Focus on your users and customers. Get to know them and their goals. Work to build and fund a culture that enables, empowers and encourages teams to explore options to find that winning combination. Your customers will be more successful and so will you.