How to Improve Velocity as a Product Manager
Officially, Engineering Managers are responsible for the team’s rate of output. However, as a Product Manager you are judged by the productivity of the engineers you work with. You might think this is unfair, but given how much impact PM’s can have on productivity it makes sense.
True Velocity Is Not Measured In Points
Points are important for capacity planning, but your stakeholders do not care about that metric. Your team could ship a ton of “points”, but if users don’t see a difference and the metrics are not moving, then as far as stakeholders are concerned the team is not productive. If the team is shipping at a high rate, and the impact is negligible, then product is not guiding the team to the most impactful work.
A common error is to assign points to bugs and chores. This makes it difficult to understand a team’s productivity because velocity can look great even though the team is busy fixing last sprint’s work.
Work Ahead
One of the most impactful habits a PM can develop is to work well ahead of the Engineering team. That means both long term (this year), medium term (this quarter), and near term (the current AND coming sprint). Having at least a full sprint fully scoped out ahead of time does some great things for you. Beyond that the returns diminish rapidly.
The sequence of work matters immensely to engineering. Having a broader range of tickets to pull from further optimizes that sequence
You can respond to changes more quickly in the event that some work becomes blocked, or you move ahead of schedule
You can better define the current sprint because you know exactly where you are heading next
Working ahead of engineering in this way creates “buffer” between your two functions, and ensures they will not be waiting for you.
Listen
There have been times when I have let retrospectives slide. Maybe our team skips them for a couple of sprints or maybe as long as a quarter. Every time this happens and we finally get around to running one, I learn about something that is holding back the team’s progress, and I am reminded that we should never skip a retro.
Another good tool is to have occasional 1:1’s with IC engineers. Sometimes Engineering Managers can get defensive about this. After all, you are not managing their team. However, it is an excellent way to get direct feedback from Engineers about how well you are teeing up tickets for them to execute.
These tactics achieve something similar to a ‘Gemba Walk’, bringing you closer to the people doing the work so that you can identify process improvements and remove limitations to the team’s output.
Unblock
Never make your team wait for you. As a PM, part of your job is to grease the wheels so that engineering rolls smoothly. That means you need to be creating thorough tickets, adding detail / revisions during grooming, prioritizing, answering any questions that come up during development or otherwise unblocking. Every PM should be doing this as a matter of course, but doing it faster is an easy way to unlock productivity.
Go Beyond Acceptance Criteria
Another way to work ahead is to preempt questions you are likely to get from engineering. That often means going beyond filling out your ticket template with a user story & acceptance criteria. Some tickets might need a wireframe, a diagram, a spreadsheet with values or formulas, a loom video, etc. Do whatever you need to do to make sure the engineer knows everything they need to know to deliver a working solution.
If your tickets do not cover unknowns, and the gap is not caught in grooming, the engineer will have to stop mid effort to ask, or they risk making an incorrect assumption and then review fails, and they need to start over.
Motivate
I have seen several junior PM’s treat Engineering like a machine… tickets go in, software comes out. Engineers are humans, and their productivity is a factor of their motivation. As a PM you need to sell your team’s mandate, strategy and objectives… you need to sell every ticket. Why do they matter to users, to the team? If you can do this well the team should be fighting over what features they get to build, and velocity will improve as a result.
Avoid Complexity
It is always interesting to watch a junior PM or a business stakeholder ask an engineering team to build something extraordinarily difficult without understanding the complexity of their request. I often see this with products that appear simple on the front end, but can require a nightmare of logic below the surface to display the right data. The risk is that engineering will accomodate the request without setting the right timeline expectations, which ultimately blows up your roadmap.
It helps to run long term planning sessions with Sr. Engineers. Whiteboard your product’s evolution and get feedback on how to build what you need efficiently before you get to grooming. Learn how the data will be created and how it will move. If something looks like a gnarly problem, it is probably even worse. You are best to find another way. If you really need to build something complicated, peeling it apart into layers can be the fastest way to get it done.
Build In Layers
A strong roadmap is not just a series of features organized by impact and effort, it is designed in a sequence that unlocks new opportunities with every release. For example, if you know that in a year’s time you will need to display data about a customer’s order in their account, but you don’t collect that data today, you can try and work that prerequisite into the roadmap before you need it.
It is easy to be wrong about what features are needed far into the future, and teams often cannot afford to make long term investments. It can take some experience and a bit of luck to get this one right, but when you nail it the team’s momentum compounds over time and the payoff is huge.
Be An Engineering Superfan
This should come naturally. As a PM you have front row seats for all the hot new tech that is coming off the line, and you get to tell the world about it. Use this as an opportunity to put the spotlight on the Engineers that make this magic happen!
PS. If you are interested in how to make systems more productive, I recommend this exceptional overview of the Theory of Constraints.
Thanks to Ian McAllister & Dan MacDonald for reading drafts of this post
