Continuous Product Delivery: Why It's Critical to Release Frequently
Do you launch at least every two weeks? 6 misconceptions, 4 delivery principles, and 7 release tactics.
Hey, Paweł here. Welcome to the premium edition of The Product Compass.
Each week, I share actionable tips and resources for product managers. Visit the archive of ~90 posts to see what you might have missed.
And consider subscribing and upgrading your account for the full experience:
Every week, I speak with dozens of Product Managers.
While many (not all, unfortunately) have adopted Continuous Product Discovery, one issue keeps coming up: many still don’t release their products frequently.
So, in today's newsletter we’ll discuss:
Why Do We Need Continuous Delivery?
Continuous Delivery: Six Common Misconceptions
🔒 Four Product Model Delivery Principles
🔒 Seven Release Tactics Every PM Should Know
🔒 Conclusions
1. Why Do We Need Continuous Delivery?
As discussed in What Is Product Discovery, it’s safe to assume most of your ideas won't work.
This happens due to risks related to value, usability, feasibility, viability, and more — all of which can lead to significant waste and rework.
That’s why Jeff Patton and others in the Agile and product communities have been advocating for Dual-Track Development or Dual-Track Agile. Marty Cagan calls it “Continuous Discovery and Continuous Delivery.”
This approach involves two parallel streams of activities:
Continuous Product Discovery aims to discover the product to build.
Continuous Product Delivery aims to deliver that product to the market.
We can visualize it as The Triple Diamond of Product Management:
We often say that Product Discovery results in a validated Product Backlog, meaning that high risks are addressed before implementation begins.
But why do we need Continuous Delivery if most risks have already been addressed?
There are a few important reasons.
Reason 1: Product Discovery doesn’t eliminate risk completely
The reality is that Product Discovery can’t eliminate all risks.
First, it's impossible to identify every potential risk, and even if you could, it would be impractical to test every single assumption - experiments might be too expensive considering the risk or take too much time.
Second, while experiments can provide varying levels of evidence, they are never 100% conclusive. The ultimate test is real customers using your product in the real world with their real data.
It's normal and expected that many ideas require additional iterations after the launch.
Lastly, the market and your business environment are constantly changing. What was true a few months ago may no longer be true today.
Reason 2: You can’t fully learn without releasing
Even with the best research and experiments in Product Discovery, the ultimate validation and learning happens when the product is in customers' hands.
It’s not just about fixing issues you haven’t predicted.
Continuous Delivery helps you identify new opportunities and uncover insights that can shape your future objectives and inform your product strategy.
Time-to-learn (TTL) is arguably one of the most critical product metrics.
Reason 3: There is no value without release
A product only generates value when it is released. Even the best features are worth nothing until they serve the customers.
Continuous Delivery creates an ongoing cycle of creating, validating, and capturing value.
It also enables you to achieve a faster return on investment (ROI), which you can reinvest in to further improve your product.
2. Continuous Delivery: Six Common Misconceptions
Let's address six common misconceptions.
Misconception 1: Internal deployments are enough
It’s great if your engineers and DevOps have continuous integration and delivery (CI/CD) and automatic testing that enable continuous internal releases.
But if those deployments are limited to a testing environment, and that's often the case, it’s far from sufficient.
You need to deliver new product versions to the users regularly. As Marty Cagan defines in TRANSFORMED, this means launching at least every two weeks.
Misconception 2: You need to compromise quality
Some believe that releasing early means compromising quality. But this should never be the case.
What we compromise can be capabilities and features, never quality.
A good example is Confluence Databases, which has surprisingly few features:
It doesn’t support 90% of the capabilities you might recognize from tools like Notion or Airtable, such as grouping records, creating new records inline without opening another database and creating calculated columns.
But it effectively solves a few selected problems, allowing Atlassian to quickly gather feedback and learn how (and if) customers will use it.
You might ask me about a more controversial example: Meta released Threads in July 2023 with a poor feed, lacking hashtags, search, or direct messages.
This approach led to 100 million signups in less than five days post-launch, but it also faced immediate backlash and declining engagement:
But the trend has since reversed. The recent stats of monthly active users (MAU):
October 2023: 100 million MAU
February 2024: 130 million MAU
April 2024: 150 million MAU
July 2024: 175 million MAU
August 2024: 200 million MAU
The idea of learning with the users wasn't necessarily bad. Later in this post, I’ll suggest how Meta could have improved its release.
Misconception 3: Frequent releases mean building in public
Frequently releasing new features and sharing decision-making processes publicly is part of a “building in public” strategy.
While this could offers many benefits, such as increased user engagement and real-time feedback, it’s not the same as releasing frequently. Importantly, building in public can increase the risk of exposing your ideas to competitors.
That’s why it's important to understand that you can release often without revealing every detail. Most FANG companies frequently experiment in production and release new features, but they maintain privacy around their decision-making, roadmaps, and challenges.
Misconception 4: It can’t be done in B2B
There is a common belief that Continuous Delivery works only for consumer-facing products (B2C), where rapid iterations and quick user feedback cycles are more common.
But that's simply not true.
In fact, especially in B2B, where you might struggle with finding customers to talk to, releasing early allows you to:
Test whether customers desire your idea (e.g., the feature stub experiment).
Analyze data to measure how customers interact with your feature. Your email messages and surveys might be ignored (say, 2-5% conversion rate), but 100% of the customers interacting with your feature will leave a digital trace.
Invite your customers to a conversation, e.g., by letting them suggest improvements or initiate contact with the product team.
Companies like Salesforce, Atlassian, and Slack continuously deliver updates to their enterprise customers.
Misconception 5: Frequent releases will overwhelm users
Some worry that frequent releases will confuse or overwhelm users.
But in reality, the opposite is true.
The key to successful frequent releases is to make them gradual and seamless. Depending on the context, you can also allow users to control their exposure to new experiences.
It's typically the large, infrequent releases that feel disruptive or make users feel like they're interacting with an entirely different product.
Misconception 6: We work in Scrum, so we are good
In Scrum, there is a Sprint Review at the end of each Sprint, where you can review progress with stakeholders and decide on further adaptations.
However, Scrum doesn’t explicitly mention releasing anything.
Let me be clear: your Sprint Review is not enough. You can't reliably measure outcomes until people use the product "for real."
Stakeholders' opinions, even if some of them are your customers, might be irrelevant. And in my experience, even if you perform a workshop, those opinions are not necessarily more valuable than what you can learn from experiments conducted before implementation.
Therefore, it’s essential to release regularly, measure results, and learn from them.
Two New Courses
Before we move forward with Continuous Delivery, I’m excited to announce that I'm finishing up two new video courses:
From Strategy to Objectives Masterclass:
We’ll discuss the importance of Product Vision, how to craft Product Strategy, and how leaders can empower teams with meaningful problems.
As in the Continuous Product Discovery Masterclass, you will receive digital, verifiable credentials after passing the exam.
This course will be released on September 21, 2024
Product Innovation Masterclass:
We’ll discuss the Initial Product Discovery (including Business Model, Positioning, and Value Proposition), strategies to achieve Product-Market Fit, and when and how to ignite growth.
As in the Continuous Product Discovery Masterclass, you will receive digital, verifiable credentials after passing the exam.
This course will be released on October 26, 2024
🎁 The courses are valued at $298 in total, but all current premium subscribers and those who upgrade by the end of September 2024 will get them for free:
So subscribe and upgrade your account, if you haven’t already, for the full experience:
3. Four Product Model Delivery Principles
Keep reading with a 7-day free trial
Subscribe to The Product Compass to keep reading this post and get 7 days of free access to the full post archives.