Continuous Feedback through Continuous Deployment

When you’re developing a product, you’re constantly surrounded by questions like, “How can I improve my product?”, and consequently, “What’s the next step to take?”. There are 2 ways to answer these questions:

1. Ask your customers
2. Decide yourself

Ask your customers

Asking your customers appears like the better solution: You’re building the product for your customers, so they should know what they need. Unfortunately, they don’t. Henry Ford, the founder of the Ford Motor Company, once said:

If I had asked people what they wanted, they would have said faster horses.

Your customers are biased with current solutions for their problems, that’s why you can’t expect true innovation from them.

Decide yourself

It’s your task to innovate, not your customers’. The problem is that you don’t understand your customers’ problems entirely in advance. Your most important task as product developer is to learn to understand your customers better than they understand themselves. Make a hypothesis about what your customers need and then try to prove (or even better: refute) this hypothesis. A hypothesis is always a guess, but you will become better and better at guessing the more you validate.

[otw_is sidebar=otw-sidebar-1] 

Iterate fast

Your product development will become a cycle of changing the product based on a hypothesis and getting feedback on this change. The speed at which you’re able to run through this cycle determines the speed of your innovation. If you’re only able to deliver changes to your product to your customers every few weeks, you’ll only get feedback every few weeks. Therefore your innovation will be considerably low.

The key step to increasing innovation is: Ship as soon and as often as possible. But how can you get there?

1. Build tiny features

Only focus on single features. Every single feature should be shipped separately so you can immediately validate it afterwards.

If a feature takes more than a few days to create, split it into several parts and start with the most basic one. Ship every part separately and validate it. Quite often you will realize that you need less or different parts than you initially intended. This way you can even validate a feature while it is still in development.

2. Automate testing

Many teams have slow release cycles because testing their products takes a lot of time. So the more often they release, the more time they spend testing that everything still works. The solution is to automate testing. Once set up, it doesn’t matter if you release every month or every hour, it won’t take away time from product development.

3. Automate releases

If you can be sure that your product always works, you can automate your releases as well. Once you set up a solid release process, you can be sure that it will work and it won’t take away time from your product development either.

[otw_is sidebar=otw-sidebar-2] 

4. Deploy continuously

Once all previous steps are set up, why not release on every change to the product? At the Codeship we deploy changes without thinking about it. Every time a tiny feature is complete, it is released automatically. This process is implicitly triggered by completing a feature. Continuous Deployment involves testing the whole product automatically and releasing it if all tests succeed. This way we can release new features several times a day without any overhead for testing and deployment.

Continuous Feedback

Changing your development process to use Continuous Deployment directly fosters innovation in your product development. Continuous Deployment removes all overhead of releasing a new version of your product that you might know from your workflow. This way you can release more often and thus get customer feedback more often. This lets you develop the product your customers really want.

Clemens is responsible for the software engineering team at the Codeship. He’s obsessed with creating efficient processes and loves Continuous Deployment. The Codeship is an online service that aims to make Continuous Deployment as easy as possible. Clemens regularly writes on the Codeship Blog.

[otw_is sidebar=otw-sidebar-4]