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

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 well I 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 py little reminder that your team needs to understand the cathedral that they're actually building because nobody wants to live bricks all day in service of nothing and you know for me it was told to me by shashir 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 Lan shakotan Chief product officer at Coda Lang 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 L well you know thanks so much for joining me great to have you here do you guys have a ritual atota 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 probably two that I keep coming back to two 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 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 as 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 with probably too many companies and a lot of times the vision is just like this one line statement this like py statement usually pretty broad but I actually really like the vision artifact you have a whole figma around this so we can just come describe that a little bit more

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 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 grock it or understand it or get on board and so you know some people need the metric and 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 kot's history where we were making a pretty significant change uh in terms of kind of our medium-term vision um and as a part of that shashir and I uh triy 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 G gave them kind of a clear 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 present it in all hands something that the team can like regularly come back to yeah cuz like if you make like you know B has or the stuff that you have in the figma like you can literally just print out and put 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 did 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 norstar experience it's like so much better than just like a oneel statement or like 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 road map 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 3 months we were kind of reviewing this type of stuff uh 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 Challen so that might be a list of 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 L 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 in 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 to forecast further ahead than you need to and so you know when we were writing quarterly okrs it felt like oh quarterly oks are great but like what happens you know on the six-month time Horizon and then if you're doing 1 and 2 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 of 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 like having like a annual road map for every quarter down to like what fat ship like three quarters from now is kind of like a myth or something yeah how do you kind of evaluate when this stuff changes halfway through like I don't know if Kota AI was like something that kind of came halfway through or you kind of plann 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 Reed 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 like a that'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 is 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 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 eval valate is a given strategy working and that tends to span 2 three four five quarters right you know one example is we're trying to make the product more approachable that is a multi-year Endeavor and so so by necessity we're making adjustments within quarters about what the highest value thing may be and that may surface as okrs but we still need to evaluate kind of the longer strategy are yeah interesting comment so like yeah I'll give you an example from Roblox it's a pretty interesting culture where like if you're working on like a bet then you're not really on the hook to move some number by 2% every quarter like the example that I got was like it's better to like not move the number at all for 3 quarters and then you know tanks number in Q4 then you move it by 2% every quarter totally so that's pretty interesting 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 so yeah so let's talk about like uh product reviews which like you know probably people spend a lot of time on like you know you've been at Google for seven years before kot like what are some drawbacks that people like traps that people fall into for car 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 often times that it highly correlated with the output itself I think some of the pitfalls in general often times 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 just it's 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 2x 3x 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 a similar or shared set of context so often times 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 what 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 and 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 I definitely saw this all the time at Google and YouTube it was 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 prws too and like a lot of times it's like you know there's like 10 exacts in the room with the CEO and most times just a CEO providing feedback and like you got like sometimes you got to do some pre-work you got to make sure like use the management chain to talk to co beforehand make sure he has the right context and there's like a lot of like time way wasted doing the stuff so I actually think like you know Koda has a really amazing process so maybe like it starts with just the schedule right like these people available so maybe you can talk about the catus schedule that you guys have yeah I think so the

