post

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

Successful product management in companies where it’s least understood

Measuring critical user journeys – Javier Andrés Bargas-Avila (UX Director, Google)

A new way to look at applied experiments

Product survey findings: Only 15% of users are embracing AI features 

Building high-performing product teams: The PDLC approach

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Overcoming the 20% feature usage challenge

Product Management

Three product leaders to learn from at #mtpcon inside Pendomonium

With a career founded in writing, I pivoted to Product, enjoying the challenges offered by managing diverse products while bringing clarity of communication to my work. I&#39;m passionate about seeing how fast the space is evolving, and always interested to be part of the conversation, whether as a contributor, or writer.

Jon Horvath

<p>In this keynote session at <a href="https://www.mindtheproduct.com/mtpcon/san-francisco/" target="_blank" rel="noopener">#mtpcon SF+Americas</a> 2022, <a href="https://www.linkedin.com/in/jen-dante-6745321/" target="_blank" rel="noopener">Jen Dante</a>, VP of Product at Ancestry examines how over and under scoping cannot be eradicated from the product process, rather we can optimise them, based on the agility of our organisation, to deliver the most effective value.</p>
<p><span style="font-weight: bold;">Watch this video or read on for key highlights from the talk.</span></p>
<p>Jen begins by showing how over or under scoping is an inevitable outcome of the product planning process “for the exact same reason why most product ideas don&#8217;t work [&#8230;] it&#8217;s super hard to predict”. Finding ways to “balance the impact” and cost of this “over/under product management world” is crucial to delivering value, while supporting the organisation.</p>
<h3>Hacky vs polished</h3>
<p>During the planning process, product people must consider where upcoming work will sit on a scale of “hacky” to “super polished”. Jen recommends first questioning whether you’re really going to build a Minimum Viable Product (MVP), the smallest of a “series of investments” resulting in learning, and also whether you’ll be able to iterate on it.</p>
<p>An MVP <span style="font-style: italic;">should</span> have “iteration built into the concept”. Then if it works, you can invest further or move to something new without spending time on the wrong thing. Jen describes organisations that force teams to productise half-built work and then move on to something new without iterating. If you’re in an organisation like this “you cannot build an MVP”, Jen says, and recommends instead an MLP or Minimum Lovable Product; “the smallest amount of functionality, polished”. Doing so allows you to perform the same validation and learning exercises as part of your investment, but also gives you the security that if this work becomes a permanent fixture it has a level of polish. This can mean technical or design efficiency, which does not require immediate iteration or create problems if left untouched.</p>
<h3>Comprehensive vs limited</h3>
<p>In planning, you should also consider how complex something needs to be on a scale of “limited” to “comprehensive&#8221; – the greater the number and complexity of use cases it covers, the greater the chance of succeeding, but with a greater total cost.</p>
<p>To make this decision, Jen recommends thinking about how your organisation considers the cost of failure by assessing its risk tolerance. This translates to the number of attempts you will have to build and refine an idea before needing to move to something new. “The fewer bats you&#8217;re going to get, the more comprehensive the initial build should be,” Jen says. A more comprehensive build needs to give you the certainty that you legitimately tested the idea, “because if I don&#8217;t, and the thing doesn&#8217;t work, I&#8217;ll never get to build that use case”.</p>
<h3>Waterfall prioritisation</h3>
<p>Prioritisation is centralised in waterfall organisations with the same group meeting periodically to review a large backlog of projects ranked their projected return on investment (ROI). While “agile tends to be seen as the shining light on the hill,” Jen admits there are times when a waterfall-style planning makes sense, for example, when multiple teams must coordinate, manage dependencies or limited capacities of specialised resources.</p>
<p>In general, waterfall prioritisation favours:</p>
<ol>
<li>High quality ROI analysis to ensure reliable decisions are made when choosing which “great big idea” will be successful, and won’t require iteration.</li>
<li>Bigger projects are popular as they are more manageable and, when pitched, have more attractive forecasts due to their size.</li>
</ol>
<p>Scope creep is common in waterfall organisations, Jen says. Teams increase scope to maximise their chance of successfully delivering a project with only “one bite of the apple&#8221;, something which is the result of being unable to iterate. It’s accepted in some ways, she says, particularly when the person pitching a large project is not the person delivering it. But there will often be someone accountable for the original scope estimate and as a result of increased work, a reduction in resource efficiency.</p>
<p>Jen recommends managing scope creep by adjusting expectations and potentially “sandbagging” the scope of a project by inflating estimations upfront. This gives you some flexibility, while leaving room for ‘being the hero that cuts scope later’. If you’re in a waterfall organisation, overbuilding <span style="font-style: italic;">and</span> being successful is better than underbuilding, Jen says, allowing for some scope creep and even moving deadlines. Underbuilding and failing, as an alternative, will result in lost credibility in your delivery and future ROI predictions.</p>
<h3>Agile prioritisation</h3>
<p>Product planning in agile organisations is more continuous than in waterfall and happens alongside sprints or cycles. “Decision-making here is distributed,&#8221; Jen says, with teams owning their roadmaps, while strategy and KPIs are signed off at a higher level where decisions focus around moving metrics, rather than focusing on features.</p>
<p>Agile prioritisation favours:</p>
<ol>
<li>Multiple initiatives, as the organisation is essentially “buying an index fund, not an individual stock”.</li>
<li>Iteration is highly valued and viewed as the best way to increase the chance of success.</li>
<li>Data-driven decisions allow less experienced teams to make better decisions, and avoid productising things that don&#8217;t work.</li>
</ol>
<p>In order to deliver effective agile investments, teams can under-scope on scalability and design polish Jen says. Neither are directly needed to test whether something works, however, “you can&#8217;t really get away with not having that in your core product”. Once you want to productise Jen recommends doing code-hardening and scalability work, though it’s easier to justify than design, so it’s always good to reassess whether you’ll be able to iterate.</p>
<p>Risk tolerance is culturally specific, Jen says, and she recommends staying agile by under-scoping and looking to move on from any project where your tests fail, provided you’re confident you did quality testing, rather than investing further. Under-building may incur design and scalability debt, but “almost all the downside is in the overbuilding”, which means fewer opportunities to measure and learn, accusations of scope creep, and less iteration.</p>
<p>Jen closes by reminding us “it&#8217;s literally impossible to get the scope right [&#8230;] what you want to do is you want to optimise for how your organisation prioritises so the cost you pay for either having your builder overbuilt is minimised”. In waterfall it’s better to build too much than too little and deliver MLPs over MVPs, while in agile, it’s best to build too little, focusing on a true MVP. She says: “The biggest takeaway here is that the scope creep might actually be your friend.”</p>
<h2>There&#8217;s more where that came from!</h2>
<p><span style="font-weight: bold;">Explore more #mtpcon SF+Americas 2022 video content or use our </span><span style="text-decoration: underline; font-weight: bold;"><a href="https://www.mindtheproduct.com/content-a-z/">Content A-Z</a></span><span style="font-weight: bold;"> to find even more product management insights</span></p>
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

core/freeform

Reduce risk, fail faster: Experimenting across the product development lifecycle

Why does my product suck? by Jen Dante

Jon Horvath