Velocity: The Often-Overlooked Secret to Product Manager Success
Product Managers (PMs) do many different kinds of work, and the role of a PM can vary from organization to organization. However, one thing is consistent: the job of the PM is to deliver value for the business. My belief, and what I’ll be writing about in a series of posts, is that if you want to be successful as a PM delivering value for your business, you need to focus on increasing the velocity of value delivery.
Increasing velocity does not mean just producing more stuff, more features, more whatever. It does not mean more hours. It means finding ways to do the right things in the right order, removing obstacles, and supporting teams in a way that leads to more and more value being produced.
When velocity is good, your work is more enjoyable, and you and your colleagues will tend to be happier, and your stakeholders will be more satisfied.
When velocity is not good, it’s frustrating and painful, and things go wrong, and they often go wrong in ways that inspire interventions that make things even worse.
How velocity issues can spiral into more and more pain for everyone
Let’s walk through a squad productivity scenario. Imagine a squad that owns a component of a software product. This particular team does not have a great reputation with leadership. Leadership has the feeling that this team moves a little bit too slowly and is somewhat unreliable. The team has a reputation for “missing dates”. They are currently working on a large feature that is already several weeks past the original target date, and the team doesn’t seem to have a lot of confidence even in the updated date.
So what happens next? All sorts of bad things, including:
- Leadership steps in and asks for more status reporting, more frequent updates, more detailed schedules, etc.
- Leadership sets a “drop dead” date and tells the team they need to ship the feature by that date no matter what.
- Leadership puts pressure on the team to “work harder” or stay for “nights and weekends”.
And how does the squad react to these moves? They become defensive, de-motivated, negative, and checked out. And then what? Things slow down even more, the date slips out further, and then rinse and repeat this cycle of misery. Does this sound fun? I can tell you from personal experience, it is not!
What went wrong?
In the situation above, what went wrong? If that were easy to answer, it might be easy to solve. However, ask five different people and you’ll get five different answers covering topics like:
- “Bad specs”. Stakeholders say the specs were too light, too heavy, or missing key aspects leading to later claims of feature creep.
- “Unrealistic expectations from leadership”. As in, the team knew they couldn’t hit a particular date but felt like they needed to sign up for it anyway.
- “The team is checked out”.
- “The technical work was more involved than we thought and took longer”
- “The code was too buggy”
You could probably ask twenty different people and get twenty different reasons why things weren’t going well. In reality, all of the above problems may be true or partially true. But in my experience, these types of problems are often not root causes but are rather symptoms of underlying velocity issues.
I’ve seen organizations try to solve these kinds of issues by making the PM create different kinds of specs, or having the engineering team spend more time on technical swagging, or pushing the engineers to QA more, etc. Do these approaches work? I can tell you they do not, and I’m guessing this matches your personal experience. What I have found is that you cannot address squad productivity problems until you deal with underlying velocity issues.
Okay — how do I address underlying velocity issues?
I’ll be writing about the topic of squad productivity in more detail in a later post, but at a high level, if you told me about a team in the situation above, my initial guess is that the team was lacking in one or more of these key squad attributes for velocity:
- Are they empowered to deliver in their swim lane?
- Do they have an understanding of why their work matters?
- Are they operating in a psychologically safe environment?
- Do they have a structured process for continuous improvement?
Usually, if a team is struggling in the way described in the example, the answer to one or more of the above is “no”, and that’s where I would start doing work to improve velocity. As these underlying issues are addressed, things will begin to move faster, and gradually the external pressure from leadership and elsewhere will be relieved, because stakeholders will see that the team is doing good work for the business.
The magic of focusing on velocity is that once the team is moving faster and delivering more, many of the problems that people were complaining about will go away on their own or will naturally improve as part of the velocity increasing process. You will get the result you want by focusing on the cause, not the symptoms. You will solve productivity problems by enabling the team to do well and by taking care of them, not by blaming them or demotivating them.
Velocity is a key factor in all aspects of a PM’s job
I used a squad productivity example above because that’s something that most PMs can relate to. But velocity is a key to success well beyond the performance of a squad. Focusing on velocity will help you in many critical areas such as team management, personal time management, stakeholder management, working with difficult people, and more. Velocity gives you oxygen to try things out. Velocity gives you and your team the chance to make a mistake and recover. Velocity inspires confidence inside and outside the team. High velocity individuals and teams are generally standouts in the eyes of their peers and leadership. And most importantly, being part of a high velocity team is fun and rewarding. To me, that sounds a lot better than being asked to write more detailed status reports or longer specs.
In the upcoming months, I’ll write some posts that include practical, road-tested ideas for improving PM velocity in a number of key areas.
Available now:
- Managing Other Product Managers Part 1: Empowerment
- Managing Other Product Managers Part 2: Meaningfulness at Work
- Managing Other Product Managers Part 3: Psychological Safety
Coming up:
- Managing Other Product Managers Part 4: Continuous Improvement
- Squad attributes for velocity
- Working with an unhappy engineering team
- Dealing with difficult people
- Stakeholder management
- Starting off with a new engineering team
- Managing your own productivity and responsiveness
- Communicating progress and wins
- Using metrics to create alignment and focus
- Doing things that you don’t know how to do
- and more
For years, I’ve been discussing these kinds of topics in 1:1 mentoring sessions or internal company presentations. I’m excited to write some of them down now in a format that is more broadly available, and I hope they’ll be helpful to other product managers.
