Great Products Don’t Happen By Accident
Using playbooks for designing and building products
These are the slides and speaker notes from a presentation I gave on July 21, 2016 at the Design & Content Conference in Vancouver, B.C..
I’d like to start be asking you a simple question. How do you do what you do? Bad grammar and alliteration aside. That is to say, what actions do you repeatably and consistently execute to do the thing you are best at?
While you think about that I want to tell you about my experience answering this question.
I started making things on the Internet in 1994. I survived the first wave of the Internet where I had worked on too many awful PM driven projects that were so burdened with process they had no ability to respond to the fluidity of making software.
Requirements documents created on day 1 were irrelevant on day 2 but the process dictated a complex protocol to undo something that had been agreed to on day 1.
Change management was so painful it was avoided at all costs. So you worked on a project that had mistaken assumptions on top of bad decisions. This led to massive design and technical debt crippling products and projects before they were even launched.
The prevailing document on projects at that time was the Gantt chart, which seemed to be the only output of Microsoft Project. If you lived through this era, you probably remember entire walls being covered with the project’s Gantt chart.
Gantt charts show the streams of work and their interdependencies. When you hear people talk about Waterfall processes, they come from this method of working. The chart visually creates a “waterfall” as work stream dependencies are visuallized… also the name of TLCs greatest song.
The chart is named for Henry Gantt a turn of the century manufacturing manager turned management consultant who believed in the methods of Scientific Management. Scientific Management, also known as Taylorism, is a theory of management that analyzes and synthesizes workflows. Its main objective is improving economic efficiency, especially labor productivity. It attempted to maximize economic efficiency in factories and shop floors, by minimizing waste caused by inefficient workers.
The work of Taylor and Gantt was widely discredited and largely abandoned by the 1930s. The theories were so dehumanizing and morale crushing for workers, the implementation were failures.
Scientific management relied on embracing the notion that there was “one best way” to perform a task. It believed that through scientific measurement you could determine the most efficient movement of workers (e.g. the best way to shovel coal) and then prescribe this movement to all workers.
The inherent flaw to Scientific Management was that it did not have clear methods for dealing with technical innovation or continual improvement.
Despite its failure, some parts of Scientific Management survived into modern times, two notables are the use of hourly billing and the Gantt chart.
When I came face to face with Gantt’s handiwork in the mid 90s, it was already 80 years old, a relic conceived for the efficient production of pig iron and gun powder being applied to the creation of software and design.
But by the early 2000s, cracks were beginning to show in the purist methods of building software. The rise of open source software and low cost hardware intersected with the bubble pop of the dot coms.
While not directly to blame, it is clear now that many of the first generation Web companies failed because of how they were building their products. Adopting purist approaches to software development on top of monolithic hardware software stacks that buckled under their own weight. Venkatesh Rao equates this to a predictable failure pattern that was eroding all industrial age models of production, distribution and sales.
By the mid 2000s a new breed of companies rose up using new, more agile methods to build their products.
Much of this shift and can be credit to a group of 17 software engineers, who in 2001, met in Snowbird Utah to discuss lightweight development methods.
They agreed to and wrote down a set of values that would come to define what we now call Agile.
These values put a heavy premium on change and adaptability.
Around this same time, on a parallel path, some of us in the design community were coming to similar realizations as software engineers. Very slowly we stopped generating reams of documentation like 200 page wireframe decks and static mocks, instead seeing huge value in the creation 0f working software and iteration.
The 2000s saw technology shortening business cycles and increasing disruption of traditional business models. As technology moved distribution costs close to zero, the importance of speed and agility were no longer a competitive differentiator for businesses but essential for business existence.
By the late 2000s Silicon Valley companies were claiming that even failure was welcomed as long as it came quickly. Agile methods uncovered failure quicker and therefore superior.
The public failure of healthcare.gov seemed inevitable to anyone who worked in tech. The site, which had been developed with the stalwarts of industrial age methods and companies (government contractors), had to be saved by the new guard of builders who brought methods popular in Silicon Valley and startups to Washington.
This failure serves as the symbolic end of a struggle between two opposing world views. In this struggle, the debate seemed settled with pragmatic, agility winning over rigid methods.
It is inside this environment that we have sacrificed “process” to the agility gods.
Process has become a proxy for the old methods and the enemy of progress.
Since we value agility our technology and tooling has increased to enable us to pursue it. These same products and enabling technologies have accelerated the decline of structured methods of building software. And these tools are amazing. They unlock our creativity and help us build solutions that hopefully improve lives.
But we’ve become an industry that spends a lot of time debating the relative merits of one Javascript framework or prototyping software versus the other. We endlessly discuss if designers should code and if so what language should they learn.
We’ve become obsessed with speed, agility and how to acquire it.
While I believe in rapid iteration and validation…
when speed becomes the ONLY thing we talk about, it is bad… really bad.
When we stop and ask “how do we do what we do?”. We don’t really have good answers. We tend to respond with what tool we use. Ask a designer how they design and they will usually answer “In Sketch”.
This is like asking a master carpenter how they built that piece of furniture and they respond with “a hammer”.
So let me go back to the question I asked at the beginning… “how do you do what you do”?
I’ve become a little obsessed with this question over the past few years, I am interested in the response so I ask a lot of people this question and the most common answer I get is…
“It depends” is a terrible answer. But it feels good to say because we exist in an industry that values rapid iteration and changing its mind. It depends preserves option value.
Think about hearing “It depends” as an answer to questions, what you would take away?
Q: Captain, how do you fly your plane? A: It depends
Q: Dr. how will you perform today’s surgery? A: It depends
Q: Do you love me? A: It depends
There are two problems with answering a question with “It depends”.
First, it implies you have no conviction that you know how to do what you are great at. It means that you haven’t detected any discernible pattern that repeatedly delivers a successful outcome.
Second it isn’t true. There are a whole set of things you do, instinctively; to solve problems, write, design, research behavior, collect and analyze data. You just haven’t codified it by identifying the consistent patterns that exist.
Before any debate or discussion on process you need to agree that the work we do isn’t fatalistic. You must believe that creating products or whatever you do, isn’t just an invisible hand but instead something that can be achieved through intentional repeatable actions and frameworks.
This isn’t to say that luck or timing aren’t variables but that they aren’t the only variables. This isn’t to say that a process guarantees success but that it biases you towards it.
If you believe that the only way to find product market fit is to throw a lot of stuff against the wall and hope something sticks then it is difficult to discuss or debate intentional methods.
If you believe it is all chance. Then you might as well start every project with a dream board. You are saying The Secret is a worthwhile operating philosophy. If you believe this, any discussion of process is a waste of time.
I don’t believe this. I don’t believe it is random. I don’t believe that this all an accident. I believe that great products don’t happen by accident.
How many of you are familiar with this? It is part of presentation that Spotify uses to explain how they implement Agile. Whenever I begin to talk about being more intentional about how we build, it is the most cited example about why not to be rigid.
There are two problems with this diagram.
- While the diagram is a great simplification of iterative design I don’t think if you want to build a car you first build a skateboard. It assumes that there is some clear evidence or data that tells the team that the motorcycle can or should become a car.
- The second problem is that we never seem to talk about the next slide in the presentation…
The other slide that people talk about less is this one, the one that says there needs to be some sort of plan for how you do what you do. Rough adaptive architectures are what take us out of the realm of vision boards.
But what are rough adaptive architectures?
Rough architectures are a set of boundaries we use to guide us in dynamic environments.
In improvisational music the rough architecture is tempo and key. As long as the musicians don’t violate this architecture and listen to each other, they can create endless music.
In improvisational theatre the rough architecture is a set of rules like… say “yes, and”, “add information after the and”, “Avoid questions”.
If you ask an comedian how they improvise, their answer isn’t “be funny”, They will tell you a set of rules to follow… that allow them to be funny.
The best rough architecture I’ve found for building products comes from…
Football.
Football is a dynamic 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.
For our purposes that is all you really need to know about football, is that its rough architecture, besides the rules, are plays.
Both the offense and the defense run plays to try and win the game.
It would make no sense for a coach to pre determine, every play in order they will run in a game before stepping on the field since they don’t know how well each play will work.
It would also make very little sense for the players to just do whatever they felt was right on the field. Some level of coordination and collective agreement is required to win the game.
Over the course of a coach’s career they will create and inherit hundreds, if not thousands of plays. These are collected into playbooks. If you’ve never seen a football play, they look like this…
It doesn’t really matter if you understand that in this play the tackle blocks the defensive end or that are three receivers on the wing. It is more important to understand the architecture of 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.
In our world when you say “let’s build an MVP” does everyone know what that means? Do we each understand our role in executing that play?
If you’ve ever watched a football game you will see coaches holding laminated cards.
These cards are a subset of plays from the coach’s play book they think may work for the game they are playing. This lets them make decisions in the moment. A coach may have 1000 plays in the play book but will only use a fraction in a game situation.
Game cards outline available options for different scenarios they might encounter in a game. For example, 3rd down plays, 2 minute drill, kick off plays. These plays have been created over a career of coaching. A playbook is the collected knowledge of a coach or team on “HOW they do what they do”.
I believe we need to create playbooks for building products. We need to have a set of plays we can go to so we can build better products smarter and faster.
Building a play book of HOW you build products is essential for every company but missing for most.
Having a consistent format to document plays is important for a working play book. Plays are similar to recipes where they have a standard format (ingredients, procedures, tools) that make it easy to read a set of recipes and understand them.
Your play book should also have a consistent format. While you can create whatever template you want, here are some things that you can learn from football plays.
Name your play — names of plays will create shared language. Make sure you provide some definition of the name to make sure everyone understands what it means. A play called MVP could have a lot of meanings.
When to run — define the situations when to run this 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. Running a post-mortem or after action review too early in the product may not be best, just like kicking on second down isn’t a great idea.
Why to run — if the team runs this play well, what can they expect? Why is this play superior to other actions the team could take or what advantage can the team hope to achieve through this play?
Roles — outline what roles exist for the play and what to expect from different people
How to run — outline the steps of the play. What repeatable actions do you do to run this play.
Pro tips — anything the team should know or resources they should read.
I see a lot of teams at Facebook running this play. Design Sprints.
Design Sprints are a play that you can call at a specific part of the game you are playing to gain progress. They have a set of discrete and defined actions you can run to achieve a desired outcome. They have repeatable steps.
Design Sprints are 5 days they have prescribed actions and roles. While each Design Sprint is different it has an architecture to follow. Design Sprints work best at the early phases of products but can be run at any time in the product’s lifecycle (they work less well as you move towards launch).
Content maps, prototypes, internationalization, audits, launch plans… they are all plays. Anything you do that has some repeatable action is a play.
There are plays you may use a lot…
… and some you use infrequently.
Thinking in terms of a play book allows you to to embrace continual improvement since you can always remove old plays that no longer work and continuously add new ones as they are created. Playbooks only require teams to use the plays that work for them in their situation.
Plays can be grouped anyway you want… maybe you believe the Stanford D-Schools design thinking method is best. Organize your plays to map into the each of the phases.
organize around more a phased deployment model
Plays can be grouped by disciplines
or situational. These are situations that teams we know teams will find themselves in, and here are plays they can run that have worked in the past. So if your trying to validate an idea, here are plays you can run, if you are trying to prioritize or determine what to build first, here are plays you can run if product isn’t working.
So the next time someone asks you How do you do what you do… you can show them your playbook.
