Why ship when you can debate?
Anti-patterns in product launch velocity
My last post was about keeping launch velocity as companies scale. Now let’s have some fun with anti-patterns at scale. These crop up the larger you get. Some only appear when you are really big. This list is infinite, but here are a few that come to mind.
The distributed decider
You need to get approval to launch from 5 different, functionally equivalent people who may not agree, have different visions, whatever. Matrixed orgs love to distribute responsibility. Everyone gets to take the credit when things go well but no one can be held accountable for things that go wrong. You’d think this would lead to faster decisions because risk is distributed, but the opposite is true. Have one accountable decision maker with supporting functions weighing in.
The top-of-org-chart decider
You often see this on projects where a product crosses org boundaries. It is a velocity killer because this person is always the least close to the details AND the busiest. That means the team spends a lot of time distilling information and tying launch velocity to someone’s calendar rather than the project work itself.
This doesn’t mean you shouldn’t get input from folks up the chain. The higher you go, the broader the view of the business. When you are working on the wheels of an airplane, those wheels are what you see. Higher up the chain you may see that the trend is towards float planes that need to land on water. But those are strategic points of view.
Empower teams to make decisions and hold them accountable. If a project crosses org boundaries, make the call to hold one person accountable and explain why. While this may make the non-chosen person unhappy, I guarantee it will make many more ecstatic in the long run.
We need UXR for that
The bigger a company gets, the more specialized the resources you can draw on, like UXR teams. These functions are useful, but can be abused. Product and design teams should be using their understanding of the user and their own judgment to make calls about many product features. Pull out the big guns on major questions, not every feature.
Let the lawyers decide
Your product counsel is like an overprotective parent. They are extremely useful in keeping you safe, but aren’t going to endorse climbing to the top of a tree. There are great product lawyers who deliver their analysis as a risk equation, but not all do. So have someone senior to listen to the advice of counsel, then make a risk call on a launch.
Form a steering committee
When you hear that someone is forming a “steering committee”, you’ve hit a nadir in velocity. Not sure I can offer solutions other than run.
Don’t decide anything, just ask for more data
This is often a cop-out path for not making hard calls on projects people don’t believe in. Just ask for more data and hope the project dies of attrition. There are legitimate reasons for needing data — revenue risk, legal risk, customer impact, etc. But for projects that are that sensitive you should have the team lay out what data they need early on, then work towards that. If the data comes back inconclusive or negative, don’t pivot endlessly — make a call and move on.
In closing, don’t confuse QA with upstream strategy & design
At the end of the day, you want to launch great products, not crap. That means creating a culture of excellence where teams working on the product know what great looks like, have a clear strategic direction, and a mandate to get there.
As product leadership, you want to be setting upstream strategic direction, creating a culture of design excellence, and playing a small role as backstop QA at the end of the process. But don’t confuse the QA part with the upstream bits. The factory QA person says the blue color is off; they don’t say the product should be red. QA doesn’t go ask users if they prefer one shade to the other. There isn’t a committee to discuss the blue color.
There are two key takeaways here: Streamline key decision making to accountable individuals, and answer the strategic questions early in development not at launch. Just those two things will go a long way to keeping velocity up.
Ship it.
