A very bright product and engineering leader at one of the world's largest media companies once asked me a question -- "What's a product release?" I had never thought a release needed explanation, but sometimes the simplest questions are the most profound. In the past, I have written about other seemingly simple questions, including, "What's a product?" So, in hindsight, I should not have been surprised when this question was posed.
The question was as much about the mechanics of a release as it was about the best ways to organize teams around them. He was asking a human engineering question veiled as a "best practices to product management" inquiry. And in a world where teams are increasingly heads-down on the technology due to "agile ambitions," it's no wonder that the very concept of a release needs attention.
I believe that a sprint is not a release. But releases are still important. They represent the big ideas that you bring to customers and the market.
Having clarity about what a release means to you -- and how it is managed -- drives accountability and responsibility. However, lots of teams move forward without such agreement and transparency. They tend to suffer in silence instead, then wonder why delivering products feels so painful.
But the moment you start using an application like Aha! you are forced to think more seriously about your product releases. You must confirm how to deliver new software efficiently -- even when everyone wants to keep sprinting.
Getting teams properly aligned around the notion of a cross-functionally supported release seemed obvious to me. I really never thought of addressing this most fundamental product management and roadmap question until the customer asked:
"How would you recommend that we manage releases? We are a widely distributed and dynamic team. We need to rally many groups and stakeholders to deliver functionality that customers can use. Other non-technical groups have given up on us. That's because we often struggle keeping the entire team in sync and on schedule. What's the best practice for thinking about releases?"
In a world of physical goods, defining a release is fairly straightforward. In most cases, it is when the product can be wrapped and sold on a shelf. And that act creates a forcing factor for most to be organizationally ready. A solid definition of a release for a physical product is something akin to: the date that customers can purchase the product. Even if there are many components that go into the final offering, the item that customers are looking for -- and the final deliverable -- is generally clear because it can be bought and supported.
But when we start thinking about digital goods, many of us lose our way. We have convinced ourselves that it's okay to think about the technology we deliver separately from organizational or customer readiness to adopt it. Many now (wrongly) think the former is enough to deliver great new software and the rest will take care of itself.
When we talk about virtual offerings like software -- especially cloud-based services -- teams often confuse rolling out new features with the total customer experience. This is why a sprint is not a release. A release is the date when the company is ready to deliver a new customer experience and support every customer interaction point associated with it -- not just the act of providing access to new technical functionality.
Just because you and your engineering team are oriented around the technology stack does not mean that's all customers care about or need. Don't mistake internal, technical bits with how you should manage releases or set up a team to successfully deliver them. Customers read your website, call support, and try to reconcile what they can do now with what they did the day before. They want to be able to explain what's new to their boss.
So, when our customers ask us how they should think about releases in Aha! we provide the following suggestions. This guide is useful for any team that is building a digital product and debating how to get everyone collaborating on releases:
It takes a product team
This is the first principle; everything else is meaningless if you get this wrong. It's critical to organize a cross-functional product or core team of leaders who can provide insight into and take ownership over key efforts within their organization. This is necessary to prep for providing customer delight at every turn. A typical team is led by product and includes leaders from program management, sales, support, ops, and marketing. This team should meet weekly, have real authority, and be responsible for all aspects of a release -- including any required internal communications and trainings.
Track technical and non-technical deliverables
If you are thinking more broadly about the entire customer experience, it's obvious that you need to track all of the technical and non-technical work that must be completed. And this needs to happen in one place. Using one tool ensures that everyone stays in sync as dates or plans change. How many times have you found that a date has slipped and most of the organization has no clue? This is where automatic product team notifications -- and using a consistent template of phases and milestones for every new release -- can help get you ready and make it clear who needs to do what. For example, if you are delivering a few bug fixes and incremental enhancements, you probably will not need to rev the go-to-market engine.
Take responsibility
Clear ownership drives accountability. You might work in an agile environment with sprints. Nevertheless, your job is to see the bigger picture. There is a reason that the product manager is often considered the CEO of her product. So, as you think about all aspects of the product experience, you should be the customer champion and help each group be its best.
Hopefully, it's clear that a release is everything that impacts a customer. It starts with the new technology and carries on through every interaction. The key is to start from the perspective of your customer and orient your releases around offering value in every possible way. If you do, you will set up your product and team for success.