'Let's do it'! A mantra for customer value in software development

If one line of code needs to be changed to improve a customer's experience and pushed to production immediately, your team should say, “Let’s do it".  

It's a simple-enough mantra – and, of course, much harder to do in the real world. 

And I think it means a number of things.  

One is that you should never hold the customer hostage. If changing one line of code improves the life of just a single customer, you should change the code and push it to production.  

Another is that you should never hold the code hostage. If your team has already fixed a customer issue or made an improvement which will benefit the customer but are waiting for a regular release schedule which is taking more time than expected, in this scenario the team should not wait any longer: they should push the changes to production.  

This first became a mantra I followed when I worked at a company releasing software every two weeks. The argument was that small changes, minor updates, or improvements that were useful to a small handful of individual customers could (would, so the argument went) upset the release rhythm. 

I didn't agree then, and I don't agree today. Doing what's right for the customer complements the regular release routine.

To my way of thinking, waiting for a week or two, or a month or two, is simply unacceptable when you know that whatever changes you have made will bring value to customers, even if there is only a handful of them.  

The role of process, the management of resources 

How does this work in the real world?  

And how does this mantra integrate, or perhaps clash with, an established release process? 

This brings us very quickly to the long-running debate between what is lean and what is agile. 

I’m not going to add more to that debate, but this mantra I subscribe to contains elements of both: the benefits of collaboration to create results more quickly (agile) and the continuous improvement of development efficiency, removing waste along the way (lean). 

In a real scenario that played out recently, our development team ran into issues and couldn’t complete all the committed stories, resulting in an incomplete application feature. Customers reported, and the internal team found, bugs that were then resolved. 

Faced with updates that fell outside the weekly software release cadence, the product manager asked, "How do I announce a release with only bug fixes? Can we wait to complete the feature and push it to production next week?” 

Some team members and I pushed back and said, let's release as planned with all the bug fixes. 

The product manager argued, "That's not attractive enough to talk about right now." 

And my response to that was, why not? If there is a bug that even just a handful of customers have been waiting for, those customers will be excited to see that the reported bug is fixed. 

In other words, the perception of the value in the software or a release sits with the customer. 

If it adds value to a customer, don't wait until you have killer features to take it to market.  

Of course, this scenario – to “release when ready” (sometimes called “rapid improvement”) – also creates very positive development improvement along the way. If a development team has identified and then releases bug fixes immediately, those fixes are embedded in all future software development. The medium-term to long-term development cycle benefits because the software developers are always using the best-possible version of the software at any given time. 

As to resources, the reality is also that in a modern software development environment, a team is going to be either lean, agile, or both. Following this mantra does not therefore replace either, nor does it claim to be better than either. 

Customer first, splash second 

Part of what we are talking about here is the human desire always to look for (and always to provide) the next big thing. 

But software releases should, on the whole, never be about making a big splash, in my opinion. What's suitable for the customer counts for far more, and I think that's a better approach. 

I’ve talked before about the importance of the customer and when it comes to software releases, there are always three types of customers. 

The first are those who use your product and are not shy to provide feedback. We love these customers because they help us to make our products better.  

The second are those who see problems but don't complain; they will get angry over time. 

And the third are those who don’t care and who simply trash the product. 

We strive to care about all three customer types because they are indeed our customers. And by delivering continuous improvements, as often as we have them, we meet their needs faster and demonstrate that we care about them. 

One recent example of how well this approach works is the Lenovo ThinkPad X Fold foldable laptop. It has software called a mode switcher, developed by our team, which reconfigures the mode of the device depending on whether or not it's folded. We've iterated several times on the mode switcher to improve the user experience since we launched the product, and we've supported customers who gave us great feedback - and the customers who remained silent. What was key was that we introduced those improvements continuously, without waiting for big features to be ready. 

Bringing process and customer together 

There are instances where the amount of time spent on fixing a bug is far less than the process followed to take it to production.  

In all of this, the process needs to serve the customer. Process is of course always important, on large-scale software projects especially. But any process that creates obstacles to customer delight does need to be removed, certainly to be reviewed and changed. If the process helps you be efficient, secure, and move faster with the production, do it; otherwise, discard it! There is no advantage to anyone in creating dissatisfaction in the minds of customers. 

In short, I am a big fan of bringing value to the customer as soon as possible, irrespective of the release cadence being followed.  

The most familiar sound around the corridors of the software team is, “Let’s do it!”