Chapter 5

Grow

5.1 Welcome to Grow

Welcome to the right side of the Lean Product Lifecycle (Lean PLC)! As you went through Idea, Explore and Validate, you ploughed through the paths of uncertainty using experimentation and iterative product development methods. Emerging from that journey, you now have some clarity on the right solution for your customers and the right business model to deliver that value. This is the transition point from the left side of the PLC to the right side. It is now time to double down on your validated business model. But if you think that this is all about execution; well think again!

Grow will be a critical and challenging stage for your product. It is not as simple as pouring fuel in your rocket and watching it fly. This is the lifecycle stage where many of the technology game changers that have been documented in the media such as Uber, Airbnb and Dropbox really knocked it out of the park.³⁷ But this is also the stage at which a lot of great products have failed. Grow requires relentless focus, energy and commitment over the long term. And even as you scale, you will need to continuously apply lean thinking within an environment which is constantly evolving.

To succeed in Grow, you will need to navigate the operational and cultural challenges of discovering and executing your business model at the same time. You will need to continuously improve operations so that you can scale fast. It will require you to keep pace with the progression of technology against a continuously evolving and relentlessly changing business environment. And if you stand still for too long, someone will be ready and waiting to take your customers. The Grow stage can be split into the following key phases.

1. Tuning the engine: This phase focuses on finding the right growth engine and testing our growth hypotheses. We will have learned some key lessons around potential growth during Validate, but now we want to refine our learnings so we can fully execute on our growth strategy.
2. Accelerating growth: As our knowledge and confidence around our strategy increases, we can then turn our attention to accelerating growth. We can deploy various growth tactics to rapidly increase customer numbers, revenues and profits. The goal here is to not only grow these key numbers but also improve our growth rates.
3. Optimising the engine: When we get to full velocity, our product will be growing fast. This does not mean that we rest on our laurels. We will continue to improve the product and optimise our growth engines. Such continuous improvement is a key part of lean thinking; and we will use it to maintain our growth rates.
4. Preparing for sustain: Every product eventually matures in the market. Growth rates will slow down as technologies and customer preferences shift. This does not mean we kill our cash cow. Rather, it means we have to change how we manage it. Our investments in growth can now be decreased and we can turn our attention to optimising and reducing costs.

5.2 Premature optimisation

So far in this book, we have been cautioning you against premature scaling. If you have followed our advice, you have worked hard to systematically uncover a great business model for your product. While this may be exciting, we have some more words of caution for you: avoid premature optimisation. In most companies, when a team with great product enters the Grow stage, they come under immediate pressure from leadership to rapidly grow the product. This can lead to early standardisation and counterproductive marketing expenses before the team has found the right growth engine. In other words, avoid those Super Bowl ads.

Before scaling rapidly, what we want to do first is find sustainable growth. According to Eric Ries, a product has sustainable growth when new customers come from the actions of current customers.³⁸ This is different from one-off marketing activities that may drive an initial bump in customer numbers and then fade over time. There are various ways to achieve sustainable growth and we will discuss these in more detail later. At the moment, we want to emphasise that before finding sustainable growth, any actions towards ramping up scale are bound to fail.

To find sustainable growth, we have to apply the same build–measure–learn process that we used during the earlier stages of the Lean PLC. We have to identify clear hypotheses about the level of growth we want to achieve and how we think we might achieve that. We then have to test these assumptions by deliberately measuring the impact of each growth tactic on the bottom line. Our goal is to find a repeatable process for driving customers to our product, converting them into paying customer and retaining them over the long term. Only after we have found this repeatable process are we then ready to scale.

As such, we never stop using lean thinking across the entire Lean PLC. As we grow our product we have to manage a continuous cycle of learning and development.

1. We will need to ensure that our teams are balanced and resourced so that they can simultaneously manage searching and executing on your business model.
2. We will need to decide on a range of key metrics that we will track to manage growth and scaling.
3. We will benefit from introducing a cadence for growth reviews during which we examine whether our growth tactics achieve our hypothesised results.
4. We will need to continuously advance our practices so that we can reach a state of continuous delivery.

5.3 Beyond the early adopter

As can be seen from Figure 3.2, on the left side of the Lean PLC you did most of your work with early adopters. However, in order to scale, you have to start thinking about mainstream customers. Unlike early adopters, mainstream customers are more demanding in terms of product quality and reliable service. The channels and marketing messages to reach mainstream customers will also be a little different to those you used to reach early adopters; and as your customer numbers increase you cannot retain the intimacy you once had with customers.

As such you need to adopt a different mindset. All of your learnings from Validate will need to be reconfirmed as you take the product to scale. This includes the technology stack, levels of service provision and business model which will need to be continuously refined as you learn. When maturing operations for scale, your team’s culture will be challenged and will be expected to evolve. In most cases each challenge may slightly change the culture and you will need to be mindful of the direction it takes. These changes are needed to grow, but also risk negatively impacting growth if not managed well.

