How to be Bad at Product Development – Josh Mahoney

Josh Mahoney draws on his experiences of being inspired to solve real problems for real people and talks to ProductTank San Francisco about the dissonance between that drive to solve problems, and the reality of so many product roles.

Surely the way to create great products that solve real problems is very straightforward:

1. Create a better way to solve a problem
2. Tell people with that problem about the new solution
3. Profit!

And yet Josh constantly found himself bogged down in meetings, and planning out OKRs, revenue estimates, executive presentations, more meetings, stakeholder management, experiment analysis, query analysis, and let’s not forget the meetings!

While working out what he should be doing instead was pretty tough, Josh has been able to single out a few things that will guarantee bad product decisions – so here are a few things to avoid!

Step One: Don’t Speak to Users

This is surprisingly common in tech companies – partly because there are literally hundreds of tools available to help teams get access to data, analytics and insights, which often ends up being substituted for actual conversations with customers.

But the first step in solving real problems is to identify the right problems to solve. And the best way to identify which are the right problems to solve is… you guessed it… talking to users.

Step Two: Get Addicted to Metrics

Josh described an article he read about games of luck which provide an unexpected reward schedule – specifically how:

[This] illusion of control is a crucial element in the maintenance of gambling addiction… [as it] installs a feeling of skill or control
– Dana Smith, The Guardian, 2014

The flash of insight that followed was that this was a perfect description of his product management experiences – a very unpredictable schedule of successful experimental outcomes, coupled with a strong (retroactive) sense that the outcomes were mostly controlled, with a light sprinkling of luck. Particularly because, when investigating why results may not have panned out as expected, it often turns out to be due to factors entirely out of your control.

Despite having worked at some of the most data-driven companies in the world, Josh has learned that data is a useful tool, but certainly not something to put blind faith into!

Step Three: Do What You’re Told

Josh shares a perfect example of different approaches to tackling problems based purely on the number of people asking for fixes – pothole repairs in Melbourne, Australia. The mayor there initially tried repairing potholes based on “severity” (size of the hole) and proximity (whether the holes were all clustered around similar areas) – these could be analogous to the number of bug reports, or whether the bugs were all focused within a particular functional part of the product. What they found was that the number of reports – of unhappy residents/users – barely changed. There were still a lot of complaints.

However, when they analysed the most common routes that people would drive along – the literal user journeys – and focused their budget on repairing the potholes along those routes, the impact was huge. The number of complaints plummeted!

Focus on solving problems based on your users’ journeys, not just on the “obvious” issues that are right in front of you, or which lots of customers/execs are focused on.

Surely There’s a Better Way?

Rather than just leaving us with a set of anti-patterns, and a mild sense of “what now? 😫”, Josh spins his experiences around, and offers a clear path towards solving real problems in a way that feels meaningful.

Step 1: Talk to Users

Involve your stakeholders as early as possible. Nothing will illustrate real user problems better than real users, encountering and describing their problems.

Step 2: Build a “Concept Car”

The point of concept cars is not to be something you actually expect to see on the road (it may not even run!). The point is to inspire your teams and stakeholders – to give them a North Star vision to aim for.

Step 3: Now do Your Job

Once you’ve got a North Star, informed by real user conversations, that’s the point when you can pull out your tools, get down into the details, and start building a product that feels meaningful.