post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

mission statement

Deep dive: Crafting your product vision and mission

Podcast

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

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! 🎉

Join us at #mtpcon London in 2025 – mark your calendars

How Google makes AI work at Enterprise scale – Miku Jha (Director, AI/ML and Generative AI, Google Cloud)

5 ways to invent and simplify as an AI/ML product manager

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Building your own user experience and software stack: This week’s product news

Ambre Josse is Head of Product at Easygenerator. She is PMP certified with 7 years' experience and always has a Kanban board within reach. She is French from New-Caledonia, based in Dubai, United Arab Emirates.

Ambre Josse

<p><span style="font-style: italic;">Product management is not an exact science. Yet, our decisions are supposed to be based on solid verified assumptions. To do so, measuring and analyzing user behavior is key throughout the entire product cycle. However, </span><span style="font-style: italic;">there is often an inadequacy between the pressure to deliver and the required time we should ideally spend on measuring and learning. </span><span style="font-style: italic;">In this post, I’ll elaborate on switching the focus back to a more balanced product cycle.</span></p>
<p>A few months ago, while scrolling through a well-known product management meme account, I landed on this funny image:</p>
<p><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2022/06/b3a71875-9858-42df-92fb-30528ea53562_pasted20image200.jpg" alt="" /></p>
<p>On the left, is a “HOW IT STARTED” draw, with a clear product cycle broken down into three equal circles : Build, Measure and Learn. Next to it, on the right, a “HOW’S IT GOING”, where all three circles were down to one major taking all the space, “BUILD” and two tiny ones, “measure” and “learn”. It felt so true, that my original laugh turned into weeks of thoughts and direct work on what I could do to shift the balance from the right graph back to the left one.</p>
<h2>How it started</h2>
<p>In the books, in the blog articles we read, we are all taught that, to do things properly, we need to start from the problem and do in-depth user research and extensive testing of our suggested solution and designs. We would take time to <a href="https://www.mindtheproduct.com/everything-a-product-manager-needs-to-know-about-analytics/" target="_blank" rel="noopener">define the KPI’s</a> on which our feature would have an impact on. Then, and only then, we would switch to writing our user stories.</p>
<p>After the release we would analyze the performance of our newborn, collect the first feedback, run a post mortem, present our data with key takeaways and learnings to the stakeholders. In most cases, it’s never over &#8211; you keep measuring, you keep working on increments. A feature is rarely only a quarter worth of work that you forget about after it’s been delivered. Isn’t that the difference between project and product management after all?</p>
<h2>How it&#8217;s going</h2>
<p>Unfortunately, this model, as ideal as it is, gets often compromised by the pressure put on the “build”. Expectations within the company are high to deploy new things often.</p>
<p>We work on multiple features and enhancements in parallel and one “project” usually succeeds another the second it gets released. Post-deployment analysis does not always go much further than a follow up on the adoption rate.</p>
<p>Sure, everyone will agree that user research and data analysis are key. However, not that many stakeholders are ready to fully accept the time it should partake in our workload in a well balanced product cycle.</p>
<h2>Focusing on “build” will compromise the quality of your product</h2>
<p>When you are under such pressure to deliver different impactful features often, the risk is generally that your thorough research ideally involving more than 20 clients at different stages of the conception might turn into a quick 2-3 clients interviews based on pre-established assumptions you would have built from customer-facing teams feedback. You are likely to never run a feature retro, nor to run cohort analysis throughout time.  Not because you are a sloppy product manager or product director. Simply because you are trying to work in parallel on 5-10 projects with X amount of resources and playing a funambulist role between the business as usual, solving enough problems and delivering enough value of things “that will help sell more” at the same time, all within a defined company timeline that might not be your team’s capacity timeline.</p>
<p>Yet, if in theory, product management praises so highly the need for user research and data analysis, this is not without reason &#8211; it’s because focusing on “build only” does not work in the long run. Eventually, you will miss out on what your user really wanted, you will lose knowledge on how your product is really performing and the impact of what you are working on.</p>
<h2>How to change from the &#8220;build only&#8221; to a &#8220;build measure learn&#8221; mindset</h2>
<h3>Educate your team</h3>
<p>When people start in product management, one of the first things we learn is to write user stories. Creating tickets on jira gives the impression that we are doing things. Whereas setting user research or working on the post launch analysis are often very generalistic terms that are not always defined into clear actions.  Has your team been properly educated and trained on how to write user interview guides?  Are they aware of how to run a post mortem?</p>
<p>Setting regular meetings about product methodology is one of the ways to make sure the team keeps educating themselves about product &#8220;outside&#8221; their own day to day.</p>
<h3>Educate your stakeholders</h3>
<p>Is everyone really aware that if X features comes at the top of the prioritization meeting, it does not mean it will be designed tomorrow and ready to be estimated the day after? Start by communicating the timeline of each main feature you are working on (at least the beginning of it if the dev effort is still pending). Use your deliveries measurement of the previous quarters &#8211; if we released an average of four main features/quarter worth x amount of story points the past three quarters, it is highly likely that we will not be able to do more than this with the same resources. The company’s stakeholder needs to be aware of this, and so should you, to set realistic expectations. Read this blog post <em><a href="https://www.mindtheproduct.com/easy-ways-to-engage-your-stakeholders/" target="_blank" rel="noopener">Easy ways to engage your stakeholders.</a></em></p>
<h3>Is your roadmap structured in the right way?</h3>
<p>This is maybe the most challenging part. We often structure our work (and hence the roadmap) per quarter. This set the dangerous idea that within one quarter, we need to align on the priorities, perform user research, write user stories, estimate it with the dev and, finger crossed, see the entire feature delivered. Depending on what you have the ambition to do, the quarter structure can likely do nothing else but urge you to push to dev something that has not been thoroughly prepared. Can you run your prioritization meeting in a different way? Can you make sure you are clear on what will likely only be researched and maybe tested within one quarter?</p>
<h3>Set team KPIs about measuring and learning</h3>
<p>When it comes to setting your team members KPI (or your own), ensure you do not only focus solely on features that got delivered, but also on the data built around it and the action done post release. Building dashboard, funnels, running x postmortem should be part of product managers quarterly OKR/KPI if you are looking to shift the mindset.</p>
<h3>Use the right tools</h3>
<p>To “build” we have tools like Jira. Make sure you also identify helpful tools with your team to help them structure user interviews, write interview guides, run workshops. It can be a shared Notion space, Miro board, Airfocus access. Share template if you need to do so. When it comes to measurement, make sure everyone is aware of what can be tracked and how (google analytics? Tools like Amplitude? Product database directly?)</p>
<h3>Set the right team structure</h3>
<p>It goes beyond managing expectations. Is there a realistic way, for your team structure, to deliver as much as what’s planned on the roadmap? Is the load balanced enough? Is your team growth plan coherent with the development team growth? It is worth considering involving a data analyst or hiring a data product manager in your team.  Product management is about being a generalist person surrounded by specialists. In this scenario, having someone helping structuring funnels and running analysis can make a difference.</p>
<p>Switching from a built focus to a concrete built-measure-learn focus can be a long shot. Often, you need to challenge a company culture that focuses above all on what they see getting deployed. It is your role to be proactive in voicing the long term advantages of measuring more efficiently the impact of what gets built. To ensure your team masters the entire product cycle. Communication remains key to get stakeholders on board. They need to be aware of the time measuring the outcome of a feature<span style="font-style: italic;"> really</span> takes. Our main focus as product managers should always be about ensuring we are solving the right problems. When it comes to adding real value, the quality of what is being worked on will always surpass the quantity of what can be delivered.</p>
<p style="text-align: center;"><a href="https://www.mindtheproduct.com/category/product-lifecycle/" target="_blank" rel="noopener">Discover more content on the Product Lifecycle.</a></p>

Switching back the focus from ‘Build only’ to ‘Build-measure-learn’

Ambre Josse

Read more

Comments