To go beyond innovators and early adopters there are several things that you now need to consider. Table 5.1 lists things which your early majority customers and beyond will expect over your early adopters which you’ll need to prepare for.

5.4 Engines of growth

In order to grow effectively, companies need to have a shared language. As part of the lexicon, innovation teams need to understand the growth engines for their product. An engine of growth is our system for sustainable traction. It is how we ensure that the actions of current customers are consistently driving new customers and revenues to our product. In other words, engines of growth are a repeatable system for growing customer numbers, customer retention, engagement, revenues and profits. There are three main engines of growth that teams can use.

• The paid engine relies on paid advertising, marketing or a sales force to grow your product. With this engine, the key behaviour from current customers that drives growth is the amount of money they spend when they purchase our product. Since we are paying to acquire customers through advertising, marketing or a sales force, there are costs associated with every new customer we get. To achieve sustainable growth, the cost of customer acquisition must be less than the money those customers spend when they purchase our product. This then allows us to reinvest the money to acquire more customers creating a virtuous cycle of sustainable growth.
• The sticky engine relies on customer retention. The challenge here is how we get customers to stay with our product and potentially increase our share of their wallet. With this engine, the key behaviour from current customers that drives growth is whether they keep coming back to use our product. For sustainable growth, our retention rate has to be higher than our churn rate. If the rate at which we acquire and keep new customers is greater than the rate at which we lose customers, then sustainable growth will be achieved.
• The viral engine relies on word of mouth and usage by your current customers to drive growth. With this engine, the key behaviour from current customers that drives growth is the extent to which customers are willing to actively market our product for us by making referrals. The viral engine can also work when current customers inadvertently market our product through their active use of it. The success of our viral engine is indicated by our viral coefficient. In a good viral engine, a current customer brings with them on average more than one other customer (e.g. 2 or 3). This means that any viral coefficient above 1 indicates a good engine with sustainable growth.

It is possible for a product to have more than one growth engine. For example, a viral engine works really well if you have also got a sticky product with good retention rates. The key is to identify your primary engine and use that to make decisions. Our goal is to ensure that our growth engine works the same way with mainstream customers as it did with early adopters. Getting your growth engine right and refining it regularly is really important. For example, Dropbox had to pivot away from their initial paid engine of growth to a viral engine of growth. This change increased their user base from 100,000 to 4 million in 18 months.³⁹

It is also important to recognise that sustainable growth has to be based on sustainable profits. A great viral engine with high retention rates is a good indicator that customers love our product. While we can grow customer numbers with a good viral engine, we don’t want to do this while losing money! It is true that some great companies have been built through an initial focus on growing customer numbers (e.g. Facebook). But this growth was not an end in itself. It was simply an initial step to grow customer numbers with a view to eventually monetising those customers and becoming profitable.

5.5 Tuning your engine

When you first enter Grow you are still learning and your product could still be changing in response to the market. It is possible to view the first stages of Grow as beta. The best way to avoid premature optimisation is to benchmark where you are at the moment. You may not yet have the large numbers of customers that indicate a growing product. What we need to know at the moment is the product’s potential for growth and make decisions about what to do next.

In order to tune our engines of growth, we have to revisit our funnel and cohort analyses. As can be seen in Figure 4.1, we are looking to examine our per-customer metrics. What are our customer acquisition rates using our current marketing channels? What is our average cost of customer acquisition? How well are we converting or activating our customers? What are our current customer retention rates? How much revenue are we getting per customer? What is our customer lifetime value? How many referral customers are we getting? What is our viral coefficient?

If we benchmark these numbers, we will know what the current state of our product is. We can then begin to work towards growing the product while tracking any improvements in these numbers. The cadence at the which we track the numbers depends on the number of growth experiments we are running and the pace at which we acquire new cohorts of customers (e.g. weekly or monthly).

As noted in the previous chapter (Figure 4.2), we want to track our metrics on a cohort by cohort basis. We do not want to mix last month’s customers with the new customers acquired this month. The reason for separating our cohorts is that we want to see if there are any real improvements on our per-customer metrics. Are we growing the product at an improving rate? This benchmark becomes the basis for decision making going forward. The success of every decision we make will be judged by our ability to move that needle.

5.6 Growth hypotheses

In most traditional business plans, you will find growth projections. These are usually described in 3–5 year periods. Within the Lean PLC, we prefer the team use growth hypotheses instead. This minor difference in wording represents a significant difference in orientation. While growth projections can result in an exclusive focus on execution, growth hypotheses orient teams toward learning and discovery as they scale.

It is important to note that our growth hypotheses are not pulled out of the air. They are based on what we learned during validate and what we need to learn going forward. Much of what you think you know is an assumption and not necessarily fact. At the same time, we need to have a vision about where we need to be for the product to be successful.

