Deploy = is the process of making software available on a target environment. This could be a production environment, but it also might not be.

Release = is still a technical activity, but it’s where you make the newly deployed changes available to your users.

Launch = is a strategic activity (non-technial) where you inform the market about specific features and changes.

From my experience, there are two common reasons why I see product backlogs become long and unmanageable.

​A lack of strategy​ and, therefore, backlogs become a dumping ground for any and every idea.

Working big, breaking down big solutions, rather than breaking down the outcome (refer to ​my last post​)

A common pattern I see in many of the product teams and companies I coach is that they’re doing a lot of incremental work but little-to-no iterations.

They have this big idea (often framed as an initiative) and become solely focused on breaking it down. The initiative becomes a series of epics, and that epic becomes a series of user stories, and so forth.

80% of features are never or rarely used. The best Product Companies known this which is why last year, Spotify announced it would be sunsetting Spotify Live, Medium sunset their Profiles and Themes, and Airbnb has hit paused on Experiences to focus on their core offering.

If we can all agree that the outcome is important, not the output (i.e. a feature) then we shouldn't consider any item of work as 'done' until it's created the desired outcome.

Building products is messy, uncertain, and non-linear. I’ve always found trying to explain this to someone who hasn’t experienced it difficult.

When I've helped organisations become more outcome/product orientated, more often than not, I've moved them away from 'epics' and 'user stories' and towards things like one-pagers, opportunities, hypotheses, etc. Why? Because they’re are better tools for facilitating outcome thinking and experimentation.

Jeff Patton was one of the first people to challenge the notion of a linear backlog when he created — and then wrote the book — User Story Mapping (more on that later)…

When you start to scale and have multiple products and/or teams, alignment becomes paramount. The general trap is to try and control things to stop misalignment from happening by adding many layers of bureaucracy. This stifles creativity, does very little to keep your people motivated and usually degrades team velocity.