There’s an Innovator’s Bias for the “Solution”

Ash Maurya, Founder at LEANSTACK KEY TAKEAWAY We see a problem and rush to build a solution. We do everything in our power to bring this idea to life, but then we often miss the mark. In reality, we should focus on the problems intently….

Ash Maurya, Founder at LEANSTACK

KEY TAKEAWAY

We see a problem and rush to build a solution. We do everything in our power to bring this idea to life, but then we often miss the mark. In reality, we should focus on the problems intently. By understanding the real underlying causes of trouble for customers, we can build the right solution.

OUR TAKE

As product people, it’s a natural thing to focus on the solution.  We want to make our customers happy. We want to be able to solve problems for them.  But, when Ash talks about focusing on the problem and not the solution — it made us at Product Collective realize that rushing to the solution right away can be a huge mistake.  

It’s not that creating a solution quickly is a bad thing.  However, it is when it’s the wrong solution.  Product Managers are doing themselves and their customers a disservice when they don’t spend enough time on understanding the problem in great detail.  It’s easy to hear about a problem once or twice and think that you understand it. But this may not be enough.

So, what are we to do?  As product people (whether we’re an acting Product Manager, Startup Entrepreneur, or “intrepreneur” at a larger company), it’s our job to be efficient and solve product problems that our company is faced with… quickly, at that.  

A few things come to mind:

  1. Ask “why” more often.  When we hear a customer bring up a specific problem, we need to dig in with them more to understand why it’s a problem.  We need to understand context as best as possible.  Perhaps the reason it’s such an issue is much different than we may assume.  And if that’s the case, that solution that we rush to build wouldn’t even solve the underlying issues.
  2. Share context with our team members.  If it’s sometimes hard for us as product people to understand “why”, it certainly is going to be even more difficult for the designers and developers that we’re working with… only because they’re a bit farther away from the customer.  Yet, they are the people who are actually building the products. It’s important that they understand the underlying problems deeply, too. So we need to be sure to share that with them.
  3. Get in front of more customers, more often.  When we hear about problems from one customer… it’s an issue.  But, does that mean we should assume that the same problem is experienced by all of our customers?  Are there nuances with this specific problem depending on the persona? The only way to know this is to get in front of your customers as often as possible.  But we know… you’re busy, right? Of course. We all are. But think of it this way: if getting in front of more customers can help you avoid spending a lot of time building something that people don’t actually want or need… and that doesn’t solve a real problem… it’s time well spent, isn’t it?

We all care about solving problems.  But this portion of the chat with Ash reminded us at Product Collective that *problems* need more of our attention.

MORE READING

Story Map your way to MVP. If you consider an MVP to be a “product built from the smallest set of features that delivers customer value” then a story map can be a good route to take to determine what should be included in your MVP.  The folks at Cayenne Apps explain 5 steps to building an MVP with story mapping.

How to maximize your minimum viable product. There are plenty of good reasons to employ MVPs. As the HUGE team note, good product teams do so because they understand that you can’t assume you know what your customers want and that you should “focus your MVP on validating your assumptions about users, and listen to their reactions closely.” MVPs will also help your team focus on what’s important — testing key features as opposed to all of them and reacting iteratively based on what is learned.

Think less, think better. Moshe Bar’s research concluded that “the mind’s natural tendency is to explore and to favor novelty, but when occupied it looks for the most familiar and inevitably least interesting solution”. Not many of us will find time for a weeks-long silent retreat, but perhaps we should be cognizant of the fact that overthinking, or “loading”, will hamper your creativity.

Paul McAvinchey
Paul McAvinchey
paul@productcollective.com

For over 15 years, Paul has been building and collaborating on digital products with fast-growing startups and global brands, including AOL and WMS Gaming. Currently, he's a co-founder of Product Collective, a 15,000+ strong worldwide community of product people. Members collaborate on Slack, meet at INDUSTRY: The Product Conference, listen to Rocketship.fm, learn at Product Lunch and get a weekly brief that includes best practices in product management. In recent years he led business development at DXY, a leading product design firm in the Midwest, and product innovation at MedCity Media, a publishing startup acquired by Breaking Media in 2015.