Proven Rituals of Great Product Teams | Lane Shackleton (CPO Coda)

This is a YouTube video titled "Proven Rituals of Great Product Teams | Lane Shackleton (CPO Coda)" containing an English conversational interview recorded in June 2024. The discussion features Peter Yang interviewing Lane Shackleton, Chief Product Officer at Coda, about effective product vision crafting, planning rituals, and product review processes within product teams. The conversation covers practical strategies such as working backwards from customer experience, creating clear vision artifacts, quarterly planning, and handling changes in strategy, with insights drawn from their experiences at Coda and other companies.
And the story basically goes, you walk up to three people, they're laying bricks. You ask the first person, what's your job? They say, well, I take the bricks from this pile, put them over here. You ask the second person, what's your job? And they tell you what, put the cement on top of the bricks over there. And then you go and ask the third person, what's your job? And they say, we're building a cathedral. And the basic idea behind this, you know, for product people, it's, and leaders, it's a pithy little reminder that your team needs to understand the cathedral that they're actually building because nobody wants to lay bricks all day in service of nothing. And you know, for me, it was told to me by Shishir in a one on one where I was kind of bemoaning the fact that my team wasn't reaching their full potential. And he asked me this question of, well, do they have a clear cathedral? And at the time I didn't have any idea what he was talking about. And then he explained the story and it sort of immediately clicked for me.
My guest today is Lane Shackleton, Chief Product Officer at coda. Lane has built some amazing product rituals that you can follow to craft a great product vision, host effective product reviews, make decisions without meetings, and ship faster. I especially love his two way write ups and catalyst meeting rituals they can put into practice right now. If you enjoy our conversation, please like and subscribe to support this podcast.
All right, Lang, well, you know, thanks so much for joining me. Great to have you here. Do you guys have a ritual at quota for crafting a vision for a product or for a company?
Yeah, I think there's, there are a few different ways to do this that have worked for us over the years and there's probably two that I keep coming back to. The first is adopting kind of an Amazon style approach where you work backwards from an end customer experience that you're trying to create. I'm generally a huge fan of the process of writing a press release as a way to anchor to the value that you're going to drive for customers. I think it really forces you to speak clearly to what the customers are going to get out of what you're doing from the very start of the product development process. And sort of one thing I like about the working backwards process in general is that it kind of works at all levels. Like it could be a feature, it could be a big launch that is, you know, a bunch of different things, or it could be as big as Like a company vision that you're working backwards from. So it's sort of a one process that tends to work well at all layers, which I like. So that's one. The second one is to do an exercise with your team. So, you know, if you have some doubts whether your team is kind of rowing the same direction, I think it's helpful to have some starting point into that discussion so you can run an exercise to see if you're kind of picturing the same vision and then use that as kind of a jumping off point to create kind of a clearer picture for the team. So you might start with a big question like, you know, what's different in the world when we're done with our work? Or, you know, what change are we responsible for driving in the world? And I think big questions like that tend to unhook a team from their current work streams and kind of like smaller day to day thinking and help them climb up the ladder of abstraction and see the forest a bit. And you can do those. Both these processes is like a part of a planning process or maybe at an offsite times when you're getting the team together to reflect. So I think those are two rituals that we have for crafting product vision that I think have, you know, kind of stood the test of a lot of planning cycles.
That's awesome. Yeah. So like, you know, I worked at probably too many companies and a lot of times the vision is just like this one line statement, this like PDF statement. Usually pretty broad, but I actually really like the vision artifact. You have a whole figma around this.
Yeah.
So you can just kind of describe that a little bit more.
Yeah, for sure. Yeah. In general, I'm a really big believer in creating clear artifacts at the end of these processes. I think way too often people leave these types of exercises and they're energized and then a week later nothing is different and, and everything kind of fades into the background or they leave with some generic vision statement that no one really believes in or can effectively, you know, tie their identity to. So you kind of have to create a clear picture of what that, you know, future might look like. Right. And I've definitely made the mistake plenty of times in my career of painting just one part of that picture, only to realize later that, you know, a key member of that team needed something different to like really grok it or understand it or get on board. And so, you know, some people need the metric and some people need the directional mock of how it's going to look to Customers and some people need the strategy paragraph that kind of like summarizes what the thesis is. So I wrote a post about this and sort of talked about a particular moment in Coda's history where we were making a pretty significant, significant change in terms of kind of our medium term vision. And as a part of that, Shashir and I tried to learn from all the past mistakes in planning. And so we created this kind of really comprehensive planning artifact with a small group of people. And it, you know, this particular artifact included, you know, what a product marketing sort of page might look like, example product improvements, what a billboard would look like, what our target customer was in this particular case, you know, all the different types of content that we might create as in service of this kind of shift in vision or strategy. And that served, I think, as an anchor for people and gave them kind of a clearer picture of what we meant. Right. And it ended up being kind of one of the most smooth planning processes we had, despite it being like a pretty large change. So I think in general, my advice in this topic is essentially don't let yourself leave these nice, important planning or vision moments without something that you can put on the wall, something that you can present it in all hands, something that the team can like regularly come back to.
Yeah. Cause like if you make like, you know, billboard ads or the stuff that you have in a figma, like you can literally just print it out and put it on the office of walls, Right?
Exactly. Yeah, exactly. And we did. Yeah.
Was it like a pretty small group of people, like a couple of designers or like, who would you work with to put this together?
Yeah, at the time it was basically the head of brand who was also an amazing writer. It was one of our more senior designers. It was a couple of the folks from the core product team and then someone from the marketing team as well.
Yeah, I think the visual stuff really brings it to life. Like even, you know, at Roblox and other companies, like having a North Star experience. It's like so much better than just like a one line statement or like a couple of paragraphs. Like people don't like to read my paragraphs, you know.
Got it.
So now that you know you have this artifact, which I think is amazing, like what kind of ritual do you have to translate this vision into? Like what to build next or like a roadmap?
Yeah, I think we generally have kind of like a strategy or annual planning nowadays. Annual planning memo. And this has changed in terms of its cadence over the years. You know, it used to be every, in the early days, it was like every three months we were kind of reviewing this type of stuff. And then as the team got larger and as the vision got a little bit more cemented, we could do it less frequently in terms of translating that. You know, it starts often with kind of a strategy memo or a vision memo. And that is, you know, try to limit that to like one or two pages. Leading up to that, there's a process that starts by identifying what are the key challenges of the business. And often nowadays our Data Insights, Data Research and Insights team comes up with all of the kind of most recent and interesting insights as a feeder to that process. And so from that we can kind of extract, okay, here are the big challenges that are facing the business. And then we can basically map the most important of those challenges. So that, that might be a list of 20, 20 things, right? And then we whittle it down to a small set, 2, 3, 4. And then we try to map those key challenges onto what are the big bets for the year. And that way there's kind of a direct linkage between the challenge that's facing the business and a big effort that is going to drive change in that area. And so once you have kind of like those key challenges and then the big bets, teams can go off and plan, you know, quarterly okrs and can give a bit of a look ahead what we call quarterly plus okrs.
Got it. And like, what is a quarterly plus okr? What does plus mean?
Yeah, it's not sort of a fancy term for a simple concept. So it starts from this idea that, you know, it's difficult to do medium term planning in environments when where everything's changing, you know, your customers are changing, what you're delivering is changing. In this world of AI, technology is changing incredibly fast. So, you know, you try not to forecast further ahead than you need to. And so, you know, when we were writing quarterly okrs, it felt like, oh, quarterly okrs are, are great. But like what happens, you know, on the six month time horizon. And then if you're doing 1h and 2h planning, it felt like we were asking teams to be too precise with what's going to happen five, six months from now, which was just unrealistic. Right. And so the idea behind quarterly plus is you commit to what you're doing this quarter. So that's the quarter part. And then the plus part is effectively take us ahead a quarter and just give us an idea of what's coming up. So if you're in Q1 planning. You commit to your Q1 okrs and then you say, look, these are the big milestones or decisions or risks or other things that we foresee coming up in Q2. We may not have all the answers right now, but you know, we want to give you an early heads up that these points in time are coming or these decisions are coming, these risks are there. And that way the team can kind of feel like they can evolve as they learn. Right. Instead of trying to set everything out six months at a time.
Yeah, I think having a annual roadmap for every quarter down to what features you'll ship three quarters from now is kind of like a myth, something.
Yeah.
How do you kind of evaluate when this stuff changes halfway through? I don't know if Coda AI was something that kind of came halfway through or you kind of planned for it already in January. But like, how do you evaluate when the market changes?
Yeah, code AI really came up in Q4 of last year, spurred by some internal teams who are starting to build some really interesting prototypes. And then our investor, one of our investors, Reid Hoffman, is very, you know, obviously very involved with AI from the beginning in terms of the question of like, how do we change these? I mean, it's a tricky question. It always depends on the situation. As an aside, the longer I do product work, the more my answer is like, it depends or it's complicated.
So that's like a.
It's a cop out of an answer, but worth giving that caveat. I mean, the kind of shorter or more direct answer would be we try to let teams make that determination as much as possible. So if they're working on delivering something, some okr and you know, they feel like the customer need has changed or they have a higher value item that they should work on, like they have full agency to say, hey, we canceled that OKR and we have, we wrote ourselves a new OKR in the even within the quarter and that, that does happen. And then I think the other, you know, that's some mix of like the OKR itself and the strategic principle or like what changed in the strategy to change that okr. So it's a little bit hard to decouple those two things. I think, you know, the way that we tend to do strategy over the longer arc is we're trying to evaluate is a given strategy working. And that tends to span 2, 3, 4, 5 quarters. Right. You know, one example is we're trying to make the product more approachable. That is a multi year endeavor. And so by necessity we're making adjustments within quarters about what the highest value thing might be. And that may surface as okrs, but we still need to evaluate kind of the longer strategy arc.
Yeah, that's an interesting comment. So I'll give you an example from Roblox. It is a pretty interesting culture where if you're working on a bet, then you're not really on the hook to move some number by 2% every quarter. The example that I got was it's better to not move the number at all for three quarters and then tanks number in Q4, then you move it by 2% every quarter.
Totally.
So that's pretty interesting.
Yeah, yeah, yeah, I like that. Yeah. I mean, I think in general, like if you're going to hire really smart people, you have to trust their intuition. You know what I mean? And so too much management of the how in that sense can often get in the way of some really clever solutions to problems.
Yeah. So let's talk about product reviews. Which product people spend a lot of time on. Like, you know, you've been at Google for seven years for quota. Like what are some drawbacks that people like? Traps that people fall into for product reviews?
Yeah, there are a lot of these and I think it's. I think in general people don't pay enough attention to how the work gets reviewed because I think oftentimes that it highly correlated with the output itself. I think some of the pitfalls in general, oftentimes you just start with the wrong people. So the number of times that I've been in product reviews where someone says do we have this person? Shouldn't they be here? Is probably too many times to count. The other one that is debilitating for velocity of a product team is this. It just takes too long to schedule. So this happened a lot at Google and YouTube where you'd have a review and it was a month out and you'd start preparing for the review and then by the time that you actually got to the review, the thing that you were wanting to talk about had like either shipped or, you know, you could have made 2x3x faster progress if you just had the review that week. You know what I mean?
Yeah.
Which is insane. But like it's the reality of busy people with busy calendars. I think the other one is review meetings starting without similar or shared set of contexts. So oftentimes you'll start a review meeting, someone will dive right into a deep topic and no one who's deep on that topic wants to go through 10 slides about the background Right. Like they want to get into the discussion. But you have three or four people in that room that really need that context in order to give input, which you're asking them to do. So starting with kind of like shared context is I think is essential and it tends to be easier to do in my opinion, in a written doc form because you can just, you know, write some background or context and collapse it. If people already know that, they can just not read it. And then I think the other one that's kind of classic is getting a meeting kind of co opted by the highest paid person in the room, the loudest person in the room. I definitely saw this all the time at Google and YouTube. It's a very common pattern. So yeah, we've spent a bunch of time thinking about how to work around these issues.
Yeah, like, you know, like I've had a lot of problems too and like a lot of times it's like, you know, there's like 10 execs in the room with the CEO and most times it's the CEO providing feedback. And like you gotta like sometimes you gotta do some pre work, you gotta make sure like use the management chain to talk to the CEO beforehand, make sure he has the right context. And there's like a lot of like time wasted doing this stuff. So I actually think COLA has a really amazing process. So maybe it starts with just the schedule. Right. These people are available so maybe we can talk about.
More from Peter

Dropbox VP's Best AI Workflows to Help You Take Back Time at Work | Morgan Brown

Canva Co-Founder: The AI Playbook Behind the World's Most Popular Design Tool | Cameron Adams

How OpenAI's Head of Business Products Uses ChatGPT to Save Time at Work | Nate Gonzalez

Complete Vibe Coding Tutorial: Build a Full Stack App in 30 Min with AI | Matt Palmer (Replit)

Complete AI Course (2025): Prompting, Evals, RAG & Fine-Tuning | Adam Loving (Meta)