Figure 5.1

There are three main time layers within our hypotheses. The first layer is our 2–5 year vision of where we want the product to be. The second layer is our annual growth strategy that will help us achieve our long-term vision. Finally, the third layer is more tactical and refers to shorter time cycles such as monthly or quarterly growth numbers that are related to our annual growth hypotheses. The time to validate each of the layers varies and as such, each of these three layers have their own set of hypotheses which should have a direct connection to each other through leading indicators. If tactics need to pivot when reviewed at a quarterly point, this doesn’t and shouldn’t mean your vision needs to. If you fail to deliver tactical success on a continuous basis though, this might indicate a change in strategy is needed.

Our growth hypotheses have to be specific and actionable. As part of our 2–5 year vision we have to set clear goals of the customer numbers, market share, revenues and profits we want to achieve. Once we know our long-term goals, we can then break it down into our per-customer metrics or business relevant units of value (e.g. customer numbers or number of new subscriptions).

Imagine a team that wants to achieve $50 million in annual revenue by year three. This broad number can be broken down into the number of customers, sales, or subscriptions needed to achieve that goal. For example, the team using a subscription model can calculate that they need 200,000 customers paying $250 per year to reach their target of $50 million in annual revenue. This larger growth target, together with the current state of the business, can be used to set annual growth hypotheses (e.g. Year 1 = 50,000 customers at $150; Year 2 = 125,000 = customers at $200, Years 3 = 50,000 new customers at $100 CLV (customer lifetime value)).

At the tactical level the annual growth hypotheses can be then broken down further into monthly hypotheses. Now the team has clear benchmarks with which to monitor progress and learn early whether they are on track to reach their goal. As the team deploys its growth tactics, it can set clear per-customer target metrics such as conversion rates, retention rates and lifetime value. Each cycle of tactical growth experiments can then be tracked against these minimum success criteria.

5.7 Growth tactics

Once we have outlined our growth benchmarks, we can then begin implementing and optimising our growth engines. On the basis of our funnel we can develop techniques to acquire, activate and get customers to pay for our product. There are also techniques that help us retain customers and convince them to make referrals on our behalf. As we deploy each tactic we should do it in a systematic way, while keeping an eye on our target metrics.

Patel and Taylor⁴⁰ differentiate between pull and push tactics for acquiring customers. Pull tactics involve subtle marketing techniques such as blogging, writing magazine articles and social media campaigns. The goal is to give customers a reason to come to our product through enticements and incentives. In contrast, push tactics are more aggressive and involve acquiring customer in more direct ways such as sales teams. Both pull and push tactics apply are part of the paid engine of growth. As such, when we use these tactics we have to ensure that our cost of customer acquisition is lower than the customer’s lifetime value.

The viral engine of growth can also be used when the product becomes its own customer acquisition tool. Product-based tactics include customers inviting friends to our product, enabling customers to talk about our product on social networks and incentives such as giving customers some reward if they make referrals and get their friends to sign-up. It is important to note here that acquiring customers is not the end goal. We want to activate them to buy and use our product.

To activate customers and get them to buy our product, we must have clear calls to action. Once the customers are engaged it must be clear what is expected from them. This applies to both physical and digital products. Customers need to know how they can buy the product, sign-up or subscribe if necessary. For complex products, it is also important to have a good process for onboarding customers which reduces the customers’ time to value. A good onboarding process can increase customer activation rates. Teams should provide support and guidelines to help customers use our product. Finally, we should test whether we have the right price to attract customers to activate, while also maintaining good profit margins for us.

The best way to retain customers is to make sure they are happy and engaged with our product. This is why the Grow stage is not just about scaling the product. Part of the focus should be on improving the product to ensure that we get better and better at delivering value. For example, we should not focus on giving good deals to new customers only. We should also offer similar rewards to current customers. Rather than treating our customers as disposable commodities, we should treat them as members of a community. We should consistently seek their feedback and improve our product in response to this feedback.

These are some tactics we can use to scale our product. What is important is to always remember to apply lean thinking. Do not apply every single tactic at once. Using the build–measure–learn loop, we can systematically test each tactic and how it is impacting our key growth metrics. We must always remember that we are trying to learn about what works. The discipline is to keep learning with data.

5.8 Learning with data

Usually the things that see themselves as immeasurable in business usually reveal themselves to much simpler measurements of observation once we learn to see through the illusion of immeasurability – Douglass W Hubbard⁴¹

Decision making in the Lean PLC is based on evidence. As such, whenever we deploy our growth tactics we have to use data to track progress. The effort spent in capturing data is worth it if we want to stay lean and ensure we are not wasting time and resources. We should only collect data that allow us to learn. We don’t need to know everything, we just need know enough to focus on our growth hypotheses and track the relevant metrics.

