Create cathedrals, not bricks.

Principle 1: An approach to team vision and purpose.

Lane Shackleton

Lane creates insightful product experiences and leads effective, empathetic teams, including the Product and Design team here at Coda.

Create cathedrals, not bricks.

By Lane Shackleton

Share this article

Share on TwitterShare on LinkedInShare on Facebook
Product Teams · 8 min read
Let’s start with a story. One day, you walk up on three people who are busy working. So you ask the first one, “What’s your job here?” And they tell you, “Well, I take the bricks from this pile and put them over there.” And you ask the second person, “What do you do here?” And they tell you, “I put the cement on top of the bricks.” And then you ask the third person the same question. But their response is quite different. With a smile on their face, they reply: “We’re building a cathedral.”
Shortly after I transitioned into product at YouTube, Shishir Mehrotra (my boss at the time) told me that story. We were in our regular 1:1 meeting, and I described how my team wasn’t motivated and delivering what I thought they were capable of. He asked what I would later realize is a profound question, “Do they have a cathedral?” I didn’t know what he meant, but after hearing him describe the concept, the analogy immediately made sense. I was driving the team from one task to the next, from one release to the next, from one meeting to the next. In a second, it was obvious to me that the team felt like they were laying bricks and not building a cathedral they cared about. So I planned an offsite with the team. We opened with a simple question: why are you here? The answers were incredibly vulnerable and insightful. Many people shared things their co-workers never knew about their careers and lives. In the days that followed, we facilitated several sessions that led to our shared vision. Our cathedral was helping remove gatekeepers (historically studio executives) for content creators, by making sure that any creator could quit their day job, do what they loved full time, and get paid for it. Years later, along with several other partner teams, we built that cathedral. Nearly 15 years later, I find myself regularly thinking about this story and it’s implications for my own role and the leaders in our company. Oh, and if you want to hear it, here’s Shishir telling the story himself.

Creating cathedrals

 Great product teams create a clear cathedrals. In doing so, the team understands how their work contributes to something that is larger, more substantial, and more ambitious than their individual activity. Some people call this ‘vision’ but I prefer the cathedral analogy for two reasons. First, the word ‘vision’ is very ambiguous. It means ten different things to ten different people. I mean, this post is about creating clarity. Second, cathedrals start from the point of view of the other humans working on the effort. You’re immediately forced to step into the shoes of your teammates and answer, “Do we feel like laying bricks or building a cathedral?” That clarifies things quickly. But how does this feel in practice? A few years ago at Coda, we were in a particularly tough and ambiguous product planning cycle. Shishir and I were trying to re-orient the company toward focusing on a different part of our broader market that cared less about all the powerful capabilities and more about simplicity. It was a big cultural change for the company. With all big changes, it’s important to start with the understanding that everyone brings their own biases and perspectives to the conversation. To use the analogy, everyone needs to see different sides of the cathedral. Some people need to know the metric, some need to see a picture of what you mean, and some people need a conceptual framework. Too often, product leaders think they can just craft a vision statement or one-pager of a product vision, and everyone will be happy and productive. I’ve made this mistake; it doesn’t work. When you start from the assumption that everyone needs to understand a different facet of the broader plan, it forces you to create a clearer set of artifacts for your team. You create a shared vision of the cathedral instead of handing people bricks.

Putting it into practice

 Here are three ideas for how you might create and clarify cathedrals for your team.

(a) Create a vision artifact showing multiple angles.

 In the story above, I talked about when Shishir and I needed to make a big change at Coda. To do that, we worked with a small group of Codans to create an artifact that created clarity from multiple angles of the cathedral at once. We knew that some people needed to see example mocks of the product, some needed to see how new messaging might look on a billboard, and some would resonate most by reading a sample blog post. Each was a slightly different lens on the same future, but together formed a three-dimensional cathedral the team could rally behind. We had the people that created each part talk through the different pieces, and spent a while answering questions live to ensure we were calibrated to the different lenses for the team. Here’s a sanitized version of what that visual looked like, and we also worked with the Miro and Figma teams to create templates for how you might do this in their tools.
View the Figma templateView the Miro template

(b) Work backwards from the desired customer experience.

 One of my favorite ways to align a team is to work backwards from the customer experience. Amazon is famous for this strategy and it works. Here’s how it’s described in the book Working Backwards.
Working Backwards is a systematic way to vet ideas and create new products. Its key tenet is to start by defining the customer experience, then iteratively work backwards from that point until the team achieves clarity of thought around what to build.
Bill Carr and Colin Bryar
Authors of Working Backwards
At Amazon, they start new efforts with their PR / FAQ process. While most companies write blogs posts and produce videos for launches these days, I find the press release mindset is incredibly helpful. It forces you to articulate the value you’re going to bring to customers, without jargon or unnecessary cruft. It’s a clear ritual to drive clarity around your cathedral. Over the years, I’ve done this ritual dozens of times, and our product team regularly writes some version of a press release. I’ve also adapted the ritual based on an observation. Most teams just write one press release, then go create 5 prototypes or do a bunch of engineering work. But, it’s much cheaper and faster to just write a few versions of how you intend to bring that value to customers. Then you can debate whether these solve the customer or business problem up-front, before doing costly design, product, or engineering work. I call this idea ‘prototyping with press releases’ and wrote more about it here.

(c) Run a team exercise to see if you’re picturing the same future.

 If you’re not sure whether your team is picturing the same cathedral, I’d start by running a short exercise to calibrate. Start by asking two simple questions: “What change do you think our team is trying to drive in the world?” and “What’s your role in creating that change?” Have everyone fill out the answer to those two questions without reading each others. Then reveal the answers and let people read each others. Here’s a template for the exercise. If you create a safe space, I guarantee you’ll have a rich discussion. What you’ll find is that you’re hearing direct answers to what your cathedral is, or what others perceive it to be. And you’ll also quickly determine if people feel like brick layers or cathedral builders. But once you’ve sketched a vision for your cathedral, how do you make it happen? You start by creating systems, not goals. More on that in an upcoming post.
Principle 2

Create systems, not goals.

Read next

Weekly insights from Lane, delivered to your inbox.

Join the Product Snippets newsletter, an informal rituals email for curious product people.

Subscribe

Related posts

Explore more stories for product teams
Principles of Product Teams

The PM role, and building product, is fraught with ambiguity. Explore proven principles used by today's best product teams to turn ambiguity into clarity.

Principle 2

Create systems, not goals. Goals with good intentions don’t work.

Run your product team on Coda.

Product teams are different — Coda fits them all.