Principle #2: Create Systems, Not Goals
Goals with good intentions don't work.
Quick note: for new subscribers, welcome! Today’s post is the second principle in a series of posts on my 7 Principles of Great Product Teams. If you’re interested in reading the first in the series, check it out here, ‘Principle 1: Cathedrals, Not Bricks.’ I’m thrilled to have you on this journey, would love to hear any topics that are top of mind for you.
I’ve always been fascinated by comedians. Maybe it’s because they often have an intuitive understanding of the world, and aren’t afraid to say it. If you think about it, it’s such an insane profession. Somebody hands you a microphone, then you stand-up in front of a group of strangers for an hour, make them laugh, and ideally create an almost hypnotic effect on a room full of humans.
Jerry Seinfeld is one of the greatest comedians of all time. In 2002, after ending his namesake show Seinfeld, he did what no one expected him to do: he aired a live HBO special, telling the audience that this was the last time he was using any of that material. No comics abandon their time-tested jokes like this. He threw away a huge body of work that had made him famous and started over. Imagine the pressure of being one of the funniest comics ever and discarding the comfort of all your past success. Even his close friends and peers were surprised.
So what’d he do next?
He used the same system that he’d always used. Write for an hour every morning. Perform the material several times during the week. Write for an hour every morning, perform the material. Write, perform, write, perform. The documentary Comedian has footage from this time. It’s amazing to watch him use this system to build up five minutes of good material, then 10 minutes, and 20 minutes.
What I love is that it’s all a struggle for him. It shows how hard and messy the process of making can be. He bombs, he’s uncomfortable, he gets down on himself. But he struggled within a system that he created and one that he knew would reliably produce the results he wanted. Eventually, the system worked. He built an entirely new hour of jokes that made audiences around the world laugh non-stop. He had a goal in mind, an hour of new material, but it was the system that got him there.
Creating systems in product teams
Like Seinfeld, product teams become the systems they create.
Over my career, I’ve found that teams with good intentions and good goals often fall short of achieving them. Why? Because there is no system in place. I’ve made this mistake myself plenty of times. Nowadays, when teams are presenting their goals, I often think about this quote from James Clear in the book Atomic Habits.
You don’t rise to the level of your goals, you fall to the level of your systems.
I’ve found this to be true of even the most capable teams. Want to talk to customers regularly? Great, show us your system for that. Want to create cadence of regular experimentation? Great, show us your system for that. Want to improve the performance of your product? Great, show us the system that creates those incentives and conditions. The ideal state is when goals become inevitable because of their corresponding systems. Good will and good intentions aren’t enough.
Create the system that reviews the work
We don’t have the right people here for this discussion... We don’t have enough context to make this decision... We’re just listening to whatever the CEO wants...
Have you ever felt this way in a product or other review meeting? If so, you’re not alone. One of the most common topics I discuss with peers is how product work gets reviewed and how to improve that process. There are six issues that I’ve experienced and found to be very common across other companies:
The review meeting takes too long to schedule. As my friend Phil Farhi says, ‘Decisions happen at the speed at which you can review the work.’ Too often, decisions are tied to a discussion in a meeting, and that meeting takes too long to schedule.
The review meeting starts with the wrong attendees. A topic may include one function like Engineering, but not another, like Design. Or, a topic maybe heavily debated and decided upon in an executive meeting without the people who are deeply involved in the project.
The review meeting starts without clear, shared context. The people deep in solving a problem don’t provide enough broader context for the audience to understand and come along on their journey.
The meeting gets co-opted by the highest paid person in the room. The CEO or a member of the executive team asks all the questions or takes up all the air-time with their opinions. The hidden downside is that important considerations or concerns don’t get raised.
The group un-intentionally stalls the team asking for feedback. The team is bombarded with feedback at all levels. Big questions on the overall strategy alongside small nits on the detailed proposal. In the worst cases, no one helps parse which feedback is important to act upon, and on what timeframe.
And finally, the review meeting didn’t need to happen in the first place. The team spends valuable execution time where they already had alignment or support to keep moving.
If you can design a product review system that avoids these problems, you’ll likely create more impactful product improvements at higher velocity.
At Coda, we’ve learned from our mistakes and carefully created a handful of rituals to prevent the problems above from happening. The one people ask about the most is our meeting system for reviewing work, which we named Catalyst. The core components of the system are:
Frequent, pre-scheduled blocks of time. It’s a one hour calendar block that happens three times per week. It’s intentionally frequent enough so that teams never have to wait more than a couple days to get on the schedule.
Blocked for everyone, means anyone is accessible. The time block is for everyone in the company, which means that you can ensure you’re able to get the right people in the room. If there are no topics, the calendar holds are released and people get that time back.
Run out of a written doc, not a presentation. Inspired by Amazon six-page memos, we ask the meeting driver to deliver the content in the form of a clear, concise writeup. That way, everyone can read, understand and we can get to the discussion. The alternative of sitting through a presentation feels very inefficient. I’ve written more on this topic in another post called Two-way writeups.
Docs or writeups are mostly sent as pre-reads, or time is scheduled to read. These writeups start with clear context and framing on the problem or decision, so that everyone starts from a common understanding.
Overall feedback is written and structured by the team to make progress. The driver of the meeting, often a Product Manager or other leader, will ask for overall feedback that is required for the team to make progress. Said differently, we ask that the person asking for the review is very clear on what they need from the audience, and that they gather feedback in a way that makes that process expedient.
Discussion topics are added by participants and voted on to prioritize. When we’re in the meeting, it’s important that we use the time effectively. So we ask the audience to add their questions, then ask everyone to upvote which questions we should discuss. That way, we’re spending the time on what the audience thinks is most important to discuss.
Here’s what that looks like in practice. Below is the Catalyst schedule for what topics are getting reviewed.
Here’s an example of a team gathering structured feedback that will help them unblock progress.
And, here’s an example of a question voting table, where we’re upvoting the most important questions.
If you’re interested in more details about how we’ve adapted our Catalyst ritual to solve the most common review problems, checkout the template. And if you want to see real examples of product proposals that use the format above, see this page. If you have other ways that you’ve solved these problems, I’d love to hear about them in the comments!
Putting it into practice
Here are three other ideas of how to create systems within your product team.
(a) Create a low-friction system for distributing key updates.
One system that creates a proactive and continuous communication system is Lyft’s status updates system. It’s a consistent way for people to create and consume updates on three key dimensions — progress, plans, problems. I love that it helps increase serendipity through concise communication in distributed teams.
(b) Create a central place for every customer facing launch.
Create a clear single source of truth for everything that is in beta, experiments and launching to customers. We modeled ours after a much larger and more robust system at Google called LaunchCal. Our’s is flexible and lightweight and automatically sends Slack summaries of what’s launching and when. Checkout the template here.
(c) Create & customize your decision making systems & docs.
When Zac Hays started as the CPO at a new company, he realized the team wasn’t making decisions fast enough. So he rebuilt a concise decision making process and centralized it in one place for the company. The company sped up their decision making, while moving 90% of decisions to getting resolved asynchronously instead of requiring a meeting. You can read more and use the template here.
Next
In the coming weeks, I’m excited to publish principles 3-7!
👋 This little newsletter experiment is just getting started. So if you enjoyed this post, I’d love it if you subscribed and shared with a friend. Have a wonderful day! ✌️
Note: we also published this on the Coda blog.
@Lane, would you mind re-sharing the catalyst template? It doesn't appear to be working. Thanks!