Another common mistake to avoid is not collecting data due to the perceived of difficulty of capturing them. Whatever you need to learn, you should know that pretty much everything is measurable, albeit with variable degrees of complexity. Don’t fall into the trap of thinking that what is difficult to measure cannot be measured. If you need to learn something, figure out a way to measure it! Based on the work of Douglass Hubbard, please consider the following factors when deciding what to measure:

1. What is the decision the measurement is expected to support?
2. What is the definition of what is being measured in terms of observable consequences and how does it matter to the decision being made?
3. How do we compute outcomes based on the value of this variable?
4. How much do we know or what is our current level of uncertainty?
5. How does uncertainty about this variable create risk for the decision makers?
6. Is there a ‘threshold’ value above which one action is preferred and below which another is preferred?
7. What is the value of additional information?

These seven questions can help us discover the key data we need to capture, as well as how much effort to put into capturing these key data points. This allows us to focus our effort where there is a return in value.

5.9 Metrics are people too

Out of all the things we did, the most important change was in how we thought. In simple terms, we reversed the flow of the company: instead of our work ending with the customer, it started with the customer. That basic principle embodied our desire to avoid letting them down again. We would do everything and anything to ensure that we knew what customers needed, and that we gave it to them before any of our competitors did – Sir Terry Leahy⁴⁷

One of the points that can get lost when exploring data is that there are customers behind each of those metrics. As businesses scale, the focus on improving the numbers can lead to counterproductive behaviour. This is a particular challenge when it comes to handling financial metrics. There is often a lot of pressure to keep those profit numbers improving. Over time this pressure can lead to poor decision making and subsequently long-term loss.

A lot of companies fail to realise that you can improve profits in the short term, while destroying value in the long term. This is because profits are a ratio. They can be improved by revenue increases or by cutting costs. In a competitive market where the cost of switching is low, companies must avoid falling into the trap of increasing revenues by raising prices while not improving on the value they provide. Cutting costs can also lead to increased profit but a poorer service for customers. In a competitive market or a well-defined category, not balancing this ratio with customer value in mind can be costly.

Metrics are people too. Regardless of the Lean PLC stage we are in, the focus on customers must be ever present. As we deploy our growth tactics, we will be tracking our key metrics. However, we should also consistently get out of the building and talk to customers face to face. This is especially powerful when our growth tactics are not working. Instead of just trying different tactics to see what sticks, we should find our key customers and talk to them. The lessons learned will add more colour to our numbers and ensure that we keep delivering value.

5.10 Managing prioritisation through risk and value

No matter where your product is in its lifecycle, the environment, competition and future changes ahead will present risks and uncertainty. To help you adapt, apply and recognise new learnings and challenges that have emerged, we recommend regularly facilitating a prioritisation and roadmap review. These reviews should reflect your experimental outcomes and look to apply the learnings directly. There are a number of different practices and techniques that you can apply to facilitate prioritisation sessions and we have shared just a few below. The important points to consider when reviewing your priorities are:

1. Evidence and data will reduce prioritisation subjectivity. Contribute learnings from previous experiments and surface examples containing antilogs (things that have failed in the past) and analogues (similar things that had worked in the past). Remember internal validation has limited to no value. There is no substitute for direct customer feedback.
2. Re-state the problem you are solving for who and why. Overtime assumptions creep in and can blur the focus or goals previously set. It is beneficial to recap on the goals and outcomes to help re-prioritise goals as well as helping new ideas to be prioritised against.
3. Ensure you have a cross-section of representatives. If you’re organising a group facilitated session, ensure you have a small, but decisive group which contains a spread of stakeholder and/or functional roles.
4. Ensure you understand and are clear on the strategic objectives. When we engage in our day-to-day activities, many opportunities surface for pivoting. Although all learnings are captured, it is important to ensure the correlation with strategy is clear as this may affect stakeholder value and continued sponsorship.

With these suggestions in mind, below are some techniques you can apply to help prioritise your backlog.

Prioritising risky assumptions

Building upon the earlier exercises which explore the identification of risky assumptions, we should now have more information to work with being in Grow. Taking a similar approach, the following exercise which is a light version of a traditional risk monitoring approach, can be quite revealing and powerful to facilitate with your team. This is particularly useful when referencing risk as a confidence indicator when planning your product roadmap. To explore new risks and assumptions, the following six steps exercise can help your team prioritise what to do next.

