Cognitive biases can negatively impact your ability to think critically and make informed decisions. Once you are aware of them, it will help you identify and navigate them.

Here is an explanation of the 7 main types of cognitive bias, some examples and how you can navigate them:
1. [Survivorship Bias](#survivorship)
2. [Confirmation Bias](#confirmation)
3. [Framing Bias](#framing)
4. [Groupthink](#groupthink)
5. [IKEA Effect](#ikea-effect)
6. [Availability Bias](#availability)
7. [Commitment Bias](#commitment)

## <a name="survivorship"></a>1. Survivorship Bias
> Focus on the traits of the successful whilst ignoring the failures.

![survivorship-bias](//images.ctfassets.net/vwq10xzbe6iz/t9fd2snGayd6dZM2Dn9Js/5e615d3df42fa017582a58b9f06a0e57/survivorship.JPG)
This involves limiting our analysis to instances that have passed a success hurdle and not analysing those that didn’t pass the hurdle. This commonly occurs when we adopt key learnings from successful case studies yet remain blind to the unsuccessful instances who may have also followed the same learnings. 

### Examples
The famous [WWII case study](https://www.researchgate.net/publication/254286514_Abraham_Wald's_Work_on_Aircraft_Survivability) involves mathematician Abraham Wald who was tasked with identifying where to place more armour on fighter planes. The officers data of bullet holes in returning planes supported placing more amour on the fuselage vs the engine. However, Wald’s insight was to ask where the bullet holes weren’t - i.e. the engine. The surviving planes had fewer hits to the engine because those that were hit didn’t return.

A modern example would be to look at a customer acquisition funnel with a 10% activation rate. Common analysis would be to take key learnings from the behaviour and personas of this group to further lift activation. However, the greater insight would be to analyse the other 90% and ask why aren’t they activating? The latter is more challenging and often involves less access to data, but the payoff is greater.

### How to Navigate?
Ask questions about what other data and groups are missing. Identify the success hurdle and ask why others have not passed it.

## <a name="confirmation"></a>2. Confirmation Bias
> Focus on data to promote our existing beliefs.

![confirmation-bias](//images.ctfassets.net/vwq10xzbe6iz/3Fwt3vluPTrXkA41Yfj6Dx/585fec98fc5647b58a14f4d568b973c7/confirmation.JPG)
This involves seeking out information that validates our existing views and prior commitments. We also discount other information that may invalidate our views. Confirming evidence makes us feel good and people do what makes them feel good. The counter approach is the scientific method, which attempts to ask questions first before gathering evidence to either support or reject a hypothesis. The former is easier and faster, the latter is harder and time consuming.

### Examples
The CEO has a new idea to launch a new product and instructs a team to conduct market research and competitor analysis on the feasibility of this product. The market research team is limited in scope and risks being urged to validate the success of the CEO’s new product idea. A better task for the team would be to investigate what the best product would be to solve a particular problem.

### How to Navigate? 
Try and identify if there is a pre-existing belief (yours or otherwise). Reflect on information you have rejected. Ask others with a different viewpoint.

## <a name="framing"></a>3. Framing Bias
> Solving a problem based on the context it is presented.

![framing-bias](//images.ctfassets.net/vwq10xzbe6iz/1RJWOsPkQawJKKxYk8oIQM/6ee3c51d2e488ae5ecd40e1abd233596/framing.JPG)
The specific context a problem is framed/ presented can influence the options and choices available.

### Examples
The problem of low company profitability can be either framed as a need to cut costs or to increase revenue. The way the problem is framed will influence the options available (i.e. fire and restructure or enter new markets).

### How to Navigate? 
Ask what is the ultimate problem we are trying to solve. For example, ask what the outcome would be if we solved this problem. See if there are other solutions to achieving the same outcome.

## <a name="groupthink"></a>4. Groupthink

> The desire for group harmony leads to poor decision making.

![groupthink](//images.ctfassets.net/vwq10xzbe6iz/3BvESluOEJuRmYVODq44U1/12de08589e23649ad287ff3abba0912b/groupthink.JPG)
People tend to avoid conflict, particularly in the presence of a majority and people of authority. People assume others have made informed decisions and fear the risk of looking un-knowledgable in front of others. 

### Examples
The term groupthink arose from the [case study](https://www.bassberry.com/wp-content/uploads/Effective_SEC_Rulemaking_Letters2.pdf) of the failed US Cuba Bay of Pigs invasion. In 1961, the CIA presented to President Kennedy a Cuba invasion plan formulated under the previous administration. Kennedy accepted it and early objections were dismissed and eventually no objections or alternatives arose. Kennedy learnt from this and a year later during the Cuban Missile Crisis intentionally absented himself from initial meetings to encourage free discussion. Two teams were created to evaluate the options before presenting to Kennedy. 

### How to navigate? 
Be clear on the objective and values. Encourage other views to solve the objective.

## <a name="ikea-effect"></a>5. IKEA Effect
> Overvaluing things we place successful effort into

![ikea-effect](//images.ctfassets.net/vwq10xzbe6iz/1o8egJQ2qvuZqLQjsPpOSf/5c7e44c7d77fc37f809a05fe47b6d357/ikea-effect.png) 
The IKEA effect is a finding that people tend to ascribe a higher valuation towards self-assembled products compared to objectively similar products which they did not assemble ([see article for study](https://mannhowie.com/ikea-effect)).
### Examples
A product team has spent significant time developing a high fidelity prototype based on the sales team's feedback. It has the latest best practice design patterns. They have not shipped an early version yet. The IKEA Effect makes the team less likely to cull or dramatically change the product in response to real world usage. They are at risk of devoting resources to failing projects. 
### How to navigate? 
Treat your ideas like cattle, not like pets. Spike rough prototypes, talk to customers and run growth experiments.

## <a name="availability"></a>6. Availability Bias
> Overestimate the likelihood or frequency of an event when it is easier to recall

![availability-bias](//images.ctfassets.net/vwq10xzbe6iz/3xmF85xOP7EIdJWIa0tJ9D/e54863460e43ac8d37a49683182e7fd0/availability-bias.png)
People tend to assess the relative importance of issues by the ease of which they are retrieved from memory. Factors that influence memory include: recency, vivid emotion, and imagery.
### Examples
Tversky and Kahneman's famous 1973 study had participants listen to a list of 39 names being read and were then asked to recall whether the list contained more men or women. The list either had fewer names of famous women and more names of less famous men (e.g. Elizabeth Taylor vs William Fulbright) or a list with fewer names of famous men and a list with more names of less famous women (e.g. Richard Nixon vs Lana Turner).

Over 80% of the participants incorrectly judged the list with famous names to be more frequent in terms of gender. 

### How to navigate?
Look for different examples: seek out and compare counter examples of what is easier to remember. For example older vs recent instances, positive vs negative experiences, multiple instances of any memorable imagery.

## <a name="commitment"></a>7. Commitment Bias
> Following actions consistent with prior beliefs, words and actions

![commitment-bias](//images.ctfassets.net/vwq10xzbe6iz/64jQHFYz9cGi3m4paOJYvj/346f4a84c3224ec7e8b9601900999f1b/commitment-bias.png)
Following through with commitments help confirm self-image and avoid cognitive dissonance. They are most effective when they are active, public, effortful and viewed as internally motivated.
### Examples
At the height of the Cabbage Patch Kids craze in the 1980s the company was forced to halt its pre-christmas advertising after it was accused of over advertising and under-supplying toys. The strategy aimed to get parents to commit to their children of buying the toy in the lead up to Christmas. Then hoping parents would go to the store but left purchasing a different toy and then returning post Christmas to honour the original purchase commitment.
### How to navigate? 
Remind yourself it is ok to change your mind. Beware sales tactics that employ commitment bias to make prospects agree to a little purchase before a big purchase.

What are the 7 common types of bias: 1) Survivorship Bias; 2) Confirmation Bias; 3) Framing Bias; 4) Group Think; 5) IKEA Effect; 6) Availability Bias; 7) Commitment Bias.

survivorship

7 Types of Bias - Examples & How to Navigate

Here are five rules of thumb you can apply to common UI design challenges when building web applications:

1. [Use defaults](#use-defaults)
2. [Obvious settings](#obvious-settings)
3. [Show progress](#show-progress)
4. [Avoid interruptions](#avoid-interruptions)
5. [Flat hierarchy](#flat-hierarchy)

## <a name="use-defaults"></a>1. Use defaults
Provide default values to guide users on the most common choices or behaviour you want to encourage.

![use defaults](//images.ctfassets.net/vwq10xzbe6iz/58lgklls1TQqgvFstGDF0B/938dffbe618bb3d424cf8c3acac015c4/use_defaults.png)

Defaults reduce the number of choices and decision fatigue users must face. They provide context as to the next decision required. Attempt to reduce the number of inputs you require by collapsing optional values. 

## <a name="obvious-settings"></a>2. Obvious settings
Settings should be obvious and unambiguous. Use radio buttons or checkboxes to indicate whether a setting is active. Where possible opt for binary settings instead of multiple states (e.g. flash mode on/ off vs flash mode auto, on or off).

![obvious settings mode](//images.ctfassets.net/vwq10xzbe6iz/7n6LxMmrztHcv9hRjouZbx/82419567536619908d199d5c20f16ebd/obvious_settings_mode.png)

Clearly label preference settings with positive active labels. Avoid negative labels. Checkboxes should enable things, not disable them.

![obvious settings preferences](//images.ctfassets.net/vwq10xzbe6iz/4HvT2YSTTMnzQFeQ5Wvh8x/c3551e5ea801c581972cfff1ede51a9c/obvious_settings_preferences.png)

## <a name="show-progress"></a>3. Show progress
Feedback should be immediate to communicate to users that the action has been received. When feedback cannot be immediate, use loading spinners for short waits (<10 seconds) and progress loaders for long waits (>10 seconds).

![show progress](//images.ctfassets.net/vwq10xzbe6iz/dMSFEcZYTeCzT6K5bx3LL/ce2eb70fb73b68448425fe946840141b/show_progress.png)

## <a name="avoid-interruptions"></a>4. Avoid interruptions
Avoid interrupting users' workflow by making decisions to allow slips with ways to undo. Allow slips with the use of less intrusive toasts vs intrusive warning confirm modals.

![avoid interruptions](//images.ctfassets.net/vwq10xzbe6iz/51iV8AagtUtyl8UeASDp8W/a41fb967b86ee1455f6d21a701419849/avoid_interruptions.png)

## <a name="flat-hierarchy"></a>5. Flat hierarchy
Use flat instead of deep hierarchies. Content is more discoverable if it is not deeply nested inside hierarchies. People are good at naturally grouping categories based on labels without relying on deep nesting.

![flat hierarchy](//images.ctfassets.net/vwq10xzbe6iz/4AoNBBWhKfLtA0ouDCSYjC/9a4ca81d0feb42cbadff92b4e566e7d4/flat_hierarchy.png)

### References
- The Power of Defaults ([Article](https://www.nngroup.com/articles/the-power-of-defaults/)) - Nielsen Norman Group
- Flat vs Deep Website Hierarchies ([Article](https://www.nngroup.com/articles/flat-vs-deep-hierarchy/)) - Nielsen Norman Group
- Designed for Use: Create Usable Interfaces for Applications and the Web (2016) ([Book](https://pragprog.com/titles/lmuse2/designed-for-use-second-edition/)) - Lukas Mathis


UI design patterns for web apps: 1) Use defaults; 2) Obvious settings; 3) Show progress; 4) Don’t interrupt; 5) Flat hierarchy


show progress

User Interface Design: 5 Rules of Thumb

The Cognitive Reflection Test (CRT) is a simple three question test that measures people’s tendency to answer questions with the first idea that comes to their mind without checking it.

The first and most popular question is the “bat and ball problem” which more than 50% of students at Harvard, MIT and Princeton get wrong. 

![cognitive-reflection-test](//images.ctfassets.net/vwq10xzbe6iz/55mZtOXLz6Z3uVaaFzEFKy/cce62be0aa1919ebdcf07e80fa73f713/cognitive-reflection-test.png)

### Sections
1. [The Bat and Ball Problem](#bat-and-ball)
2. [How to Improve Your CRT Score](#improve-crt)
3. [Examples of Reacting vs Checking](#react-vs-check)

## <a name="bat-and-ball"></a>1. The Bat and Ball Problem
__Problem:__
- A bat and a ball cost $1.10. 
- The bat costs $1.00 more than the ball. 
- How much does the ball cost?

__First Reaction:__
- 10 cents

Nearly all people have a first reaction of 10 cents which is wrong. The correct answer is 5 cents. 

In a study of 3,428 university students, 50% of participants across Harvard, MIT and Princeton gave the incorrect intuitive response and did not actively check their response. A failure to check is instructive because it requires such minimal mental effort.

Anyone who would pause and check would recognise that if the ball is 10 cents the bat would need to cost $1.10 and the sum would be $1.20, which is above the target $1.10. 

Daniel Kahneman describes this cognitive bias as the distinction between a person’s two processes of thinking:
- __System 1__: executed quickly with little conscious deliberation; and
- __System 2__: executed slowly and more reflective

System 1 processes occur instantly and effortlessly for example knowing the answer to 5 x 5 or indicating left when turning the car left. 

System 2 processes require more effort, concentration and calculation for example the answer to 25 x 7 or correcting for car slides on icy roads. 

## <a name="improve-crt"></a>2. How to Improve Your CRT Score
Here are three ways you can improve your CRT score and mitigate against biases of System 1 thinking:
1. __Acknowledge__: that you will always have an initial “gut” reaction to an event or problem and jump to solution mode. This is unavoidable and it is ok. Note your initial reaction and solution;
2. __Pause and check__: your first idea before sharing your feedback. Check who the decision would impact and how much effort the solution would require; and
3. __Ask questions__: to find out who really has the problem and where the problem comes from. Check again whether your first idea would answer these questions.

## <a name="react-vs-check"></a>3. Examples of Reacting vs Checking
Here are three examples of how product, customer success and marketing teams may react with their first idea and how they could pause and check.

| Example     | React First Idea     | Pause & Check     |
| ---------- | ---------- | ---------- |
| __Product__ <br> Watching an end-user struggle to upload a file       | Propose feature solution of drag and drop file upload       | Before solution mode: <ul><li>check funnel data of what % of users fail upload</li><li>are those not uploading files blocking the flow of other users</li><li>are there non-UX factors causing this (e.g. file size, internet speed)</li></ul> |
| __Customer Success__ <br> Unhappy customer feedback that solution was not a fit with their internal system and they may now churn       | Blame sales team for selling to clients with poor system fits and create a new process to screen out incompatible customers       | Before solution mode: <ul><li>check how many existing customers are at risk of incompatibility. Are they using workarounds</li><li>could the cause of the incompatibility be known in advance of the sale</li><li>does the customer still see value in the solution</li></ul> |
|__Marketing__ <br> Prospect complains angrily they are getting too many marketing emails | Disable this week’s new marketing campaigns | Before solution mode:<ul><li>confirm how many other recent complaints have been received</li><li>check if prospect is an existing paying customer or opportunity</li><li>if not, check if prospect fits the ideal sales qualified target</li></ul>|

To learn more about how to pause and check, read about the 4 simple questions you can ask to help identify and solve the right problems before jumping to solution mode ([How to solve the right problems](https://mannhowie.com/problem-solve)). 

## References
- Shane Frederick (2005). ["Cognitive Reflection and Decision Making"](https://www.aeaweb.org/articles?id=10.1257/089533005775196732). Journal of Economic Perspectives.
- Daniel Kahneman (2011). [Thinking Fast and Slow](https://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp/0374533555). Chapter 3, The Lazy Controller


Why 50% of Harvard, MIT and Princeton students get the bat and ball problem wrong. 1) The Bat and Ball Problem; 2) How to Improve Your CRT Score; 3) Examples of Reacting vs Checking in Product, Customer Success and Marketing.


cognitive-reflection-test

Cognitive Reflection Test - Examples of Reacting vs Checking

Google acquired YouTube for US$1.6bn in 2006. In 2022, YouTube could be worth over US$180bn achieving a +110x return. Analysis of YouTube revenue and usage statistics and financial metrics.

yt valuation comparison

How Much is YouTube Worth? Over US$180bn in 2022

The IKEA effect describes how people come to overvalue things in which they have successfully put effort into. This cognitive bias can pose risks to organisations in the form of sunk cost effects and “not invented here” syndrome.

![ikea-effect](//images.ctfassets.net/vwq10xzbe6iz/1o8egJQ2qvuZqLQjsPpOSf/5c7e44c7d77fc37f809a05fe47b6d357/ikea-effect.png)

This article explains when and why the IKEA effect emerges and introduces four ways you can defend against it.
1. [What is the IKEA effect?](#what-is-the-ikea-effect)
2. [Pitfalls of the IKEA effect](#pitfalls-of-the-ikea-effect)
3. [Four ways to avoid the IKEA effect](#ways-to-avoid-the-ikea-effect)

### <a name="what-is-the-ikea-effect"></a> 1. What is the IKEA effect?
The IKEA effect is a finding that people tend to ascribe a higher valuation towards self-assembled products compared to objectively similar products which they did not assemble.

A study by Norton, Mochon and Ariely ([2011 paper](https://www.hbs.edu/ris/Publication%20Files/11-091.pdf)) found participants who self-assembled an IKEA storage box (Builders) valued the purchase price 63% higher than those who inspected the same pre-assembled box (Non-Builders). Similarly, the Builders also rated liking the box 55% more than Non-Builders. 

__IKEA Effect Experiment A - Perceived value of IKEA storage box by Builders vs Non-Builders__

|   Measure   | Builders (Self-assemble)     | Non-Builders (Inspect pre-assembled)     | % Difference     |
| ---------- | ---------- | ---------- | ---------- |
| Willingness To Pay (0-100 cents scale)       | 78       | 48       | 63%       |
| Liking of Box (1-7 scale)       | 3.8       | 2.5       | 52%       |

*Participants: N = 50*

In another experiment one group of participants were asked to create origami (Builders) and another asked to inspect their creation (Non-Builders). Similar to the first experiment, the Builders valued their creation 360% higher than the Non-Builders who ascribed close to no value to the origami (“nearly worthless crumpled paper”).

__IKEA Effect Experiment B - Perceived value of origami creation by Builders vs Non-Builders__

|  Measure    | Builders (Self-create)     | Non-Builders (Inspect creation)     | % Difference     |
| ---------- | ---------- | ---------- | ---------- |
| Willingness To Pay (0-100 cents scale)       | 23       | 5       | 360%   
*Participants: N = 106*

### <a name="pitfalls-of-the-ikea-effect"></a> 2. Pitfalls of the IKEA effect
The IKEA effect explains broadly why people may come to fall in love with their own ideas. With the effect strongest when people expend a greater amount of their own effort and perceive their effort as successful.

The IKEA effect has negative implications for organisations more broadly as a contributor to two key organisational pitfalls:
- __Sunk cost effects__: people continue to devote resources to failing projects in which they have previously invested
- __“Not invented here” syndrome__: people refuse to use perfectly good ideas developed elsewhere in favour of their own, often inferior internally-developed ideas

Here are some examples of how the pitfalls could occur:

| Team     | Effort     | Pitfall ⚠️     |
| ---------- | ---------- | ---------- |
| Fund Manager       | Creating a company financial model with industry and market share forecasts       | Perceiving company to be more valuable than it may be even when forecasts are not met       |
| Sales Executive       | Developing a sales slide deck on a unique selling proposition       | Selling the solution instead of listening for customer struggles       |
| Product Designer       | Building high fidelity prototype of MVP product       | Over Indexing visual design feedback and distracting from focus on user goals       |
| Growth Marketer       | Developing Account Based Marketing strategy based on LinkedIn research       | Avoid comparing cost of acquisition vs other more effective initiatives like SEO and direct prospecting       |

### <a name="ways-to-avoid-the-ikea-effect"></a> 3. Four ways to avoid the IKEA effect
Here are four ways you can avoid and defend against the IKEA effect.

#### 1. Acknowledge your unconscious bias
In the IKEA effect study, participants were found to be unaware of their unconscious bias. 92% of the participants when asked said they would pay more for pre-assembled products compared to self-assembly. This was in direct contradiction of their actions in the study. 

Acknowledging you are prone to the cognitive bias of the IKEA effect can be the most effective way to mitigate against it. When completing an effort on a solution or idea, admit to yourself that you probably love it more than other solutions, because you worked on it.

#### 2. Spike rough prototypes
The IKEA effect study found that the effect was strongest only when the effort was successful. Failure to complete tasks had corresponding negative psychological consequences. People ruminate more on tasks they failed to complete than on those they successfully completed, leading to negative affect and regret.

Spike rough prototypes and MVPs to test ideas early. Embrace sharing ideas that you are embarrassed with so it will be easier to cull.

#### 3. Talk to customers
Framing your solutions and efforts towards the customer struggle can help mitigate your bias against any one solution.

Talking to customers is the best way to achieve this. Learn how to conduct user interviews to surface customer's struggling moments and understand why they don't love their current solutions ([example user interview questions](https://mannhowie.com/user-interviews)).  

#### 4. Run growth experiments
Growth experiments can help mitigate against [confirmation bias](https://mannhowie.com/cognitive-bias#confirmation) by setting the discipline to state the problem statement, hypothesis and success criteria upfront before expending effort on a solution. Learn how to run your own growth experiment in this tutorial ([How to run a growth experiment](https://mannhowie.com/growth-experiment)).

The Build, Measure and Learn framework popularised by Eric Ries in his book [The Lean Startup](http://theleanstartup.com/book) explains how to apply a learning and feedback loop to measure the success of products and solutions.

__Sources__
- Norton, M. I., Mochon, D., & Ariely, D. (2012). [The IKEA effect: When labor leads to love.](https://www.hbs.edu/ris/Publication%20Files/11-091.pdf)
- Ries, Eric. [The Lean Startup. (2011)](http://theleanstartup.com/book)


When and why the IKEA effect causes people to overvalue their own ideas. Examples of organisational pitfalls of the IKEA effect. 4 ways you can defend against the IKEA effect: 1) Acknowledge your unconscious bias; 2) Spike rough prototypes; 3) Talk to customers; 4) Run growth experiments

ikea-effect

The IKEA Effect - Why people fall in love with their own ideas

The average is the most commonly used metric we use to understand data and infer insights - it is also the most dangerous.
![beware_average](//images.ctfassets.net/vwq10xzbe6iz/12kJw6jBqfvjjSCHyMxUNm/2dbf7edf379236641095dffe09c670fb/beware_average.png)

# The Pitfall of the Average
The US Air Force began life in the late 1940s with a high rate of aircraft accidents and pilot fatalities (excluding combat losses) with 23.6 aircraft destroyed per 100,000 flying hours. This dramatically reduced to 4.3 by the end of the 1960s driven largely by the work of one man, Lieutenant Gilbert S. Daniels who saw the pitfall of using “the average” to design solutions.

> The tendency to think in terms of the “average man” is a pitfall…it is virtually impossible to find an “average man” in the Air Force population.
[Gilbert S Daniels (1952 US Air Force Report)](https://apps.dtic.mil/sti/citations/AD0010203)

US Army engineers had standardised the design of pilot cockpits to conform to the average dimensions of a 1926 pilot. This was revisited in the 1950s by Lt. Daniels who measured the bodily dimensions of more than 4,000 pilots and found that zero pilots matched the average dimensions.

The US Air Force responded and demanded that its manufacturers design its cockpits to be adjustable to individual dimensions vs the standardised average. As a consequence, both pilot performance and accident/ mishap rates dramatically improved.
![us_airforce](//images.ctfassets.net/vwq10xzbe6iz/6mtEbxaIXNU60Svdu9uGsO/3c61d041d241f4040e7269db2552b8eb/us_airforce.png)

# A Modern Example
A modern example of the pitfall of the average would be to look at user activity. Imagine we build software that helps users perform inspections and we are tasked with improving user engagement.

Looking at the data we find that the average count of monthly inspections performed by our active users is 32 inspections per month:

![table_inspections](//images.ctfassets.net/vwq10xzbe6iz/3SfYJ8CwfGsBPFptTVL3jB/44bd12fd8ec35a7fc0c8efe608a47ed3/table_inspections.png)

Knowing this, we can deduce that our users on average perform 32 inspections per month or approximately one inspection a day. We begin building solutions such as daily notifications to help remind our users to perform their daily inspection.

__Stop.__

Reducing a large data set into a single number can often mask useful information and give us the wrong answer. Instead we can look at the distribution of our data and graph the same data as a histogram to reveal how often each different value occurs in a dataset.
![histogram_inspections](//images.ctfassets.net/vwq10xzbe6iz/1UixJwtgp0xcrWIvV6I6J2/ce429dc02a478f3c49abb41f28b113bc/histogram_inspections.png)

Now looking at the distribution of our data we can see that none of our users perform the average number of 32 inspections per month. Instead we see that 60% of our users perform 10 or fewer inspections per month and a large group (+30% of users) perform 70 or more inspections per month.

The distribution of our data could suggest that the usage of our software differs widely by different cohorts of users. One cohort could be using it to perform monthly scheduled safety checks vs another cohort using it to perform factory line QA checks. 

Next time when using the average, pause before making any conclusions and ask: "How many instances of the data actually reflect the average?". 

__References:__
- [THE “AVERAGE MAN”? - Gilbert S Daniels (1952 US Air Force Report)](https://apps.dtic.mil/sti/citations/AD0010203)
- [Trends in U.S. Air Force Aircraft Mishap Rates (1950-2018) - Thomas Light, Thomas Hamilton, Spencer Pfeifer](https://www.rand.org/content/dam/rand/pubs/research_reports/RRA200/RRA257-1/RAND_RRA257-1.pdf) 
- [The End of Average - Todd Rose (2015)](https://www.penguin.com.au/books/the-end-of-average-9780141980034) 


The average is a myth. Understand the pitfalls of the average and how it can conceal useful information. How the US Air Force threw out the average and saved lives. Use distributions to better understand your data.

beware_average

How the US Air Force Ditched the "Average" and Saved Lives

Product, marketing and sales teams can learn to run growth experiments to validate new strategies in the real world before incurring significant resource investment.
![guess_vs_experiment](//images.ctfassets.net/vwq10xzbe6iz/40uy9hD2VDsloevHEODX5m/7231e7f18856fa8c00e0f9eaef7347ec/guess_vs_experiment.png)

[Confirmation bias](https://mannhowie.com/cognitive-bias#confirmation) is a psychological tendency where we seek information that validates our existing beliefs as well as avoiding contradictory information. This bias often causes teams to waste resources on initiatives that validate existing views but are ineffective in the real world.

This article explains the 4 key steps of a growth experiment and a practical example of how you can run your own growth experiment quickly and cost effectively:
1. [Hypothesis](#hypothesis)
2. [Trigger](#trigger)
3. [Action](#action)
4. [Measure](#measure)

Imagine we are in the product marketing team of a B2B software startup that provides a tool for capturing customer complaints called Capturo.

## <a name="hypothesis"></a>1. Hypothesis
Set a hypothesis early. Start by identifying a customer struggle and business outcome of what you are trying to achieve. Form your own explanation as to what is causing the customer struggle and come up with a solution as to what could ease that struggle. [User interviews](https://mannhowie.com/user-interviews) are an effective tool at this stage if you have the time.

It is important at this stage to avoid the pitfall of falling in love with your explanation and solution. Focusing on the struggle will allow you to run a new growth experiment if the current one fails.

### __Example Hypothesis__
__Struggle:__ Our new users are observed to create a lower number of customer complaint forms on the platform than our existing users which is leading to lower product engagement and complaints captured.

__Explanation:__ We suspect two core reasons: 1) New users are unfamiliar with the types of questions to ask to gather complaints; 2) New users lack the time or know-how to digitise their existing questions into our platform.

__Solution:__ Our proposed solution will address the first explanation of new users not knowing what questions to ask. We will research and propose the most frequently asked questions to address customer complaints by service type (e.g. contact centre, restaurant, consultation).

__Hypothesis:__
> “Teaching new users the most commonly asked customer complaint questions relevant to their business will help them create more forms on the platform and gather more customer complaints”

## <a name="trigger"></a>2. Trigger
Establish a trigger point to communicate with your customer around their struggle and your proposed solution. The most effective mediums are email and calling customers directly. In-app banners, notifications and user flows are expensive if you do not already have the infrastructure in place. As this is a growth experiment we do not need to worry about solutions that don’t scale yet. 

The three most important components of a trigger:
1. __Audience:__ identify your target audience. Start with bigger groups, segmenting at this stage will be time consuming and take longer to gather results
2. __Message:__ keep consistent with your original hypothesis. There is no need to A/B test on a small scale but avoid message variation overkill
3. __Timing:__ identify the best time to contact your users to get their attention. Be sparing for when you trigger again due to lack of response

### __Example Trigger__
__Audience:__ our growth experiment will be to email new users who have created two forms or less in the platform from their first three months of joining

__Message:__ “Real examples of customer survey questions [Dental Practices] are using in Capturo” or “Top 6 customer survey questions [Dental Practices] ask in Capturo”

__Timing:__ Send when admin users are most active on the platform (for example mid-week mornings)

## <a name="action"></a>3. Action
Establish an action that you can measure based on the trigger. This can include opening a link to an article, registering interest via a form, logging in to the platform to perform an activity, emailing or calling back to respond.

Without creating an action it will be difficult to measure the success of your growth experiment.

### __Example Action__
Create a webpage link in the email which takes a user to the top customer survey questions.
E.g email link.
“View top 6 customer survey question examples”

## <a name="measure"></a>4. Measure
Measure and track the performance of the trigger and action stages. Start simple and use a spreadsheet to track key results. Free or cheap email tracking plug-ins are an effective way of tracking email open and click-through rates.

Once you feel you have gathered enough insight (can take a few weeks) assess the results and determine if your hypothesis was correct. Within the same experiment you can go back and modify the trigger and action to gather more data if needed.

### Example Measure
Create a spreadsheet with columns to track the following:
User contact email and id
- Email message sent
- Date and time sent
- Date and time opened email (use email tracking tools)
- Date and time opened link (use email tracking tools)
- Already sent (Y/N)
- Created a new template (Y/N) (check manually each week)

After measuring the performance assess engagement metrics for example:
- Total users contacted
- Average contact count per user
- % email open rate
- % click through rate
- % users creating new template

__Happy case__
If the % click through rate and % users creating a new template is good we have quickly validated that knowing the right questions to ask can help boost form creation. We now have an improved business case for investing more resources in-app to build onboarding tours in the form creation stage.

__Sad case__
If the % open rate is poor after adjusting for message and timing then the solution of our hypothesis is likely incorrect. We can go back to our original hypothesis and form a solution for our second explanation (e.g. already know what questions to ask but don’t have the time to create a new form). 


4 steps to a successful growth experiment: 1) Hypothesis; 2) Trigger; 3) Action; 4) Measure. Practical example for how teams can run growth experiments quickly and cheaply.

guess_vs_experiment

How to Run a Growth Experiment - Learn the 4 Steps

![fininte state machine](//images.ctfassets.net/vwq10xzbe6iz/6JNh1Rpi6a1VUnTux03TzW/c69b8b54a1be48ec820cec8e721163af/fininte_state_machine.png)

Finite State Machines allow cross-functional teams to visually design complex logic before committing expensive resources to design and code implementation.

It is a powerful tool for product teams and business owners to communicate on customer requirements in order to identify rabbit holes and poor UX early in the process.

They have been widely used in electrical engineering and in the logic design of electronic devices for decades. 

To illustrate the power of Finite State Machines, imagine we have been briefed by the business to build a customer feedback form widget.

## Phase 1 - Simple Feedback Widget
The first phase of our brief is for a simple feedback widget that will do the following:
- Ask for positive or negative feedback
- If positive display a happy success message
- If negative display an apology
- Allow user to cancel the feedback form

We can visualise this simple application using Finite State Machines below:
![phase1](//images.ctfassets.net/vwq10xzbe6iz/3aRVidpZK6c6qevtvEWLfB/9a09666917aeeddc3170c9a4ef80cfcf/phase1.png)

Our application has 4 states:
1. __START__ - our initial state where a user can click to begin the survey
2. __RESPONSE__ - where a user is asked for a positive or negative response and where they can cancel to go back to START
3. __POSITIVE CONFIRM__: an end state upon a user clicking POSITIVE
4. __NEGATIVE CONFIRM__: an end state upon a user clicking NEGATIVE

Our 4 states are also characterised by 4 events and transitions which are conditional upon the current state the application is in.

Our application also triggers actions such as saving the rating and updating the message upon certain events and entering different states.

Once the logic and user flow has been agreed we can easily convert this to design and code stage. In the examples below we use the open source library [XState](https://xstate.js.org/docs/) by [David Khourshid](https://github.com/davidkpiano) to codify our Finite State Machine and use ReactJS to render our UI.

<iframe src="https://codesandbox.io/embed/feedbackphase1-stkhm?fontsize=14&hidenavigation=1&theme=dark&view=preview"
     style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;"
     title="feedbackPhase1"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
   ></iframe>

## Phase 2 - Negative Feedback Reason
The business has now come back asking for us to capture the main reasons for negative feedback.

Our application now must:
- Ask the user to select the main reason for negative feedback (Service, Product, Price)
- Also allow a user to select POSITIVE again if they accidentally selected NEGATIVE

With Finite State Machines we can easily modify and expand our logic without breaking any previous logic:
![phase2](//images.ctfassets.net/vwq10xzbe6iz/38VI5AsXioynO833DlaAzM/9f8c7edb547374d6044b6bff26400c85/phase2.png)

Our application has a new __NEGATIVE FEEDBACK__ state which allows a user to select from three of the main reasons for the negative response (SERVICE, PRODUCT or PRICE). Upon selecting an event the reason is captured and the state transitions to the NEGATIVE CONFIRM end state and displays an apology message.

We have now also added a new POSITIVE event which a user can click on to transition directly to the POSITIVE CONFIRM end state.

Our team can now confidently update our application with the new business logic:

<iframe src="https://codesandbox.io/embed/feedbackphase2-lg6sy?fontsize=14&hidenavigation=1&theme=dark&view=preview"
     style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;"
     title="feedbackPhase2"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
   ></iframe>

## Phase 3 - Advanced Feedback
The business comes back wanting to direct users to contact sales for pricing discussions if they select PRICE as a negative response. In addition they want to capture any other reasons for negative feedback.

Our application must now grow in complexity to handle the following:
- If user selects PRICE as a negative response, send to different end state with pricing discussion CTA
- New OTHER option for a user to select with ability to leave comment

Once again we modify our Finite State Machines to expand our logic
![phase3](//images.ctfassets.net/vwq10xzbe6iz/6wb9cvXQflR8QIBGul2SOU/b8e775fd2c86f028a3c4652602219969/phase3.png)

Our application has now added two new states:
1. __PRICE CONFIRM__: end state when a user selects PRICE as a negative response. We will display a contact number for pricing discussions. Creating a new end state provides us with flexibility if the business may want to display discount offers or ask the user for more contact information in the future
2. __COMMENT__: when a user selects OTHER as a new reason for their negative response. This state includes three events where a user can UPDATE COMMENT to capture the reason, SUBMIT COMMENT to transition to end state and CANCEL to go back and select a different reason

Once again, our Finite State Machine is able to handle increasing complexity without breaking previous logic. Our designer and developer team can now confidently work on implementing the new logic:

<iframe src="https://codesandbox.io/embed/feedbackphase3-8y5dx?fontsize=14&hidenavigation=1&theme=dark&view=preview"
     style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;"
     title="feedbackPhase3"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
   ></iframe>

## Future Complexity
Our application will naturally grow in complexity as business and user requirements evolve. 

Examples may include:
- Ask for feedback for positive response
- Invite user to add users after a positive response
- Ask user to provide the name of the poor service representative
- Introduce a passive response in addition to positive and negative
- etc.

With Finite State Machines we can confidently continue modelling this advanced complexity into our design and visually see how it interacts with previous functionality.


How Finite State Machines allow cross-functional teams to visually design complex logic before committing expensive resources to design and code implementation.

fininte state machine

Finite State Machines - A Common Tool for Product Owners, Designers & Developers

Why do most startups fail to find product market fit? 
![beware_solutions_seeking_problems](//images.ctfassets.net/vwq10xzbe6iz/2rGuWsynYvglJNeJeWcQoz/b11da185061ef24f957efe1f9683d4f8/beware_solutions_seeking_problems.png)

Because our [confirmation bias](https://mannhowie.com/cognitive-bias) creates tunnel vision towards our existing solutions. Instead we should frame our focus on solving the user’s struggle.

Here are 5 questions you can ask in user interviews to validate if your startup has found product market fit.

Imagine we are a startup building solutions for mortgage brokers.

## 1. What progress are you trying to make in X?
__*Example:*__
__Q.__ What progress are you trying to make in finalising loan applications?

__A.__ I’m looking for my team to close more loans and shorten the bank approval times.

## 2. What is your biggest struggle when trying to make progress in X?
__*Example:*__
__Q.__ What is your biggest struggle in getting bank approvals completed on time?

__A.__ Document gathering with our customers. A single important lost or incomplete document can slow the whole process down and cause frustration amongst both lenders and borrowers, both of whom are our customers.

## 3. Tell me about the last time you encountered this struggle?
*__Example__*
__Q.__ Tell me about the last time you encountered this struggle? (create a timeline of the event as if you were in their shoes)

__A.__ Last month one of our new starters had a backlog of 10 applications with one of our newer lenders. An applicant customer did not submit a key piece of information that the new lender required but this only came to light a couple of weeks after the applicant had already submitted all the documents we asked. The lender was frustrated that we missed the information (as they said they had asked us for this before) and the applicant was livid as they had already terminated their rental lease.

## 4. What solutions have you previously tried?
__Example:__
__Q.__ What solutions have you previously tried to avoid or manage this struggle?

__A.__ We’ve used shared cloud storage solutions like Google Drive and Dropbox, onboarding checklists to make sure we don’t miss things and our CRM tool to keep track of emails.

## 5. What didn’t you love about those solutions?
__Example:__
__Q.__ What don’t you love about those solutions you’ve previously tried?

__A.__ Some of the tools create more work for our team in managing the document workflow and version control, we still have to review all the documents to make sure they are complete. As a result we still rely heavily on email to follow-up and confirm next steps with both lenders and customers but then it’s easy for us to miss things and drown in emails.

## Bad User Interview Questions
User interviews to find product market fit should be framed around the user’s struggle and not solution ideas. 

Bad user interview questions include:
- What ideal solution would you like to solve your struggle? ❌
- Do you have any feedback on our solution? ❌
- Would you use this solution if we offered it? ❌
- What do you think we could do to improve your process? ❌
- Do you know anyone else in your company who would use our solution? ❌

## User Interview Insights
Following the insights from our 5 user interview questions we are now better able to frame the struggle for our mortgage broker manager as:

> “Communicating between lenders and customers the missing information needed to complete a loan application”

Solutions we can now explore to solve the problem could include:
- Assignees for onboarding docs (whose court is it in now) 💡
- Automatic email reminders of incomplete docs 💡
- Auto-logging emails to capture a digital chat history 💡
- Identify which docs have not been updated in a while 💡

Framing the challenge around the user struggle allows us to continue iterating on solutions to help users make progress instead of being fully invested into one solution. 

⚠️ Beware solutions seeking problems.


5 user interview questions to validate product market fit: 1) What progress are you trying to make?; 2) What is the hardest thing about making progress?; 3) Tell me about the last time you encountered the struggle; 4) What solutions have you previously tried? 5) What didn’t you love about those solutions?

beware_solutions_seeking_problems

5 Questions to Ask to Find Product Market Fit - User Interviews

Inversion is a mental model of framing a problem from an opposing objective in order to solve the original problem.
![inversion](//images.ctfassets.net/vwq10xzbe6iz/61qV3DFcVLXMoW1R899hWB/db5a16bc87fc56ff29624d857bbed49f/invert_image.png)
It is a favourite trick of famous value investor Charlie Munger. He gives an [example of how the inversion process](https://youtu.be/_uacTl8Lv_U) helped him in his early career become a better meteorologist:

> “When I was a meteorologist in World War II, they told me how to draw weather maps and predict the weather. What I was actually doing was clearing pilots to take flights. 
> 
> I just reversed the problem. I inverted, __I said:__ __suppose I want to kill a lot of pilots. What would be the easy way to do it__? And I soon concluded that the only easy way to do it was to get the planes into icing conditions they couldn’t handle or to get the pilot into a place where he’d run out of fuel before he could safely land. 
> 
> So I made up my mind I was going to stay miles away from killing pilots by either icing or getting them sucked into conditions where they couldn’t land. I think that helped me be a better meteorologist in World War II. I just reversed the problem.
> 
> Algebra works the same way. Human beings should do the same thing in their ordinary walks of life. Just constantly invert. You don’t think about what you want. You think about what you want to avoid. When you think about what you want to avoid, you also think about what you want. And you just go back and forth all the time.”

This article looks at how others have used the inversion process to innovate big ideas and new solutions in both life and growing start-ups.

## Productivity
In solving the problem of decluttering one’s life, Marie Kondo frames the challenge of effective tidying __not as what we want to get rid of__, but instead __choosing what we want to keep__.

The big idea of the [KonMari Method](https://konmari.com/what-is-konmari-method/) is to keep things that spark joy: “Does this spark joy? If it does, keep it. If not, dispose of it.” 

By reframing the problem she was able to develop her tidying techniques as “involving only two essential actions: discarding and deciding where to store things.”

## Product Innovation
In solving the problem of product innovation, Bob Moesta and the late Clay Christenson frame the question __not as what new features do customers want__, but instead understand __what struggles they experience with their current solution__. 

The big idea behind their innovative [Jobs To Be Done (JTBD) framework](http://jobstobedone.org/) is understanding the struggles a customer faces in making progress in their lives and innovating around those struggles.

By reframing the problem in understanding the struggle, Bob Moesta innovated his JTBD framework to look at “four forces of progress” where progress only occurs when:

> (__Push__ of the current struggle + __Pull__ of the new solution) > (__Habit__ of the old solution + __Anxiety__ of the new solution).

## Project Management
In solving the problem of delivering meaningful work on time and on spec, Ryan Singer from Basecamp frames the challenge __not as how long will it take to execute__, but instead __how much time do we want to spend__. 

The big idea of [Shape Up](https://basecamp.com/shapeup) is to focus less on estimates and more on appetite in order to narrow down problems and design outlines of solutions that fit within constraints of appetite.

By reframing the problem based on appetite, Basecamp’s Shape Up techniques focus on setting bounded solutions using fat marker sketches and addressing risks and rabbit holes early on. All the techniques are designed to set guardrails based on appetite to de-risk projects from derailing or growing in scope.


How Charlie Munger used the inversion process to save the lives of pilots during WWII. How inversion helps frame innovative solutions in productivity, product design, and project management.

inversion

Invert, Always Invert - Find out how to kill pilots

Alibaba operates three of the largest digital platforms in China: e-commerce, cloud and payments. We estimate Alibaba Group (BABA:NYSE 9988:HKG) to be valued at up to US$900 billion based on a Sum Of The Parts (SOTP) valuation of its various operating segments:

#### Alibaba Group SOTP Valuation (2021)
![alibaba sotp](//images.ctfassets.net/vwq10xzbe6iz/5JX9uAgNOkj85xN3eJWyA8/16003aacd7bc9972fb8da8e3a55152a6/alibaba_sotp.png)

This article analyses Alibaba’s two main operating segments that represent up to 88% of the group valuation (Taobao/ Tmall and Alibaba Cloud) and shows how you can formulate your own valuation and thesis. To learn the fundamentals of valuing any technology company refer to [this article with a case study of how to value YouTube](https://mannhowie.com/youtube-valuation). 

__Key Sections:__
1. [China E-Commerce Market Share](#industry)
2. [Taobao/ Tmall Valuation](#taobao)
3. [Alibaba Cloud Valuation](#cloud)

## <a name="industry"></a>1. China E-Commerce Market Share
China dominates global online spending. Over 57% of total global online spend happens in China with an estimated +1 billion online shoppers spending over US$2.8 trillion annually. Online spending in China alone is more than 70% more than the next 10 countries combined.

#### Global E-Commerce Spend by Country (2021 Forecast) & China E-Commerce Market Share by Company (2020 Actual)
![global ecommerce](//images.ctfassets.net/vwq10xzbe6iz/5RpP7NWgAWsBH0A4nt048d/f2e7b2c21f59148f2c90ad8d99d618e0/global_ecommerce.png)

China is likely to continue to dominate global online spending the next decade and beyond. Relative to the United States, China has 5x the online shopping population and is still only at 20% of US GDP and Income per capita. Across e-commerce there are two economies: China and the Rest of the World.

Within China, e-commerce is dominated by three players: Alibaba, JD.com and Pinduoduo. Alibaba’s annual Gross Merchandise Value (GMV) across its two platforms Taobao and Tmall in China alone is more than all annual online spend across the US, UK and Japan combined. 

#### China E-Commerce Major Players
![china ecommerce table](//images.ctfassets.net/vwq10xzbe6iz/2vOtxucZPBnNJvlZH9KklU/c8ed8fe3cda225faf94169a6df37080a/china_ecommerce_table.png)
Across the three major Chinese players Alibaba maintains its dominant position. However newcomer pinduoduo has grown considerable share in a very short period focusing on a new trend in e-commerce in China, lower basket value social commerce.

## <a name="taobao"></a>2. Taobao / Tmall Valuation
Alibaba’s largest and most profitable segment is its e-commerce marketplace platform in China known as Taobao and Tmall. We value this segment at RMB 4 trillion (US$ 624 billion) representing 80% of the entire valuation of Alibaba.

### What is Taobao and Tmall?
With over 811 million active annual customers, Taobao is effectively the internet platform for e-commerce in China. Nearly all merchants and businesses that sell to Chinese consumers have an online store on Taobao. 

There are two main platforms within the one Taobao mobile and web app: Taobao and Tmall with a total GMV split 50/50:

- __Taobao__ is a marketplace platform where any merchant, person or small business can set up an online store and sell to the Chinese population.

- __Tmall__ is a B2C platform reserved for brand companies where they can set up their own dedicated stores. Most international brands selling into China will transact through their Tmall stores vs their own online shops.

#### Taobao vs Tmall
![taobao vs tmall](//images.ctfassets.net/vwq10xzbe6iz/4QhVDL6MlaqeWzoag1v54z/9ee6f6d521faa305e273bfd0f4407907/taobao_vs_tmall.png)

Alibaba’s e-commerce business model is marketplace-based and facilitates transactions between buyers and sellers. Unlike Amazon and JD.com, Alibaba does not purchase and resell inventory nor does it own or operate its own fulfilment and distribution centres. It is the sellers responsibility for organising delivery to the buyer either direct or via Alibaba’s network of 3rd party logistics providers (via its global Cainiao logistics business).

### How does Taobao Tmall generate revenue?
Ads and commissions:

- __Ads (70% of e-commerce revenue)__: merchants buy keywords and display ads on Taobao and Tmall to attract traffic and purchases to their stores. Ad monetization represents 2-3% of GMV transacted through the platform. Alibaba’s high margin ad revenue model is similar to Google’s cash cow Search business.

- __Commissions (30% of e-commerce revenue)__: merchants pay commissions on transactions through the Tmall network as part of hosting their stores on the largest e-commerce platform in the world. Commission monetization represents ~1% of GMV.

### What is the growth thesis for Alibaba China E-Commerce?
The e-commerce market in China is now highly mature with over 50% of retail sales done online and Alibaba maintaining the dominant share. Having been the dominant e-commerce platform in China for the last decade we expect overall growth to slow. 

Having said that, we still expect Alibaba to remain the dominant e-commerce platform in China and expect Alibaba’s annual GMV to grow another 50% over the next decade and ad monetization to increase from ~3% to +3.5%.

We can represent these assumptions as key operating metrics to arrive at a forecast annual revenue by the end of 2030 of RMB 521bn (US$82 bn), up from ~RMB 300bn (US$47bn) ending 2020.

#### Alibaba China Retail Marketplace Revenue Model (RMB)
![alibaba retail revenue model](//images.ctfassets.net/vwq10xzbe6iz/7AgIVJxBlV9K6uenKzyOX9/af5ab81611f9c3a6cba49f4a7b23d585/alibaba_retail_revenue_model.png)

### China Retail Marketplace DCF Valuation
We arrive at our RMB 4 trillion ($USD 624 bn) valuation for Alibaba’s China e-commerce business applying the following key assumptions:
- __EBITA margins__: remain stable at 72% given the high margin operating model of its ad ad and commission businesses. We expect Alibaba’s other segments to operate at break-even largely to support its high margin e-commerce segment (e.g. Cainiao logistics) 
- __Tax rate__: long term effective tax rate of 20% (China based)
- __Stock Based Compensation__: while non-cash we treat this as an expense as it’s largely a substitute for compensating staff. We expect SBC to remain at 25% of total revenue going forward to attract key talent
- __Reinvestment (Net Capex)__: assume a capital-light sales to capital ratio of 1.5 (in line with Alibaba historical and compares to 1.9 for Alphabet) meaning for every one dollar of incremental annual revenue growth, Alibaba will reinvest 66% back into the business for future growth
- __Discount rate__: assume 8% discount rate, low by historical standards but higher now given subdued global interest rates
- __Long term growth rate__: 3.5% above global GDP long term GDP growth of 2-3% as China is still expected to grow faster than the rest of the world for the next decade

#### Alibaba China Retail Marketplace DCF Model (RMB millions)
![alibaba retail dcf](//images.ctfassets.net/vwq10xzbe6iz/3em6HkDrD1MyZwUDTEdslh/e15b1815727f85c2aadc60bb3221838d/alibaba_retail_dcf.png)

## <a name="cloud"></a>3. Alibaba Cloud Valuation
Alibaba’s second most valuable operating segment is its cloud computing business Alibaba Cloud. We conservatively value this segment at RMB 390 billion (~US$60 billion) on the basis it continues to dominate the Chinese market but will face stiff competition globally particularly given political concerns in western economies around hosting of data by Chinese domiciled companies.

### What is Alibaba Cloud?
Alibaba Cloud is the 4th largest cloud computing provider globally and the largest in the Asia Pacific with +40% share in China. It sells cloud-based compute and storage infrastructure services to businesses looking to host their applications and data primarily in China (although it operates globally).

#### Global Public Cloud Infrastructure Services Spend 2020

![global cloud spend](//images.ctfassets.net/vwq10xzbe6iz/77Vqh2ZPUOpbpsZ2EmAFer/5f135f4d953b45be2e4716c4d5588999/global_cloud_spend.png)

Alibaba Cloud is similar to Amazon Web Services offering similar competing offers often at even lower prices when hosted in China vs AWS. It has a clear advantage over the other hyperscale cloud providers within China given its significant existing presence in the Chinese market and wider local market support.

### Alibaba Cloud DCF Valuation
Our RMB 390 billion (US$ 60 billion) DCF valuation for Alibaba Cloud is based on the following key assumptions:
- __Revenue__: Achieve revenues similar to that of current AWS levels by 2030, largely driven by growth in the local Chinese and Asian market. Alibaba is following in the similar footsteps as AWS (~7 years behind) as both the local market leader and without competition from global hyperscale providers. However growth is expected to slow as we expect international growth to be more difficult
- __EBITA Margin__: Achieve similar EBITA margins of +30% as AWS as it reaches scale and continues to reinvest for growth
- __Tax and SBC__: Effective tax rate of 20% and lower stock based compensation expense as % of revenues vs Alibaba China Retail as lower proportion of costs represented by people
- __Reinvestment Rate__: Sales to capital ratio of 1.5 continuing to reinvest 66% of net revenue growth back into the business each year
- __Discount and growth rate__: 8% discount rate and 3.5% LT growth rate in line with Alibaba China Retail

#### Alibaba Cloud DCF Valuation (RMB millions)
![alibaba cloud dcf](//images.ctfassets.net/vwq10xzbe6iz/1yolWWSzSGMD3dC1BOLU7j/d8fa2dedd86c7bde6d2fa70393c5700c/alibaba_cloud_dcf.png)

Alibaba operates three of the largest digital platforms in China: e-commerce, cloud and payments. We estimate Alibaba (BABA:NYSE 9988:HKG) to be valued at up to US$900 billion based on a Sum Of The Parts (SOTP) valuation of its various operating segments.

global ecommerce

How Much is Alibaba Worth? US$900 billion in 2021

Uncle Bob's famous [Clean Architecture](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html) is a way to write resilient software.

Resilient software is divided into layers, underpinned by business logic and is independent of technologies. It should be:
1. **Independent of Frameworks**. Libraries and frameworks should be treated as tools and not dependencies.
2. **Testable**. Can be tested without external dependencies.
3. **Independent of UI**. You can easily switch CLI for Web or RasberryPi.
4. **Independent of Database**. Switch out SQL for MongoDB.
5. **Independent of any external agency**. Business rules don't know anything about outside world.

![The Clean Architecture diagram](https://blog.cleancoder.com/uncle-bob/images/2012-08-13-the-clean-architecture/CleanArchitecture.jpg)

In practice, choice of technology should be the last decision you make or code you write (e.g. database, platform, framework).

By following clean architecture, you can write software today that can be easily switched out for different technologies in the future.

## Practical Example of Clean Architecture in Node.js
This is an example of a simple CRUD application with layered software and separation of business logic vs technology. 

It is a simple API for creating `students` and `teachers` and includes validation, persistence and UI. It includes examples using different interfaces (CLI and Web), databases (in memory, MongoDB), and libraries (validation).

[Click here for github repo.](https://github.com/howardmann/clean-node)

*Note: this application is different to the Clean Architecture diagram above but attempts to achieve the same outcome.*

### Software layer overview
The application is separated into three layers. Inner layers cannot depend on outer layers and outer layers should only depend one layer in:

- **Inner Layer**
  - **Models**. Handles the creation, validation and reading of our entities (students and teachers). Note that this should be custom logic and not include the DB implementation of models (e.g. in Mongoose DB ORM, their models should be encapsulated in the DB layer below). Our model schemas live here. 
  - **DB**. Our choice of DB (in memory, MongoDB, SQL), this is independent of the model. Note that in Clean Architecture this is considered an outer layer framework, but for practical applications I find it easier to place it inner and have the data-access layer depend on it rather than injecting it in.
- **Middle Layer**
  - **Data-Access**. Handles transfer between the DB (like an ORM). Depends on the model to validate and create the entity in DB. The key is to have a consistent & custom API that all outer layers communicate with. Testing here will ensure that replacing or using multiple DBs doesn't break anything further upstream. 
- **Outer Layer**
  - **Drivers**. Represents the UI or interface (Web or CLI). It communicates only with the data-access layer.

### Example application structure
```bash
============= INNER LAYER =====================================================================
models                    // create new entity by validating payload and returning new read only object 
  L student
    L index.js            // dependency inject schema/ validation library
    L index.test.js       // tests makeStudent()
    L student.js          // simple model takes info, validates and returns read only object
    L student-schema.js   // student validation schema
  L teacher
    L index.js
    L teacher.js
    L teacher-schema.js
  L validator             // wrapper around JOI validation library
    L index.js            // consistent API if ever to switch out a new validation library
    L index.test.js       // tests for validation schema for all models

db                        // db connection and adapter
  L memory                // in memory JSON
    L students.js         
    L teachers.js         
  L mongodb               // mongodb alternative
    L connection.js       // connection library
    L seeds               // seed library
      L students-seeds.js // async seed students db
    L models
      L student.js        // models specific to mongodb. this is different to our business logic models which handle tests and validation

============= MIDDLE LAYER =====================================================================
data-access               // think of it as our internal ORM (logic for our use-cases lies here)
  L students-db           
    L index.js            // other controllers and drivers rely on this API (findStudent, listStudents, addStudent)
    L memory              // in memory
      L index.js          // expose the memory implementation of findStudent, listStudents, addStudents
      L serializer.js     // serializes to DB specific properties (e.g. serial > id, year > grade)
    L mongodb             // mongodb ORM
      L index.js          // uses mongoose implementation of findStudent, listStudents, dropAll etc.
      L serializer.js     // serializes _id to id
    L postgresql          // TODO: Illustrative
    L airtable            // TODO: Illustrative
  L teachers-db           // per students-db above

============= OUTER LAYER =====================================================================
drivers
  L cli                   // cli driver depends on data-access students-db
  L webserver             // express web-server
    L routes
      L index.js          // routes paths
      L students.js       // requires our data-access students-db
      L teachers.js       // per above
    L server.js
```

### Practical approach
In practice, we can defer technology decisions by writing our application in the following order:
1. Start with models, schema and validation. Write test spec.
2. Defer DB decision by using in-memory JSON store
3. Create a data-access API that depends on model and in-memory DB. Write test spec.
4. First tech decision: UI interface (e.g. web or CLI). Depend on above data-access layer. Write integration test spec. 
5. Second tech decision: DB choice (MongoDB, SQL). Replace in-memory DB store. Write data-access methods specific to the DB choice. Ensure previously written test specs pass.

### Models
Our model is a simple factory function that validates a payload (dependency injected validator) and returns a new object with getters.

```javascript
// models/student/student.js
let buildMakeStudent = function(studentValidator) {
  return ({
    name,
    age,
    grade,
    prefect = false
  } = {}) => {
    let {error} = studentValidator({name, age, grade, prefect})
    if (error) throw new Error(error)

    return {
      getName: () => name,
      getAge: () => age,
      getGrade: () => grade,
      isPrefect: () => prefect
    }
  }
}

module.exports = buildMakeStudent
```
While the model schema is dependent on a validation library and breaks the Clean rules, I find it easier to understand the model by having the schema inside the model. (Note: see the repo for an example of how the validator could be separated into its own software entity).

```javascript
// models/student/student-schema.js
let Joi = require('joi')

module.exports = Joi.object().keys({
  name: Joi.string().required().error(() => 'must have name as string'),
  age: Joi.number().error(() => 'age must be a number'),
  grade: Joi.number().error(() => 'grade must be a number'),
  prefect: Joi.boolean().error(() => 'prefect must be a boolean')
})
```

We then dependency inject the validation library into the model. Note we use a wrapper for the validation library to make it easier to switch out libraries in future.

```javascript
// models/student/index.js
let buildMakeStudent = require('./student')
let studentSchema = require('./student-schema')
let studentValidator = require('../validator/')(studentSchema)

let makeStudent = buildMakeStudent(studentValidator)

module.exports = makeStudent
```

Write two sets of unit tests for our model. First testing the validation library for valid vs invalid payloads and relevant error messages. And second testing the creation and read only of the model entity.

```javascript
// models/validator/index.test.js
studentValidator
  [] validates name:string:required, grade:number, age:number, prefect:boolean 
  [] returns error messages if invalid

teacherValidator
  [] validates name:string:required, subject:string, tenure:boolean
  [] returns error messages if invalid
```

```javascript
// models/student/index.test.js
makeStudent
  [] throws error if invalid payload
  [] must have name
  [] can have grade
  [] can have age
  [] sets prefect to false by default
```
### Data-Access
The data-access layer is one of the most important. We should feel confident to easily replace DBs.

Here we need three key components
1. API and test spec
2. Serializers to adapt custom DB to our model schema
3. DB implementation of the API and passing of test

Start with how we think the outer layers will communicate with the data-access layer and what they should expect to get.

```javascript
// data-access/students-db/index.test.js
// example test spec
studentsDb
  - listStudents() lists students
  - findStudent() find single student by id
  - findStudentsBy() finds all students by property
  - addStudent() inserts a student
  - throws error if student payload invalid
  - deleteStudent() deletes a student
  - dropAll() drops students database
```

Write a serializer which adapts the custom DB schema with our model schema.

```javascript
// data-access/students-db/mongodb/serializer.js
// e.g. mongodb stores property id as _id
const _serializeSingle = (student) => {
  return {
    'id': student._id,
    'grade': student.grade,
    'name': student.name,
    'age': student.age,
    'prefect': student.prefect
  };
};

const serializer = (data) => {
  if (!data) {
    return null
  }
  if (Array.isArray(data)) {
    return data.map(_serializeSingle)
  }
  return _serializeSingle(data)
}

module.exports = serializer
```
Write custom DB implementation of the test spec API. Here is an example of an in-memory implementation (which you should start with) and a MongoDB version. Note: the advantage of writing a test spec is you can focus on simply writing code that just has to work.
#### In-memory data-access:
```javascript
// data-access/students-db/memory/index.js
let STUDENTS = require('../../../db/memory/students') // DB
let makeStudent = require('../../../models/student/index') // model
let serialize = require('./serializer') // serializer custom to db

let listStudents = () => {
  return Promise.resolve(serialize(STUDENTS))
}

let findStudent = (prop, val) => {
  if (prop === 'id') { prop = 'serial' }
  let student = STUDENTS.find(student => student[prop] == val)
  return Promise.resolve(serialize(student))
}

let findStudentsBy = (prop, val) => {
  let student = STUDENTS.filter(student => student[prop] == val)
  return Promise.resolve(serialize(student))
}


let addStudent = (studentInfo) => {
  let student = makeStudent(studentInfo)
  let newStudent = {
    serial: STUDENTS.length + 1,
    year: student.getGrade(),
    name: student.getName(),
    age: student.getAge(),
    prefect: student.isPrefect()
  }
  STUDENTS.push(newStudent)
  return findStudent('serial', newStudent.serial)
}

let deleteStudent = (id) => {
  return findStudent({id})
    .then(student => {
      if (student.id == id) {
        STUDENTS = STUDENTS.filter(student => student.serial != id)
        return {
          id,
          status: 'success'
        }
      }
      return {
        status: 'fail'
      }
    })
}

let dropAll = () => {
  STUDENTS = [];
  return STUDENTS;
}

module.exports = {
  listStudents,
  findStudent,
  findStudentsBy,
  addStudent,
  deleteStudent,
  dropAll
}
```
#### MongoDB data-access:
Note for our MongoDB data-access implementation we depend on the DB from the inner layer. The DB includes MongoDB specific implementation of the model and DB connection.

We write a dropAll function for the purposes of writing a test spec that can be used across any DB choice. E.g. beforeEach test we would drop the DB and seed items for testing.
```javascript
// data-access/students-db/mongod/index.js
let Student = require('../../../db/mongodb/models/student')
let makeStudent = require('../../../models/student/index') // model
let serialize = require('./serializer') // serializer custom to db

let listStudents = () => {
  return Student.find({})
    .then(serialize)
}

let findStudent = (prop, val) => {
  if (prop === 'id') {
    prop = '_id'
  }
  return Student.find({[prop]: val})
    .then(resp => {
      return serialize(resp[0])
    })
}

let findStudentsBy = (prop, val) => {
  return Student.find({[prop]: val})
    .then(serialize)
}

let addStudent = (studentInfo) => {
  let student = makeStudent(studentInfo)
  let newStudent = {
    name: student.getName(),
    grade: student.getGrade(),
    age: student.getAge(),
    prefect: student.isPrefect()
  }
  return Student.create(newStudent)
    .then(serialize)
}

let deleteStudent = (id) => {
  return Student.findByIdAndDelete(id)
    .then(resp => {
      return {
        id: resp._id.toString(),
        status: 'success'
      }
    })
    .catch(err => {
      return {
        status: 'fail'
      }
    })
}

let dropAll = () => {
  return Student.remove()
}

module.exports = {
  listStudents,
  findStudent,
  findStudentsBy,
  addStudent,
  deleteStudent,
  dropAll
}
```
### Drivers
Finally we write our drivers whose only dependency is our data-access layer. The drivers should not communicate directly with the model or db.

Any changes to the inner layer will cascade up and as a result there should be less testing done on the outer layers. E.g. if we were to test changes to the model schema in the driver layer we would need to rewrite our tests here as well.

```bash
drivers
  L cli
    L index.js
  L webserver         // express webserver
    L routes
      L index.js
      L students.js   // depends on students data-access layer
      L teachers.js   // depends on teachers data-access layer
    L server.js       // depends on routes
```

Writing Clean Architecture in Node.js. REST API Tutorial using MongoDB, Express and other best practices. How to write software that lasts and can be independent of technology choice.

Howie Mann
Startup Strategy
Subscribe
Articles Search About Subscribe

Topics

Popular Articles

About