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.

This is not Waterfall

Even though this is a process that moves from left to right, and there are gates to go from one to the next that we’ll get into. This is not a waterfall process.

Each phase is kept as short as possible. A cross-functional team moves projects and programs through different phases as the squad is constantly building and learning and adapting. Squads constantly move between programs at different phases as the business demands and opportunities are discovered and seized. This is “Agile”.

Phase Requirements

Members of the squad will change as the product, project, or feature moves through phases. However, each phase has clear requirements that are maintained.

The Directly Responsible Individual (DRI) is the person leading the effort. They are responsible for the success of the project and will be held accountable. Few if any people will report to them, but they bring clarity to what is being done. They are responsible for stakeholder management and reporting progress up and across the company. They help the team resolve issues and are responsible for escalating to leadership or executive sponsors when appropriate. Often this person is a PM and it’s a wonderful way to hone leadership skills and drive impact to accelerate a career.

The Impact or return on the investment made must be clear. It must be measurable and it must be at the center of decision making. Returning to this metric is the fastest way to regain alignment in a squad or stakeholders who drift. And to make potentially contentious decisions easier and quicker to make and understand.

Every phase has a well understood Deliverable. High velocity teams keep deliverables as lightweight as possible. Only producing enough to make the right decision to move to the next phase. Iteratively increasing fidelity as the squad moves from a customer pain-point, for example, through to code to be pushed onto production and made Generally Available (GA).

Between each phase there is a Leadership Review. Reviews are not gates intended to slow down the process with unnecessary micro-managing. They are intended to generate momentum and a bias to action. They ensure the squad is on the right track and stakeholders are aligned. They are an opportunity to increase clarity and surface opportunities to unblock progress. Yes, they are a point of accountability, but in this way they build velocity by removing inertia and indecision.

1. Discovery

This is where I see many teams spend way too much time. Wasting way too much time and delaying the rest of the squad from making progress.

The goal of discovery is to understand a specific problem or opportunity space to accomplish a clear company objective. It is not for the PM to spend months learning about the entire industry, or space. They need to be doing that continually, working with various pieces of foundational materials and assets created by them, their product marketing partners, and user researchers.

Discovery encompasses the definition of a user or business problem, an analysis of an opportunity, a technical discovery, or a user experience vision. Scope and success criteria will be defined along with a phased approach to tackling the problem. But the PM needs to keep this tight and focused.

There are multiple inputs to this phase (see above), and it is the PMs responsibility to synthesize all of this down to create a Product Brief that succinctly describes the problem, the initial scope of the solution, areas of exploration, and any assumptions to be validated in the Definition phase.

2. Definition - The Design Sprint

The fastest way to get through the definition phase of the process is to carry out a Design Sprint. Well documented and improved from the original Google Ventures post and book (and worthy of a separate post), the Design Sprint is a fast paced and exciting four to five day exercise. During the exercise, a cross-functional team moves from a clear definition of a problem/opportunity to a validated starting mock-up or proof-of-concept (PoC) for what is to be built and delivered.

The team uses the Product Brief as the starting point of the exploration. The output is a rough interactive design/mock-up or PoC/prototype. The Product Brief will be transposed and expanded upon in a light-weight PRD. We’re not looking for War and Peace in the PRD. It is intended to provide validated technical, user, customer, and business context to what is demonstrated by the PoC.

Between the mock-up and the light-weight PRD, the tech lead will understand what needs to be built. They will be able to imagine and assess risks, technical challenges, and areas where further exploration will be required during the delivery phase. They will be able to provide an estimate of timing and own that as a commitment. To be clear, it is the engineering leader within the squad who is responsible for dates. Not the PM. Engineers are writing the code and are therefore the only members of the team who truly know what needs to get done.