1. Business model review – Review your business model canvas and call out and untested introductions, opportunities, risks, changes as well as new learnings. For instance, to grow to the next level you may introduce a new channel or key relationship and may want to test the value of this before committing. You can also review any new inputs and learnings at this point around your business model as a whole.
2. Learning reflection – Reflect on your growth hypotheses and learnings to date. Then review your proposed growth hypotheses for the next period 1–3 months.
3. Capture outstanding assumptions – With your teams, individually list assumptions, goals and risks.
4. Group visibility – Group all the results and list them on a board for everyone to see and input into.
5. Scoring – Score each item by the risk of failing and the impact to the business if not true. It is recommended that you establish and define a few examples for each scoring reference. For example, an item which has evidence of high risk of failure or conversely has no evidence to reference should increase the risk of failure to 5. The impact rating should be informed by the dependencies of its success against your business model projections. For instance, if you will cease to operate if regulatory needs aren’t met or you will put at risk continued sponsorship, then the outcomes of this should be scored 10.
6. Refine – Discuss and refine through conversation as a team.

Table 5.2 Impact of uncertainty scoring example

By applying evidence from learnings, antilogs and analogues, you are able to highlight a reasonable prioritised list to tackle next with an improved level of understanding. This fairly quick way to numerically quantify some of the risks, helps you prioritise your backlog for experimentation. It will also help invoke interesting conversations as a team, surfacing further insights whilst providing improved team alignment. You may be surprised to see what new evidence surfaces when facilitating these sessions.

Cost of delay and weighted shortest job first

Depending where you are on your growth path, another factor to consider is the cost of delay. This is useful where you have a lot of ideas channelled through a bottleneck competing for resources and need a logical prioritised path of value. When your business model has a level of increased certainty you will be able to call upon more evidence and lean more towards operational efficiency. This is where the weighted shortest job first (WSJF) can be beneficial as a prioritisation effort, especially considering the effort versus returned value.

  Tip

Don’t make the mistake that many do by assuming you’re in a predictable state where assumptions are confused with facts. We recommend regularly reviewing your riskiest assumptions for the whole period that you’re in Grow. Therefore, however you prioritise, always consider data and evidence as a prioritisation qualifier. Where there is an absence of data and evidence, consider prioritising and obtaining this first. This should be a small investment in time and will reduce risk significantly.

The WSJF is a common practice advocated by larger agile development teams to capture value and prioritise the product backlog. This is further explained by Donald G. Reinertsen in his book The Principles of Product Development Flow.⁴⁸ This approach considers the following three aspects when prioritising the backlog.

1. Shortest job first (SJF) – The principle is to do the shortest job first where the jobs have the same cost of delay. If one were to do the longest job first, it would delay many short jobs and result in the ‘Convoy Effect’, delaying the overall time to value.
2. High delay cost first (HDCF) – Where job durations are homogenous, but the cost of delay differs, it’s best to do the high delay costs first.
3. Weighted shortest job first (WSJF) – When both duration and delay costs are different which is most common, the best approach is WSJF. Priority is based on delay costs divided by task duration. An example of this can be seen in Figure 5.2.

As further highlighted by Reinertsen, there are three common mistakes to avoid when implementing this process.

Figure 5.2

1. Assuming the return on investment (ROI) alone should be used for priority where high ROI projects are prioritised over lower ROI projects. You should consider the sequence of the ROI and the sensitivity to profit. A project with lower ROI, but higher sensitivity to profit should go first. Overall portfolio ROI adjusted for delay is more important than an individual project ROI.
2. In the absence of quantitative information, companies can operate on a ‘first in first out’ basis. Although simple, this is dangerous when jobs have a different delay cost.
3. Some companies use a critical chain which allocates buffer time to each job and gives priority to the project with the smallest remaining buffer also known as minimal slack time first (MSTF). This aims to minimise the total number of projects that miss their planned schedules. This approach is not optimal when considering overall delay costs and projects with a higher cost of delay with ample slack time should take priority over projects with lower costs of delay, but with less slack time.

When taking a hypothesis-driven approach to calculating or estimating the WSJF, we would strongly advise that the values are informed by evidence. When working with some teams and particularly those in larger enterprises with reference to mature products, we advocate using evidence as a multiplier. This is particularly important if you’re operating within a complex or complicated domain as defined by the Cynefin framework’⁴⁹ where discovery is expected. Evidence helps calculations of WSFJ to have a higher degree of certainty, removing some subjectivity from the scoring. Taking the example shown in Table 5.3, you can see how this can transform the previous priorities set.

Table 5.3 WSJF – evidence as a multiplier

To support the inclusion of evidence in a more structured format, we would recommend that you establish an agreed understanding of weighting towards the evidence provided using a confidence indicator. The more evidence and data provided the more confident you should be with your projected outcomes. Recognising this can help facilitate the emergence and realisation of risk which could reduce waste early. If something is deemed as high value for growth, then supporting evidence should be strong.

You should extend and contextualise your scoring system for your business and environment. It’s important that this is explicit and shared before any scores are applied. An example of such a weighting can be seen in Table 5.4.

