post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Creating metrics that matter

A case study: Launching a product process in a project-based company

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

How much are product managers getting paid in 2024?

Leading product ops at Delivery Hero with Koen Dubelaar

Connecting fans to creators at Spotify (Dariusz Dziuk, Product Lead, Spotify)

“You’re not as competent as you think” 5 lessons from Ken Chin on navigating a product career (CPO, Spark Networks)

Everything wrong with the product management job market. And how to fix it

With his background in technical editing, community building and product marketing, Chris' approach to product management is inherently centered around user narratives. He spent the first few years of his career working with the B2B developer products, prototyped an experimental technical publishing platform along the way, and then kick-started the Mind the Product platform. You can find him at ProductTank, or on twitter as @camassey.

Product Manager

Chris Massey

<p><a href="https://twitter.com/joshmahoney">Josh Mahoney</a> draws on his experiences of being inspired to solve real problems for real people and talks to <a href="https://www.mindtheproduct.com/producttank/">ProductTank</a> San Francisco about the dissonance between that drive to solve problems, and the reality of so many product roles.</p>
<p>Surely the way to create great products that solve real problems is very straightforward:</p>
<ol>
<li>Create a better way to solve a problem</li>
<li>Tell people with that problem about the new solution</li>
<li>Profit!</li>
</ol>
<p>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!</p>
<p>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 <em>bad</em> product decisions &#8211; so here are a few things to avoid!</p>
<h2>Step One: Don’t Speak to Users</h2>
<p>This is surprisingly common in tech companies &#8211; 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.</p>
<p>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.</p>
<h2>Step Two: Get Addicted to Metrics</h2>
<p>Josh described an article he read about games of luck which provide an unexpected reward schedule &#8211; specifically how:</p>
<blockquote><p>[This] illusion of control is a crucial element in the maintenance of gambling addiction… [as it] installs a feeling of skill or control<br />
<em>&#8211; </em><a href="https://www.theguardian.com/science/blog/2014/apr/01/candy-crush-saga-app-brain"><em>Dana Smith, The Guardian, 2014</em></a></p></blockquote>
<p>The flash of insight that followed was that this was a perfect description of his product management experiences &#8211; 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.</p>
<p>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!</p>
<h2>Step Three: Do What You’re Told</h2>
<p>Josh shares a perfect example of different approaches to tackling problems based purely on the number of people asking for fixes &#8211; 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) &#8211; 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 &#8211; of unhappy residents/users &#8211; barely changed. There were still a lot of complaints.</p>
<figure style="width: 1600px" class="wp-caption aligncenter"><img loading="lazy" decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2021/01/131498e5-4a4a-45e9-91ba-01620ff7d687_user20journeys20-20producttank20san20francisco.jpg" alt="Mapping user journeys through Melbourne, Australia" width="1600" height="892" /><figcaption class="wp-caption-text">Mapping user journeys through Melbourne, Australia</figcaption></figure>
<p>However, when they analysed the most common routes that people would drive along &#8211; the literal <span style="font-weight: bold;">user journeys</span> &#8211; and focused their budget on repairing the potholes <span style="font-style: italic;">along</span> those routes, the impact was huge. The number of complaints plummeted!</p>
<p>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.</p>
<h2>Surely There’s a Better Way?</h2>
<p>Rather than just leaving us with a set of anti-patterns, and a mild sense of “<em>what now?</em> 😫&#8221;, Josh spins his experiences around, and offers a clear path towards solving real problems in a way that feels meaningful.</p>
<h3>Step 1: Talk to Users</h3>
<p>Involve your stakeholders as early as possible. Nothing will illustrate real user problems better than real users, encountering and describing their problems.</p>
<h3>Step 2: Build a “Concept Car”</h3>
<p>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 &#8211; to give them a North Star vision to aim for.</p>
<h3>Step 3: <span style="font-style: italic;">Now</span> do Your Job</h3>
<p>Once you’ve got a North Star, informed by real user conversations, <em>that’s</em> the point when you can pull out your tools, get down into the details, and start building a product that feels meaningful.</p>
<div>
<h2>Enjoy more from ProductTank</h2>
<p>ProductTanks are informal meetups, <a href="https://www.mindtheproduct.com/about/">created by Mind the Product</a>, to bring local product people together and to enable speakers to share amazing product insights. Today we have ProductTanks in more than 200 cities across the globe and there’s probably one near you.</p>
<p><a href="https://www.mindtheproduct.com/producttank-about/">Learn more about ProductTank</a> – find your local meetup, explore more ProductTank content, see the latest ProductTank news, and discover ways to get involved!</p>
</div>

How to be Bad at Product Development – Josh Mahoney

Chris Massey