SovTech DevChat: Highlighting Lean Product Development Principles

Introduction

 Hello everyone, today I will be talking about Lean Product Development.  

What my talk entails is:

•  A short introduction to the concepts and origins of lean product development 
• I will highlight some of the focus areas that we as software development teams should focus on building cultures around; Steering on Value, Iterative Implementation, Validated Learning and Innovation 
• Then I’ll also mention some basic applications throughout

Concept and Origins

So you will notice that a lot of the principles that are discussed in this presentation are also present in the Agile principles and in accordance with a lot of the behaviour and operational aspects of how we run our development processes.  

This is because many of the principles that make up Agile are taken from lean manufacturing and lean product development principles and have been combined with other principles that apply specifically to software development teams. 

I want to focus on the lean product development principles to provide a clear understanding of their benefits so that we can pay particular respect to these in our operations. 

The aim of adopting the concept of lean product development is to ensure that we are speeding up the delivery of value to our clients and increasing the rate of innovation.

Consider this quote:

“To manage product development effectively, we must recognize that valuable new information is constantly arriving throughout the development cycle. Rather than remaining frozen in time, locked to our original plan, we must learn to make good economic choices using this emerging information.” 

― Donald G. Reinertsen 

 See how this applies to the projects and products that you are working on and highlights the qualities of uncertainty, discovering new information, and adapting to that new information.

The roots of lean manufacturing and product development lie in the Toyota Production Development System, where their application resulted in Toyota becoming a powerhouse in the automotive industry. 

I am going to run through some of the principles shortly, but essentially the main results of adopting these development principles are:  

• High rates of delivery at a large scale 
• Reductions in waste by focusing on what is valuable
• Products that accurately suit the needs of their customers

These are the 13 principles that have been outlined in the Toyota Product Development System. I would like to highlight a few which I think are applicable to this discussion: 

• Establish customer-defined value to separate value-added from waste.
• Front-load the product development process to explore thoroughly alternative solutions while there is maximum design space.
• Develop towering competence in all engineers.
• Build in learning and continuous improvement.
• Build a culture to support excellence and relentless improvement.

And before moving on, I would like to be specific about the difference between lean manufacturing and lean product development here.

• Lean manufacturing focuses on reducing waste 
• Lean product development focuses on designing new products which improves the lives of customers and is a complex space where the flow of value can only be discerned at an abstract level and where cause and effect might be separated by time and space.  

The Experimental Cycle 

So what we are going to discuss here is the cycle and focus areas of lean product development.

The areas in which I would like to focus and highlight are:

1. Steer on value which is focusing on what is going to deliver value to the digital products and its users - basically what we should be aiming for.
2. Iterative implementation. Breaking down initiatives or chunks of work into different iterations to deliver value early. Mainly focusing on what the benefits of this are.
3. And then validated learning and innovation, making sure that we are developing reusable knowledge to maximize the delivery of value.

Steer on Value 

Steering on value and making sure that every effort spent is creating value for our client's users to ensure that the product can grow therefore translating into value for the owners of the product (our client).

I'm going to start with the product sponsor because without the product sponsor the product would not exist. What we are looking at here is measuring value for the product sponsor from a unit economic perspective which is typically how our clients would measure the value generated from their product.

So for any product sponsor type whether it be for-profit or not-for-profit organisations, both would use this concept of measuring value per unit although value may be denominated in different forms. Typically in software products the units of measure would be users and the value per user can be measured by dividing customer lifetime value by customer acquisition cost. Customer lifetime value estimates how much a company receives from a customer during the entire engagement time before this customer churns, and then customer acquisition cost estimates how much it costs to attract a customer. 

It is important for us to understand exactly how our clients see value for the products that we develop so that we can focus on means to maximize customer lifetime value. This may be by hooking customers for a long time, creating high value features that customers love and demand and therefore have a higher willingness to pay for. 

And then by reducing customer acquisition costs, also delivering valuable features which create higher demand and lower the costs to convert customers, means that improve the performance of marketing and sales, and then leveraging network effects so that we are able to attract more users to the products.

In terms of delivering value to products, there is no set play on how to do this as it is context dependent. But the main areas to elicit value from are:

• Business - what delivers value to the business. Maybe its reporting, admin features, process optimisation, etc. This can be identified by chatting to business stakeholders.
• Customers - new features and enhancements, bug fixes - basically what helps customers achieve their goals on the platform.
• Tech/product - what does the development team suggest; optimisation, refactoring, tests, analytics. 

I read an article by Zandre Coetzer, a UX designer who worked at SovTech sometime ago. He outlined a high level framework for setting metrics to evaluate performance of a product and distinguished between “External” and “Internal” metrics. 

At an organisational level there will be goals to aim for, for example; revenue, leads, turnaround time, etc. - these can be referred to as external metrics. 

External metrics can be set at different levels of the product and can be changed according to the evolution of the organisation. A simple way to get started with this is by creating a North-Star metric, similar to our “one numbers”, which is a specific metric that best captures the core value that your product delivers to customers. 

In terms of internal metrics, these will be set at a more granular level and help you create hypotheses and test the effects of effort spent. This will be discussed further under validated learning and innovation. 

As I mentioned abstract levels earlier, what delivers value to customers is difficult to model and predict, and obviously very context specific. Lean/Agile/etc are all schools of thought to address this and the delivery of value is very much an experimental cycle. 

