Do we have a problem with Product Speed?

If you work in Product Management for a couple of months you will inevitably come across people who feel like you are not moving fast enough. Problems will likely be uncovered faster than we can solve them and this can result in some frustration with product managers and they can quickly become viewed as not being team players. Often product managers need to be ready to talk about why developing products is not as fast as we all hope. However, product managers should pause and check to see if product speed is actually an issue. Because if it is it will become one that will ultimately threaten the business completely.

If someone is concerned about product velocity they are probably concerned about one of two things:

1. We are releasing enough features given a period of time, especially their ‘pet projects
2. We are not delivering value and solving problems fast enough to be competitive in our space

If someone has the first concern all you ought to do is clarify that the business’s priority is not to maximize the number of features delivered but to maximize the value delivered to the business customers.

However, if you are not delivering value to our customers fast enough to be competitive that will become a real problem.

What signs would indicate you might have a problem:

• Taking long (e.g. months) to ship the first release that generates any value for the customer
• Having to ensure every scenario and contingency is accounted for before developing: long scope docs, decision trees, picture-perfect mocks, etc.
• Not involving development beyond just “can we do this?” until the project is “scoped” and ready to be developed
• Not knowing if a release had the impact that would indicate it is valuable
• Measuring success primarily by how much is released, or just that something released, instead of on did it generate value

What could be the causes:

• Complexity of the business: This will vary from company to company but I’ve started things that are as simple as getting people to the page and been at companies that have intricate processes that need to be understood or you are more than likely to make this worse than better.
• Risk Averse: People generally are afraid of taking risks. We are also loss averse, so you and everyone in the company will be more prone to remember the times you struck out instead of the little wins that help create the company you are a part of.
• Tenure of product teams: Look at how long your product teams have been a part of your company. If it hasn’t been very long you may need to do things to accelerate getting them up to speed, this is especially true if your business is complex.
• Lack of Urgency: Some industries and companies have very natural and real deadlines (e.g. holiday season for e-commerce, beating a competitor). However, many software companies do not have these. Deadlines do create stress, but they also give teams a greater ability to focus and prioritize. Be careful not to overuse them, or else you will
• Low skill level of Product Managers: As a wise friend once told me over lunch that “making products is hard!” Many people want to build things and feel like they have good ideas. However, the harsh reality I’ve experienced is that without almost constantly reminding myself and my team we quickly fall into bad product habits.
• Problems with or lack of a process: One of the things I think product managers love about their role is that their job is a bit of the wild west. People don’t understand exactly what product managers do and day-to-day a product manager could do hundreds of different things. But this lack of process can result in chaos that yields nothing. I am not a proponent of a process that serves as a checklist. , but even the greatest piece of art has boundaries.
• Prioritization: Knowing what you should work on first is hard. If teams get this wrong it will mean they deliver things that miss the mark on value despite shipping features.
• Cadence of Development: I put this last intentionally because while I may be the problem I don’t think it is the most likely one. If you have a half-decent development process and a normal level of development skill your development team will not be the first problem to address.