I feel the need. The need for speed
Velocity hacks for product leaders
Have you ever been in an organization that struggles with product launch velocity?
If you are at a startup, the answer is hopefully no. The opportunity cost to continue working on something is high, the need to ship is clear, the downsides to iteration low, and survival of the business existential.
Yet as you become more successful, as a company and team grows, so do the barriers people erect to launch. As a product leader, how do you keep up team velocity?
In a recent post I talked about using product reviews as product crits and not as launch reviews. This is one way to keep up velocity, because product feedback happens earlier in the process. One of the worst things you can do to a team is only provide feedback when something is ready to launch.
Here are some other velocity ‘hacks’ for product leaders. In a follow up post I’ll also talk about anti-patterns — things to avoid in launch processes.
1) Think of it as a test, not a launch
If you think of product development as a continuum rather than a finite project, you will develop better products. You need to get a product into users hands fast, learn, then iterate. This may even mean a launch is actually upstream from final ‘general availability’ (for instance, in hardware you can’t wait until mass production to test but you can get an early prototype into users hands asap).
2) Enable teams to align work with priorities early
Does a feature or product align with the business strategy? Have a process where this can be answered early in product development so people don’t waste cycles. Waste kills morale. Low morale kills velocity. Low velocity kills baby kittens.
3) Have a product strategy. Then communicate it over and over. Until you hate it
To know if a feature aligns with strategy, you need to, uh, have one. Just as important, the team needs to internalize it. I was once leading an org of a few hundred people. We had an all hands where we went over the product roadmap. The next week someone came to me complaining about how they didn’t know what our roadmap was. That was an ah-ha moment as a leader. Just because you look at strategy day-in and day-out, don’t assume others are paying attention. We are all guilty of daydreaming, so overcommunicate. As the saying goes, repetition doesn’t spoil the prayer.
4) Have teams state their hypothesis early
You’ve got a feature. It is supposed to do something. What and Why? What user pain point is it solving? What do you think will happen when you launch? Why do this now? Being clear about the objective and hypothesis early in product development keeps everyone on the same page about what the launch is about.
Sometimes a feature solves a business goal rather than a user pain point. This can be ok. If you need to launch a business objective, don’t spend cycles contorting users’ need to fit what you are doing. Be honest with yourselves that it solves a business rather than a user need, launch it, then move on to other user needs.
5) Be clear about what you are measuring up front. But not all things need to be measured, either
What are the key metrics you are trying to move? Are they the right ones and what telemetry do you need to measure them? This is so important most of the time, but not all product improvements are worth the cost of measurement. Oh, fightin’ words! I once saw a team trying to clean up some settings in a product. It was a no-brainer improvement and the engineering cost to do so was tiny. But because of process, the team was spending more time trying to engineer some CSAT metric to prove impact than they were shipping the changes. Please no. Metrics should be the mainstream, but sometimes velocity calls for a pass.
6) Decide the deciders and make it transparent
Everyone on the team should know who can make the launch decision or what the process is. You’d think this would be commonplace, but too many times I’ve come into a new team where the process and who can make the call isn’t clear to the team. Ideally these deciders are close to the work and not the top person in the company.
7) One-way door decisions
One-way door frameworks are a good heuristic to help speed up decision making. Can you easily reverse the launch? If things go wrong, is the impact relatively small? If the answer is yes, adjust the launch bar and speed accordingly.
8) The journey shouldn’t end at launch
Circling back to the first point, build a culture and process around product success, not product launch. There are many reasons why launch-as-the-end-game can creep into companies at scale. The two most prevalent I’ve seen are a) launch timelines are long or b) reward systems favor launches and not ongoing product success. Keep an eye out for this. Launch fast and reward product success.
And now to practice what I preach. I’ve written this. It isn’t perfect. Its missing a bunch. But I think it provides some value. So…
ship it.
