Six Product Development Mistakes That Slow Teams Down
What product managers should do instead.
This article is based on “The Principles of Product Development Flow” by Donald Reinertsen, and my experience following his principles.
Using Reinersten’s principles, these are what I think are six common mistakes Product Development teams make:
- They often do not use a useful metric for prioritizing projects (Hint: there is one that works better than most others)
- They do not make decision principles readily accessible by everyone
- They try to maximize utilization instead of optimizing outcomes
- They try to minimize variability without understanding the implications
- They minimize disruptions rather than reducing total work in progress
- They don’t clarify what role each person plays in product development and how to leverage them best
1. The importance of prioritizing projects
If you asked most teams what is most important to them, they would tell you in no uncertain terms, “Ship value to customers fast!” After all, who would not want to ship value to customers? And faster is always better isn’t it?
The one metric that encompasses all of this is the cost of delay.
Think of your favorite project or feature. Why is it so important? Is it because if you don’t do it, you will lose a major customer? Is it because of revenue loss? Does it cause tech debt that slows down other projects? Do other features depend on it, if so and you don’t do it, then you cannot ship the other capabilities?
All of this can be expressed in one number: the cost of delay. Go through a thought exercise, and add a cost of delay for every feature. Even if it is rough, it will give you a “more objective” criteria to prioritize features.
Then take the feature that has the maximum cost of delay, and work on it first.
2. Make decision principles easily accessible to all
The Product Manager is responsible for prioritization.
We “know” that.
I want to challenge that notion.
What if the product manager was responsible for making the prioritization principles clear for all? So that anyone on the team can make the same prioritization decisions that the product manager made. Establishing these principles removes the bottlenecks that are caused by product managers, and makes sure that the technical choices made by engineers are the right ones.
But just working on the right projects might not solve all the problems. To actually ship the value to customers, you need to focus on the best outcome for the end user. Product managers shouldn’t be the only ones making those decisions.
3. Focus on optimizing outcomes vs. maximizing utilization
Think of one of your highly compensated engineers. Now imagine this person is sitting idle. They are not building new features. They are not fixing bugs. They are just chilling.
What if I told you that was a good use of their time? You would think I am crazy, right?
That’s because the engineer is visible to us. We see their utilization. And we try to maximize and optimize what we can see — the engineer and their usage.
What we don’t see is the places where the customer value we wanted to ship is trapped: namely in queues.
Forms of queues might be code reviews, cross-team dependencies, waiting for the design to be done, waiting for answers from customers, waiting for assumptions to be validated.
In most organizations I have been part of, inventory is not visible at all.
Once you start to make inventory visible — as you would in a factory — you begin to recognize where the bottlenecks in the system are. You would begin to clarify what you can do to ship value to customers faster, rather than just focusing on keeping people busy.
Do you have inventory visible on your team’s board? And are you taking steps to optimize it?
4. Manage variability, don’t just reduce it
Have you been in an estimation session? No matter how much you focused on clarifying that these are estimates, what happened next?
The estimates and expected dates are taken as commitments.
And when we don’t ship things exactly on time, someone is disappointed. Do this consistently, and you have a velocity problem.
That’s because we seek to minimize variability from the plan. We try to treat product development as a predictable activity; just like producing things in an assembly line based factory.
Instead, we need to manage variability in a way that minimizes the impact of variability.
Because variability sometimes leads to bad outcomes, it is inevitable that some observers will incorrectly generalize that variability always leads to bad outcomes. They compound this faulty logic by reasoning that if the presence of variability leads to bad outcomes, then the absence of variability must lead to good outcomes. Energized by this insight, they advocate variability reduction. — Reinertsen, Donald G.. The Principles of Product Development Flow.
The author of the book gives an interesting example. If you had a project with a cost of $10K, a 1% chance of a return of 1 billion dollars, and a 99% chance of failure, should you do it?
Yes.
If we sought to minimize variability, we would never invest in any risky projects.
As a product manager, you have to think through your portfolio and understand where is variability the right answer, where you must make space for experiments that might fail.
And you must understand how you can reduce variability by pooling variability. If you run many uncorrelated experiments, some will succeed, and some will fail. This is a great way to manage variability.
5. Reduce work in progress
Product development brings with it unpredictable bottlenecks. Everything is humming along one week, and suddenly there is an unforeseen dependency or complexity.
The temptation here is to let the person working on that one thing to keep going and let the other engineers stay productive on other tasks.
That’s a mistake.
Most product development initiatives benefit from “swarming.” Swarming ensures that the team can flexibly jump to unpredictable bottlenecks and be able to ship customer value sooner.
6. Each person can add value in unique ways
We love to set requirements in terms of the number of engineers. For example, a particular feature will be allocated to two front end and three back end engineers.
And that’s it.
Or we have full-stack engineers, and anyone can jump to anything.
But the reality is that most engineers are, or can have “T shaped” skills. They can build broad skills overall and go deep into one area.
Except we forget the Big Gun Principles.
There are engineers in your group who understand your system better than most. They are known to bring creative, excellent solutions to the most challenging problems you face. These are the big guns.
The Big Gun Principle is: Pull high-powered experts to emerging bottlenecks.
In some sense, you need to be very careful about how the big guns work. The general principle you might follow is to maximize their value. But you must give the big guns more slack time. They should be empowered to transition quickly to emerging bottlenecks, and make the whole team more productive.
Conclusion
All of this might seem like a sea of change in how you work today.
I encourage you to start small. What is the one little experiment you can propose, that will move you towards the right model of product development?
And of course, please do read Donald Reinertsen’s book. It’s dense, and hard to follow in places, but worth the time investment.
