Part 2 — How to Work Like an Outcome Team
In the previous post The Simplest Explanation to Outcome and Feature Teams, I tried to explain the difference between the two.
We got to know the two characters of our story: Delivery Dan and Experimenting Eve. Additionally, we learnt that consumer products require a different way of working. Releasing new features does not necessarily increase value for the customers. New features can actually make the product more complicated than before and customers might even struggle to use the product.
Now suppose both Dan and Eve started working for product teams.
Delivery Dan will care about delivering features (feature teams)📦🚚
Experimenting Eve will want to ensure her customers make progress (outcome teams) 🚀🎯
For all matters, outcome teams could be called mission teams, impact teams — or by any other name, the name is not important, — for it is the mandate for teams which is the centerpiece, which is to deliver value to customers, not features. Think of an outcome as something that has an postive impact on your customers/users, and thereby also your business. Something that you will continue to work towards over time. The solutions to deliver on this outcome will change with time.
Lets give both Delivery Dan and Experimenting Eve a task and see how they tackle it.
Here is the brief:
A charity hires you to help increase the standard of living in the village. You notice villagers spend a lot of time walking to the river to carry water.
The charity believes having a well in the village would allow the villagers to use their time for other activities — ones that would allow them to improve their standard of living.
Delivery Dan is on it.
Nothing is going to stop him building that well. He takes the brief and breaks it down into various features to deliver and rallies his team on making sure they deliver these on time. Along with the features, he also finds metrics to measure success.
Goal— Increase standard of living in the village 🥅🥇🏆
Solution— Build a well💡
Features to deliver 📦🚚
- Hole
- Casing
- Brickwork
- Pump
- Pulley system
- Buckets
Metrics for success🎯
- Rate of water output
- Measure capacity
Experimenting Eve also tries to figure out a solution.
She doesn´t rush into thinking about any features to launch but instead spends time thinking about how she wants her customers life to be better. In this case it is about increasing their living standards; she takes a pensive approach to understand what it would take and how could one measure being on the right path.
Here is her method, which we can all apply in increasing value to our customer when we deliver new functionality.
#1 Goal 🥅🥇🏆
(Where do you want to go; what do you want to achieve?)
Increase standard of living in the village
#2 Write the outcome the team focus on 🚀
(Think of an outcome as something that has an impact on your customers/users and thereby also your business. Something that you will continue to work towards over time. The solutions to deliver on this outcome will change with time.)
Increase standard of living in the village
Eve ensures that the outcome for her team is aligned with the goal; in this case it is the same.
#3 Write hypotheses that could deliver on this outcome 🔬
(Write all the hypotheses that could apply to your outcome and goal in #1 and #2)
We think if we can reduce the time villagers take to carry water home, they will have more time to do other things like study that will increase standard of living.
#4 Write experiments 🧪
(Write experiments for each of your hypotheses. Experiments can be features too and their main purpose is to test the hypothesis)
- Provide bottled water in the village
- Put a pipe from the nearest river with a pump
- Build a well
#5 Define and measure the relevant metrics 🎯
(Metrics you pick should be truly representative and indicative of progress towards the outcomes you care about. Don´t pick metrics for the sake of having metrics. Stop and think. Make them meaningful.)
- Reduction in time to carry water
- Amount of leisure time
- School enrolment rate
- Adult literacy
As you can infer from this illustrative case study, to work like an outcome team, like Eve, requires a different mindset.
Delivery Dan rushed to a solution and started to measure things which were not best suited to evaluate success. Stop and think about it for a minute. Does measuring “Rate of water output” suggest any improvement in standard of living? Unfortunately it does not. If you measure the wrong thing, you will never learn what you are doing wrong, and your next steps will lead you down the wrong path.
Consider this for example: after building the well Dan discovers the living standards have not improved for the residents. What do you think Delivery Dan would do next? What would be his next move? Perhaps he would suggest that the pump is below par, and inadequate at pumping water, and we need to install a better pump. A better pump would certainly increase the rate of water output he would say, because that is the metric he is optimising for. For we already know, rate of water output does not improve standard of living.
An outcome driven team is much akin to Eve´s approach. She didn´t take the brief for granted. She stopped and thought about the goal. Instead of getting started on the idea mentioned in the brief, she thought of it as a hypothesis.
A hypothesis in science is a proposed explanation to a phenomenon. Hypotheses are based on observations and thoughts, they are not self-evident. We need to find evidence before relying on them.
Eve rewrites the brief into a testable hypothesis.
Brief: “If villagers had a well in the centre of village, they could use their time for other activities”
Hypothesis: “We think if we can reduce the time villagers take to carry water home, they will have more time to do other things like study that will increase standard of living.”
She uses this hypothesis to write a number of experiments to find evidence. Experimenting Eve, unlike Delivery Dan, doesn´t believe that building a well will increase the standard of living. There is no proof yet; it is merely a hypothesis. She wants evidence.
Using experiments which range from being very cheap and easy like distributing bottled water or putting in a pipe from the river instead of building a well right away, she tries to validate if a reduction in time spent carrying water has an affect on standard of living.
She uses metrics that have a direct correlation with the standard of living — for example “amount of leisure time” or “school enrolment rate”. When she finds a solution that does increase standard of living, she can implement it and make it work for the residents and the charity.
This way of working, also allows her freedom when all her experiments fail. Where Delivery Dan was stuck, the only suggestion he had up his arsenal was a new, fancier pump; Eve writes a new hypothesis: “We can increase living standard if more people could attend school at night after finishing their daily chores.” She will then be able to create new experiments to validate or invalidate this.
Delivery Dan, after implementing the features (the well components), will continue to add more features like better pump, fancier pulley system without ever knowing if the standard of living is actually improving for village residents because he is measuring “rate of water output” and will optimise all new features with that aim — increase rate of water output.
Delivery Dan, knowingly or unknowingly mistakes “making stuff” for making progress and mistakes building well for being done. Eve measures success using the correct metrics and will not stop until she improves lives of the residents.
I must emphasis, that Delivery Dan also has good intentions but unfortunately his methods are not the best fit for delivering customer value.
If you have made this far, another examples using Airbnb. Can you spot the difference between the two approaches? Which one would have a more positive impact on customer and thereby the business itself?
🥅 Goal: Increase number of guests on Airbnb
🚀 Team Outcome: Convince first time guests to use Airbnb
🔬Hypothesis: Travellers often judge the Airbnb based on photos and having good photos will increase the chance of bookings
🧪Experiment 1 Provide a list of local photographers
🧪Experiment 2 Send a photographer to take photos
🧪Experiment 3 Write a blog telling people how to take photos
🎯Metric: #5000 new guests/per week
🥅 Goal: Increase number of guests on Airbnb
📦 Feature: Build a machine learning tool that makes apartment photo look good
🎯Metric: #photos optimised using new tool
Tl;dr
For all matters, outcome teams could be called mission teams, impact teams — or by any other name, the name is not important, — for it is the mandate for teams which is the focus, which is to deliver value to customers, not features. Think of an outcome as something that has an impact on your customers/users. Something that you will continue to work towards over time. The solutions to deliver on this outcome will change over time.
5 steps to working like Experimenting Eve
#1 Goal you want to reach 🥅🥇🏆
#2 Write the outcome the team focus on 🚀
#3 Write hypothesis that could deliver on this outcome 🔬
#4 Write experiments and features to test hypothesis 🧪
#5 Define and measure the relevant metrics 🎯
This is my thesis on how I think we could be more like Eve and help improve the lives of our customers. They don´t care about features, they care of making progress.
Next — Reasons why feature teams struggle to transform into outcome teams (coming soon)
