A note for new subscribers: This post is part of a series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. And, I hope you find that to be the case as well…
A quick overview of what we’ve covered on “Notes on Product Management” so far –
I’ll start this post with two assertions.
i) Moving with velocity should be an explicit goal for every product team. Velocity is different from speed in that velocity is a vector. Velocity combines speed with direction.
Making velocity as an explicit goal does two things at once. First, it puts the onus on the leads in the product team to provide the team direction and ensure the path is as obstacle free as possible. For example, executives who commit to velocity do their best to clear out any alignment issues with fellow executives well ahead of the first line of code being committed.
Second, it focuses every member of the team on shipping/iterating quickly. This focus on shipping/iterating quickly turns out to be the best thing we can do to ensure the long term survival of our product.
If our product team works at a start-up, velocity can be the difference between life and death. And, if we work at a large organization, velocity can save us from having a smaller, more effective company, eat our lunch.
ii) Velocity doesn’t scale linearly with resourcing. The bottleneck to higher velocity isn’t always resourcing – it may be so 50% of the time. But, pointing to resourcing when there’s a lack of velocity happens close to 95% of the time. :-)
So, spending all available energy to grow the size of the engineering team working on a product is an amateur’s game. That’s because lean, aligned, and focused product teams operating with high velocity can blow better funded teams away.
As a PM, this might require a bit of reorientation as it is easy to fall into the trap of optimizing for the size of the team. I’d instead wager that it is always better to be part of a team that is known to punch well above your weight.
This, then, leads to the obvious question – if velocity doesn’t scale linearly with resourcing, what helps?
I think there are 5 habits that can step change the velocity of the product team.
(1) Replace hub-and-spoke leadership and communication with tight knit circles:
Many product teams operate via hub-and-spoke models. The PM may be the hub for some members of the cross-functional teams, the Eng manager for the IC engineers, and so on. Information flows from the hub to these spokes. You’re “in the know” when you have 1:1 meetings with the hub.
While this can make folks at the center of the hub temporarily indispensable, it happens to be terrible for the productivity of the team. Trust and psychological safety are the keys to effectiveness on a team. And, hub-and-spoke models aren’t optimal because they create silos that aren’t conducive to building either.
The good news is that there is a better way.
There are 3 things we can do as PMs to help a product team move away from this model:
I think of this this mode of operation as a tight knit circle. Every dot on the circle is key to the shape. And, the space in the middle symbolizes the space we create for the kind of conversations that build trust and psychological safety within the group.
(2) Replace small meetings with large meetings that are used to create alignment.
Imagine you are close to launching a feature you are really excited about. Just as you get close, you realize there is a dependent team who wasn’t on the same page. Now, your team is faced with many weeks of rework before this feature sees the light of day.
This needn’t just be a dependent team. It may be an infrastructure team that didn’t get the memo about your change. Or it could be that your marketing team didn’t have enough time to prepare customers. Or an executive who is opposed to it. And so on.
Whenever a team is forced to do a lot of rework close to or after the launch date, you can be sure the culprit is poor product management. “Selling” is a core product skill for a simple reason – it is key to ensuring folks around you understand what problems you are solving, what they should be doing to help you, and why it matters.
And, a habit that helps with selling and bringing people along for the ride is embracing large meetings. Here’s why – in the formative stage of every product, it helps to bring the entire cross functional team along. And, if you are partnering with other product teams, that means bringing every member of that product team along too.
Sure, you can shortcut this and aim to only sync with a few of the decision makers. But, I can guarantee this strategy will cause pain down the line. It prioritizes short term efficiency over long term effectiveness.
Being comfortable with running large meetings and using them to create alignment lets us become liberal with the flow of information and context. That, in turn, helps us move significantly faster in the long run. How?
That, in turn, speaks to the power of broad information flow and more perspectives in the room. It moves teams away from a focus on efficiency to a focus on leverage.
If you want to go fast, go alone. If you want to go far, go together.
(3) Be a Lannister and pay off your tech debts.
When was the last time your team had an urgent bug? I assume you celebrated the folks who burned the midnight oil to solve it?
Acknowledging and appreciating such efforts is good. But, we provide more leverage to our teams when we use such issues to prioritize upstream/preventative bets. Attempting to squeeze every inch of engineering capacity in the quarter to move metrics is a short-term efficiency focused game. And, again, if it isn’t evident, our goal isn’t efficiency – it is leverage.
To enable high velocity product development, we need to free engineering time from constantly dealing with urgent issues. And, we can do do that by marking off a proportion of our engineering capacity for foundational efforts.
This investment turns out to be one of the easiest things we can do to help create happy engineering teams. Such efforts don’t just reduce painful on-call shifts (they do that). In addition, they are often source of intellectually stimulating work that can often provide leverage to other engineering teams as well.
Finally, while we can run with a ~25% allocation as a rule-of-thumb, this can go up in some quarters depending on the nature of the team. Typically, the more backend work involved, the more it is likely we’ll need to make large investments and ensure the engineering team has the space and autonomy to build scalable systems.
Be a Lannister and pay off those tech debts.
(4) De-risk big bets with many small bets – remember the pottery class A/B test. Every once in a rare while, we’ll work on a project that will require us to take one big not-testable-till-we-launch bet. But, in the majority of cases, we can de-risk big bets by taking plenty of small bets.
It should come as no surprise that the way to do this is with the help of crisp problem statements, hypotheses, and success metircs. The clearer the assumptions in our hypothesis, the easier it is for us to validate them.
However, the bigger benefit of taking plenty of small bets is that it builds the team’s muscle to become comfortable moving quickly. This is where the story of the pottery class A/B test comes in.
Two artists, Ted Orland and David Waylon, once shared the story of a ceramics teacher who found herself teaching a class on two separate days, neatly divided in half. She decided to try an A/B experiment.
To the first half of the class she said what she’d been saying for years – “You’ll be graded based on the quality of your work. At the end of the semester, turn in the single best piece of pottery you created.”
To the other half of the class, she said something very different. She explained to them that they would be graded purely on quantity – “Crank out as many pots as you can this semester.”
At the end of the term, she noticed that the best pots – both technically and artistically – didn’t come from the quality group, they came from the quantity group. By making pot after pot after pot, they were learning, and adapting. They didn’t set out to make the best pots, yet they did. Meanwhile, the other half spent the semester aiming for perfection and falling short.
(5) Live rug free – prioritize discussing the biggest challenges and be willing to change your mind.
The final habit that helps with velocity is living “rug free.” This is the most abstract note on the list – so, let me explain further.
When there are no rugs in the team room, it is impossible to sweep things under them. And, if we can’t sweep things under them, we have to be willing to encourage discussion around challenging questions and encourage thoughtful dissent.
It is easy to prioritize such discussions on our best days. But, on days when we feel our insecurities gnawing at us, it feels easier to just avoid these discussions and talk about the weather or argue about something meaningless.
But, it is precisely on such days when we should:
The fascinating thing about pushing for these often uncomfortable questions is that they are generally on the minds of others too. So, as long as it is accompanied by a willingness to listen to the response and change our mind based on that response, asking these questions ALWAYS helps move things forward. They help us resolve disagreements, remove discomfort, and get to alignment without letting any unpleasantness fester.
The courage required to live rug free every day isn’t talked about much. But, it has the potential to step-change the velocity of any team we’re on by changing the culture of the team. Focusing on the most challenging questions creates helps us understand how we make decisions as a group and creates an environment with high trust more often than not.
It is the sort of thing that never gets easy or comfortable – no matter how often we do it. We just learn to recognize when it is more important to push beyond our fears.
And, it always is.