idea behind Catalyst was really born out of trying to solve those problems very directly very tactically okay so first it's a frequent and pre-scheduled block of time on everybody's calendar so I have three week three hours per week on my calendar that are blocked for Catalyst slots and that means that and that's everybody in the company right that's not just me or shashir or other people so what that means is that you can always get the right person in the room right like sort of by default you have you should have no excuse to wait a month for a review because there are going to be times where you can get people there and in practice this is perhaps one of the biggest pieces of catalyst just that you can get the meeting scheduled and get the right people in the room so the other part of catalyst scheduling is that you add there are kind of three main roles there's the driver the person who's like kind of responsible for driving either the meeting or the decision there's the Brain Trust that's sort of modeled after Pixar's Brain Trust concept and then there's people that are interested and so this schedule is open to the entire company and so anyone can go in and say like I'm interested in this topic you know this may affect my job I want to be involved and click an interested button and they'll get added automatically to the calendar and so what ends up happening is the night before so say it's a catalyst slot on Tuesday the hold will be removed and I'll get scheduled for the specific Catalyst topics that are relevant to me that where I've been added as like the driver the maker of the Brain Trust and that way I have exactly what I need on my schedule usually they're very you know well-run because docs are sent ahead of time as pre-read and they're almost always run out of a written doc where I can go in read the doc get all the context and then the kind of process generally is to add both questions and kind of a written feeling about like how the proposal what you feel about the proposal and teams will use lots of different kind of clever ways to get reactions from people they might have something that says like I'm aligned on this topic I'm not aligned I have questions like there's a lot of different patterns that people use within a catalyst but that I think the key part is that you can always get people the right people in the room so the doc is sent out like a day before or like a couple days before is it's either sent out the day before or we take the first 15 minutes of a meeting it's sort of both patterns it really depends on the person and like I really like this concept of two-way docks cuz I find that a lot of the discussion can actually happen in the doc itself so like but you have this thing called a pulse check and you also have Dory talk those two things yeah I mean this is again born out of the kind of negative experience of many times at Google and YouTube sending out a doc as a pread and then trying to figure out like who's actually read the doc waiting for an BP or like a leader Avatar to show up in the dock and to figure out if they' actually read it and then you know ultimately having these like long comment threads and that were like really substantive stuff like we should cancel this effort someone makes a comment on the title of your doc that says that and then like three lines later someone's talking about you know the fact that you have a grammar mistake like those two things are totally you know opposite ends of the Spectrum in terms of feedback but they're sort of in the same modality so the idea behind what we call Dory which is named after the fish and Finding Nemo that ask all the questions is you should be able to get out your kind of like top level questions and then we should actually vote on those questions like we should get a pulse from the group on what is on people's minds and so the basically the table sorts Itself by the votes and so the top rated questions go to the top and then often the discussion will be driven from that question table and then the other aspect is I don't know if you've ever seen this but you have these comments that often are either in like the title of the doc in like a ghoul do or they're like on the last paragraph and it's the meta thought or like how I feel about the overall decision or the overall proposal or something like that and so we try to pull out the kind of like meta or overall summary of someone's feeling or sentiment on a proposal into its own table and that way we can kind of get an overall check like okay I know that you have these three issues or questions but like do you feel good about us moving forward with this or give us your specific take and this has helped in so many different ways over the years and it's so ingrained in our culture and you know first and foremost it helps people really understand what the room is thinking and feeling and so that they don't have to go do the like 2 one on ones and get everybody's individual sentiment right it's such a waste of time and so personally I'll give you like one example I had a proposal that I thought was like totally uncontroversial and so I kind of rolled out this proposal in a catalyst and I got four and five stars out of you know kind of out of a five smiley face skin from everybody and then like one of our most senior designers gave it a one and basically said like I think this is all wrong we shouldn't do this and like this person's actually quite you know is a quiet kind of personality and so if you had a typical review cycle where you had a bunch of loud people in that room discussing it like their voice would have gotten drowned out for sure but I and I wouldn't have known that they were so against this proposal unless we had something like a pulse table so they're many instances where you kind of get how people really feel about something yeah but I think that also requires a culture where people uh are open to voicing their opinion right because like you know if the designers disagreeing with you or sh share then you feel comfortable doing that for sure yeah you I mean without a doubt you have to have a culture that is like a safe space yeah

do you think just I think this is overall great do you think there's do some challenges like for example if shashir gives like a five star or like you know puts a comment in there is like do people just follow along be like hey sh you're right or people actually call him out I think people will add their feedback way before he I mean he's obviously a busy person and so he's often giving his feedback in you know right at the start of the meeting or something like that and so people will have added their feedback already in many of those cases and I don't really he's a the type of person that takes input and wants to know everybody's Real views and opinions and so I don't think people feel bad about disagreeing with him I think he also often brings a different level of context into decisions just because he's talking to investors he's talking to other Executives companies he's you know on the board of Spotify so he brings a lot of context that I think sometimes people might not have but in general I you know I think it's part of his personality to want to know if someone disagrees I think just to wrap this part up like when should a PM like actually have a product review with ref process and like do you think some of the most some of the more like controversial decisions like have more disagreement or like have more discussion yeah I think you know it's probably more art than science of when to do these I tend to be a big fan of trying to get teams to gather input early as possible so we do something that we call Brin trust kickoffs where we basically say Okay gather the people that you think are going to be integral to this effort and then the kind of failure mode to draw some contrast for a second the failure mode is you learn late in the process that shashir feels really strongly about XYZ or you learn late in the process that some customer has a big issue with the direction that you're headed right and so what you're trying to do in something like a Brain Trust kickoff is get all the context out there from the very beginning so like as a PM I want to know your worries what you think success looks like I want to know all of that like on day one of this effort so in general like I think the there's a failure mode of product reviews which is it happens at the end of the process right and so like I think what we try to do is try to go to the other side of the spectrum and say like it's not a review per se but it is a kickoff of sorts where you can kind of start to gather that input that you think can help you accelerate your effort instead of you know having to feel like you're just going through a pure review cycle and that way that when you go into later reviews you know oh you know shashir or lane or Oliver or someone feels strongly about this particular concept so we need to address that you know we need to make sure that they concern is heard so that's one facet of it which flips the idea of like a review in general and then I think the other thing to say is you know often times it's like a conversation it's is this going to impact a lot of customers is it internal teams okay it's probably worth going to Catalyst right is this going to be a reversible decision or an irreversible decision okay if it's irreversible or if we feel like it's a one-way door then like we should be more deliberate about it right and so bring that to catalyst so it's a conversation like that usually yeah I love the point about getting the feedback as early as possible maybe just like with the proposal stage because you don't want to like build a product and have strong feedback afterwards yeah the worst feeling in the world right yeah so I love how

