Speed determines victory for technology companies. Since the internet was invented, the fast have killed the slow. And out of all the ways that speed matters, product velocity – the pace at which you evolve your product – matters most of all.
But improving product velocity is hard. It’s common to view velocity as an engineering consideration, but a modern cross-functional team’s velocity is just as influenced by product management, design, or even sales and marketing. These teams form a complex machine that’s only as fast as its slowest component.
This post contains my go-to steps for debugging slow product velocity, particularly in SaaS. While I believe that these tactics are generally applicable, they’re heavily informed by my personal background. I have an engineering background and a reasonable sense for when I’m getting bullshitted about how hard something is. I also have a degree of control over both what teams work on and how they work – without that, some techniques may not apply. So while your mileage may vary, I hope that it’s helpful to lay these tactics out in one place.
Remove Dependencies
Product development is like climbing a mountain – there are a lot of ways to the top and seemingly small decisions have large impacts on when you’ll reach the summit. It’s a lot faster to climb a mountain if you’re not waiting around for others.
Some organizational structures and cultures create dependencies, and dependencies directly cause slowness:
- Teams need approval for every new iteration. They could launch updates practically every day, but approvals come in every week (or less).
- Teams need to make handoffs constantly. I’ll write the backend API, then you build the frontend. I’ll start the frontend once design is done. Design won’t start until PM or research have run 5 customer interviews.
- Teams are dependent on others’ knowledge. We need to get Jimmy in the room to confirm that this algorithm will work, and he’s on vacation and then busy catching up for a few days.
Crafting a sensible organizational structure is one of your most important responsibilities as a product or engineering leader. Here are a few steps to reduce dependencies and speed your team up:
- Assemble teams that have everything that they need to build and launch products. The standard groups to include in this unit are Engineering, Product, and Design, but if Data Science, Project Management, Product Marketing, Research, or others are required to actually build and launch a product end-to-end, you can include them as well.
- Create a culture that favors begging forgiveness (and reversing decisions quickly) rather than asking permission. Invest in infrastructure such as progressive / cancellable rollouts. Use asynchronous written docs to get people aligned (“comment in this doc by Friday if you disagree with the plan”) rather than meetings (“we’ll get approval at the next weekly review meeting”).
- Keep teams together for long periods of time so that knowledge and builders are tightly coupled. Create incentives relating to long-term excellence to discourage bouncing around the company. Enjoy the process benefits of teams making no-look passes.
Overall, teams should be willing and able to act like smaller sub-startups within a broader organization. Removing dependencies is something that can be done fast and pays dividends almost immediately. There’s a selfish benefit here, as well – if you’re a leader, dependency hell is going to get escalated to you.
Demand Clear Narratives
Climbing a mountain takes longer if you don’t know the route.
When there’s no clear narrative for your goal and the steps you’ll take to reach it, requirements become slippery and product velocity grinds to a halt. Customers always need one more thing; there’s always an edge case you didn’t catch. “Done” becomes a moving goalpost that permanently hovers about 4 weeks in the future.
Requirements can shift for many reasons:
- Your product management team sucks and can’t clearly define customer needs.
- Your design team sucks and can’t make up their mind.
- Your engineering team sucks and can’t define working architecture upfront.
- Executives are swooping in at the last minute to fiddle.
These teams all share one trait: The lack of a clear plan enables aimless wandering towards a fuzzy goal.
The best way to resolve shifting requirements is to require clear narratives for what it will take to get a project done, and force teams to document them. Teams must clearly explain:
- What they’re aiming to build.
- What solution path they’re planning to follow, step-by-step and in as much detail as possible. This is critical even if you aren’t very familiar with the space – teams should be able to answer all of your questions on what’s going on.
- All of their known unknowns.
The first advantage of requiring clear narratives is that it reveals whether your team has a complete end-to-end plan. Unclear thinking is a reliable cause of slowness, and gets revealed under a microscope.
Additionally, demanding clear narratives on why something is hard is the best way to reveal when the root cause of slow development is product management (typical failure modes: poor definition, executive stakeholder dysfunction) or design (typical failure modes: over-analysis, poor understanding of the problem). Otherwise, it’s easy for teams to use hot potato accountability where fault lies with whoever touched the project last – typically engineering.
Bonus points for documenting plans in writing. One of the largest advantages of a strong writing culture is that it forces much clearer narratives than meetings, powerpoint, or five Slack threads spread over 8 business days.
Get Your Deployment and Incident Metrics In Shape
It’s faster to climb a mountain if you’re fit.
Engineers are the largest subset of a cross-functional product development organization, often outnumbering PMs or designers 10:1. As a result, it’s especially important that engineering teams are efficient. Technology companies live and die by the health of their engineering teams.
If you care about speed, the most important operational metrics for product velocity relate to development efficiency and stability. For example:
- How long does it take to deploy?
- How often is your build broken?
- How fast can you go from merge/pull request to live code?
- How often do you have a show-stopping bug?
Deployment metrics are like an engineering team’s resting heart-rate, blood pressure, and BMI. If you have a BMI of 30 and a resting heart rate of 85, I don’t need a stopwatch to figure out that you’re not crushing your local half-marathon.
Stability is also a strong indicator of velocity, because it’s a strong proxy for engineering team quality and effectiveness:
- Stability reduces context-switching and can be a major speed boost.
- Stable products and product velocity go hand-in-hand – in general both velocity and stability are downstream of highly skilled engineers.
- Better engineers stay on teams where there’s high system stability, because the lifestyle isn’t miserable. This creates more talent density.
No matter what your job function is, part of your role is ensuring that your engineering team has enough time to get their vital metrics in order. Especially if you’re a product leader, it’s essential that you resist the temptation to push relentlessly for more features and give your engineering counterparts the room to get fit.
Find Trusted Engineering Guides
It’s a lot easier to climb a mountain with a guide.
To an outside observer, the following situations can all look identical:
- It’s hard to build in your environment; sometimes new products or “small changes” require rewriting or coding around prior assumptions that no longer hold. These prior assumptions might be due to poor decision-making, or they might just be due to bad luck (usually it’s at least a bit of both).
- The problems you’re working on are extremely difficult; perhaps they require deep math or statistics knowledge, or arcane knowledge of how to scale distributed systems.
- Your team is brilliant and inherited a mess from their incompetent predecessors.
- Your team is incompetent despite inheriting a goldmine of perfect code from their brilliant predecessors.
- Your engineering team is under-resourced for the business’ needs, typically consisting of a combination of insufficient headcount combined with too much context switching.
Some of these reasons for slow product velocity are due to your team being weak; some occur in spite of your team being strong. To the untrained eye a great team climbing K2 can look like a terrible team tripping on a staircase (this inability to tell great teams vs. hard problems from bad teams vs. easy problems is also why unwise non-technical leaders reliably drive technology companies into the ground).
The best solution to this conundrum is to find great engineers who can identify and resolve the root causes of slowness. Finding these truth-tellers is the best way to debug whether your team is weak or your problems are hard, allowing you to actually resolve the root causes of slowness.
To find these guides:
- Identify the fastest-moving engineers on the team. It’s rarely a secret. See who’s always on time, or even better, occasionally early.
- Look for people who consistently hit estimates. Even if they’re slower, they’ll be able to serve the role of trusted guide.
- Hire people who were successful key contributors at winning startups – ideally people who were promoted at least once through an extended period of high growth. Because of the importance of speed (recall from the top that the fast kill the slow), it’s almost tautological that winning startups moved quickly.
It also goes without saying that it’s especially important to build a strong relationship with all of your engineering partners, and especially these trusted guides. More on how to be a PM that works well with engineers here.
Watch Out For Important But Unpopular Products
It takes a really long time to climb a mountain if you have to climb a different unrelated mountain first.
Finally, if you still can’t figure out your velocity woes at a SaaS company, look at your feature adoption. In particular, look for a pattern where your products share two key traits:
- They’re adopted very well by a small but specific segment of your userbase – even a single very important customer.
- They’re barely used by the rest of your otherwise happy users.
This usage pattern is often a sign that you’ve stretched to close deals that are outside your ideal customer profile. This adoption pattern can actually be even worse than a useless product, and often occurs when sales and marketing fail to generate enough pipeline:
- Sales teams need a certain amount of pipeline to hit their numbers, assuming a consistent win-rate.
- If your demand generation efforts underperform, you won’t have enough pipeline to hit your goals.
- To make up the difference, you start trying to sell deals that aren’t quite in your sweet spot. Maybe you venture up-market or into a new industry vertical, trying to capture whatever peripheral opportunities you can get ahold of.
- You’ve now committed yourself to an area where you have weak product-market fit. To bridge the gap, you need to expand your product on an emergency basis, often building custom functionality.
- Splitting focus slows you down dramatically.
- In the worst case, slowing down degrades your product and makes it harder to generate new pipeline – completing the vicious cycle.
Once you’ve found product-market fit, the majority of customers that you do business with should be good fits for your offering. You’ll move slower if you’re stretching your product in strange directions hoping to close business.
The best way to avoid this issue is to build a great marketing team once you’ve found PMF. Great products and great marketing naturally reinforce one another.
It’s also your role as a leader to break the cycle of one-off demands and interrupts. At the extremes, this can mean saying no to deals and accepting the consequences personally. It can be scary (and sometimes you should build custom features, so it requires judgment), but as a product leader your reputation will ultimately hinge more on your product velocity than it will on how much sales likes you.
Ultimately, some amount of interrupts has to be Enough. Your sales team can’t be trusted with the call because they’ll just do whatever it takes to retire their quota. Your team builds the product, so it has to be your foot on the brakes.
Takeaways
Here are some final thoughts on product velocity that I’ve found to be reliable.
First: Fast-moving teams can regularly outpace partner teams’ and customers’ ability to absorb new products. You want to reach the maximum pace of innovation that your customers (and support team) are able to absorb.
Also, realize that in order to fix velocity problems you may need to replace team members. Unfortunately some people move slow and some move fast and no amount of refining or encouraging is going to speed them up. There is no amount of hard work or motivational speeches that will turn a water buffalo into a gazelle.
Make sure that you’re always moving a little bit faster tomorrow than you did today.