Generate an idea

Determining what people want is not easy, but it can be simple. The best way to determine whether people want to pay for something is to put it in front of them. Some companies do this by creating a completely finished product which has been fully designed, architected, and tested before a customer sees it. They want it to be perfect before showing it to customers and getting feedback. There’s only one problem with this approach: they can’t be sure what the customer wants until it’s in front of them. It’s entirely possible to waste an entire product or service delivery budget creating something nobody wants. It’s a huge risk, whose upside (if you’re exactly right) is often more than outweighed by its downside (what if it turns out the product doesn’t actually have a market?).

Hypothesise

The only time we find out if a product is valuable is when we get feedback from the customer. That means the faster we get feedback, the faster we can decide whether we want to continue, change, or cancel the product. The same is true when changing products – a change is only valuable once a customer is using it, and can provide feedback on it. (The corollary to this is that until a product is being used by a customer, it has absolutely no value.)

The logical extension of requiring customer feedback to find value is to work in ways that enable feedback as quickly and frequently as possible. Get your product in front of a customer, and see what the feedback is. Then adapt. This is also known as applying the scientific method to product development – generate an idea, form a hypothesis about the idea, create a means of testing the hypothesis, test it, draw conclusions, and adapt.

Image is CC-SA

In order to test whether your new approach works, make sure you measure what matters – how long does it take for an idea to come into the company from the customer, be developed, tested, released, and be back in front of the customers, happily being used. Don’t measure the time in each stage, as the customer can’t see them. The only thing the customer cares about is how long it takes to deliver a working, usable product, from end to end. And all you care about is whether that time is stable (with some degree of predictable variation), and whether your changes are improving it.

Test

Shortening feedback cycles means changing the way you organise product development. Rather than focus on who answers to who, and drawing it in an org chart, focus your teams on rapidly delivering products to customers. The focus should move from working on each phase of development to working on what customers need.

If you need analysis, development, and testing, then put them all together so they can figure out how to respond to customers quickly. If you write software, put in testing and deployment automation, so you can rapidly deploy small changes that customers see immediately. If you work on a large product, with lots of dependencies, start working on separating the components so development in one area doesn’t require testing and changes in a completely unrelated area.

Conclusion

You’ve changed your company. You’re now looking at how product development works, rather than on how people work on product development. And you have a measure you can use to determine success. It takes less time than it did before to deliver new features and products. They’re higher quality, and customer feedback is improving. Your measures indicate that you can get new features out the door in a predictable amount of time ( between X & Y days).

Your focus is no longer on production, but on flow. Keeping it there can be difficult, but it’ll significantly improve delivery, which will improve profits now, and in the future.

Adapt

Your first experiment worked. Now it’s time to see how you can continue to improve it. What factors contribute to product delivery timelines? After you’ve identified them, think about how changing them will change your delivery time scales, and whether a change in one area will impact another adversely. Focus on the areas that appear to be bottlenecks, and improve them until they stop being bottlenecks. Then repeat.