The scoring guide is an example of how evidence can be considered. We weighted the cost of delay against effort equally to balance the investment to the outcome. The value of the confidence score is that it challenges the commonly observed practice where people treat estimates and numbers as fact. That’s not to say there is no value in estimation, but the added realisation of risk and confidence will encourage teams to experiment more.

  Tip

Hierarchy is built into the cultural operating system of society and does influence behaviour and direction whether we like it or not. The consequence of this is that ideas born from HiPPOs (Higher Paid Person’s Opinions) are seldom challenged or refined to be more meaningful. This isn’t necessarily the fault of the individuals but is inherited through our cultural development of behaviours, experiences and the working system. Where failure isn’t accepted, few people like to take high risks, especially in situations where accountability is at play. In almost all our experiences dealing with HiPPOs, we have come to learn that the favourite food of the HiPPO is data! We actively encourage the collection and contribution of data for any proposed ideas and recommend you feed the HiPPOs!

Table 5.4 Confidence value scoring

Evidence type	Comments	Score
Legal & regulatory conditions	Where you need to apply regulatory or legal conditions to operate which are non-negotiable, then the maximum score is assigned by default.	1
Research sources	Cost of delay	Max value 0.5
Market research	What worked for others doesn’t mean it will work for you and your customers. Market research is valuable, but not absolute. Market research should provide insights and depth in addition to experiments. Consider that just because market experiments are successful, it doesn’t mean the market is big enough to warrant the investment.	<=0.2
Market experiments	Market experiments have been carried out with real customers and consist of enough of a sample set. The data demonstrate clear customer intent to commit to the solution on a repeatable basis.	<=0.3
Development sources	Duration/effort	Max value 0.5
Previous development experience (3 parts below)	Estimates are best guesses at a given point in time, often with limited information provided. Therefore, it’s recommended this is recognised to help indicate confidence. Low confidence can trigger exploration and experimentation which could rapidly improve confidence. If confidence is low for effort estimation, then consider running short, focused experiments first.
Dev experience (High)	Where you are using the same team who have developed very similar or the same components in the past many times and they have directly contributed the effort estimate with supporting evidence and references. The team may also reuse many existing components and patterns from previous implementations, prototypes and experiments. Best practice can be applied.	<=0.5
Dev experience (Medium)	Where you have team with a high ratio of new members or members who haven’t worked together much previously and only can reference 1–2 similar projects with limited direct evidence. They only have some pre-existing resources to utilise and will need to explore the difference. This could be considered complicated, but good practice can be applied.	<=0.25
Dev experience (Low)	Where you have a new team and the challenge is new to all or most members, where little or no resources, knowledge or previous patterns can be utilised. This could be considered a complex state and therefore presents higher risk. Discovery and experimentation is encouraged.	<=0.1

Combining risk and value

Building on the technique above as an alternative to the confidence indicator, another useful exercise is to combine both the values above: impact uncertainty scores and WSJF. Whereas the WSJF in practice can sometimes omit uncertainty, the uncertainty score can omit the effort and duration and the benefits of WSJF. Where you have higher risk features, ideas, projects or stories it would be beneficial to experiment and obtain more knowledge before deciding to invest significant effort and detail. Taking the Risk prioritisation and the WSJF technique above, it can sometimes be beneficial to visually cross-reference the values. The following model illustrates this point.

Value-uncertainty prioritisation quadrant

In Figure 5.3 we are recognising that although there equally or similar weighted scores for both Risk, Impact and WSJF, when combined there’s a distinction which realises limited certainty and/or understanding. The top right quadrant recognises that there are three ideas which present a higher risk of uncertainty against higher value of return, measured by WSJF. One could argue that these ideas would need to be prioritised and explored further to reduce the risk which might position them in the lower right quadrant. Recognising this explicitly surfaces questions and uncertainty back to the stakeholders to not yet bet on these outcomes. It also implies more exploration and knowledge is needed before value can be realised.

Figure 5.3

If prioritising the ideas above, the order of priority recommended would be to follow the number convention from 1–4 as a guide. Some subjectivity is required as the metrics informing the positions in the first instance are subjective. Taking the example of idea H against idea C, you might prioritise idea C first as the cost of delay in the WSJF may have more value than the risk exploration than idea H.

  Tip

It’s important to note that evidence and inputs should be used to support the numerical projections above. Estimates alone without qualitative evidence to help quantify your backlog of ideas will limit the value of prioritisation.

5.11 Managing a nonlinear adaptive state

With all the best projections and plans, in each Lean PLC phase you are highly likely to be in multiple states simultaneously while you expand your business and execute. In the digital economy, nothing stays still for very long and therefore it’s important to recognise the constant need to adapt and respond. Not only are you looking to make unknowns become knowns, but your environment could also reduce the lifespan or relevance of some knowns over time.