Key to the successful delivery of the solution is the reduction of the initial design to the Minimum Viable Product (MVP) state. What could be a complex and highly valuable complete and whole product needs to be reduced to what solves the immediate problem with the smallest amount of code possible. But not too small. The product must be economically viable. Meaning that it can be sold or it can sustainably reach the metric of success as stated. It must also constitute a complete product. Intuitive to use and able to solve all of the immediate problem and marketable as a self-contained entity.

3. Delivery - MVP

This phase is when the squad builds, tests, and deploys to production the code that solves the problem as defined by the mock-up/PoC and the PRD as inputs.

The emphasis is placed on it being a Minimum Viable Product (MVP) to ensure three things.

Firstly, technical risk is reduced to a minimum. The bigger the solution the more complex the code and the higher the risk that something will go wrong and the project will be delayed.

A common failure mode I have seen coming into a program has been caused by too broad a definition of what is to be built. Squads get bogged down on a huge set of elaborate features, functions, or workflows to address a very tight problem. They struggled with uncovered technical debt, realized too late that a new piece of foundational technology would perform better than what is currently in place, or the second or third order effects of the proposed change were not taken into consideration or ignored as scope creeped forward.

Secondly, to reduce business risk. The longer it takes to get the product into the hands of users, the longer it takes to get the return on the investment. The longer it takes to learn what does and doesn’t work. The longer the competition has to discover and work on something similar.

Lastly, to enable agility in the squads. Once the squad has pushed to production code that solves the business problem, and is sustainable and maintainable, the go-to-market motion can work to get the return on the investment made. At the same time, the squad is positioned and available to pivot if needed. They can easily move to a different opportunity or challenge while minimizing technical or business debt accrued.

The flexibility and agility of an MVP approach is foundational to a high velocity PDE (Product, Design, Data, Engineering) organization. All long-term and sustainable product and economic success for the company stems from this operating model.

4. Refinement

The objective in this phase is to decide what further investments are needed to accomplish the immediate user goal. We analyze engagement metrics and qualitative feedback from users to make an informed decision about what to do next, if anything.

To do this, during delivery you have set up and built the different mechanisms to get both quantitative and qualitative feedback on the product or feature.

Instrument the workflow from feature discovery to successful completion and monitor the engagement funnel over time. Complement this analysis with qualitative user research, usually carried out by the designer of the feature. Sometimes we’ve had the lead engineer and designer on a call with a user making modifications and changes live on prod to get the feature to where it needs to be. That’s exciting!

The engagement funnel will be a source of inspiration and curiosity. It is the what of the analysis. User research is how we understand the why behind the user behaviors we observe.

If users are completing the flow and accomplishing their goal with a high degree of satisfaction move on to the Growth phase of the process. If users are almost there and they’re just getting a little lost in places, time-box the investment and iterate on the solution to get enough users over the line.

If user’s expectations are not being met and they’re not engaging with the feature to the degree you’d expect, take a step-back and understand why. A common failure mode to protect against is the sunk-cost-fallacy trap. Start from a blank sheet and decide anew if investment is warranted relative to other investments that could be made across the product and through the product strategy.

5. Growth

In larger scaleup companies, Growth will be a separate squad working towards driving top-line company metrics and unit economics. A new feature released can be a source of expansion within customers and the Growth squad will leverage the new feature as part of their overall strategy.

At Slack we drove growth within our own squads. We set up and ran multiple simultaneous experiments to drive up engagement across the entire user workflow. We then built upon that to bring net-new users to the platform.

Within the Productivity team, we were so successful at running these experiments we became the biggest source of product-led expansion growth within the fastest growing PLG (Product Led Growth) company. Every squad is a growth squad.

Across all of your products, features, and experiments, monitor investment and progress towards your stated goals. Most experiments will fail, some will have incremental impact, and others will prove to be highly successful.

Growth features with the highest chance of success are those that bring value into the natural workflow of users within and across their own teams. When you unlock these flows, double down and drive hard.

Be aware of a diminishing rate of return of changes and stop additional investment once that has been achieved. Momentum and organic growth will take over and you can move your valuable resources to the next area of growth.

