High-Velocity Product Development Process
The number one predictor of success for a startup is speed of execution. This article details the process I've built while leading successful Microsoft, Slack, Spendesk, and Lepaya teams.
Where Things Go Wrong
The number one predictor of success for a startup is speed of execution. The velocity at which a solution to an identified problem or opportunity can be delivered to customers and monetized. This is what makes the difference between success and failure for any company. For a startup with limited resources, poor execution is fatal.
Every company I have joined and organization I have led has been in a similar situation. Product Market Fit has been established. Often with multiple products. Strong individual contributors are operating at the top of their game across engineering, product management, design, and data. But velocity has slowed.
Progress toward the founder’s vision has all but stopped. Features that should take weeks to deliver take months or even quarters. The commercial organization no longer trusts the roadmap will be delivered. Competition has started to appear and look credible.
What was working when the team was small is broken. Trust across organizations erodes. Unit economics start to slip and the board starts to ask pointed questions of the executive team that all question their ability to execute.
This is when a startup must transform into a scaleup. A leveling up of processes, people, tools, and leadership to power the change. The engine of that transformation is the product development process.
Here I’ll describe the phases of the High-Velocity Product Development Process. How to bring it into your organization and how to drive momentum as velocity increases. I also include a section of common failure modes I’ve encountered with tips on how to avoid them.
The High-Velocity Product Development Process
This process takes pieces of everything I’ve seen, learned, and built while leading teams at Microsoft and Slack. Adapted and then deployed at startups transforming to scaleups at Spendesk and Lepaya. There’s a little bit of everything.
Prerequisites
Every high-velocity squad needs context and clarity of purpose to move quickly. Ideally, the assets below exist to provide that context and clarity. Realistically, most will be incomplete or out of date. Many will be missing. That’s OK, but it means leadership must be hands-on providing guidance directly while gaps are filled as you go. You’re building the car as you’re driving down the freeway!
Company Vision
Strategies
Product Strategy
Technology Strategy
GTM Strategy
Objectives and Key Results
Resources
Ideal Customer Profile
User Personas
Customer Journey
User Journey
General User Research
Product Analytics
Customer Requests
Sales, Customer Success, Support
Competitive Landscape
Internal Idea Backlog
Commercial Performance Metrics
5 Phases of the Product Development Process
All of these phases will look familiar. What I’ve seen fail is what goes into each of these phases and the speed at which the team transitions from one to the next.
Too much time is spent in Discovery exploring the universe of possibilities. Definition is encumbered by huge Product Requirements Documents (PRDs) that are out of date as soon as they’re shared into Slack. They are rarely read anyway. Delivery is a black box focused on shipping overly complex features rather then solving a specific problem and driving impact. Refinement is just another feature in the roadmap kicked-off out of habit. And Growth is rarely invested in as squads move onto the next feature. Actual business impact is expected to happen organically right after code is pushed onto prod.
Keep reading with a 7-day free trial
Subscribe to Beyond the Build to keep reading this post and get 7 days of free access to the full post archives.