'Lean' businesses are able to build better products, get them to market sooner and get them to market with less investment by delivering products which contain real value for customers. The idea, introduced by Daniel Jones’ and James Womack in their book Lean Thinking requires constant feedback throughout the design and supply chain; feedback which, in their terminology, “pulls” value through to the customer. This idea has gone on to spawn the concept of the Lean Startup put forward by Eric Ries and become part of how many modern products are built.
But how can software engineers feed into the lean process?
It turns out there is a very important role for software engineers in the concept of ‘lean thinking’: they can see inside the minds of customers.
Engineers can see what really happens when the customer clicks “buy”, when the customer’s data hits your data centres or when the user puts on their IoT watch. Engineers deal in the raw data of the product’s day-to-day use, allowing them to see what’s really going on. While marketing and product managers will have measures and KPIs, these are often a subset of the complex pathways users take through the product each time they use it.
So, to address our question: software engineers deal in the raw activity of what’s possible and what is happening in the product as it’s being used today. They can record activity, investigate performance and dig into user behaviour faster than any other part of the product because they have their hands in there.
Let’s take a hypothetical example of an IoT health device: people buy it, use for the first couple of months and then progressively forget about it, using it every few weeks before it ends up residing in in the cupboard. Like many connected devices, the business model is based on on-going usage and so it’s in our interest to keep the device in use.
When used in this way, the engineer can walk through logs which provide a great source of quantitative and qualitative data about what’s happening day-to-day, both for the user and for the product. Does the user stop using the device after a certain time of day? Is there a peak “push notification” time? Does the system require setting up which discourages the user from continuing?
This aggregate trend data which describes when the device is being used, for how long and for what purpose provides the engineer with clues as to where to go next. If we know that users start giving up after 4 weeks perhaps we can look at what’s happening on the device around that time? This is where walking through the static code and looking at specific user records can help expand the story of why users don’t carry on using the device.
At this stage, engineers will fall into two camps: those who can confidently dig into the software and those that can’t. And this is almost entirely down to tooling.
If you, as an engineer, can’t imagine stepping through the code or extracting useful logs for the running system you just won’t bother.
But if you, as a well-tooled engineer, know that you can use automated tests to show you how the APIs are used, you can step through the code and insert breakpoints, and you can step back in time to investigate specific scenarios then you’re going to be able to expose more data - numerical and narrative - about what’s going on with the system.
When it is time to make a decision about which direction product development should go, the well-tooled engineer can provide deep, insightful and informed descriptions of how the product is being used, where issues lie and where there are opportunities for improvement. This insight informs the commercial strategy and product roadmap, ultimately delivering greater value for users and developing the product in a manner which consumers will want.
For many engineers, this changes the relationship between them and product management. Instead of taking direction from the top-down, they start influencing and guiding the product strategy from the ground-up based on the real behaviour of real users. Build better products and have happier customers: what’s not to like?