Shared language and visualizing to deliver great products

*Football is an environment with changing variables that players and coaches need to react to. Teams attempt to move the ball down the field by running or passing in a set number of plays.

*If you’ve ever watched a football game you will see coaches holding a subset of plays from the coach’s playbook they think may work for the game they are playing. This lets them make decisions in the moment. A coach may have 1,000 plays in the playbook, but will only use a fraction in a game situation. And each team may have a different playbook.

At Zalando, we came across the idea of creating playbooks for building products in a great article by Jon Lax. We also spotted the nice application of it at Typeform.

What is “a play”? *A play is an agreed upon set of actions the team takes in a given situation. When the coach says “let’s run Statue of Liberty Buck Sweep” everyone knows what that means and knows what they need to do to execute that play. A playbook is the collected knowledge of a coach or team on “HOW they do what they do”.

*It inspired us to make a playbook of how we build products — how we go from identifying value opportunities, delivering solutions, iterating or dropping on them.

*Anything you do that has some repeatable action is a play.

*Visualizing our product development like this helps us highlight the emphasis we put on keeping things simple. It helps to demystify and push people involved in product related tasks, and lead to continuous improvement.

Equal importance, it forces us to name our play which helped to create shared language:

• We provide some definition of the name as much as we can to make sure everyone understands what it means. A play called MVP could have a lot of meanings.
• Clarify the situations when to run a play. While most plays could be run at any point in a product’s life cycle most plays are most effective in a certain situation; big bets require extra scoping efforts ,  quick wins go straight to design kickoff , spikes are recurrent and ensure continuous discovery ,  running loads of AB tests in pre product-market situation may not be best for us, etc.
• Also, why is this play the right one to deliver value to the team?

Let’s take a step back, and go through the playbook pillars:

• The 4Ds
• Getting real
• The 50% rule
• Learning loops

🖖 The 4Ds Maybe you believe the Customer Journey map method is best, the Double Diamond, the Hooked model, the six-weeks cycles or the Lean Canvas.

It doesn’t matter.

Plays can be grouped anyway you want. Simply organize your plays to map into the each of the phases.

At Zalando we commonly use the 4Ds framework: Discover, Define, Design, Deliver.

Every team member contributes to “Discover” which leads to richer ideas and involvement.

The simplicity of the framework helps us ship early to the customer ,  the only validation we ultimately seek. It ensures we develop great customer experience while ensuring business impact.

**📱 Getting real

This mantra is inspired from the essay, Getting Real of 37 Signals.

*Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing.

Getting real is less. Less mass, less software, less features, less paperwork, less of everything that’s not essential.

Getting Real is staying small and being agile.

*❌ Things we don’t do:

• Timelines that take months, version numbers roadmaps that predict the perfect future
• Functional specs scalability debates
• Endless preference options
• Proprietary data formats
• The “need” to hire dozens of employees
• Ask users with hypothetical questions, instead we ask to complete tasks

** ✅ Things we do:**

• Less meetings, less abstractions and less promises
• To launch on time and on budget, we avoid throwing more time or money at a problem, instead we scale back the scope
• It’s better to make half a product than a half-assed product
• “Just-in-time” thinking
• Multi-tasking team members
• An open culture that makes it easy to admit mistakes
• Basic documentation which makes clear what we do and includes people
• Dead simple prototyping

*🎨Prototypes often start on a notebook

*Overall, less mass lets you change direction quickly. You can react and evolve. You can focus on the good ideas and drop the bad ones.

🌗 The 50% rule We believe that for any business to succeed, you’ll need to achieve 3 things:

• a viable product/service
• a large enough market
• and a way to reach to your customers

As described by Gabriel Weinberg in Traction: *Startups often spend most their resources developing their products; By the time they realize they need to get more customers and try to ramp up their sales+marketing efforts, they’ve run out of money.

*This is why from the onset, we spent 50% of our time on product development and 50% on traction development. We can’t predict which traction channels will work; the only way is to test them.

To keep on the 50% rule, we share ‘simple’ documentation about what we are planning. This ensures alignment and makes it clear what we are trying to achieve.

💫 Learnings loops At the core of our product DNA is collecting and sharing learnings. The 4Ds cycles foster learnings inside the team and reinforce our plays.

4Ds cycles are our “learning loops”

To ensure learnings circulate, we have three (internally) public initiatives:

• A team newsletter to highlight the achievements ,  but also the failures ,  from the past six weeks
• A team website where are documented the features and AB Tests hypotheses and results
• Real-time funnels to monitor the impact of each change , being traction or product

Learning loops are what keep us ahead of competitors. They enable us to iterate or pivot based not only on instinct but also on data. They ensure we ultimately ship in the right direction 🚢

Conclusion

• The product playbook is a powerful way of explaining our underlying thinking.
• Thinking in terms of a play book provides a shared language and visualizes how we do things. It crystalizes a common understanding of how we build products.
• It allows us to embrace continual improvement: we remove old plays and continuously add new ones through learnings loops.
• It ensures our team dynamic: we look in the same direction and move forward against clear business goals.
• To an extent, it helped to build our relationships.

The product playbook template. It’s yours to make a copy and adapt it 👌

We're hiring! Do you like working in an ever evolving organization such as Zalando? Consider joining our teams as a Frontend Engineer!