One of the easiest ways to kill a product is inside-out thinking in the Product org. Take a quick read of this and come back, I’ll wait:
Imagine putting years of research and development into a product for it to end up being “completely stupid”. How does it happen? While some of the issues in the article could be attributed to bad UX, the problems with this truck’s design really come down to poor product management that stems from inside-out thinking.
Inside-out thinking happens in the office, when the Product Manager works in a bubble to innovate, then brings that innovation to market. They may talk to customers or prospects, but when they do, they are not looking to understand, they are looking to validate their perspective and sell those people on it. They are not following the principle of “seek first to understand” and the product/market fit suffers because of it.
The lean movement can enable inside-out thinking, making it tempting to lean on “experiments” and pivoting to bypass the fundamentals of understanding the market and the problems it is looking to solve, along with understanding why things are done the way they are, to begin with. This isn’t to say that lean methodologies are inherently bad, just that to be used effectively they have to be leveraged in an outside-in environment.
Inside-out thinking is very tempting for a Product Manager. Inside-out thinking can come from a high level of self-confidence when you’re an SME, believing that you know the industry and what it needs. The problem is that your experience is a sample size of one. Inside-out thinking can also come from a high level of self-confidence as an innovator, assuming that you have a unique perspective and sufficient market knowledge to do something better. The problem is that if you don’t know why things are done the way they are, you don’t know which traditions to keep and which to replace.
Instead, we have to focus on outside-in thinking as Product Managers. We need to talk to the market, not to pitch or validate, but to fundamentally understand what problems they need to solve, what context they operate in, and what really matters to them.
Outside-in thinking doesn’t mean asking users what features they want and writing them down, it requires digging deeper to understand what benefit the customer would get from those features, and what problems those features solve. would solve for them.
I learned this principle when I ran a global pre-sales team. Discovery inevitably involves a lot of people asking if your product does X, and one example was “Can your MTA (email server) rotate logs every five minutes?” It’s an easy question to answer, because yes, the server could do that, but that yes answer only checks a box, it doesn’t differentiate.
Instead of just saying yes, I dug a little deeper, asking them why they needed to rotate the logs every five minutes. The answer was so they could get closer to real-time data. Again it would be tempting to say yes because I could tell them how our MTA had a real-time data logging system with built-in indexing and garbage collection, allowing them to get actual real-time data. It’s not only a checked box, it’s an actual differentiator.
Again, instead of saying yes, I kept digging, asking them why they needed real-time data on email events. Their answer this time was that they needed to spot any issues with the delivery of messages so they could resolve them before they became a bigger problem. This was my chance to go from not just checking a box or differentiating, but actually making their lives better: our MTA had an automation layer that monitored the responses coming from the mailbox providers and automatically took action to prevent issues, address outages, etc.
While that was great from a pre-sales perspective, the same principle applies in the product world: keep digging past the feature request, and the functionality request, and get to the fundamental problem the customer is facing. The product that solves the fundamental problem is the one that gets used. The only way to build that product is through outside-in thinking; the outside-in Product Manager spends their time talking to the market, learning what matters to them, what problems they need to solve, what keeps them up at night, then builds something that helps them.
I’ve heard inside-out thinkers argue that true innovation requires setting aside traditional approaches, and they love the apocryphal Henry Ford quote:
“If I had asked people what they wanted, they would have said faster horses.”
Attributed to Henry Ford (see Henry Ford, Innovation, and That “Faster Horse” Quote (hbr.org) for why it’s likely not a real quote).
Here’s the thing: even if that is exactly what people would have said, it’s not proof that innovation comes from inside-out thinking because a good outside-in Product Manager would still dig deeper and ask why faster horses? To get somewhere sooner? What else is a problem with horses? The smell, feeding, injury risk, etc.? What do you like about the current solution? The extendable carriage roof? The seats in the buggy? The outside-in Product Manager doesn’t necessarily give the customer what they ask for, they develop a deep understanding of what the customer needs.
Outside-in thinking helps your development team be more effective and even better motivated because they get to understand not only what to build, but why they are building it. I’ve been a developer, and building in a bubble is work, solving a problem is much more enjoyable. Knowing why you’re building something for someone in particular (even if that someone is a well-written persona) brings meaning to the work of the dev team and keeps them going.
Not only does an outside-in perspective help build the right product, it accelerates and improves the go-to-market and launch process. When you truly understand what problem you’re solving and how it impacts your market, you can truly enable your sales and marketing organizations to be effective. Instead of trying to sell a feature, they get to sell a solution, one that takes care of problems that their prospects feel, but never could properly articulate.
Don’t build a “completely stupid” product, start working from the outside-in!