I’m annoyed!
We’re in 2023, and the feature factory is everywhere. This situation is heartbreaking because teams cannot unleash their true potential when creating features is all that matters. Shall we join forces and transform this situation?
I’m writing this guide to give you an orientation on what increases the chances of creating value through collaboration inside and outside the team. I don’t promise you any successful recipe, but I do dare to say if you follow the insights I’m about to share, chances are high that you will escape from the build trap quickly.
Yet, I must warn you this is another extensive guide. It’ll take around half an hour to go through, and you may sometimes need to return to grasp the content. If you’re willing to do what it takes to overcome the feature factory, this guide is for you, and I want to help you.
Let’s start!
Product Delivery
When I first landed in a team wearing the Product Owner hat, I thought my role was to optimize delivery. I did my best to keep the team delivering at their maximum speed. What I missed was the connection between outcome and output. Back then, I didn’t know about it or even talk about results beyond meeting deadlines and following plans. That was my faulty perception of product delivery.
Following a plan and delivering all features from your product backlog isn’t a meaningful strategy. On the contrary, that transforms teams into feature factories. Sadly, product delivery is full of anti-patterns that get in the way of creating value. Some common traps are:
Every request you receive becomes a product backlog item
Teams strive to implement perfect features instead of learning
Delivering more features is the definition of success
Nobody dares to remove a live feature from the product
Commitment to output instead of outcome
A common mistake is separating discovery from delivery and having a handover between teams. One uncovers what’s relevant, and the other builds it. That’s another type of waterfall that won’t help you create value faster. As I already said, discovery and delivery are intertwined. One depends on the other. That’s why one team should be responsible for both sides.
Product delivery isn’t following a plan. It’s about creating value at a steady pace.
Making that possible requires a learning mindset. Some solutions will go wrong, even though you have strong evidence. Other solutions will justify high investment because they indeed create value for customers and businesses. The challenge is identifying which solution is which, dropping bad ones, and doubling down on the promising ones.
During this guide, I will walk you through the most critical aspects of product delivery. The aspects I will mention are related to how to apply meaningful product delivery in practice. It doesn’t matter which framework you use or don’t use. Whether you work with Scrum, Kanban, Scrumban, LeSS, or something else, you will get applicable insights from this guide.
The elements I will cover are:
Product Backlog: Organizing opportunities you want to pursue
Refinement: Sharpen backlog items to build a shared understanding
Alignment: Decide what to focus on and progress
Getting Things Done: Delivering value
Using Tech Debt: Accelerate learning through wise use of tech debt
Review: Evaluating results and working with stakeholders
Improve: Take action to grow as a team
I will elaborate on every item to help you understand how to use these elements and which common traps you can expect to find.
1 - Product Backlog
Managing the product backlog represents one of the biggest traps for product teams. Product managers can descend to backlog managers by spending most of their time writing backlog items and adding details. Software engineers get trapped by implementing requirements and fighting against product managers when details are missing. And product designers have to create high-fidelity prototypes to enable teams to match expectations.
Whenever you observe any of these behaviors, it’s a sign you need to step back and challenge the status quo.
The product backlog isn’t a wishlist to have everything everyone wants. It’s a means to organize tasks that enable product teams to reach goals. Ideally, the product backlog emerges from a goal. Realistically speaking, that’s seldom the case.
Most teams have a running product with tech debt, bugs, improvements, and feature requests. These items tend to go to the product backlog with the hope the team will work on them once they find the time. Sooner than you imagine, you have an unmaintainable product backlog that leads to distraction instead of alignment.
Basecamp realized how detrimental the product backlog can be and decided not to use it. Within their framework, Shape Up, Basecamp doesn’t have a product backlog. Every six weeks, they decide what to pursue next. They benefit from having a fresh perspective and don’t get stuck with the past.
Coming back to reality, you will probably have to deal with a product backlog. Most companies use agile frameworks that have a product backlog. So how do you keep it balanced? It depends on your situation. New products and running products tend to be different. Let me help you understand that.
Product backlog for new products
Getting started with a new product is exciting. Take this opportunity whenever you have it because it’s rare. Yet, it’s easy to get excited about everything and dump all your ideas into your product backlog. Don’t do that. This will block you from focusing on what matters.
User Story Mapping is a simple way of starting a Product Backlog. You set a goal, craft the user journey, and then align on the tasks you want to address. This way, you will have the first version of your product backlog. Then, you need to sit down with your software engineers and create the tech tasks, e.g., setting environment, infrastructure, architecture, etc.
I had a few chances to start with a new product and struggled to know where to start. I thought it was about writing backlog items, but I got it wrong. It’s about commitment and alignment. You commit to reaching a goal and align on what to deliver and what not to.
The first part is crafting your initial product backlog, which you have to maintain. Otherwise, it will become a monster you don’t want to face. We will address this soon.