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

<a href="https://www.linkedin.com/in/suziejprince">Suzie Prince</a> is Head of Product for <a href="http://www.thoughtworks.com/products">ThoughtWorks Studios</a> building pioneering tools for software development teams. She has over ten years experience as a business analyst and product manager designing and delivering software that is valuable, usable, feasible, and desirable. On weekends, you'll find her either eating in San Francisco's Mission district or hiking in California's National Parks.

Suzie Prince

In the <a href="https://www.mindtheproduct.com/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/">first part of this series</a>, I explained what these buzzword-y &#8220;Continuous Delivery&#8221; (CD) and &#8220;DevOps&#8221; things are and started to touch on why you should care. But really, why should you care about these practices? Here&#8217;s why continuous delivery is a product manager&#8217;s new <a href="https://en.wikipedia.org/wiki/Best_friends_forever">BFF</a>.
<h2>Continuous Delivery is Transformative to Businesses</h2>
The main reason you should care about CD and DevOps is that it is transformative to businesses. Time and time again, organisations you admire, which produce products people love, reveal that they are doing Continuous Delivery and/or Continuous Deployment, and have a DevOps culture. Some good examples of companies that do this would be <a href="https://www.infoq.com/news/2014/03/etsy-deploy-50-times-a-day">Etsy</a>, <a href="http://techblog.netflix.com/2015/11/global-continuous-delivery-with.html">Netflix</a> and <a href="http://joshuaseiden.com/blog/2013/12/amazon-deploys-to-production-every-11-6-seconds/">Amazon</a>.
But CD and DevOps have not just helped Silicon Valley darlings to get big: CD has helped transform organizations all over the world. The Guardian is a <a href="https://www.theguardian.com/info/developer-blog/2015/jan/05/delivering-continuous-delivery-continuously">great example</a> of an older business who embraced the benefits CD brings by moving from a bimonthly release cycle to making tens of thousands of automated deployments a year. And the benefit for them? 
<blockquote>“What has been transformative for us is the massive reduction in the amount of time to get feedback from real users.”</blockquote>
Likewise, <a href="https://www.thoughtworks.com/clients/expedia">teams at Expedia</a> embraced CD, and within the first three months of using the new practices, they were able to run more experiments on their site than in the entire previous year. This ability fueled increased conversion rates, and led to significantly improved business performance. 
And these examples are not outliers, my friends, oh no. In the <a href="https://puppet.com/resources/white-paper/2014-state-of-devops-report/thank-you">2014 State of DevOps</a> report, Puppet Labs asserts with confidence that:
<blockquote>&#8220;high IT performance correlates with strong business performance, helping to boost productivity, profitability and market share.” </blockquote>
Likewise in the <a href="http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2681909">2015 paper by Jez Humble and Nicole Forsgren</a>, after analyzing data from the thousands of companies surveyed by Puppet Labs, they were able to conclusively show that: 
<blockquote>“IT performance positively affects overall organizational performance”. </blockquote>
This means that if you can up your IT and delivery game, you can up the game of your whole organisation. 
So there you have it. That’s the big, meaty, &#8220;you should totally do it!&#8221; justification screaming at you. Share it with your manager and your manager’s manager. 
<h2>Why Does Continuous Delivery Matter to Product People?</h2>
But how will the product manager, the marketing lead and the support gurus out there see the benefit of these practices in their day-to-day work lives? Let’s find out. 
<h3>It Will Help you Get Feedback Sooner</h3>
The main reason I love to deliver continuously is to get product feedback and validation sooner. The moment a new product or feature gets delivered to your customers, you start to get real feedback. Yes, there are a bunch of things you can do to test ideas before this with interviews, mockups, prototypes and user tests. <a href="https://www.mindtheproduct.com/find-right-customers-product-development-interviews/">I love these practices too</a>, and I am not advocating “build it and they will come”. Yet there is nothing like the rubber-hits-the-road feedback you get, having pushed a new feature to production, to really learn if it achieves what you hoped it would &#8211; or not. 
<h3>It Increases Responsiveness</h3>
When your team can deliver each and every build to production, you get to choose if each and every build goes to production. That means the time-to-market for the feature your customer asked for last week is, theoretically, just the time it takes to build and test it. If an idea is your top priority, why would you want to wait before delivering it? With CD, you don’t have to. No longer do you need to say “It’s built &#8230;  and will be released in December”, unless you actually want to. Instead you get to say: &#8220;The team pushed that to production while we were meeting. What do you think?”
This responsiveness works in a million ways to help you, the product manager. When the next <a href="http://heartbleed.com/">Heartbleed</a> bug comes out, you can get a fix out before lunch. When your startup’s biggest customer needs a change, you can get it done and deployed overnight. Or let&#8217;s say your once-great-but-slowly-fading industry giant is being killed by small, lightweight, agile competitors, and you’re in charge of delivering value to customers this quarter: Let CD be your friend. It will help you solve problems quickly, fix issues as they occur and stay on top of customer needs.
<h3>It Reduces Waste and Risk, and Saves Money </h3>
I would need numerous hands to count the number of times I have seen product managers and clients add scope to a release, horde bugs, or refuse to deliver an MVP because they thought the next release was the only chance they had to complete a feature. Just last week a friend of mine at a well-known healthcare company said:
<blockquote>“We missed the May release train, so we go live in December. And that means January because of holidays, so we’re just doing some extra stuff until then.” </blockquote>
Seriously, they are just “doing some stuff” for 10 months while they wait for the <a href="http://www.scaledagileframework.com/agile-release-train/">release train</a> to pull into the station. And I bet they&#8217;re not the only ones. 
If you’re not following me, here’s another example of what happens when you have to wait to release.
Imagine you have an app store and you want to test out whether a ratings and review system helps users find the best apps on your store. If you are delivering continuously, you could start with a simple &#8220;thumbs up&#8221; feature &#8211; User gets apps they like and so give a &#8220;thumbs up&#8221;. Does this solve your problem? If yes, sweet &#8211; you are done. Next problem please. If no, then let’s see if a five-star system is better. Or reviews. Or scores out of ten.
<h4>Continuously Deliver Small Chunks of Value</h4>
If you can deliver value incrementally and iteratively, you can deliver less at each stage, get to the right solution faster and get better ROI on your investments. If you weren’t delivering those features regularly, I bet you that you would design, develop and deliver a whole five-point rating systems with user reviews. Then when you were thinking about reviews, you’d realize that you need to run them through a moderator, or remove blacklisted words so the reviews don’t have profanity in them. Suddenly you’re building the world’s best text moderation tool, and all you wanted to do was show users which apps were great and which were terrible.
In this way (and by avoiding traps like those I outlined above), CD reduces waste. It saves your business from building stuff it doesn&#8217;t actually need, allowing you to focus on value. It helps you meet customer needs sooner. It helps you to quickly understand how your product strategy is working. It helps you get ahead of your competitor more quickly. It will help you with your &#8220;business hat&#8221; on, not just your &#8220;technical hat&#8221;.
<h3>It Facilitates the Creation of Higher Quality Products</h3>
<blockquote>&#8220;Quality is everyone&#8217;s responsibility. One of the significant benefits of CD is that it gives better visibility to everyone associated with a software project of the state of that project and so anyone can react to something that doesn&#8217;t look quite right.&#8221; 