Providing insights into understanding your domain state and how to operate successfully to build successful products in this space can be established through the support and reference of the Cynefin Framework.⁵⁰ This framework identifies five domain states.

1. Simple/obvious – Represents known-knowns where the relationship between cause and effect are clear. This domain advocates best practice through ‘sense–categorise–respond’ behaviour.
2. Complicated – Represent known-unknowns where analysis and/or expertise is required to understand the cause and effect relationship and then apply appropriate good practice. The framework recommends ‘sense–analyse–respond’ behaviour.
3. Complex – Represents unknown-unknowns. The cause and effect relationship can only be understood in retrospect within this domain. The framework recommends ‘probe–sense–respond’ behaviour. This can be achieved through safe to fail experimentation.
4. Chaotic – The cause and effect relationship are unclear and as such a knowledge-based response cannot be applied, and any action is the most appropriate initial response to establish order. The framework recommends ‘act–sense–response’ behaviour which allows the responder to use the established order to then sense and better understand the situation then respond accordingly which will move the domain to being complex.
5. Disorder – Unclear which domain applies and there are multiple perspectives in conflict. It’s recommended that event or situation is dissected into parts and distributed appropriately to each of the other four domains.

This sense-making framework provides much depth and realisation into the preferred paths and ways of working when you identify your product and business model context. It is also possible to be in more than one state at a given time depending on what level of granularity you observe. For example, your customer services team could be operating within the simple domain, while R&D operate in a complex domain and your business model across all domains across its respective areas. It’s worth noting that your domain state can change over time with environmental influences. This is why we recommend reviewing your strategy, vision and tactics on a regular basis.

The common overall domain state of product development when in the Grow stage of the Lean PLC is often likely to be weighted towards the complex and complicated domains. This is due to the inherent complexity of product development and management, coupled with emergent complexity and knowledge around your business model and environment in Grow. These domains reveal more than one right answer to any given problem or hypotheses and advocate the recognition of assumptions to be explored and validated. Recognising which state you’re in will help inform preferred operational practice. The realisation that product development in the Lean PLC phases from Idea through Grow is complex to complicated is recognition that you’re exploring known-unknowns and unknown-unknowns; where the learning in the latter state by definition can only be obtained in retrospect.

A common mistake that businesses make is assuming they are in a complicated or simple domain where there are fewer unknowns. They operate where exploration, discovery and change are unwelcomed or not expected and then default investment to longer term plans which are highly detailed. The Lean PLC on the contrary advocates emergence and continuous learning, particularly through Idea to Grow. This supports the behaviours of probe–sense–respond (complex domain) or probe–analyse–respond (complicated domains) to improve the chances of success and maximise learning. This is why the similarities of build–measure–learn practices and the scientific approach of hypothesis-driven development can be exploited to maximise your potential from Idea through Grow Lean PLC phases.

5.12 Capturing your product roadmap

Your product roadmap is an extremely powerful and a living artefact which impacts every function in your organisation. It’s a declaration of all the knowns and unknown outcomes ahead, built on the presumption of the most valuable return on the investment of effort contributed. Don’t get misled by the term ‘Product’. The Product Roadmap is the path of value delivery which an entire business is undertaking. The ongoing delivery of the product is the repetitive transaction of value between the customer and business. Your roadmap is the one true reflection of all the points previously discussed, disseminated into a clear and transparent sequence for all to see and contribute towards.

In order for the Product Roadmap to be most effective, there are some common attributes which should be sought and employed. An effective roadmap should be simple and need little or no explanation to those consuming it. The following list of properties should be considered when forming and supporting your product roadmap.

Although a single roadmap is desirable, in larger organisations it’s likely that you will need to expand the details and provide different views of granularity for the different viewers. As companies need to be more adaptive to change and are becoming learning organisations, using tools which are more open to discover value and explore outcomes and respond to change are more effective for the Grow phase of the Lean PLC. A useful tool to use is the Go Roadmap by Roman Pichler.

Go Roadmap

The benefit of this approach is that the Go Roadmap is goal orientated which allows teams to inspect and adapt as they delivery to shape to best solution for the desired outcome. Supporting the explanations during Explore, Validate and Grow, the Go Roadmap also supports a hypothesis-driven approach with key measurements and metrics for review. It’s also at a high enough level that it can be shared across a broader range of your organisation.

Figure 5.4⁵¹

If you are working in larger organisations need to communicate intentions and state across many locations and people, you may want to use a digital tool. There are many options available and the choice of tool should be carefully selected not to compromise the principles expressed in the Lean PLC. Using a tool shouldn’t replace the behaviours and working practices advocated, but should be used to complement them and to add value.

A useful roadmap tool which we have used with some teams is http://www.aha.io, which offers a range of solutions which support goal orientated product roadmaps with references to business model. Another powerful capability of this tool is that it can translate and provide different views and granularity levels of the same path. Having multiple views presented from one single source of truth can be useful.

