“Won’t running all those experiments slow down our product development?” When speaking at conferences, I get this question a lot. And my answer is always the same: yes and no. Let me explain.
There is a difference between “speed” and “velocity”. Speed is how fast something is going, while velocity is how fast something is going in a certain direction. For example, if you’re running on a track, your speed is how fast you are running, while your velocity is how fast you are running in a certain direction. Imagine running around a track in a circle. You could be running really fast, but your velocity would be zero because you’re not going in any particular direction.
When talking about the speed of product development, we must take care not to confuse speed with velocity*. We want to release features quickly (i.e. speed), but we also want to release features that add value (i.e. velocity). Experimentation helps distinguish between the two.
The answer to the question above is “yes and no” because experimentation will reduce product development speed while at the same time increasing product development velocity. We will ship fewer features when it turns out they don’t add the value that we expected. But we will also learn which features add value and which do not, and this will help us better decide which features to build next.
Speed matters, but we also need to ensure that we are speeding in the right direction. Running into a wall faster is not a recipe for product success.
*) What in Agile/Scrum is often referred to as “velocity” (e.g. the amount of work a team can tackle during a single Sprint) is from a product development perspective actually a measure of raw speed. Marking more tickets as completed or shipping more features to production might contribute to more product development speed, but customers don’t care how many tickets are done or how many features are released. Customers only care about things that bring value to them; they only care about your product development velocity.
