Let’s Stop Talking Solutions and Start Talking Problems

Innovation is all about building the solutions that nobody would think to ask for to the problems that they didn’t realize they had.

You wouldn’t go into a doctor’s office with a pain in your side and ask for an appendectomy, you’d let them offer you the solution that they believed best solved your problem, and you’d rely on evidence (the cessation of pain in your side) to determine the quality of that solution.

Similarly, great product teams innovate by building trying (failing) until they’ve found a solution that achieves the outcome they were searching for.

OUTCOMES, NOT FEATURES

Products are not measured according to their volume of features. They are measured by how effectively they solve users’ problems. Innovative solutions are developed by teams who are given problems to solve, and the freedom to explore and fail. That path may be winding, but a product that doesn’t solve anyone’s problem is of no use.

Determining whether you’ve really solved a problem requires a definition of what it means to succeed. More sessions, more active users, reduced bounce rates. Furthermore, that definition needs to be the first thing that you define for your team. Before requirements. Changing your definition of success cannot be done lightly.

What’s measured gets managed. Choose the outcomes that you can measure and is reasonably responsive to change.

Working in this way is difficult. Baselines, gathering logs, testing, and repeating is difficult and stressful, but so is looking for a new job when you (or your team, or your company) fail to yield results for your users, so pick your poison.

There is no such thing as a solution that is perfect from the point of inception. Great solutions come from imperfect ones that are tempered through cycle after cycle of development, testing, and redeveloping.

You’ve succeeded when you’ve achieved a desired outcome, and not before

TEAMS NEED THE FREEDOM TO FAIL

Teams are a key part of this equation. Teams work better when they are given the freedom to succeed, or fail, on the journey towards an outcome, rather than the execution of a predefined solution.

Marty Cagan, in his book Inspired, describes the difference as missionaries vs mercenaries, a concept first made popular by John Doerr, as such…

Teams of missionaries are engaged, motivated, have a deep understanding of the business context, and tangible empathy for the customer. Teams of mercenaries feel no real sense of empowerment or accountability, no passion for the problem to be solved, and little real connection with the actual users and customers.

In a world where teams care about the outcomes that they achieve for users, empathetic teams get riled up over the ideas of users in pain, and seek out solutions which solve those problems in ways that thrills the user.

Building great product is extremely difficult, and no solution is perfect the first time its put to paper. As often is the case…

“the vast majority of innovations in our industry, the customers had no idea that what they now love was even a possibility.” — Marty Cagan

FAILURES ARE JUST SUCCESSES IN PROGRESS

Teams that embrace failure as an accepted possibility are ultimately going to take the sorts of risks necessary to build a winning product. Teams that are afraid of failure will build the product they’re asked to build, so as to not be responsible for its’ outcomes.

Failures and successes aren’t that different. The only real failure is not understanding the implications of what you’re building. So long as you’re willing to measure the outcome and adjust accordingly, failure is just a waypoint on a journey towards a successful product.

So let’s get out there and tell the world

Here I am. Judge me by my outcomes

How are you going to take ownership of your product’s success?

Thanks for reading! I’m Jack Moore. If you are passionate about building impactful product, I’d love to connect with you!

and if you liked this, I bet you’d like these too…