Chapter 18: Lean Product Development and Lean Startup

Until now, we have only focused on how you should build and deliver software and not on what you should build or how you can determine whether you are building the right thing. But lean product development practices have a great positive impact on software delivery performance, organizational performance, and organizational culture (Forsgren N., Humble J., & Kim G., (2018), p. 129). Therefore, many DevOps transformations start by analyzing the value streams and try to optimize product management alongside the engineering practices. But, in my opinion, this results in too many moving pieces, and it is also a chicken and egg problem. If you are not able to deliver frequently in small batch sizes, it is hard to apply lean product management practices.

In this chapter, we'll have a look into how you can apply lean product development and lean startup practices to build products that delight your end users. This chapter covers the following:

• Lean product development
• Incorporating customer feedback
• The minimal viable product (MVP)
• Enterprise portfolio management
• The Business Model Canvas

Lean product development

Building the right things is hard and often underestimated. You cannot just ask potential customers what they want. What people say they want, what they really want, and what they are willing to pay for, are three completely different things.

Lean product development was introduced by Toyota to address challenges in their product development approach, notably the lack of innovation, long development cycles, and many reproduction cycles (Ward, Allen 2007 p. 3).

Lean product development is built on cross-functional teams that take an incremental approach. The main characteristics are as follows:

• Work in small batches.
• Make the flow of work visible.
• Gather and implement customer feedback.
• Team experimentation.

As you can see, this completely aligns with what we've learned in Part 1, Lean Management and Collaboration. The new dimension is customer feedback and experimentation. But without the ability to work in small batches and a visible flow of work, it is not possible to experiment based on customer feedback.

Incorporating customer feedback

But how can you gather customer feedback and implement it as a learning into your product? Most importantly, you need the autonomy to do it. As long as your team still receives requirements to deliver, you are not able to learn from customer feedback and incorporate the feedback into your product. Besides that, you need people with the right skills in the team or you must train your engineers. Product management and user experience design are skills that are not present in most teams but are crucial to learning from customer feedback and interactions.

One way to gather customer feedback is by interviewing your customers or performing guerrilla usability testing (see Chapter 12, Shift Left Testing for Increased Quality). But, you must be very careful when interpreting the results. What people say and how they behave are normally two completely different things.

To really close the feedback loop and learn from customer behavior, you need the following:

• Customer data (not only interviews but also feedback, usage data, evaluations, and performance data, for example)
• The knowledge to interpret the data (product management skills)
• A scientific approach

The lean startup methodology moves product management away from intuition (alchemy) to a scientific approach, performing hypothesis-driven experimentation using a build-measure-learn loop (see Ries, Eric 2011):

• You formulate a hypothesis based upon an analysis of your current customer feedback/data:

  We believe {customer segment},wants {product / feature} because {value proposition}

• To prove or disprove the hypothesis, the team conducts an experiment. The experiment will impact certain metrics.
• The team analyzes the metrics impacted by the experiment and learns from them, normally by formulating a new hypothesis.

Figure 18.1 shows the build-measure-learn loop used for hypothesis-driven experimentation:

Figure 18.1 – Hypothesis-driven experimentation, the build-measure-learn loop

Practicing hypothesis-driven development is not easy. You need a lot of metrics and a good understanding of how your end users are using your application. Usage data alone is not enough. You must be able to combine this with performance metrics, error logs, security logs, and custom metrics to get the full picture of what is happening. How many people stopped using the application because it was too slow? How many people cannot log in? How many password resets are attacks and how many real users cannot log in? The more you experiment, the more you will find gaps in the knowledge of how your users are behaving. But, with every loop, you will learn and add more metrics and you will build an application that is better for your users. And, you will learn what features bring real value to your users and what is only waste that you can remove to make your product leaner.

Hypothesis-driven experimentation can perfectly be combined with objectives and key results (OKRs) – see Chapter 1, Metrics That Matter. OKRs give you the ability to align your autonomous teams to a greater vision by setting measurable key results on certain metrics, such as growth, engagement, or customer satisfaction.

The MVP

One of the most misused terms over the last years is the MVP. Everything that used to be a proof of concept (PoC) or a spike is now called an MVP. But an MVP is a version of a product that enables a full turn of the build-measure-learn loop with the minimum amount of effort (Ries, Eric 2011 position 996).

A diagram I often see that resonates very well with the audience is this:

Figure 18.2 – Bad example of how to build an MVP

It shows that you should deliver with every iteration value by solving the problem domain – in this example, transportation. The problem is that this is not an MVP. This is agile delivery. But a bicycle does not allow you to test the value proposition of a sports car! Tesla could not have created an electrical bicycle to conduct an experiment on the success of an electric sports car.

If you test an MVP with your real customers, always keep in mind that it can destroy your reputation and that you might lose customers. An MVP cannot just have the bare minimum of functionality. It must also be reliable, user-friendly, and desirable:

Figure 18.3 – An MVP must test all levels in the hierarchy of needs

