3. Release Size in Product Management

In this document, we will discuss the concept of release size in product management, focusing on determining the ideal size for product releases, the benefits of smaller releases, and the trade-offs that come with different release strategies. We'll also share examples from various companies and tips on how to manage releases effectively, including considerations for timelines, scope, and team dynamics.

1. What Is the Ideal Size of a Release?

The answer to this question is, as many product managers would say, "It depends." There is no one-size-fits-all answer when determining the ideal release size. The size of a release should be influenced by several factors, including the product's goals, the team's workflow, and the organization's ability to adapt to new information during the development process.

Benefits of Smaller Releases

Smaller releases offer several key advantages:

1. Focus on Priorities: Smaller releases allow teams to focus on what is most important at the moment, delivering core functionality or key improvements faster.
2. Faster Delivery: When the scope is small, releases can be delivered more frequently, enabling users to benefit from new features or improvements sooner.
3. Constant Learning: Smaller, frequent releases provide more opportunities to gather feedback and adjust priorities based on real-world usage and user input.
4. Team Morale: Regular, incremental progress boosts team morale as there are more opportunities to celebrate achievements and reflect on lessons learned in retrospectives.
5. Flexibility and Adaptability: With smaller releases, it is easier to pivot or adjust priorities if new information or requirements emerge.

However, it's important to find the right balance—small releases shouldn’t be so small that they don’t deliver meaningful value to users. Releasing something every day may be too frequent, but regular, smaller releases help maintain a dynamic workflow without overwhelming the team or users.

2. Examples of Release Sizes from Real Companies

RD Station (2015)

At RD Station, teams worked in 1-week sprints, and each release was planned over a cycle of four sprints. Release planning involved all teams in the company, who synchronized their efforts and presented their plans for the next four sprints. However, this process had some drawbacks:

• Challenges of Fixed Timeframes: With fixed cycles, the team had to carefully balance scope, cost, and time. This approach required a lot of upfront discovery work, creating a disconnect between discovery and delivery. If new information arose during the development cycle, it was hard to pivot without losing time and resources.
• Rigid Synchronization: All teams working in parallel on synchronized release cycles made it difficult to adjust priorities mid-cycle. This rigidity sometimes led to delays or scope reductions.

Agile Content (2014)

At Agile Content, the team worked in 3-week sprints, with each sprint leading to a release. This release cadence included two weeks of development and one week dedicated to testing, integrations, and deployment. For on-premise customers, however, releases were much less frequent—sometimes as long as three months between releases. This longer gap created challenges:

• Delayed Feedback: Long gaps between releases meant customers received large, complex updates all at once, which made it harder to communicate changes and gather feedback.

RD Station (2018) - Kanban

By 2018, RD Station had shifted to a Kanban workflow, where each prioritized item led to a release. Releases became more dynamic, with variable timeframes based on the scope of the work. This approach had several benefits:

• Scope-Driven Releases: Releases were based on the value being delivered rather than arbitrary time constraints. Teams would assess whether a particular deliverable made sense as a standalone release and estimate how long it would take.
• Demand-Driven Planning: Release planning was done on demand when the current release was nearing completion, ensuring that planning efforts were aligned with the team's progress.

Involves (2018 vs. 2020)

Involves underwent a transition between 2018 and 2020, evolving from a less synchronized sprint and release schedule to a more integrated, Kanban-driven process:

• 2018: Releases were not synchronized across teams, and the timing varied by product type (web vs. mobile). Web releases occurred weekly, while mobile releases were less predictable. This lack of synchronization often led to delays in delivering features that spanned both web and mobile platforms.
• 2020: The company shifted to more integrated squads, where mobile developers were part of the same teams as web developers. This structure allowed for more cohesive releases that delivered complete features across platforms.

Xerpay (2021)

At Xerpay, the team worked in 2-week sprints, with releases sized to fit into the sprint timeframe. As the company transitioned toward a Kanban system, releases became more flexible, allowing for more tailored scopes and timeframes. The focus was on delivering valuable features in smaller chunks, which helped the team maintain a steady pace of delivery while avoiding overly long development cycles.

3. Balancing Scope, Time, and Resources

The concept of the triple constraint in project management highlights that every initiative involves balancing three key factors:

• Scope: The amount of work being done.
• Time: The deadline for completing the work.
• Cost/Resources: The team and resources available to do the work.

A key challenge in release planning is ensuring that these three constraints are balanced. If you increase the scope of a release, it will likely take longer or require more resources. Conversely, if the timeline is fixed and resources are limited, the scope must be reduced to fit.

Understanding the triple constraint helps product managers make informed decisions about the trade-offs between scope, time, and resources. If the team is reduced, the release will either need more time or a smaller scope.

4. Release Size Recommendations

Granularize Deliverables

It’s important to break down large deliverables into smaller, manageable chunks that still provide meaningful value to users. Each release should be substantial enough to solve a problem or deliver a key improvement, but not so large that it takes months to complete.

Avoid Granularizing Too Much

While it’s crucial to break down work into smaller tasks, be mindful of over-granularization. Delivering a feature that is incomplete or lacks core functionality can lead to poor user feedback and lower confidence in the product. For example, releasing a feature that allows users to create something but not edit or view it in a report could frustrate users.

Small Releases for Regular Learning

Frequent, smaller releases allow for quicker feedback and iteration. It’s easier to course-correct when the team is delivering and learning from users on a regular basis. Teams should strive to release features that are small enough to be manageable but complete enough to offer real value.

Structure Deliverables Around Real User Value

When planning a release, focus on delivering something that completes a user journey or solves a specific problem. It’s important that each release has a clear purpose and provides tangible benefits to users.

5. Conclusion

The size of a release can vary depending on the product, team, and company context. Smaller releases have clear advantages in terms of focus, flexibility, and learning, but it’s essential to find the right balance between scope and value. By prioritizing small, incremental releases that deliver real value to users, product teams can ensure faster feedback loops, improved morale, and more responsive product development processes.