Create systems, not goals.
Principle 2: Goals with good intentions don’t work.
![](https://sanity-images.imgix.net/production/a684a84f9a6b11129a67be9cd416b05db1f716ef-1238x1257.png?w=1200&auto=format%2Ccompress)
![](https://sanity-images.imgix.net/production/70a5d910b36a4556ee4d21d346f588ef6a55ffa9-550x550.png?w=500&auto=format%2Ccompress)
Lane Shackleton
Lane creates insightful product experiences and leads effective, empathetic teams, including the Product and Design team here at Coda.
Product Teams · 8 min read
![](https://sanity-images.imgix.net/production/793a7544bbb580cf47808c7cabe326032f661f76-1050x730.jpg?w=2000&auto=format%2Ccompress)
Jerry Seinfeld with every joke he's ever written. (Image by Netflix)
![](https://sanity-images.imgix.net/production/0b45111f6f856054c5d625ff4b323bc98d5bd331-532x370.jpg?w=2000&auto=format%2Ccompress)
One of Seinfeld's signature yellow pages. (Image by the New York Times)
Creating systems in product teams
Like Seinfeld, product teams become the systems they create.![](https://sanity-images.imgix.net/production/a507085c66f7c818cfded1ff85c4c66a13bc64be-1920x1080.jpg?w=2000&auto=format%2Ccompress)
You don’t rise to the level of your goals, you fall to the level of your systems.
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 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. My friend Phil 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.
- 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.![](https://sanity-images.imgix.net/production/a1959464f25b619a7798ea1fb27d11f6317ef527-1630x556.png?w=2000&auto=format%2Ccompress)
![](https://sanity-images.imgix.net/production/2290f7fed9c07135c7e89cc3a63f501f2757dcb9-1632x900.png?w=2000&auto=format%2Ccompress)
![](https://sanity-images.imgix.net/production/c114bcd43cea1ff6b939a6aadca4e27aa8aab0f3-1635x880.png?w=2000&auto=format%2Ccompress)
Catalyst meeting
If you’re interested in more details about how we run Catalyst, check out this template.
![](https://sanity-images.imgix.net/production/84a8241e537418e93f4d4104984d6b2740d7db8f-1096x720.png?w=1400&auto=format%2Ccompress)
Product proposal
To see real examples of product proposals that use the format above, see this page.
![](https://sanity-images.imgix.net/production/347d7dfe977d5d12d15502d5ae312a3d67e2ae17-1096x720.png?w=1400&auto=format%2Ccompress)
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 and 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. Check out the template here.(c) Create and customize your decision making systems and decision 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.![](https://sanity-images.imgix.net/production/103e8bac998a49c0e9db0be5167d0b8e951ae335-1920x1080.jpg?w=2000&auto=format%2Ccompress)
![](https://sanity-images.imgix.net/production/42800b54917b4a72191e0551daf5336437b72d8d-1280x556.png?w=1000&auto=format%2Ccompress)
Weekly insights from Lane, delivered to your inbox.
Join the Product Snippets newsletter, an informal rituals email for curious product people.
SubscribeRelated posts
Explore more stories for product teams