Therefore, it is much easier to conduct experiments using an MVP if you have an existing product and customer base. For start-ups and new products, it is much harder, and you must include usability and reliability testing before putting your MVP out in the wild. If not, the experiment could go completely wrong. But even for existing products, when trying new features with your customers, make sure to make them reliable, user-friendly, and delightful!

Enterprise portfolio management

In a start-up, it is normally easy – at least in the beginning. But if you have multiple teams and multiple products, the question is, how can you ensure that cross-functional, autonomous teams pull in the same direction and take decisions that serve the long-term goals of your organization?

To practice lean product development, your company needs to move away from command-and-control processes to the principles of mission (Humble J., Molesky J. & O'Reilly B. 2020). This affects the portfolio management in your company:

• Budgeting: Instead of traditional budgeting for the next fiscal year, your management sets out high-level objectives across multiple perspectives and reviews them regularly. This steering can be done on multiple levels and allows the allocation of resources dynamically when needed.
• Program management: Instead of creating a detailed, upfront plan, your management specifies on a program level the measurable objectives for the next period. The teams then figure out for themselves how they can meet these objectives.

This can be perfectly combined with OKRs (see Chapter 1, Metrics That Matter).

But the principle of mission means that you need knowledge about product management and the market on all levels. It is important to understand that like each feature (see Chapter 10, Feature Flags and the Feature Lifecycle), each product has a lifecycle. New technology gets adopted by different groups of people. There are the innovators who just try everything, and there are early adopters or visionaries who try to stay ahead of the herd. Then, you have the big majority – around 70% in total. You can separate the majority into early majority (pragmatists) and late majority (conservatives). In the end, you also have the laggards or skeptics that only follow the trend, if there is no other option:

Figure 18.4 – The technology adoption lifecycle

An interesting thing here is the chasm – the logical divide between the early adopters and the early majority. The chasm is based upon the observation that many innovations struggle after they are not seen as a source of competitive advantage by the innovators but are not yet sufficiently established to be seen as safe by the early majority. Many products fail at exactly that point.

Once the early majority has started adopting the new technology, normally, other products and offerings enter the market. The market total is still growing, but the market changes as there are more competitors and the expectation of quality and price change:

Figure 18.5 – Market maturity

It is important to understand where in this lifecycle a product is, as each stage requires a different strategy to be successful.

Start-ups begin with exploration. They search for new business models that align with the vision of the founder, deliver customer value, and can drive profitable growth. In this exploration phase, when a start-up has found a problem/solution fit, it tries to evaluate as fast as possible whether it also is a product/market fit by using an MVP.

Once the business model is found, the tactic changes to exploitation. The start-up exploits the business model by scaling up and driving down costs by improving efficiency.

Exploration and exploitation are completely different strategies that require different competencies, processes, risk management, and mindsets. Start-ups are normally good at exploration and bad at exploitation – enterprises are good at exploitation and bad at exploration.

It is important for all companies to find a balance between exploiting existing products and exploring new business models because, in the long run, you can only exist if you are able to manage both. That's the reason why so many enterprises now have innovation and incubation hubs to mimic start-ups to evaluate new business models.

To manage your portfolio, you can plot your products on a growth matrix. The matrix has four quadrants for growth and the importance of the products relative to the other investments:

Figure 18.6 – The growth matrix for portfolio management

The size of the products can be the revenue or margin. You should always have enough products in the emerging quadrant that can be developed to the growth or mature quadrants because some will just decline without gaining relevance. The left side shows the products that you should explore, and the right side the ones you should exploit.

The matrix is very similar to the growth-share matrix from the Boston Consulting Group (BCG). The framework was created by Alan Zakon – later CEO of BCG – in 1970. The growth-share matrix uses the market share instead of the financial importance on the x axis:

Figure 18.7 – The growth-share matrix

The matrix is suited if you have a clear view of the markets, but it works in the same way. The question marks are the products with high growth that must be explored and developed to stars or cash cows, which then get exploited. Pets are either failed experiments or declining cash cows. But, in either case, you should shut them down sooner or later.

The challenge for enterprises is to create products in the stars (or growth) quadrant without acquisitions. The reason is the market dynamic (Figure 18.5), and the way enterprises manage their portfolio. You can use the three-horizon model to manage an enterprise portfolio:

Figure 18.8 – The three-horizon model

The three horizons are as follows:

• Horizon 1: Generates today's cash flow
• Horizon 2: Today's revenue growth and tomorrow's cash flow
• Horizon 3: Options for future high-growth businesses

Horizon 1 is your mature products or cash cows. Investments in these will return results in the same year. Horizon 2 are emerging products that have the potential to become new cash cows. They need a lot of investment but will not deliver the same level of results as the investments in Horizon 1. Horizon 3 are the potential stars of the future, but with a big chance to fail.

The three horizons are completely different, and you need different strategies to be successful (Humble J., Molesky J. & O'Reilly B. 2020). But not only do you need different strategies, but often the new products will disrupt the market and take away share and revenue from existing business. Kodak invented the digital camera in 1975, but their business was built upon developing photographs and not on capturing memories, and the invention was turned down by management. Kodak filed for bankruptcy in 2012 – a year in which nearly every person had at least two digital cameras in their pocket at any time. A successful example is Amazon, where electronic books took away a lot from their classical business model of selling physical books, or a Microsoft cloud business that would lead to a decline in license sales for on-premises products.

With new products taking away market share and revenue from existing markets, it is important to steer the enterprise in a way that all people share the same goal of long-term success. If not, people will start to conspire against the new products to preserve their dominance inside the enterprise.

To balance the three horizons, you should have a transparent process of allocating the resources and the different strategies that apply. A common amount to invest in Horizon 3 is 10% – often quarterly, funded based upon validated learning. Table 18.1 shows the different strategies and investments for the three horizons:

Table 18.1 – The different strategies for the three horizons

But should you put the horizons in different business units? I believe not. This will just result in more competency and silos. A good company culture with a growth mindset and objectives that balance short and long-term goals allows you to be innovative on all levels and embrace innovation. But good product management is needed to visualize what products and features are in what phase of their lifecycle for all to understand the different strategies applied.

Improving your product management skills

Product management is a skill that is crucial to successful DevOps teams that want to practice lean product development. Many agile projects fail because the product owner is not able to drive the vision and make tough decisions that are often necessary. Product management is based upon three pillars:

• Understanding your customers
• Understanding your business
• Understanding your product

Understanding your customers

To build products that delight customers, it is necessary to have deep empathy for the persons that use the product. In software development, we use personas (fictional characters) to represent user segments that use our product since the 90s (Goodwin, Kim (2009)). Having specific characters in mind when designing a feature helps us to be more empathetic to the needs and limitations of our customers compared to just thinking of the customers as a big group with mixed characteristics.

But today, we can do more. We can gather data on how our customers are using our product. What personas (usability cluster) can we extract from that data? What are the most common use cases? What features aren't used? What use cases get terminated before they are complete? These are questions we should regularly answer by analyzing the data.

Understanding your business

To build successful products, your team does also have to understand the business. What is the market we are in and how big is our market share? Who are our competitors and what are their strengths and weaknesses?

Understanding the business is normally a completely new discipline for engineers. Traditionally, this was done on a different level and only a little information was passed to the engineers. Exercises such as the Business Model Canvas (see the next section) can help you foster these skills in your teams.

Understanding your product

Understanding the product is normally the strong capability of the engineering team. But understanding the product does not only mean that you know the feature but it also means you know how the product is operated, load-balanced, how the performance is, and how much technical debt you've accumulated.

Of course, you can add members to your team who are experienced product managers and user experience designers. But, as we discussed in the previous chapter, you should keep your teams small. The skills are needed for every feature you create and release, every experiment you conduct, and every decision you take. It is better to upskill your team and have, for example, user experience designers that can help your team if needed.

Business Model Canvas

To strengthen the product management skills of your engineers, you can perform an exercise to create a Business Model Canvas – a template for creating business models or documenting existing ones. The Business Model Canvas was developed by Alexander Osterwalder in 2005. You can download a free copy of the template here: https://www.strategyzer.com/canvas/business-model-canvas.

The Canvas is meant to be printed out on a large piece of paper and the team can brainstorm and jointly sketch or add post-it notes on it. It contains nine essential components for a business model:

• Value proposition: What problems are we going to solve? What needs are we satisfying?
• Customer segments: For whom are we creating value? Who are our most important customers?
• Customer relationships: What type of relationship does each of our customers expect from us?
• Channels: Through which channels do our customers want to be reached?
• Key partners: With whom do we have to create a partnership? Who are our key suppliers?
• Key activities: What activities will be required to fulfill our value proposition?
• Key resources: What resources – such as people, technology, and processes – does our value proposition require?
• Cost structure: What are the most important cost drivers for the business model? Are they fixed or variable?
• Revenue streams: For what value are the customers willing to pay? How much and how often?

The Canvas contains some more hints that help your team to create the business model, as you can see in the following screenshot:

Figure 18.9 – The Business Model Canvas

By filling out all areas of the Canvas, you are considering any potential ideas in terms of the entire business model, and you are encouraged to think in a holistic manner about how all the elements fit together.

Summary

In this chapter, you've learned the importance of lean product management and how you can incorporate customer feedback into your flow of work. You have learned what an MVP is and how you can use hypothesis-driven development to build the right things.

In the next chapter, we'll have a closer look at how to perform A/B testing to conduct experiments.

Further reading

These are the references from this chapter that you can also use to get more information on the topics:

• Forsgren N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (1st ed.) [E-book]. IT Revolution Press
• Ward, Allen (2007). Lean Product and Process Development. Lean Enterprise Institute, US
• Ries, Eric (2011). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses [Kindl Edition]. Currency
• Humble J., Molesky J. & O'Reilly B. (2015). Lean Enterprise: How High Performance Organizations Innovate at Scale [Kindle Edition]. O'Reilly Media
• Osterwalder, Alexander (2004). The Business Model Ontology: A Proposition In A Design Science Approach: http://www.hec.unil.ch/aosterwa/PhD/Osterwalder_PhD_BM_Ontology.pdf.
• Goodwin, Kim (2009). Designing for the Digital Age - How to Create Human-Centered Products and Services. Wiley