Deliverables

At each step of the process the squad leads will create and deliver for review artifacts of increasing fidelity. This means at each step produce only what is needed to make decisions and move to the next phase. And deliver no more.

Too many times, I’ve seen an innovation team iterate around and around fine-tuning designs to please an executive’s subjective opinion rather than answer the core questions. “Does this solve the problem?” “Will this have the desired impact?”.

I’ll go into the different artifacts in more detail in another post, but to make a couple of call outs.

The Product Brief has the emphasis on brief. Provide the information to answer key questions and enable leadership to quickly make a clear decision.

The Product Requirements Document (PRD) is an expansion upon the Product Brief. For user-facing products and features the mock-up or prototype is the PRD. Any documentation is intended to elaborate technical and implementation details the mock-up does not make obvious. Ideal Customer Profile (ICP) and target persona or role, for example.

The fastest moving teams I’ve seen don’t use long formal PRDs at all. At Microsoft in the Outlook mobile team we used Github discussions to capture design and UX details. We then used Jira tickets to elaborate further. At Slack, (surprise, surprise) we used Slack channels dedicated to the features and Dropbox Paper 😢 to bring out implementation details.

The draft Press Release is an important informal “contract” between R&D and the commercial organization. When scope, resources, or timeline are up for debate we consult the press release to verify the commitment and business proposition still hold true.

Scope creep pushing out General Availability (GA) or a reduction in scope can eliminate the need for the investment completely.

The Go-to-Market (GTM) and Product Led Sales (PLS) plans are used to bring alignment and collaboration between the R&D and commercial teams. A product is useless without distribution. We need both.

Quick side-bar: PLS is for an enterprise B2B company. Product-led Growth is for both B2B and B2C. They’re just used in slightly different ways for different reasons. More on this in another post.

The Roadmap Drives Impact

As product leaders, we pursue solutions to problems we identify. Successful product leaders go that extra mile and couple problems with business impact. We impact our users. We change their behaviors for the better and bring value to their lives.

In product-led companies, we deliver value to drive sustainable business impact for the company. Built upon a Product Strategy, Technology Strategy, and Go-to-Market strategy, we build a machine of highly motivated, empowered, and coordinated squads. This machine drives the business.

Failure Modes and Anti-Patterns

• The perfect getting in the way of the good - Definition takes too long as designers sand edges or innovation squads iterate around and around on a PoC before executives feel comfortable that they’re not making a mistake.

• Analysis paralysis - Discovery taking too long as an unconfident team exhaustively explores every single edge case and possibility.

• Data driven decisions - All along the process decisions are delayed or not made at all as more data is gathered to increase confidence or lower perceived risk. Data does not make decisions. Leaders do.

• Process over People - Deliverables become too formal and unwieldy for leaders to make decisions and teams to execute quickly against.

• Poor execution culture - Politics and process are used by naysayers and doubters to slow progress and divert resources. A culture of “Disagree but commit” must be instilled across the company.

• Poor product discipline - Oscillating priorities and an unclear product strategy causes thrash and indecision up and down the organization. Clarity and consistency of a vital few priorities.

• Fixed Mindset - Teams and companies are afraid to make mistakes or admit when they’ve made one and change their approach. High-velocity teams have a growth mindset. They make mistakes, but they do it quickly with the lowest amount of investment needed to learn what doesn’t work.

• Sunk cost fallacy - Pouring away resources and time in the hope that just another incremental feature will create the adoption inflection point to exponential growth. If the impact metric isn’t moving, stop and move on.

• Squeaky wheel - A whale of a customer pulls resources off a project for a bespoke feature that meets their specific need. PMs must negotiate with large customers and their own sales leaders to navigate around these company-crashing situations.

• Feature creep - The zombie project that never ships as higher and higher expectations are piled onto the squad. Ship just what is needed to solve the problem and drive impact. Then re-assess.

Go Beyond the Build! 🚀