post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Product Management

Sunday Rewind: Whose job is it anyway? The rise of Product Ops and why it deserves to be an independent function

Guest Post

Creating metrics that matter

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>Iwan Roberts (Business analyst, BBC) is part of a relatively small agile team building location services at the BBC, continuously iterating for over a year now. In this ProductTank talk &#8211; “Driven By Data” &#8211; Iwan gives a whistle-stop tour of how his team has iteratively built a set of operational dashboards to help them understand their data-driven product, and unravel how users are <em>actually</em> behaving.</p>
<h2>The Product</h2>
<p>BBC Travel sounds pretty straightforward &#8211; you enter a location, you receive travel news across multiple travel modes (road, rail, etc.). The previous iteration of the product was released in 2009, and now the team (&amp; the users!) wanted a responsive product, geolocation support, and to increase the speed with which incidents could be published and discoverable.</p>
<p>The team also wanted to change how users could search for locations. Previously this was done via a simple, relatively coarse-grained list. Now, the product allowed users to search for very specific, fine-grained locations.</p>
<h3>Editorial and Tracking Challenges</h3>
<p>The BBC Travel team actually have very little editorial control over what they publish. Their data is almost entirely externally sourced, and so their reputation is based on the data they have access to. They also reused common components from other areas of the BBC (e.g. Mapping and search) &#8211; which is fine and frugal in principle, but also means that they are even <em>more</em> beholden to external providers (e.g. Google for mapping).</p>
<p>When it comes to monitoring their systems, the team have a dashboard tracking everything from the data they ingest through to their publishing speed. It&#8217;s not pretty, but it provides realtime tracking of the health of their public-facing system, and allows them to make data driven decisions as quickly and cleanly as possible. Even the dashboard was developed iteratively in step with the development of the platform itself, with a total focus on providing accurate, realtime data (built using the Dashy framework, in case you&#8217;re interested).</p>
<h2>Development processes</h2>
<p>While developing V4 of the product, V3 was constantly live, allowing the team to iteratively release new features and UI changes, testing new code and features on existing systems. V4 of BBC travel was actually in Beta for months before the team launched &#8211; just before a bank holiday. While the deployment went smoothly, the feedback was surprising (especially bearing in mind the long beta &#8211; they weren&#8217;t expecting any surprises!) There were 3 common feature requests:</p>
<ul>
<li>Order incidents by road type (released &#8211; everyone happy)</li>
<li>Maps on mobile devices (already on the roadmap &#8211; the team just brought it forward)</li>
<li>Links to county-level incident list (completely against the grain of the revamped product!)</li>
</ul>
<p>The team immediately started trying to understand why users where asking for this list, and sensibly turned to investigating actual user behaviour. How were users currently solving this problem? Were they searching for counties? Maybe they&#8217;re doing multiple searches? In both cases, the results couldn&#8217;t account for the volume of feedback.</p>
<p>Then, after looking at how users interacted with the map after searching, they saw lots of panning behaviours, suggesting that&#8217;s “counties” we&#8217;re a proxy for longer journeys. Crucially, this potential need never came up in user testing!</p>
<h2>What Can We Learn?</h2>
<p>By dint of a large user base and investment in analytics and research, the BBC Travel team has access to large amount of user feedback and quantitative data. This is a goldmine when it comes to understanding their users, but the team have realised that they also need to have a clearer definition of success in order to make sense of that data.</p>
<p>Unlike some other products writhing publishing ‘constellations’ success for BBC Travel is actually quite a fleeting interaction. To better understand what it means, they’re conducting experiments &#8211; tracking the number of searches each user performs (too many implies poor UX or missing data), or the percentage of users who don&#8217;t reach a results page. This is data that their system now allows them to collect, but the only way to make sense of it all is to understand what they&#8217;re users are trying to do in their own contexts, not just the context of the product.</p>
<p>If you&#8217;re not already gathering data about your users, and how they’re using your product &#8211; start immediately! But more importantly, your goal should be to understand what your users are trying to achieve beyond the limited context of your product &#8211; if you don&#8217;t understand, then you’ll only ever have a limited understanding.</p>

core/freeform

How to lead data-centric product teams: Jon Mora (Chief AI Officer, Zefr)

How to be a better data-driven product manager

User insights for product decisions by Cris Valerio

Data scaling for startups by Crystal Widjaja

Make Better Product Decisions by Using Quantitative and Qualitative Data, by Brian Tran

Data-Driven Product Design at the BBC

Chris Massey