post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Podcast

Why should we care about building accessible products? – Dee Miller (Director, Product Strategy & Insights, Adobe)

Product Management

Get better at making better products: Vidya Dinamani, Founder and Partner at Product Rebels

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

A guide on implementing effective AI evaluations

The most common skill gap in aspiring product managers — and how to fix it

How to deal with information overload in product management

Meta bets big on AI while Lovable reaches $2 billion valuation: AI news roundup

June’s top product management reads

Simba is a product analyst at the fast-growing, London-based technology consultancy start-up <a>AND Digital</a>. He’s been a product manager in consumer media, academic publishing, fintech as well as retail and travel ecommerce.

Simba Sagwete

<p>Do you ever get tired of being asked, “when will it be ready?” Are you always hesitant to commit to a deadline so you can avoid being accused of being “late” when you don’t hit it? Because let’s face it, when you start to build a piece of software or a big feature you can’t easily decompose, you can never really say with any certainty how long it will take. You could spend a lot of time trying to anticipate all eventualities up front &#8211; but is there anything that sounds more <i>waterfall</i> than that? By the time you’ve done enough to be certain, you might as well have spent your time building the software.</p>
<h3>Agile vs Waterfall</h3>
<p>Long-term planning in an agile environment can seem like a paradox but what if there was a way to do long-term planning while still retaining agility? Scrum advocates planning no further into the future than the next sprint (1-4 weeks) but this simply isn’t how most businesses run; especially if they don’t have a culture built around delivering digital products.</p>
<p>Scrum is a great way of organising software development teams but it doesn’t answer the sorts of questions that CFO types love to ask like &#8220;how much will it cost and when will I get it?&#8221; This is doubly true in organisations that haven’t always built software and who are now under pressure to have a digital presence &#8211; organisations which need to build digital products and do so well if they’re to avoid being outdone by the startup crowd. If your business is building bridges or space shuttles, planning as you go along simply doesn’t wash.</p>
<h3>Managing Stakeholders</h3>
<p>Talking about the project manager’s favourite; <a href="http://smarterwebsiteowner.com/the-project-management-triangle/" target="_blank" rel="noopener">scope-quality-time/cost triangle</a> is one way to manage these seemingly conflicting needs between engineering and the business, but it can be quite a difficult concept to convey if your stakeholders haven’t worked with software development teams.</p>
<p><img decoding="async" class="aligncenter" src="https://www.mindtheproduct.com/wp-content/uploads/2018/05/0e0be95e-d65a-4852-880b-d6153c090665_Project-Management-Triangle.png" alt="A triangle showing the tradeoffs between scope, quality, and time" /></p>
<p style="text-align: center;"><em>The Project Manager’s Triangle </em></p>
<p style="text-align: center;"><em>Source: smarterwebsiteowner.com</em></p>
<p>The triangle paints a picture of a world where your only choices are between an underspecified or poor quality product versus one that meets all its targets apart from cost and time. In this world, business plans are built on clairvoyance: but what if someone told you there was a tool you can use to remove some of that guess work? Enter the release burn-up.</p>
<h3>The Release Burn-up Solution</h3>
<p>I&#8217;ve found it’s a solution that addresses how you make a commitment to spending the resources required to fulfil your business plan without pretending that you know what exactly you’ll get for that investment. It also avoids binding you to an impossible, inflexible scope and deadline which you can only ever hope to meet by compromising on quality. Or simply over-inflating your initial estimates for contingency, to the point where you might be unlikely to get approval to proceed in the first place.</p>
<p><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2018/05/fd737cc5-1f0d-4159-afd3-c9f8188752e9_Screen20Shot202018-04-1120at2011.35.56.png" alt="A release burn-up chart" /></p>
<h3>How to do it</h3>
<p>The release burn-up shown above can easily be created. Its components are as follows:</p>
<ul>
<li>Backlog &#8211; this is the solid blue line which indicates your best view of all of the work you have to complete to ship a product. You get it by adding story points of the stories you’ve already completed and your best understanding of what’s remaining in the backlog. It goes up and down and changes with every sprint as you re-estimate stories and add or remove stories/epics from your backlog</li>
<li>Projection &#8211; this is the solid grey line showing what your ideal velocity needs to be to hit your preferred delivery date</li>
<li>Actual velocity &#8211; this is the solid green line which includes your actual progress up to the present and a projection into the future (based on average from the last three or four sprints). The projection helps you to see whether you’re tracking to your ideal delivery date</li>
<li>The dotted lines show what would happen if you were to work at a rate faster or slower than your current average velocity. Where they intersect the blue line is when you might expect to deliver your product</li>
</ul>
<h3>Other key Ingredients</h3>
<p>The burn-up release won’t solve all of your stakeholder management challenges on its own. In fact, it relies on a few key ingredients to be effective, namely:</p>
<ol>
<li>A good roadmap which describes where you’re going if not necessarily the features you’ll be tackling at specific times. Roman Pichler’s goal-oriented product roadmap is a good template for communicating your high-level objectives in a transparent, flexible way</li>
<li>A layered backlog &#8211; which includes granular stories ready for the developers to work on. But it also includes a high-level map of all of the epics you might need to complete for a fully-featured product. This map need not live in task management tools and in fact, is probably easiest to understand in the form of Post-Its on a wall like MTP’s own <a href="https://www.prodpad.com/blog/product-tree-game/" target="_blank" rel="noopener">Janna Bastow’s product tree</a></li>
<li>Imprecise estimation &#8211; all of these high-level epics in your backlog can be given coarse estimates with the understanding that there’s a lot that’s uncertain and these estimates will be revised in the future as you understand more about what you’re trying to do.</li>
<li>A fixed, stable team working at a regular cadence so you can say with a high degree of certainty and precision, just how much you can do and what your velocity will be from sprint to sprint</li>
</ol>
<h3>The Best of Both Worlds</h3>
<p>A release burn-up isn’t a silver bullet that will solve everything but it does allow you to be empirical and transparent with your predictions. These still need to be communicated carefully so as not to bind your team to the fixed date and a fixed scope they were trying to avoid in the first place. It needs to be heavily qualified with words like  &#8220;things change&#8221; and &#8220;this is our best current view&#8221;. It definitely pays to prepare your stakeholders for a complete change in direction should new information suggest that it might be the right thing to do.</p>
<p>Similarly, it should also be clear that a team’s velocity ebbs and flows for all manner of reasons and an honest conversation about why that may happen is essential. Velocity is only useful in helping the team to improve the predictability of their output. It shouldn’t be used as a performance metric where not hitting a specific number indicates some kind of failure even when there are good reasons behind fluctuations.</p>
<p>Ultimately, stakeholders are only difficult to manage when they aren’t regularly reassured that the things they care about are in consideration. The release burn-up isn’t a replacement for communication and it doesn’t work on its own without other tools; you still have to do this bit yourself.</p>
<p>But it does reflect how modern software development teams actually work &#8211; which is to adapt and change direction as more information emerges rather than stick to a fixed view. In the right environment, with the right complementary tools, I&#8217;ve found that the release burn-up can be a really effective way of combining goals that seem at odds: carrying out realistic long-term planning without taking away agility or flexibility. And in my eyes, any idea that offers even a small chance of achieving this is worth exploring.</p>


core/freeform

Getting aligned with your exec team by Randy Silver

Collaborating with stakeholders to transform communication in healthcare by Jack Francis

How a Release Burn-up can do Some of Your Stakeholder Management

Simba Sagwete

Read more