&#8211; Dave Farley, co-author of Continuous Delivery</blockquote>
Although this might not be something you think about all the time, service quality is as important a “feature” as the actual code or tangible products you deliver. If your releases never result in a downtime, if your software is always available, if users never find a bug, then your customers’ opinions of your software will be higher, your referral rates will be higher, and you&#8217;ll have won your market.
<h3>It Leads to Releases That Are Sane and Calm</h3>
CD really does make releasing boring. My previous team complained to me that we hadn’t had a release celebration lunch for months. And it wasn’t because we weren’t releasing &#8211; we released everyday! It was just that we hadn’t had that adrenaline-fueled 24-hour period of “We will we get the feature out on time!” intensity followed by an evening unwinding in the pub that is often associated with a software release. 
When you get into the habit of releasing, it becomes a simple part of how your team works. At 4 p.m. every day, our teams asks each other “what is ready to deliver?”. The product team, marketing lead and support team discuss the implications of what&#8217;s ready, and they decide if they want to release or not. It’s that simple. (You’ll remember from <a href="https://www.mindtheproduct.com/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/">the first post</a> that this choice is one of the key differences between continuous delivery and continuous deployment). 
If the product manager wants to build a little more feature, they do that. If they want to test it with a few users first, they do that. If the marketer chooses to wait for PR reasons, they can do that instead. And if the support team says they need a particular fix for one high-value customer, it goes out. Calmly.
<h3>It Makes For Better Teams </h3>
As discussed in the <a href="https://www.mindtheproduct.com/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/">first post</a>, DevOps is about culture. In order to get these practices right, people need to collaborate, meaning work together, break down silos, share goals and act as a team! As you can imagine, there are many side effects of the push to DevOps that make your team function better. As shown in the scenario above, because you are talking about deploying every day, you are likely to be talking about quality every day, as well as delivering value to customers.
The more the team centers around these fundamental qualities of your software, the better the software is likely to be. Likewise, when team members are not siloed, they understand each other, and each other&#8217;s work, better. The less they are feeling the individual burden of a deployment or bug-fixing or a release test cycles, the more time they have to participate in team activities, share feedback, and help the whole team reflect and grow. It’s warm and fuzzy, and maybe even sounds idealistic, but it’s true in my experience. 
<h2>Too Good to Be True</h2>
Alright, I&#8217;ll stop here. Honestly, there’s actually more reasons that I can think of as to why I want you to embrace CD practices, but I don’t want to sound over-zealous! And I have to say: it won’t be easy. Transitioning to a continuous delivery and DevOps culture is not all sunshine, unicorns and rainbows. It’s hard work on the part of your engineering and operations staff. And you. You product people have got to work hard to get this change done. When you move to this way of working, expectations change, your way of working changes, you have to change. But when you do, the payoff is immense.
<hr />
<h3>Stuff You Should Probably Read</h3>
<ul>
<li><a href="https://www.theguardian.com/info/developer-blog/2015/jan/05/delivering-continuous-delivery-continuously">https://www.theguardian.com/info/developer-blog/2015/jan/05/delivering-continuous-delivery-continuously</a></li>
<li><a href="https://leanpub.com/buildqualityin">https://leanpub.com/buildqualityin</a></li>
<li><a href="http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2681909">http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2681909</a></li>
<li><a href="http://www.cio.co.uk/insight/r-and-d/three-views-on-continuous-delivery-3601806/">http://www.cio.co.uk/insight/r-and-d/three-views-on-continuous-delivery-3601806/</a></li>
</ul>
&nbsp;

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

Why Continuous Delivery and DevOps are Product Managers’ Best Friends

Suzie Prince

Read more

Comments