you guys run all these processes through kod itself and like another principle you have is just like you know learn by making not talking and at larger companies you can have like how it works right like you have a prod review of like the CEO and there's like people literally spend like two months preparing for it going through like VP and then going up like how do you guys I guess code is still small but how do you guys like help the PMs and the teams stay focused on just like shipping stuff to the customer versus like a bunch of internal Optics stuff yeah I mean I think a few things to say here one is I think I'm a big believer and I think shashar is the rest of our executive teams big Believers in kind of like as much as possible decentralized leadership and what that means is people should have the leads that we entrust to lead these teams should have the autonomy to make the bulk of these decisions themselves and I think that in practice that is quite true and then there are certain things that span teams or span you know the company or customers that often need kind of like a broader set of people to take a look at and so I think the default when we're talking about smaller or less consequential to the company decisions or features Etc the default should just be like those things Shi right and like there's an internal feedback process and you can like get on that train give your feedback and the teams will take that input and like iterate with it and so that's part of the culture and then I think the other thing to say is it's a culture of makers right and so like the default orientation is like okay I hear what you're saying can you show me what that looks like or like do you have a prototype of that or can you like somehow make this experience feel real versus like yeah we can talk in circles about how great this could be one example kind of tactical example of that I think created a real uh multiplier effect was something that we call ad hoc environments so the basic idea was we especially when we were building like the formula language and tables and stuff like that it was really hard to mock out all the scenarios right you would like end up with these mocks that were like 100 figma frames long because you're trying to like detail every interaction of like when the cursor moves in the formula Builder and so one of the engineers the lead engineers at the time this guy named Chris I basically said like look I'm going to make it so that any engineer can take a branch of code and get that Branch running with a full environment behind it so full database you know full calculation engine full front and everything and so what that did in it's like sort of in its own separate environment it's not going to bring down production affect customers but one important key is it was accessible and it is we still use this it is accessible to customers and so what that means is like if you're a PM or designer or engineer you're kind of like a pod working together and you have this some idea you can actually get it up on a fully functional environment and put it in front of customers in a way that is not going to affect the rest of customers and in a way that is like pretty much as easy as writing some very prototype crappy code to do the thing that you meant and then showing that to someone right and so that was like an example where it went from okay we can't really feel how it you know what it's like to deal with the formul builder with this change on typing or this change on colors or whatever it is and once you had that you could say like just make the change push it up to an ad hoc environment and then I'll play with it and then like now we're in the cycle of like building and making and iterating right yeah and so lots of other examples but that's like one tactical example of how that principle became real yeah I love that like you

don't realize how the product feels and you actually play with it a lot of times and yeah getting into the customer hands is very possible it is also like I guess if you come to a pro review of actual customer feedback that always goes better than just like totally a bunch of aump sh right yeah exactly and I think I mean if you're in a company that is like product oriented I think the leadership team often respects that so much more right they're like oh wow you've already learned that you know customers like this aspect and don't like this aspect in that first review that's like way higher Fidelity data than you wrote what the experience could be you know what I mean like a leadership team that is a bunch of Builders is going to get really excited by that yeah that's kind of my my hack like I always try to get some customer feedback yeah and you know customer feedback is one thing that can potentially if you disree with the CEO can actually support your case yeah totally so yeah awesome where can people learn more about I mean you but also like all these great rituals and like Frameworks I think it's actually available on colda right so like where can people find it so there's probably two places one is the Koda Gallery we publish a lot of these uh templates and rituals to the Kota Gallery that's ca. gallery and then I've been writing about rituals more recently especially rituals for product teams and that's just lane. subs stack. com and then shashir is also writing kind of a broader book on rituals of great teams and this was spurred by something that we started during the pandemic which was having a bunch of dinners it started over Zoom now it's in person with leaders of all types of different teams and just hearing about their rituals and how they run their teams and so he's writing a book called rituals of great teams you can just Google that and there's kind of a Brain Trust for that you can actually read kind of an early copy of it but those are probably the three places that are we talk a lot about these Concepts great yeah thank thanks so much D for sharing this information publicly like it can definitely like help other product teams including mine so thanks awesome yeah it was helpful thank you