Aadil Mamujee

One of the most common issues in technology companies is poor product development velocity. Usually, you’ll hear things like Company X or Team Y is “slow” or “takes a long time to ship.”

The faster your team is able to ship features, the more iteration cycles you’ll have, which will lead to more shots on goal. More shots on goal lead to a higher number of goals (successful product launches) and ultimately help you succeed as a business

The first step is to understand why product development velocity is slow and then apply simple mental models and implement changes to significantly improve development speed.

Why are we slow?

Slow product development typically comes down to two modes of failure: 1) Failure of the product development team(s) and/or 2) Failure of leadership. I’ve been part of the problem as both a product development team lead and in a leadership role, so these examples draw from both my personal failures and observed failures over the years.

If you’re in a smaller organization with fewer layers, the lines between product development teams and the leadership team are usually blurry, but as product teams get bigger and have more layers of approval or cross-functional involvement, the failure modes become more pronounced.

Failure of product development teams

A few things can lead to slowness in a product development team.

• People Failure: Product development teams could display a lack of competence, motivation, or the wrong “team/product fit.” This could be specific individuals on the team or a lack of balance in the team. Often, the product manager or tech lead is responsible, as these are high-leverage positions, and they significantly influence the timelines and tempo of the team.
• Process Failure: Too much or too little process is a common mode of failure. Too much process creates friction in the development system, leading to artificial bottlenecks. Too little process and a lack of clear thinking upfront can lead to lots of wasted work and “thrash” on the product development team, which is very frustrating for craftspeople (e.g., engineers, and designers).
• Decision Making: A common cause of poor product development velocity is very slow decision-making. This could be because there are too many, often unnecessary, layers of management, cross-functional “approvals,” or product leads boiling the ocean to get just X more analysis or Y customer feedback. Increasing speed often means making decisions with imperfect, incomplete information.
• Iteration Culture: Once a feature is launched, you need a culture of iteration—what are customers saying, what does the data say, and what are some high-priority improvements we should make? Few teams have the autonomy or courage to abandon or roll back features that create unnecessary product or technical bloat with no decisive customer benefit.
• Risk Assessment: If something is low risk, has clear customer value, and is easily reversible, the hurdles for shipping should be minimal. Few product development teams think about risk in a structured way, ultimately leading to faster product development and shipping.

Failure of leadership

A few modes of failure from leadership can also slow down product development.

• Rewarding “strategy” over execution is a common mode of failure when there are many intelligent, opinionated people at a company. Pristine presentations with perfect graphs are internally rewarded with praise and internal kudos. If more scrappy, execution-focused teams get less internal credit, they will shift their approach towards more “product strategy” and building consensus over execution.
• Layers of approval: Layers of approvals without clear decision-makers are the death of product velocity. Multiple decision-makers who are often not on the same page and have different “tastes,” which often come down to preference over logically superior decisions, can kill speed and team motivation.
• Changing direction: As organizations, we need to be nimble and adapt to evolving environments, but changing direction comes at a sacrifice to shipping velocity. Folks in leadership roles will change their minds on product direction too frequently without properly considering the knock-on effect on product teams and the switching costs.
• Org Design: If product teams have interdependencies with other product teams to land features, it can create significant coordination overhead and tension between teams. It’s almost always better to align single teams to single objectives/sets of features where possible. When there are dependencies, there needs to be a leadership sponsor who understands the details and can settle tie breaks.

Solution Frameworks

Now that we’ve highlighted a number of these failure modes, here are a few systems/mental models that can help solve these issues.

Guardrails for Product Development Process

One of the most important things to do is to set some organizational guardrails for the product development process. Here are a few that I’ve found helpful in my career:

• Directly Responsible Individual or “DRI”: Every initiative at the company should have a DRI, and the buck stops with this individual regardless of their level. Everyone at the company can provide input but ultimately the decisions and initiative success falls to one person.
• 1-Pagers: All new initiatives should have a short 1-2 page document that describes the problem, the solution, key risks and open questions. This is a pre-requisite to kick off a new initiative and ensures that all involved decision makers and cross-functional partners are on the same page about the scope of the initiative.
• Constrained Discussion: Once the project is approved, it’s essential to constrain the discussion to only the people who need to be involved across the org. Once the discussion phase is over, it’s helpful to have a wider kickoff meeting to inform contributors and the broader company. When approving product direction, product and design leads should avoid blowing up features purely on “taste” if what they propose is not a superior solution. It happens all the time, and product development teams waste work because person with title X gave feedback that may not actually better solution to the problem.
• Ship Goals: Companies often task product development teams with large product surfaces or specific metrics/KPIs. This is helpful long term, but in circumstances where product development velocity is an issue it’s helpful to simplify team charters to “ship goals” over amorphous metrics that might only partially be under the team’s control.
• Rewarding Execution: Leadership need to reward product development teams internally when they ship and iterate quickly. This rewards teams for taking more risk and trying more experimental things. We should also celebrate outcomes/successful impact on metrics but separately from execution. This is hard to do.
• Small Teams: I prefer smaller autonomous teams with high agency over large ones. The larger the team, the higher the coordination overhead and the more difficult it is to get everyone on the same page on both product vision and execution.

Assess Risk

Assessing risk is challenging and very important for both product strategy and execution.

• One/Two Way Doors: If an initiative is one way door, it can not easily be rolled back or changed. Two-way doors are easily changed. An example of a one way door is migrating the entire technical stack like when WordPress migrated from PHP to Block Based Editing. An example of a two-way door is changing a user onboarding funnel. New users join every day, and it’s easy to run experiments and change this experience.
• Company stage: When you’re a startup and you have nothing to lose you’re able to take more risk because there is no core asset to protect. When you’re bigger (e.g. Google) and evaluating features that could put the search business at risk, the bar is much higher to try it.
• Fail Case: When assessing risk you could consider the probability that the event happens and the severity of the event if it happens. The risks to be most mindful of are the ones where the severity is extremely high (e.g. could destroy the company) even over risks that are higher probability but low severity.

Unleveling or Refactoring Teams

If the product development team is failing because of the wrong people or the wrong processes, I use the following method to assess and uplevel the team (as the product team manager).

• Constrain the product scope tightly and ask the team to commit to a precise date for shipping. Make it clear that executing well against this goal is their highest priority.
• If the team fails, diagnose whether it failed because of people or process failures. If it is a people failure, provide clear feedback and try again (constrained scope, clear timeline). If they fail again, replace the people with others or do it yourself. If the team succeeds, incrementally increase the product scope.
• As teams continue to execute well with products with additional scope they can start taking on more of the product strategy.

---

There is nothing more important than having a product team that can execute well. This is the foundation for any high-performing software development company. Incredible execution gives you more space to be wrong about product strategy and iterate toward successful products.