Part 1 — The Simplest Explanation to Outcome and Feature Teams
There is a lot of talk about being an outcome team or a feature team in product companies these days. But what does that mean, which one is better and why should you care?
First, let me start by trying to explain the difference between the two from my own experience in a completely different environment to product development.
A couple of years ago I moved to Oslo from London. As many of you will know, moving to another country and not speaking the local language can hinder communication and sometimes give you the sense of missing out or feeling left out.
If you have been in a similar situation, you might have decided to sign up to language course. That is what I did.
I went to my first class, excited to learn. There was a teacher, lets call him Dan and his job I presume, was to teach the language or at least help increase my proficiency beyond the status quo. That shouldn´t be too hard.
The course consisted of 2 classes per week for 6 weeks. Each class lasted 2 hours. That´s 24 hours altogeher.
I attended the first class on Monday where Dan broke down the 2 hour class like so:
At the end of the class, I was chuffed and left with a sense of accomplishment, having learnt something.
I returned 2 days later on Wednesday, excited to learn more. The lesson unfolded in a similar manner and 2 hours later I walked out of the classroom, having made some progress. This went on for another 2 weeks and I began to notice that my progress had plateaued, and each class became very repetitive. It was no longer fun. I start to doubt myself and wonder if I´m really cut out for learning another language.
When I showed up to the next class, we had a new teacher, lets call her Eve. Dan was on sick leave.
I noticed that Eve had a very different style of teaching. She organised the lessons in a very different way.
We started with a youtube video about a local commercial, followed with 20 minutes of a sitcom. Opening the newspaper, reading it together and analysing world politics.
At the end, she asked us to complete a quick feedback form, asking what we found engaging, what we felt worked and what didn´t. I left the class feeling having learnt something again.
Whence I returned to the next class, I was not entirely sure how this was going to turn out. Much to my surprise, Eve had planned a whole new lesson.
She seemed be experimenting and gathering what works and doesn´t work with her students. Her lessons varied a lot.
If you have managed to follow along this far, you will be wondering what does any of this have to do with outcome teams or feature teams. Some might have figured it out, but if you haven't, here is the approach the two teacher followed.
Delivery Dan: Sat down, realised he had to deliver 24 hours of lessons. Created a plan to deliver a lesson and repeated the same plan for all the lesson.
Experimenting Eve: Sat down, realised she has 24 hours to help people learn the language. I will try different approaches and see what works. I will try to learn from each lesson and see how I can introduce new ways to help my students learn.
See the difference between the two approaches: where Dan focused more on delivering lessons, Eve cared about helping the students learn more.
If we translate this into product development. Delivery Dan is what you would refer to as a feature team. Delivering features is the sole purpose. They ship one feature after the other.
Experimenting Eve is focused on an outcome. She cares about if her students learn the language or not. Similarly, outcome teams care more about helping their customers make progress and get value from their products. They constantly experiment and measure progress. Iterate, add and remove functionality.
Ultimately, everyone in product teams wants to help their customers get the most out of their product and continuously increase the value they provide.
So one might ask, shouldn´t everyone in product development be more like Experimenting Eve and care about outcomes?
The answer is yes, but unfortunately there are a lot of teams that are more like Deliver Dan. No one is to blame, we just need to understand how we ended up here and change our thinking. To do that we must go back in time.
Before software or software products become so central to our lives, they were primarily made for business purposes. Businesses would sell to other businesses (like Salesforce, IBM, Jira), often known as B2B.
When your focus is B2B, each customer usually has 10–1000s of users. In order to attract a new customer (10-1000s of users), you usually had to build a new feature specific to the needs of that customer in order for them to buy your product.
So the revenue graph would look something like this, where an additional feature meant more revenue.
Slowly, with the proliferation of internet and consumer (people like me and you) having more connected devices (phones, laptops, TVs, watches etc), more and more companies started to focus on consumer products. This meant a business would build a product it can sell directly to consumers— some examplar products are spotify, netflix, uber and the like. This meant instead of having a business-to-business relation, you instead had a business-to-consumer relationship, known as B2C.
The goal for most companies is to create user value, or at least enough value that the customers keep using your product and paying for it.
Where we struggled was to understand how to keep creating value and acquire new customers as well as keep the existing ones satisfied. We started to conflate value with features. The legacy from the past kicked in, where addition features use to mean new customers which in-turn meant more revenue.
Instead, the graph looks more like this. Success is now measured by value delivered to customers and not number of features delivered.
Feature teams might deliver more features than outcome teams but they don´t necessarily create more value for theie users. B2C products requires a different way of working. We need to be more like Experimenting Eve and care about outcomes. We should be focused on helping our customers make progress via our product.
To get new customers or satisfying existing ones is about simplification of our value offering, making beautiful products that are easy to use and helping customers make progress. It is less about increasing the number of features but understanding customer pain points and removing friction.
