Helping founders and product people grow their business and craft.
Subscribe to ‘The PBL Newsletter’ for regular posts on Product, Business and Leadership.
Read previous posts of ‘The PBL Newsletter’
Dual Track: Continuous Discovery & Delivery
Below you’ll find a write up on:
What is Dual Track (continuous discovery and delivery) and how does it work
Why you should move away from project discovery towards this model
The mindset that you need to make it successful
and common practices that I’ve found helpful
Release ≠ Launch
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.
Long Backlogs and Unmeasurable Work
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)
Break Outcomes Down, Not Initiatives
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.
When Did You Last Remove a Feature?
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.
A Feature is not 'DONE' until it's had IMPACT
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.
The Messy Nature of Product Development
Building products is messy, uncertain, and non-linear. I’ve always found trying to explain this to someone who hasn’t experienced it difficult.
Ditch Epics & User Stories and Focus on Outcomes
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.
8 Different Ways to Organize Your Backlog to Make it More Impactful
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)…
Alignment through OKR’s and Hypotheses
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.