Whatever roadmap tool or technique you use remember you employ a tool to work for you and not the other way around! The practices shared during this book are advised as paramount over the use of any tool chosen. A Gantt chart of any kind is not a defined path of the future, but a shared snapshot of understanding at a given time. Another way to look at this is that the roadmap is simply a list of questions yet to be clarified to achieve the value desired.

A useful tip employed by many teams is to explicitly communicate certainty on the roadmap itself to ensure that the roadmap doesn’t end up being a contract of delivery. An example of this is shown in Table 5.5.

Table 5.5 Product roadmap implementation maturity

5.13 Entering new markets

Another way to accelerate and expected growth is to enter new markets. Common questions surface when mapping products to a stage in the product lifecycle around whether a product should be mapped by distinct markets. As a general rule of thumb, new markets present new and sometimes very high risks and differences which should to recognised. There are countless cases where very successful products and businesses in one market dramatically fail are constrained or choose not to operate in distinct markets.

By way of example, the tech giant Google who have well publicised success on most global regions, pulled out of China in 2013, despite the Internet user base of China being twice the residency population of the USA.⁵² Another retail and tech giant Amazon which is no doubt the default online destination for purchasing goods and maybe the distribution channel you purchased this very book from, has only recently entered and expanded in Brazil.⁵³ This is due to the unique challenges and difficulties faced in this market place. Both these giants carefully made their decisions knowing the growth model in each of these markets is unlike the other markets they have success in and needed to refine their business model or review the strategic impact.

Wherever you are in the lifecycle, when entering a new market we would advocate that you start from Idea to explicitly recognise there are unknown-unknowns which will need discovery and validation. This doesn’t mean that the product shifts its stage in the lifecycle, but simply means that each market can be in a different stage. You can have a product in more than one product lifecycle stage at a given time. Let’s say for instance you are in Grow and you have a product in the USA, but you want to go to Brazil. Your product overall and a high level would be in Grow (total combined growth), but in one market it could be in Explore (Brazil) and another in Grow (USA). Let’s take a look at the following example:

In Table 5.6, the product and business model is being refined and contextualised per market, but overall is considered to be in Grow. Collectively this declares that the product and business is expected to see growth. Market contextualisation is a key factor in success and which speaks to the reasons why Amazon may have taken longer to expand into Brazil.

Table 5.6 Mapping markets to Lean PLC

5.14 Prepare for sustain – when growth slows down

Our hope is that our product grows and continues to grow for many years. But nothing lasts forever. At a certain point, the product will reach a level of maturity in the market and growth will slow down. Recognising whether you’re in Grow or Sustain is important for Lean PLC management. This helps align expectations and goals so that appropriate resourcing, investment, support and revenue projections can be considered.

It is also important to note that, unlike the Lean PLC stages on the left side, moving a product from one stage to another on the right side is not based on teams making the decision and bringing the product to the council. When a product is on the right side of the PLC, it may remain in Grow or Sustain for many years. As such, Lean PLC governance on the right side is done via quarterly, bi-annual and annual reviews. The cadence of the reviews depends on the size of the company and the business models of each product.

At each review, the product council or investment board can analyse the performance of the product and make decision. Below are some key points to consider during these reviews in terms of making the decision to move a product from Grow to Sustain.

The move from Grow to Sustain raises one fundamental question: How can we maintain revenues and profits while reducing costs? This also raises fundamental product roadmap questions. As such, as we prepare to move to Sustain we should be able to answer the following questions.

1. How can you reduce your team size and other operational costs?
2. Does your roadmap focus on maintaining customer numbers, satisfaction and engagement? Is your roadmap weighted too heavy on discovery over execution?
3. Entering new markets would automatically position your product into Grow. By declaring your product in Sustain, you may be declaring that you are not attacking new markets as defined in Grow.
4. If you’re a digital company, how will your product keep pace with the third-party delivery platforms? Consider the frequent releases operating systems, user interface (UI) capabilities and evolving application programming interfaces (APIs) that your application might rely on.
5. How will you defend market share and what indicators will you need to monitor for early signals to respond to? How quickly can you react to change?

With these captured and defined, you’ll need to monitor and manage the transition from Grow to Sustain. This rarely happens quickly and should be handled and coordinated to assure you are seeing the impact of changes and that you’re limiting the negative effects on the company. Remember that products in Sustain should be profitable with optimised margins and operations.

An interview with:
Marc Abraham, Chief Product Officer at Settled

Marc Abraham is an experienced product management practitioner, who has worked for a large number of successful digital organisations – at 7digital, carwow, Beamly, World First, notonthehighstreet.com and currently at Settled. Marc writes about his learning and digital trends on his blog at marcabraham.com. We caught up with Marc to find out what lessons he has learned in his experience of working to grow successful companies from idea to scale.