The 11 star framework

The 11 ★ Framework makes you think and design to the extreme and then work backward to develop a delightful and word-of-mouth worthy experience.

The “11-star experience” is a concept that Brian Chesky, co-founder and CEO of Airbnb, developed to describe the level of service and hospitality that he wanted his company to provide to its customers. Chesky believed that in order to truly differentiate Airbnb from other travel companies, they needed to go above and beyond in terms of customer service and satisfaction.

The idea is to think through what a 5-star service would be like and then extrapolate that out to 11 stars. The point of this process is that the 10 or 11-star experiences are likely not feasible but there may be a sweet spot that you can achieve.

Reflection of using it

I was participating in a workshop where that framework was used. Some reflection:

Differentiating in so many detailed steps feels too much. Especially going back from a expected experience (5) and then going to step 4-3-2-1. I would recommend to just go to 3 and 1, so just 2 steps.

When going back it actually helped to see a difference of expected experience and current experience. It unveiled areas where we are not up to an expected experience.

But what actually defines the expected experience? Unclear to me and I observed myself that I was matching it to current features available. I can imagine that this should be something one can work out with users who purchased the product.

Going upwards from the expected experience (5) also here it feels a bit too much to go 6-7-8-9-10-11 and would recommend to go 6-7 to get an insight on the imagined next level from expected experience and then go 10-11 to really have the outstanding, dream experience.

It needs anchors

For the AirBnb case one can imagine and experience, likely because the product connects well with our imagination and I can describe what a great experience for traveling looks like.

I found that to be more difficult when working with a more abstract understanding of user persona groups.

What helped me, was to define a concrete use case in detail. This is my baseline, my current experience. From their I was able to define what I want to achieve (my outcome), and what my transformation should be (in what areas do my behaviors change).

With that concrete description of my product usage and my transformation and outcome I would like to reach, I can then check how the current product supports me in reaching that outcome and transformation. And how it should be different to support me better (6-7) and to support me extremely well (10-11).

For the extremely well part … this might still be too much anchored around: I want faster horses instead of I want a car. It is tough to abstract from the current version (at least for me).

I did not do the exercise with my concrete product usage to get backwards. This might be interesting to define the essentials for my use case and detect areas that just could be removed (might connect well with Liberating Structures: Ecocycle Planning).

Linking

• [[Notes from Do things that don’t scale]]

Enjoy this post?