3 Reasons Why a Sprint is Not a Product Release

A very bright product and engineering leader at one of the world's largest media companies 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.

As the CEO of Aha! (product roadmap software), 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 how best to organize teams around them. 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 the following to be true. A sprint is not a release. And releases are still important. Releases represent the big ideas that you are bringing to customers and the market.

Having clarity around what a release means to you and how they are managed drives accountability and responsibility. However, lots of teams move forward without such agreement and transparency They often do, suffer, and don't even know why delivering product feels so painful.

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. 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.

However, when we start thinking about digital goods many of us have lost our way. That's because we have convinced ourselves that it's ok to think about the technology we deliver separately from organizational (or even) customer readiness to adopt it. Many now wrongly think that 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 that 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 Web site, call support, try to reconcile what they now can do with what they did the day before, and want to be able to explain to their boss what's new.

So, when our customers ask us how they should think about releases in Aha! we provide the following guidance and provide these suggestions. We suggest that this guide is useful for any team that is building a digital product and debating how to get everyone working together on releases.

It takes a product team
This is the first principle and 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. 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 needs to be completed -- in one place. 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.

Take responsibility
Clear ownership drives accountability. Even though you might work in an agile environment with sprints -- your job is to see the bigger picture. There is a reason the product manager is often considered to be 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 but carries on through every interaction.

The key is to start from the perspective of your customer and orient your releases around delivering value to customers every way possible. If you do, you will set up your product and team for success.

What does a product release mean to you?

Also, if you would like to read my future posts then please click 'Follow' at the top of this article and feel free to connect via Twitter

__________________________________________________________________
ABOUT BRIAN AND AHA!

Brian seeks business and wilderness adventure. He has been the founder or early employee of six cloud-based software companies and is the CEO of Aha! -- the world's #1 product roadmap software. His last two companies were acquired by Aruba Networks [ARUN] and Citrix [CTXS].

Signup for a free trial of Aha! and see why 10,000+ users on the world's leading product and engineering teams trust Aha! to build brilliant product strategy and visual roadmaps.

We are rapidly growing and hiring. Rails Developers. Customer Success. Marketing Campaign Manager. Product Manager. Join a winning team -- work from anywhere in the US and be happy.

Follow Brian on LinkedIn and @bdehaaff

Follow Aha! @aha_io