Product managers — get away from the backlog!

Controversial? Some might say “yes,” but I hope to change your mind by the end of this article. Marty Cagan wrote an excellent article a couple of months ago highlighting the differences between product vs. feature teams — you can find it here. One excerpt of it says:

“In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us.”

A true product manager, working for a product team, is ensuring value and viability. Very little to none of that is done through the backlog. The backlog is a project management tool to ensure that the team has a clear understanding of the specifics of what they need to build — it is tactical and execution-driven. The backlog ensures that work is getting done, but it does not help with ensuring that the work is viable or valuable. Value and viability are achieved through product discovery, user interviews, setting OKRs, diligent prioritization, and having the time and a consistent system to check in on how features perform when out in the wild. Having a well-groomed perfect backlog means nothing when the work in it is not impactful — it is costly to build the wrong thing in the wrong way. Product managers, you are not backlog managers.

If you’re bought in and want more time to focus on understanding the value of solving for each outcome, effectively prioritizing, practicing real product discovery, and analyzing results, here is where I’d suggest starting:

• Treat product discovery as a continuous process
• Enable your team to do the work and empower them
• Develop practices that enable true cross-functional collaboration

Breaking this down…

Treat product discovery as a continuous process

All the recommendations made below assume that you’re doing product discovery constantly to both identify what problem to solve and how to solve it, including team members from different disciplines in the process. This point is imperative for all the ones that follow to have good results.

Enable your team to do the work and empower them

Engineers need to be highly involved in crafting the solution that the team will implement. Crafting the solution is not a product+design task — it is a teamwide responsibility. As part of achieving that, not only by involving the engineering lead on the team, I implemented engineering track leads. An engineering track lead is an engineer on a team that owns the technical feasibility and feature breakdown part of the equation for that track of work or outcome your team is trying to achieve. They are involved throughout product discovery and are a core part of defining the solution that they will then be building together with the rest of the engineering team. This framing truly encompasses Janice Fraser’s Balanced Team approach, where engineering, product, and design work together.

In practice:

1. Initial product discovery: all product discovery described here involves product+design+engineering+product marketing (when available to you :) to identify which problem would be more impactful to solve for both the business and the user/customer, and what outcome your team should be striving for
2. Selection of engineering track lead: the engineering track lead is selected during a feature kickoff. Feature kickoff is a meeting in which the product manager or designer tells the story to the entire team of why we are solving for this need, showcases the evidence, and articulates the impact and OKRs that the team is striving for. It is a crucial meeting for all team members to be bought into what the team is solving for. At the end of every feature kickoff, I ask the engineering team if there is someone that is particularly excited about this outcome and would like to track lead it
3. More product discovery: the triad or quad (product management, design, engineering, and product marketing or data) work together to define hypothesis to test, run design studios (brainstorm sessions on how to solve for the outcome selected), create a prototypes to test the riskiest assumptions, run usability tests, run a/b tests, etc. They do whatever is necessary to validate that the solution selected is the right solution
4. Feature narratives: product managers own writing the feature narrative. Other members of the team are encouraged to participate. A feature narrative describes: why the team is solving for this need, evidence on how this is a problem worth solving, proposed solutions and chosen solution with the reasoning behind why it was chosen, an overview of the user experience desired (generally owned by the designer on the team in collaboration with the product manager). Amazon has a fantastic model for writing feature narratives.
5. Break down feature narrative into user stories: the engineering track lead writes the user stories/tickets that break down the experience
6. Cross-Functional sync on feature breakdown: the quad or triad gets together and reviews the user stories/tickets to make sure every function is on the same page
7. Stories are presented to the team: the entire team sees the stories, gets any doubts answered, refines it further, and estimates complexity. I like to start this meeting by reviewing the “why” behind solving this outcome. It is worth reviewing it since the feature kickoff was probably a while ago, and it is always essential to ensure that the team is bought in and involved in what we’re working on as a team!
8. The team executes on the feature
9. Story acceptance: it is important to ensure that the experience is delivered as imagined and planned by the team, so I recommend sharing acceptance so that all members of the team can feel ownership over the work. My team normally has engineers devoting a couple of hours per week to be a part of this process
10. The feature is out in the wild
11. Analyze, iterate, re-ship, and repeat until you’re happy with the result — remember that a feature is not done when it’s shipped. It’s done when the outcome it set out to achieve is achieved

Develop practices that enable true cross-functional collaboration

Creating as a team is a habit that needs to be developed. The role of product management is facilitating this collaboration amongst ensuring the value and viability of what the team will build. Designers are not there to only design, PMs are not there to only manage, and engineers are not there only to write code. The entire team needs to own the holistic product development process to ensure the best experience for the user while satisfying critical business needs in the most technically clever way.