Saying the word “plan” to an Agile team is a little like saying “mouse” to a room full of elephants. That is to say: you can expect a lot of terror over something that shouldn’t be scary at all.
To Agile teams, adding more plans and meetings can seem like a slowdown, which feels scary given that the Agile methodology is all about speed and deployments. But there’s a danger to constantly deploying new product features as they’re developed: you can become so feature-focused that you forget about the overall vision and strategy for your product’s success.
The truth is: most Agile teams would be better served if they created a product release plan. Below, we’ll talk about why that’s true, and how you can take an agile approach to this planning, so you hang on to your flexibility while still accounting for the needs of your internal and external stakeholders.
Advantages of Planning for a Product Release
Your product release plan is an internal document, to be shared between the relevant teams in the weeks leading up to a major release. In terms of granularity, you can think of it as a bridge between your product roadmap and your backlog. Whereas the roadmap is a high-level document that lays out the strategy and goals for a product, your release plan is a map of the coordinated series of events that need to happen around the release of a new product or feature set.
But a release plan isn’t a glorified backlog; it’s a chance to return to your original vision, to see that your product is still solving the user problem you set out to address. When deciding how to prioritize features, you should rate their importance by asking: why does this matter to the customer?
When you plan your release like this, you may end up discovering that you can postpone building certain features in favor of others that will more directly fit with your customers’ needs and your overall business strategy. In other words, your product release plan is a way to make sure you’re adding value, instead of simply adding more features.
The other primary goal (and advantage) of a product release plan is to get support from other teams throughout the company. If you don’t plan for a product release, you risk a breakdown in internal alignment. If you launch a feature that the customer success team isn’t prepared for, you might miss the chance to get your users on board. Likewise, you could be facing a disaster if your sales team starts selling a feature before your development team is done with it.
Product Release Plans Create Cross-Team Collaboration
We’ve all seen great products doomed by a botched release that leaves customers howling to go back to the old way of doing things. The only way to avoid this fate is to have proper cross-team collaboration; looping in other teams whose entire job is to act as a bridge between your product and your customer. Facilitating that kind of collaboration is the most central function of a product release plan.
The process of mapping out your plan should start at a cross-team release meeting, where you can get all relevant stakeholders in alignment. Once you’ve heard from all these teams, you can design your plan with a clear sense of how to structure the remaining backlog, and where dependencies are lurking.
For this to work, you need to encourage active participation from everyone present, so it’s important to keep this meeting small—try and obey the “two-pizza rule.” But here is a list of the people you want in that room, and why it’s so important to hear what they have to say.
- Product team: As product manager, you’re there to remind everyone of the customer problem this product was designed to solve and prioritize the remaining work to be done. You’re the product owner, so you own this meeting, and balance the inevitable tensions between the other teams. Does sales want to drop a product by the end of the quarter while engineering is asking for more time? This is your chance to weigh the technical needs against the business needs.
- Engineering team: Your developers should come to this meeting ready to share progress, give a demo, and alert everyone else to any trouble spots they foresee with implementation. If you’re a truly Agile workplace you should be used to regular releases (whether you’re doing it after every sprint or just a few times a year), and everyone should essentially be on the same page about what constitutes your minimum viable product (MVP). Even so, this meeting is when the product team and engineering team agree on a final definition on what has to be completed before you call this particular product “done.”
- Sales and marketing team: Based on what product and engineering bring to the release planning meeting, sales and marketing can devise a product launch strategy and plan a release announcement to get new and existing customers excited about this product. But they’re not just there to handle your social media campaign: these team members can offer real insight into how to prioritize the remaining backlog. If you’re debating whether to push a particular functionality to the back of the line, but they tell you customers have been clamoring for it, that needs to inform your plan.
- Customer success team: It’s absolutely crucial to give these folks as much information as possible about the current state of your product. With that knowledge, they’ll decide how to educate users on the new product, identify which customers you most need to cater to in this release, and decide which feedback metrics will be most useful to monitor the response. Remember, your product can’t be a success unless you’ve agreed ahead of time about what success is.
You’re not ceding your status as product owner by inviting feedback from other teams, and you don’t have to take everyone’s advice (in fact, that will probably be impossible, because different teams have different priorities). But by aligning ahead of time, rather than just releasing and having everyone else play catch-up, you let all these experts tailor their strategy to this specific product. Beyond this, bringing these other stakeholders in ahead of time ensures that they’ll feel shared ownership of the release plan, which increases their commitment to its success.
You Can Keep an Agile Mindset When Making Your Release Plans
Using product release plans is more common in waterfall workplaces, or for Agile teams making physical products, but you can still apply them to SaaS settings by holding onto the core tenets of Agile.
Assign Deadlines with Care
As an Agile product manager, you have to strike a balance between committing to deadlines when work will be done and building uncertainty and flexibility into your release plan.
At some point, of course, you’ll need to agree on some specific dates for work to be completed, so you can successfully coordinate across teams. On the other hand, there’s a real danger of putting yourself at the mercy of a deadline and releasing before you’ve actually achieved your MVP. To keep your release plan Agile, you can align on internal deadlines for specific tasks to be done, but with the understanding that these are subject to change. It’s important to be honest with your collaborators that software development often takes longer than you think, and you may have to shift your priorities in response to internal or external forces.
Don’t try and set a hard and fast release date when you sit down to start plotting your release plan. Instead, give your team a release window, that you can narrow to a specific release date when you’re confident that your product is actually ready. While you can let sales and marketing start creating some buzz about the release, don’t make promises to customers you might not be able to keep.
Don’t Plan Product Releases Months in Advance
Your product release plan is an internal document that’s designed to take you through the home stretch of a product’s design, and that planning should take place when the bulk of the actual coding is done. You’re tying your product back to your product roadmap, but this isn’t your product roadmap.
It’s important to differentiate the two because no truly Agile team will commit to being tied to a release plan before they really understand the development challenges they’re facing. There are too many dependencies you’ll only be able to identify as you work. Planning for release before you know what your product will actually look like is at best a waste of time, and at worst, can chain you to a plan that can’t evolve with changing circumstances.
Break Your Release Plan into Incremental Steps
Agile is all about breaking big jobs into small tasks, and that will serve you well as you visualize the remaining work to be done before you release. There are several methods for this visualization, but any effective technique should be as much about the why of the remaining backlog as the what. Keeping your high-level vision, and your customer’s needs in mind is how release planning helps you avoid the “features for the sake of features” trap.
One popular method for visualizing your tasks is story mapping, which is particularly useful for keeping your user front-and-center as you prioritize your backlog.
The Scrum website also recommends using the Goal-Oriented Product Roadmap to identify your next steps, while constantly tying them back to your overall goals. Whatever your method, the final product should be structured with a minimum of clutter, so members of each team can easily refer back to it when they need a reminder of why you’re doing what you’re doing in the order you’re doing it.
It’s important to note that there’s no need to undergo this kind of planning for every sprint and every minor update. Release planning should be reserved for releases that will significantly impact users, such as a new product, a significant new feature, or if you’re releasing to a new platform or a new market.
Your Release Doesn’t End When Your Product Launches
Your product release plan should serve as a reminder that “release” isn’t defined as the moment your product becomes available to users: it encompasses an entire period of time before and after your release date. Even if you’re an agile team and you’re pushing releases frequently, you need a plan to announce the release and collect feedback afterward. And by looping in other teams on your planning, you can release with the understanding that when the development team’s work on a product has wrapped up, the customer success team’s work has just begun.
One of the most critical parts of a release happens when you collect and analyze user feedback, to determine if your product has done what it set out to do. You should be monitoring comments, seeing how many users are actually using the update, and how it’s landing with your VIPs and power users.
One easy way to figure out if your feature resonates with users is the concept validation methodology. This method presents users with a one-question survey gauging their sentiment when the product is announced, and another which asks why they feel the way they do.
What you learn from gauging user response is immensely valuable information and it shouldn’t stay siloed with the customer success team. Everyone who was in your cross-team release planning needs to understand what worked and what didn’t, so that knowledge can inform the next release.
Plan Product Releases with Intentionality and Flexibility
For SaaS product managers, designing a product release plan is like planning a cross-country road trip in which fifteen friends and one incontinent puppy are packed into three separate vans. You can’t be too rigid in your planning, or fail to account for the pit stops you’ll need to take along the way. On the other hand, you can’t just set off for the horizon without a roadmap and expect to all end up in the same place. But when you bring your Agile mindset to a product release plan, you can adapt to change and plan for detours, without ever losing sight of your destination.