So like any experiment, you start with a hypothesis - what you think will deliver value - and outline your team's next investment of effort or leap of faith - whether it be feature upgrades, paying back technical debt, analysing data, and so forth. The scope and nature of the leap of faith will be discussed under iterative development which is the next section.

Iterative Development

The idea behind iterative implementation is to break down the scope of work aligned with a larger goal into discrete pieces that deliver increments of value once that piece of work is Done.

Specifically in software development what you want to be doing is delivering end value to the users at the end of each iteration. This is the purpose of sprints in Scrum. The sprint should be led by a goal or an objective which defines the increments of value delivered at the end of that sprint.

The concept which underpins the idea of breaking down scope of work is called small batch processing. Working in small batches forces teams and clients to identify what the problems are that are aiming to be solved, isolating the solutions (batches), and then prioritising the batches to solve those problems. 

Being able to isolate solutions and deliver them in batches reduces the amount of work which moves from one stage to another in the process, for example from To Do, to In Progress, to Done. 

This enables work to be pulled through the process in single-piece flow. Now the idea of pull comes from pulling work from a backlog instead of having work pushed onto and overloading the resources involved in the process. When resources are overloaded they tend to not operate as effectively under pressure and therefore create waste. 

Think of it as a busy grocery store when people are consistently coming in and crowding up the store. A lot of pressure is put on the isles, the attendants and queuing systems in the store. But the cashiers, by serving one person at a time, are able to pull customers out of the store therefore relieving the pressure internally.

There are two additional benefits to this approach, further than the benefits of increasing efficiency and reducing waste from a process perspective. One, the team is able to deliver early returns on investment to your client. Two, you are able to discover new information during the iteration and adapt this information based on what has been experienced. You're able to consistently validate if what you are delivering is valuable and keep making innovative steps to further improve the delivery of value. 

Because you are also committing to smaller batches of work you are able to manage your client's expectations a lot better. For example it's better to have delivered increments of value in the past, and then run into a blocker which throws off only one batch of work, instead of committing to a large batch of work where a blocker, especially if found further down the line, throws out a large expectation. It’s particularly harmful as essentially what has been wasted is the planning invested into this large piece of work and the effort that has been spent up until the blocker was met.

In terms of breaking down work into small batches and iterations, it's everyone in the team's responsibility as it benefits the whole team. It is suggested that it's taken from a user focus with the application of technical solutions and therefore requires technical and product understanding, and attention given to effort required and risk. 

Validated Learning and Innovation

Going back to external metrics, let’s say we are going to set a North Start metric for the products that you are working on. You can set many external metrics for products but let’s just start with one for simplicity purposes. 

Some examples of large companies and their North Star Metrics are:

• Airbnb: Nights Booked
• Facebook: Daily Active Users
• Quora: Number of questions a user answers
• WhatsApp: Number of messages a user sends - same as Slack
• Amazon: Number of purchases per month

What best adds value to the users and how they engage with the product. 

Setting and measuring up to internal metrics is tricky as you are moving into a more granular domain of validation. The aim is to maintain causal relationships at different levels:

• Effects on your internal metrics need to have direct effects to your external metrics. 
• Effort expended needs to have direct effects on your internal metrics.

Again in terms of what your internal metrics look like will depend on your product. But as long as you have high confidence in the relationships between these levels you should be able to set metrics and start measuring them. If these are being measured correctly, early and often you should be able to determine if your metrics are moving you forward. To spend a bit more effort here would be to conduct regression analyses or doing split tests to more accurately prove relationships and the extent of their effects.

Ideally you would like to start with the metrics first as these are aligning with goals at different levels and cascading down. But at the end of the day, requirements might be handed down which provides the opportunity to explore new possible metrics and draw feedback loops with unexpected results and effects. I suggest identifying some possible data points with each iteration to help analyse effects. 

So let’s look at some possible internal metrics for different product types, there isn’t anything too exciting here but it paints the picture:

Some examples of tracking methods are: 

Qualitative user feedback

• Customer Interviews - The Google Ventures team says 5 customers is enough to identify trends. 
• In-app feedback forms - see Jira integrations for his. 

Tools 

• Google Analytics - setting filters on metrics and creating goals
• MixPanel 
• HotJar 
• BugSnag - Stability Score and Search and Segment
• Log-based metrics - building, storing and managing logs in a valuable way to derive insights. 

Essentially, if you are validating that what you are delivering is valuable and continue to use this knowledge to keep delivering more value, you will be able to deliver much more value at much less scope and in a much shorter time!  

References 

• Toyota Product Development System principles: https://www.industryweek.com/leadership/companies-executives/article/21943881/the-13-principles-of-lean-product-development. 
• Pull example: https://www.playbookhq.co/blog/push-vs-pull. 
• Zandre Coetzer - A framework to define your product metrics: https://uxdesign.cc/a-framework-to-define-your-product-metrics-6ca9837bfc8b. 
• Grow - Metric of the week: North Star Metric - https://www.grow.com/blog/what-is-a-north-star-metric. 
• Robbin Schuurman - 10 Tips for Product Owners on (Business) Value: https://www.scrum.org/resources/blog/10-tips-product-owners-business-value.