As a design partner at GV, I’ve worked with more than 100 startups in the past 5 years. Before that, I was a design lead on teams at YouTube and Google, and an early employee at FeedBurner, a startup in Chicago.
In other words: I’ve seen a lot of design teams in action over the past decade. The people on these teams are invariably talented, smart, and hard-working.
But having great people doesn’t guarantee great teamwork.
I’ve come to recognize 8 common dysfunctions of design teams. Fortunately, I’ve also seen solutions to these dysfunctions—proven, reliable, and simple techniques that teams can use to work better together. And finally, I’ve translated these ideas into a set of mantras that capture the best behaviors of successful design teams.
“Having great people doesn’t guarantee great teamwork.”
1. The “everybody knows” fallacy
When we start a project, we assume that everyone shares the same understanding of the problem and goal. The truth is that knowledge isn’t distributed evenly on a team—everybody knows different things. Even on teams that communicate well, there’s rarely an opportunity to unpack all this knowledge for the benefit of the group.
Solution: Assemble a cross-functional team, then interview your teammates and write down what you learn.
Mantra: “Get the right people in the room.”
2. Starting with solutions
Design teams are full of enthusiastic, creative problem-solvers. Our instinct is to kick off a project by thinking of solutions right away. It’s a lot of fun, and it feels like an efficient way to work. Unfortunately, it’s not the best use of everyone’s problem-solving energy. Without a good understanding of the problem, we get solutions that are all over the map—some good, some bad, and some solving the wrong problem.
Solution: Understand the problem. Talk about your goals, metrics, and questions for the project. Map out the problem before you create solutions.
Mantra: “Start at the end.”
Research back to 1958 shows that group brainstorming produces ideas that are inferior to good ol’ fashioned solo work, but we do it anyway. We can’t resist!
Solution: Ask individuals to work on their own. Then record, vote, and combine ideas. Avoid unstructured group discussions.
“Group brainstorming produces ideas that are inferior to solo work.”
Mantra: “Individual work is better than group work.”
4. Premature commitment
In our march toward solving a problem, we’re too likely to get stuck on the first reasonable solution that comes along. Many teams explore a range of ideas, but they’ll commit to one before validating or evaluating the others in detail. In other words, premature narrowing is often the cause of premature commitment.
Solution: Create time and structure to capture competing solutions to a problem in detail.
Mantra: “Diverge before you decide.”
Groups are no good at making decisions—at least not the way we normally do it. We want everyone to be happy, so we talk and talk until we’ve reached consensus on a decision. And we let social dynamics get in the way: power relationships, seniority, loud mouths, etc. This all leads to decisions that nobody is excited about—decisions that don’t reflect a unique, opinionated perspective.
Solution: Use voting to capture everyone’s opinions, then lean on the decider to make the call.
Mantra: “Wisdom of the crowd without the groupthink.”
6. Polishing a brick
We spend way too long polishing and perfecting unproven solutions. It’s understandable—we aim for a certain level of quality before releasing anything—but it’s sadly common when we don’t have a short-term plan for testing our ideas.
Solution: Set deadlines you can’t get out of. Use a timer to keep track of activities. Create uninterrupted “deep work” time so you can really get stuff done.
Mantra: “Create time pressure.”
“Set deadlines you can’t get out of.”
7. Shaky foundation
Every promising solution is built on a foundation of assumptions about our customer, our product, and our world. And that solution represents a hypothesis that we believe is true (i.e. “If we build this it will help our customers”). But too often, design teams let these assumptions and hypotheses go untested. Instead of a solid foundation, we stand on a shaky foundation of things we believe to be true—but don’t really know.
Solution: Ask your team to list assumptions, hypotheses, and risks. Build prototypes you can use to test and validate.
Mantra: “The more we learn, the less we know.”
8. Obsessed with shipping
Shipping has achieved mythical importance, at least in our world of software products and digital services. “Ship early, ship often.” “Move fast and break things.” We’re obsessed with shipping because we think it’s the only way to truly test our ideas. It’s fun, it’s rewarding, and it gets us attention. But launching always takes longer than expected, and it’s very difficult to un-launch a product that’s not working. Most importantly, measuring a live product won’t tell us why it’s working—or not working.
Solution: Do a series of prototype-and-test loops before you commit to building and shipping something new.
Mantra: “Learn early, learn often.”
I’m willing to bet that these observations aren’t surprising to you. Maybe you’ve seen the dysfunctions cause problems for your team, or recognize the solutions from a time when your team was firing on all cylinders.
But it’s not always easy to do the right things. These 8 are common dysfunctions for a reason—they represent the path of least resistance for design teams.
One of our goals with the sprint process was to package together all of these good habits, to make the right behaviors the default behaviors. It can be hard to remember these habits day to day, but in a sprint, good behaviors happen automatically.
John Zeratsky is a design partner at GV and the co-author of Sprint. Before joining GV, he was a design lead at YouTube and an early employee of FeedBurner, which Google acquired in 2007. John has written about design and productivity for Wall Street Journal, Fast Company, Wired, and Time. Originally from rural Wisconsin, John now lives in San Francisco with his wife.