Live from SaaStr Annual 2022: Product vs. Engineering: How to Align Two Teams Infamous for...

Please welcome amplitude executive vp of engineering shadi rostami, slack svp of engineering platform, rukmini reddy and coda co founder and CEO shishir marotra.

Pick the right seat.

I know. Make sure you put on the right seat.

See? All right. Hi, everyone. Hello. So fun to be outside for these.

Yeah, it's actually very exciting. I was telling that, you know, when you're inside, the light is in your face and you don't see the audience. Here I can actually see people. It's very exciting.

All right, so welcome to Saster. Welcome to our sure to be fun and interesting panel. We're going to talk about product and engineering. I think it's a really fun topic that these two roles often have some built intention. But I think we'll have three really interesting experiences on why it doesn't have to be that way and why this can be a really awesome partnership. So we'll start with introductions and maybe Shadi, you can go first. Tell everybody who you are, where you came from, and maybe something people don't know about you. Sure.

Hi everybody. I'm Shadi. Currently I'm SVP of Engineering at Amplitude. I. I was born and raised in Iran. I went to undergraduate there, then I left Iran, went to Canada to graduate school, got my PhD. And then after that I had to decide, like a lot of other students, whether I want to stay in academia or go to industry. And I decided, no, I'm impatient and I like to build things, so I should go to industry. So I started as an engineer, became an architect, and eventually decided that I want to go to manager track. Prior to Amplitude, I was a VP of Eng at Palo Alto Networks and I've been at Amplitude for three and a half years. Something interesting about me? Oh, actually I can say one thing because we're talking about that you have to be fun. You have to get the audience in the first five minutes. And what fun can I say? I actually have three citizenship, so I'm Iranian, Canadian and American. And my partner is French. So if I want to collect citizenship, I can marry him and maybe get another citizenship. But I have twin daughters who are 18 years old, they're girls and they've all right now left home. I'm supposed to feel bad, but I feel good. I don't feel guilty. They're in college and they're having fun. And I'm having fun too. And they're both studying computer science.

Awesome. Hi, Rukmini.

Hi everyone. I'm Rukmini. My pronouns are she herself, SPP of Engineering Slack platform I am also an immigrant. I began my life in India and moved here 20 plus years ago. Was an engineer, still an engineer, I think I can count myself as one. And about over a decade ago I made the move to management and like most ICs who are first offered their management job, I went through all the stages of grief letting that go. But now I feel like I truly found my stride. I've been at several enterprise SaaS companies prior to Slack, which I joined in the midst of the pandemic. Really scary thing to do, be a new executive where you can't see anyone in person so you have to be extra enjoyable on Zoom. So I mastered that in the last couple of years. Interesting facts About Me I also have twins and I can't wait for them to leave home so I'm jealous of Shadi's situation. And also something fun. I played baseball in India growing up and there was one time we came third in the entire country. What people don't know is there were only three teams. So nice to meet you all.

Hi everyone. So I'm Shisha Mehrotra and I'm the CEO and co founder of Coda. We make an all in one doc for teams. Before starting Coda, I was at Google for a number of years, responsible for the YouTube group. Before that I was at Microsoft for a number of years and started my career with my first startup Centrada, which we started out of school. And I think in this group I run product teams, engineering teams and so on. But I think I get to be the product person of this panel so we'll see how that goes. The fun fact about me I have two daughters as well, 16 and 13, and I coach their LEGO robotics team. They've made world championships four out of the last six years, which is super fun. If you want to know anything about legos robotics, I have a garage full of every type of Lego you can possibly imagine and we've probably built everything you can think of. Happy chat about that. Also a great way to learn about teamwork, watching kids do it. Okay, so that's a great round of interest. We talked a little bit beforehand to try to divide this up into a few interesting topic areas.

Before we go to the topic, let me just say one thing. Sorry, he's the product guy, I'm the engineering and we have to make sure that we work together. We're trying to find something in common and say, oh, our kids have gone to the same elementary school so we found something in common. So hopefully we won't fight on the stage.

I'm not going to referee whatever that.

Is the right starting point for a relationship. Okay, so we picked a few different topic areas. We'll try to run through these and leave a little bit of time for questions if people have other topics you want us to talk about. But I thought we'd start with the basics. You have product teams, engineering teams. We'll get to behaviors and rituals and so on later. But let's just start with structure. How do you structure product engineering teams to maximize the chances of that relationship working? And maybe, Shadi, you can start.

Sure, yeah, I can start. Actually, before starting, I'm going to say one thing that is very, very important and close to my mind. One of our important principles that we have, engineers, that engineers own product experience. That sentence basically tells us that engineer is not just about, I just build it to the spec. I own the product experience. I'm solving customer pain. I've heard people talk about the product. People think about the what and why. An engineer think about the how. I don't agree with that. Engineers and product own the whole thing. They own the what, why, and the how. Of course, people have different expertise, they delegate different things, but they own that entire thing together. And one of the things to basically make sure that happens in the organization is set the right structure, to basically set the right structure so that they can collaborate. They're aligned, they're measured the same way. So what we do actually at amplitude, we follow the model of a two in a box or two in a box with a designer. So I'm, I'm head of engineering. My counterpart is our chief product officer. And we own the entire product. If our product is good and selling and customers are happy, we take the credit. If our product sucks, we take the blame. We both own the whole thing, and the same thing goes down in the organization. We have a pillar structure. And the head of each of these pillars is a product manager, an engineering lead as well as a design lead. And they own it together, they're measured with the same outcome. So for example, one of our pillars, amplitude, builds product analytics. And we believe product analytics is a team sport. So companies who are using product analytics needs to collaborate with each other. Employees in those companies need to collaborate with each other. And one of the area of our focus of our product is collaboration. So that team, their metric is weekly. One of their North Star metric is weekly collaborative. So their goal is to increase that number, but that's the entire goal. And of course, they're delivering feature. They're doing slack integration and so on and so forth to make that happen. But at the end, they're measured with that outcome. Were they able to move that? It's not that, oh, we delivered the feature, and if the metric didn't move, that doesn't matter. You know, you have to go back to the drawing board, figure out how we can improve the feature or what other things that we can do. But they have the same goal, and they're measured on that goal. And so if you structure the team that they both own the same outcome, and then they kind of help them to find a common ground so they can collaborate because they both have the stake in it to make sure that successful.

I think it is the most important basic thing to start with. One, whenever I get asked this question about where product and engine teams aren't getting along, it's always the first question you ask is, do the structures actually match each other? And it's not always easy to do. I was thinking about very early in my career, I was running this product team. I had an ENG counterpart, and the teams weren't organized the same way. And it's very natural for the engineering team to want to organize however the code base is organized. You can basically take the code files and say, I'm just gonna put engineers on each of them. And it's very natural for a product team to be organized a different way. And one of the things we ended up doing was, was he wanted to reorganize the team. We're gonna change code files. I said, I can't make the product team match that. And we said, all right, here's what we're gonna do. We're not gonna change anything for a few months. And we just took a section of his whiteboard and his. And his cube, and we just drew a few different structures and said every week, we're just gonna watch what's happening and try to see if we can come up with some magical way to get them to align. And at some point, you know, a few months in, we realized, actually, those two people seem to work together all the time. And we hadn't really thought about this way of positioning that pillar or that metric or so on. But then, like, that magic answer emerged, and we ended up with a. With a sensible way to align them, and then we rolled it out. But I. Rokuni, I was gonna ask you to talk a little bit about. I mean, I assume this is sort of a truism like, get your product, and it seems to align. What. What are the Cases where it's hard and what, you know, what are the cases where maybe it's not obvious how to do it?

Yeah, I mean I think when you're really early and you have one product manager and a lot of engineers which a lot of startup space, it's just not practical to have that two in a box or three in a box. And you just have to get really scrappy with the way you org design. You know, it's a fancy term but the way you organize your teams, I would say you need to the way to be successful is to remove all impediments that are in people's way to collaborate and actually break down org structures. Almost pretend like they don't exist. So the way I like it to think of, you can call it a swim lane, you can call it a project, I mean name it what you want. Just have a cross functional set of people whose allegiance is to move a metric forward for the business, a project forward for the business, or alleviate some of your customers concerns, whatever those are. Like that's the only way to be successful. I also find that any organization structure you put in place will most likely have to change in a very stable, you know, revenue guaranteed company probably at least once a year. So just don't get too caught into whatever you put together. You have to be open to constantly iterating and finding the best path forward. Some things we've done in the past that have helped is if you're starting out early, like doing Persona based organization, right? Like who are the Personas your product start, your product is targeting. If there are two different kinds of Personas just like swarm on those two Personas with engineers, product managers and designers and go tackle the problem. That's one way of looking at the other way is like using words like what is it that you want to be true for your product? Like is this the creation part of your product and have people swarm on that. I ideally in an ideal world, what Shari does describe is my dream. I like to have just one product counterpart, one design counterpart, but it's just not practical.

I think I've seen three different ways to do it. You organize what I call by mechanism, by goal or by audience. And so goals often feel like you know, a metric. I'm trying to move activation, trying to move conversion. So on mechanism is I own this part of the product. I own this. You know, it could be a part of the code, it could be something else or audiences. You know, like for YouTube it was the viewers and the creators, you know For Coda, we end up talking about publishers and makers just as different audiences. But I think the magic happens when somehow all three align and you end up with. You kind of own a set of mechanisms to achieve a set of goals for a particular audience, but it often doesn't happen. Yeah, maybe I'll push it forward to topic number two. Let's see. Developing partnerships. And so you've got the teams in place, you got the map. You figured out, is it Personas, is it mechanisms? So on. How do you actually make sure that that two in a box, three in a box actually turns into the right kind of partnership? Rukh May. I'll let you start.

I always, you know, the way I think of it is my first team is my product counterpart and my design counterpart. They're my first team. I owe allegiance to them. And when I joined Slack about a little over two years ago, June of 2020, we don't want to go back there in time. My product counterpart has also just joined, right. And we had this meeting on the first day we sat down, we were like, okay, here's to execs who never met each other in the midst of the pandemic, having to solve this large business problem together. And there were three tenets that developed in our early conversation. One is flow of information is critical, and it's different depending on your function. For example, engineering knows when there's a upcoming. There's something under. You don't wanna know, potential reliability concern that's gonna come up, or this loss of talent or. Or we're having some technical architecture that we need to do. That's something information engineers have. Product managers have a completely different set of information, like, what are users thinking? What's the research telling us? What are our growth metrics? What does the CEO want? Right? So I think it's really important to not assume and openly share information between in this box, because you just find out different things and you all grow together and you're able to unlock your organization first. Further, that's the first thing. The second thing and the most important thing that it started with a shared view of reality. Do we all agree that the state of things the way they are today are true? Because most of the misunderstandings I notice is when people believe things are not what they seem. So they're like engineers. You ask them like, everything's going great. I'm shipping five times a day. It couldn't be more awesome. And the product manager's like, nobody's using our product, right? So getting together and sitting through what's your shared view of reality? Do you agree that the state of affairs, organizationally, product wise, growth wise, business wise, you're aligned. And finally, I think to what Shadi said in the beginning, shared success, you are measured for the same outcome. You cannot motivate an organization with different outcomes. That's just a recipe for disaster. So I personally believe in the same, like have okrs or whatever. Whatever you use, whatever mechanism you use to measure it has to be the same for engineering, product and design.

Maybe I'll share one. Actually, let me just ask here. Raise your hand if you identify more with the engineering Persona. You are an engineer. You came from that background. Okay, how about people who identify more with the product Persona? Oh, interesting.

It's a lot of product.

Okay, well, that's a higher percentage than most teams have. So I'll tell you one story I end up telling very often, by the way, if I had to list the most common question I'll get asked by a product manager looking for advice. It is very related to this topic and usually it's framed something like, my engineer won't listen to me. And you know, it comes lots of different ways. And I'll often ask them, did they ever listen to you? And sometimes the answer is no, they didn't. But often the answer is no, they did. They used to listen to me, but now they don't listen to me anymore. And my guess is many of you have helped that at one point in your career or the other. And I like to start, and maybe this is not going to be popular with some of the product folks here, but I like to start with an observation which is if your team. I'll ask the product manager who says, my engineers won't listen to me. Say, well, imagine for a moment that the engineers weren't there. What would you have to do? And they'd say, well, I'd have nothing to do. Actually, that's kind of the nature of the job. Say, well, let's picture the other way around. Imagine the engineers were there and the product person wasn't there. What would they do? Say, well, they may not head exactly the right way, but they would move. So first thing to recognize in any relationship for the product manager is the product manager is optional in the relationship. No product manager likes hearing this, but I think it's very important for every product manager to realize that you are optional. I think that product manager engineering relationships get born out of a sequence of, of partnership stages. And sometimes I think it's four stages. I sometimes I Think it happens in. It can happen in 30 seconds, it can happen in 30 minutes, it can happen in 30 days, it can happen in. In multiple years. It can never happen. But every PM starts out as what I call the note taker. And your job is, hey, Mr. And Mrs. Engineer, the amazing work you're doing. How about I take on the burden of, I'll write down everything we're doing and I'll tell everybody about it. I'll write the meeting notes, I'll write the brief, I'll write all the things. Don't worry, I'm only gonna write down what you wanna work on. At some point, that product manager evolves to being the broadcaster. And they say, hey, I'm not only gonna write it down. I'll go tell everybody about it. I'll go tell the customer about it. I'll go tell the CEO about it. I'll go tell our marketing counterparts about it. I'll go tell her. But don't worry, I'm gonna tell them exactly what you wanna do. At some point, they become the collaborator and they get invited to the discussion of what should we actually do. And at some point they become. They earn the right to be leader. And the engineer says, actually, I'll wait a little bit and hear your opinion and we'll let you decide. Many product managers come in assuming they start there. They assume they've got this viewpoint and that's their fiat, their de facto position. And my view is that's earned and you have to work your way through it. And if you find yourself in the position of my engineer won't listen to me, usually that means you lost trust somewhere in that way. And there's sort of two real points out of this lesson. One is trust is built slowly. And this is not. Actually, I give you a very similar story for the designer who says the PM will listen to him. The marketer says the salesperson won't listen to him. You know, the trust is built slowly in stages. But the other one is every role has a skill that becomes your permission for the conversation. And I'll often ask PMs, and they'll say, I don't want to be the glorified note taker. And I'll say, are you crazy? Being a note taker? That's the whole point. You get to. You get to be the one that synthesizes what everybody else is saying in a way that they feel like, okay, you properly represented. What mean, if you can do that for your engineer, then they believe you can do that for the customer, they believe you can do that for the user that actually is in a demeaning role at all. That's your, that's your point. That's the reason you're in the conversation. So do a great job of it because that's how you're going to work your way through it. So anyway, that's been my typical way to coach PM through that hard question.

That's great, actually, as a person, when I was growing up, when I was in high school, I was a competitive programmer and I was all about winning and going in competition. And one of the things that is important as I become an engineer is still winning. I want to build some product that is winning. The space is competitive. And if I feel like that the PM is helping me win, then the trust is built, right? Whether how he or she helps me win, is it with going and educating or enabling the GTM so they can sell the product better? Or helping me find the right customer to talk to, or compiling that data and telling me that's how the trust is built? Is he or she making me become more successful? I think that's what's important. And as we create that, that is very important. And one thing that I always make a joke about it, if I go to an engineer and say, why did you build this ugly product? And they tell me because the designer told me or because the PM told me, I say, wrong answer. But if they tell me because I thought it was going to be pretty, but it turned out to be ugly, that's okay. We all make mistakes and we are learning from that. But if I feel like that Shacher is helping me become successful and you know, Owen, I will definitely trust him more. And that's very important.

It's back to shared success.

It is totally about shared success. And I think, you know, you made a great point about building trust. And I'm a huge fan of Brene Brown. And she talks about it's like a jar of marbles. Like when you give someone your trust, you give a jar of marbles. And every time an action you perform that takes away the trust, you know, you have your marbles come out. So sometimes, especially in, like, roles when you're leading organizations, I believe you have to give the trust up front. I think that's, that's an important distinction from early in my career to later in my career. Like, you trust up front and then you believe in it and you, you dedicate your time and effort to make a partnership work. For example, when I started with my product counterpart and I was sharing this with you all earlier. We both were like, okay, how are we going to navigate this pandemic? And zoom and remote work? And we're like, let's meet. 15 minutes to do day and share information, and if you run out, we'll stop. He was my last meeting yesterday. Two and a half years in, right. We haven't run out of topics, so we've. We're both busy people. We explicitly made time to foster and develop that relationship. And there have been highs and lows and mistakes, but we're in this together, I think is a really important new answer.

I'm curious. What are. I love the marbles analogy. What are the. What are some good examples of a surprising marble deposit of like, hey, you've, like, you accumulated more than you might have thought. Or a case where people, you know, drew too many marbles? Or what are the.

I can actually give a specific example where I was the person who took the marbles out of the jar to my product counterpart. Shame on me. I actually was like, you know, we were not on time, like, you know, most engineering teams trying to ship something. And the CEO called me in many years ago and he was like, why is this not on time? And I was like, this is what I'm going to do. This is my plan. I just went away and then I came back the next day and I presented him a whole plan on how I'm going to get save the day. Like, engineering is going to come in, they're going to save the day. And then my CEO looks at my product counterpart. So that was me taking the marble out. And he says, manfred, what do you think? And he's like, yeah, totally in with Rukmini's plan. I was like, him putting the marble back, I didn't deserve that treatment that day. And it's then when I had this moment, like I was being. I had a single, you know, track mind. I looked at this as an engineering problem. This was several years ago, but that was a growth development for me and he was magnanimous with me in that moment. So I always keep going back to that example.

And one of the interesting. When you see those product and Eng partners, this is not just true park and Edge. Every. I think the 15 minute a day thing is such an interesting ritual. One of the things I'll ask about, or you'll notice in the good partnerships is the boundary between the roles is very thin and there's no, you know, hey, that's a product problem. That's an engineering problem. Those types of things go away, people find their natural strengths. And so it's like implied in some conversations. Of course you'll do this, but it would, you know, I'm not going to do it and not tell you about it. Or so I think that's a, I think that's a very common marble withdrawal. Is the drawing too hard a line?

Yeah, exactly. And as engineers, as you said, we're always late or things are not happening and when the product comes apart and say ok, let's sit down and let's look at the scope, let's see if we can reduce the scope or figure out what is critical here to go that's really coming and putting that partnership hat on that now we have to prioritize. Even though you told me you're going to deliver all of them and you didn't. But now we are in this game together and let's figure out how we can figure out what is the if we can come up with an MVP here that there is still viable. There's still a Vivian here. Let's figure out that scope. That's where you're building that relationship, filling up that jar that I'm here taking.

Care of you and maybe you take the other voice for the product side. I think marble withdrawals use your analogy. I really like it. The, you know, I think that the best product managers the easiest way to deposit marbles. There's I think two things come to mind. One is and comes back to note takers is does that person really synthesize and understand what everybody thinks. It's like a key part and it's not really about just understand the customer, to understand the engineer, to understand the counterpart, understand the CEO. It's understand all of it. I think that, you know, an easy way to withdraw or add a marble is to not understand well to say something that isn't true. And hey, this is what the customer is going to say and actually isn't what they're going to say or what they said. If it's facts, the other one I think is great. And this is not necessarily just product or engineering. I think it's both. I think that partnerships develop a sense of how to frame problems. And I think the I think that shared sense of reality is a really important starting point. And then there's a step of like picking the right solution. But in the in between there's that frame process. And you know, I had an old boss that used to tell me every decision goes through wallow frame proposed close. There's like four stages of how to think about things. And most people, you know, they skip the wallow phase and where's our shared sense of reality? They jump to, well, here's a solution. And they miss the how do we really think about this problem? What's the most discerning dimension of this? What are the actual options? Do we understand them well? And I think great product managers are really good at helping a team get to that right frame across whatever the dimensions are. This is what the customer might think is what the technical considerations are, whatever it might be.

Actually, I want to add something on that. And it's not about product management necessarily. It's about kind of leadership also being an influencer.

Right?

It's very important. I remember many years ago, I was an architect and my boss came to me and said, shadi, you have a hard job. I said, why do you think my job is hard? He said, because you have to basically influence everybody and you don't have positional power. So how do you get them to. You're coming up with a design, you're not their boss, their bonus is not tied to that or whatever. How do you inspire people to follow what you're saying and the way that I did it? And actually, his suggestion is that ask the right question. When you ask the right question, people come up with that answer. And when people come up with the answer, they're vested, relax their idea, and they're vested to implement that. I think that applies to a good product manager. If you're a good product manager and you ask the right question, rather than coming and telling engineer, you need to do ABCD and why you're too late doing ABCD and you're making me look bad. Ask the right question, people. When people come up with that answer, they're vested in basically driving that and making sure that happens.

Okay, we'll jump to topic number three. So this is a topic that I really love to talk about. So we've set up our teams right? We've gotten the partnerships right, and now we need to work on our rituals and behaviors. And I think the. My favorite quote on this topic comes from an old friend of mine, Bing Gordon. If people don't know Bing, Bing's a. He was one of the founders of Electronic Arts. He's now a famous investor. Amazon, Zynga, many other great companies. I had the pleasure of sitting on a board with Bing, and he used this line a lot. That really stuck with me. He said, great companies have a very small list of golden rituals. And golden rituals have three characteristics Number one, they're named, number two, every employee knows them by their first Friday. And number three, they're templated. And you know, Bing always rattles off his list. Amazon has six pagers, Google has okr, Salesforce does v2 mom and those are sort of company level rituals. There's also many that you could sort of apply at the team level, at the partnership level and so on. And I found that some of these are fairly surprising actually. As a small plug, I'm actually writing a book on the topic. Virtual's a great team. So I've gotten a chance to learn about different examples and we talked about a few of them before joining here. So I wanted to spend some of our time on the great rituals between product engineering teams. Who wants to go first?

I can just share a few. Like at Slack we have something called the Monday meeting. And the Monday meeting is basically where we review our okrs together. But week one, my first day, I show up and I'm like, what is this meeting? And it's like a cross function group and it was a part of my onboarding documentation. Everybody understands what it, it's templatized, we know what to expect. It's 25 minutes and it's the most efficient use of time. I have something else that is really quirky and local. So that's more like at a PD level of Slack leadership. There's another one that's local and it's specific to platform. It's called the Hugging Elephants where we actually hug the elephant in the room. That means no topics, off limits and it's for a closed group of like cross functional leaders. On that forum we get together, it's called Hugging the Elephants meeting and we all hug, we talk about. We usually don't come with an agenda for that meeting. The topic is to basically acknowledge the presence of said elephant in the room and just talk about it. And that's so important because we've been able to wade through discomfort and we usually don't spend a lot of cycles. What's the missile? Oh gosh, I don't know. I love to talk about the elephant in public. I think I shouldn't have ratted it out but you know, examples, interpersonal conflicts on teams or like maybe confidence in a certain function that you can just talk about externally but you want to navigate or like what's the latest feedback? How are people feeling? How are we feeling about what we are building together? Have like because leadership is so lonely, right? And to have a group of people, you can have these really hard conversations with has been absolutely invaluable. And the third thing I would say is, like with any team, I think it's. If you're familiar with the waterline, there's all these activities and rituals which are great. But I think where real team development happens, it's called below the waterline. Dipping below the waterline. Like whether it's an off site you planned or an activity or a volunteer. Some experience. We have an experience where we created our team values together. We said, what are our PDE team values? What is the product value you're gonna bring? Like I said, one of the architecture values we'll bring is. Is we'll relentlessly evolve our team values. Equity is excellence. Like, we will not take opportunities away from anyone while building this product. Things like that. Those are like below the waterline activities and rituals that can actually bring the group together. And you have to do it repeatedly. You can't just do it once and expect. Because trust the jar of marbles. Like, it keeps eroding and you have to fill it back in. But these are three examples that I think have transform the way I work and that I really appreciate.

Yeah, one of the things that we do at amplitude is that it's a very simple one. Of course, I think a lot of you are doing that. We have a PD all hand. It's not engineering all hands. It's not product all hands. It's a product development all hand. And one of the important ritual there is recognition, recognizing people who are basically showing our values. And the way it happens that people are nominating each other. And a lot of time you will see the nomination. A product person is nominating an engineer. Engineer is nominating for that that are exhibiting the values that are important for us. That basically creates that camaraderie that, you know, I'm being seen. All of the work I've done, people are seeing what I contribute in that. So that's. I really love that.

How do they do it? They call. They submit it and call it out.

They submit it.

You should use a Slack channel for that. We actually have a thread called awesome Sauce Time, which is a thread of like every. It's called the awesome Sauce Time on Thursdays. It's a thread. It's very simple. Try it out and you can do the same ritual online for the world to see.

Yes, exactly. There's a Slack commercial here.

Just so you know, engineers can't sell.

I'll tell you. I interviewed one company where the CEO agreed to whichever things were submitted for the Recognition. He would read them out, but in a different. He could do accents for. Well, but in a different accent for each person. And it's just hilarious watching this thing get right out in different accents. Yes.

Another one that is going back to again, the shared goal. We have this quarterly product reviews the engineering, design product of each of these pillar leads. They come and they say, okay, how did we do? What was the retro and what are our goal that we are setting for this quarter? And this is how we are expecting to move our metrics based on all of these features. We call them bets, the features and bets that we're delivering. And then we do a weekly, you know, half an hour like your 25 minutes, half an hour just reviewing the bets, how we are moving the bets. And actually people who are presenting to the leadership that they're taking turn. It's not always the product manager who's coming and telling you their metrics are moving or not. Once the product in one week, the product manager comes and shows how our metrics are, are moving. The next week the engineers come and show how our metrics when the other designer is coming and showing how our metrics are moving. But that gets the ritual and also people know what's happening in the other areas because you know, you might be very focused in your own area. But I think it's very important that you see the common threads and you see that what's happening cross functionally. That's also very good. And then our favorite thing is, you know, is hackathon. When you do hackathon and product manager for a week long, you know, people forget about your day to day stuff. Now you can go and solve any problem that you want. So it's a week long ritual at amplitude. And we have product manager that sometimes they code because they have been an engineer before. You know, designers who are coming up and there's so much energy in that when people and actually that deals a lot of camaraderie. That's. I think that's a team building event. And they go and everybody gets excited to win and whatever. And we actually get our customer who come and actually we have a customer choice awards that people are coming and seeing. What are the work that people are doing? So these are some of the.

I love the hackathon one. I have this love hate relationship with hackathons at YouTube. It ended up becoming very unsuccessful.

Oh really?

Hackathons became almost because we would, we'd build these things and then we wouldn't ship them. And people felt very upset because they thought the goal was to ship. So I Coda, our hackathons are a very simple rule. Default is you're not allowed to ship. And it's amazingly like freeing. You can work on whatever you like, whatever you're going to build, take a great, do a great write up, make a great video, throw it away. And it actually you would think it's reverse because many hackathons are, let's go ship something new. But what it allows, allow people to take risks, allow people to work in areas they're not comfortable in. You know, I would never let the PM write the code in this thing, but it's just a hackathon, it's okay. And we're going to work in this other space and you don't have to worry about, you know, some team has already tried it or not, doesn't matter, we're going to throw it away anyway. And we do a similar thing if we show it to customers and get feedback. But the throw it away was a very controversial rule and not what most hackathons do. I'll share our golden ritual. If you were to pick any employee at Coda and ask them on their first Friday what the most iconic ritual of the company is, they would talk about this thing we do called Dory Pulse. And it's a pretty simple idea, but it's sort of our secret to driving collaboration. Running great meetings kind of solves many different problems at once. The basic way it works is, you know, in many companies you'll have a meeting and then people will, you know, there'll be a write up and people will ask questions and they'll sort of blurt them out or there's a long list of comments in the sort of right hand rail of a document and you kind of go through those in order and none of those things actually feel that good. And so we'll do, we call it Dorian Pulse. The way it works is the Dory is a list of questions. So rather than put them right, rather than raising your hands or putting them in comments, you put them in this table and there's a little upvote download buttons, very simple. Dory's named after the fish who ask all the questions and you vote them up and down and you leave the meeting and you say, we didn't get to talk about everything, but we talked about everything with the re upvotes. So you sort of went through the most important things. And it's generally paired with something we do called Pulse. And Pulse, by far the most important is we ask everybody to write, you respond, you say, here's what I think about this discussion, this topic, this meeting, whatever it is. And our way of doing it is everybody else's responses are hidden until everybody's done. And so you come in, you say, it could be, should we ship this feature? Should we hire this person? Should we buy this company? Should we, should we launch in this market, whatever it might be, you have to go on the record. I think yes or no, or one to five stars, whatever it might be. And you write and you say, this is how I feel about it. It has a bunch of impacts. I mean, obviously one is it's way more efficient. I'm sure everybody's been in a meeting where you go around the room and you hear what everybody thinks. And it takes forever. It also, the most important thing is it removes all the group think so, you know, when you go around the room, it's like, first person says yes, second person says yes, third person says yes, fourth person kind of stuck. You kind of have to say yes. Now all of a sudden, people can talk about it. But probably the most important thing it does is it, it brings out perspective, perspectives and ideas from people who would often not get a chance to speak. They, you know, in many companies and organizations, you know, the loudest voice, the highest paid person, whatever the structure is, ends up dominating a meeting. So that's our dory pulse, is our golden ritual. Before we turn back to all of you for questions. If you have questions or mics, feel free to ask anything you like. But I thought we could wrap up on our side with maybe one thing. Everybody should take away something we talked about or something that maybe we didn't talk about.

I would say just embrace your one team. You are one team. And that just embed that within your organization and model that behavior if you're leaders. Because the organization's gonna look, they look to you and they'll do exactly how you represent yourself. So please model it and just reiterate it and live it. I think that mantra of your we are one team has been very helpful. So I hope that's your takeaway today.

I feel like I'm gonna be repeating, I'm not original, but I'm gonna go say similar things. You know, as I've been saying, you are in it together, you're winning together, you're losing together. Having that mindset and set the goals and go win it, you can all do that. Go with that positive attitude and be together and you can win and be that one team. And to make it happen.

Since the room had more product and engineering. I'll speak directly to the product managers here and say, if there's one thing you remember, remember you're optional in that partnership and I think it will help you solve many problems. And I don't mean that in a demeaning way. I don't mean that in a. You shouldn't want to be a product manager. It's a very important and impactful role. But the role is built off of being able to build trust. I think being able to go from note taker to broadcaster, collaborator to leader is a step that I've just found that to be the most impactful advice I can give product managers. Okay, we have a few minutes for questions. And if people don't have questions. Okay, go ahead. I think you can come to the mic.

I'm Justin from satu. One of the biggest conflicts we see is predicting when software can be finished.

Right?

And that's the conflict. So any comments on how to deal with estimation, how to deal with talking to customers and engineers and product managers?

So how do I manage all of that around estimation?

If it were predictable to build software, we wouldn't all have jobs. But I think you just have to build frameworks, something I've done in the past that's been really helpful. This comes back to the shared view of reality is actually coming up with a custom scale for how important something is. It's not about how much you can build. I think most teams end up with the trap of building too many things at the same time. I think the one thing you can control is focus. Less dilution, more focus. That is the key to success. And how do you all come up, come to the same page on that? I would say build a metric or whatever works for you. Is it a revenue opportunity? Is it technical debt? Get everybody in the room together, weight that scale and use that scale to stack. Rank your initiatives and then cut, cut and cut again. I don't think any engineer wants to like they're purposefully delaying you. It's just that if you talk to most ICs, they end up with multiple things on their plate every day. And you know, we were joking about the Dilbert cartoon earlier where the product manager is like, what's the story with user stories? Like, give me all my stories or else. Right. So I would say less dilution, more focused. You can come together as one team and choose what you prioritize and that's the way you can drive to more predictability. I wish there was something like More predictable software.

Magic answer?

Yeah. No, I don't have a magic answer. One thing that I can say, one of the reasons that engineers are not able to deliver on time is because they have to context switch a lot. They move from one to the other one. Oh, there's this deal we're closing and we need to do that. And there's another win. And you know, people take it. You know, people really want to win, but there's a big cost with this context switching. So you are, as a product manager, you are the one that can really figure out, okay, is this the right time? Is this still gonna be gone away if you do it in two weeks later? Or is really that necessary? Create that space so the team can operate the best. But again, as you said, it's about prioritization. And there are a lot of time that you have to go back and think, what is the right scope? Maybe we try to boil the ocean and let's figure out what is the MDP still, it needs to be viable. I always say there's a V in mdp, so make sure that you're building something that is viable, but go and figure out what is the right scope, but create that space so people can work efficiently and effectively.

My short answer to your question is it's very important when you ask the question. So if you ask the question too early, be ready to be disappointed. If you ask it too late, it's irrelevant. I remember I started my career in the days when software was shipped on CDs. And in those days estimation really mattered. And we would sit down and everybody ran a waterfall process. And you know, at Microsoft there was, you know, almost a third of the time was left to test. And so there's like long period because once you ship the cd, it wasn't coming back. We all now live in this new world for all aster where that none of that's true anymore, right? There is no, you know, release to manufacturing moment and so on. Many of us ship every day. And in some ways that's good because we, we can like ship very fast. It makes that question really, really hard. Because when is this going to be ready? I can no longer just say like, you know, the train's leaving, you know, on this day, you're in or you're out. And I, you know, I can kind of work our way through it. And so we've kind of lost the tool. I, I find most times when people ask for estimates and are unhappy with theirselves, I mean, there's some things about you know, as a product manager, if you have an estimate, how do you make sure the engineer hits it? Make sure they have enough focus, make sure you get the scope clear. Those are all really important. But we've all had that moment where, you know, we asked the question, they said there was gonna be two months of work, and it ended up being eight. And why was that? And in my experience, that usually happens because you asked the question at the wrong time. You didn't actually know what you were building. You didn't, you know, that person wasn't, you know, the great engineers are obviously very good at est, at like, having some sense of complexity and time estimation is one way to say that. But, you know, they're very good at the. This is about how hard this will be. And you can, as you know, you'll perform the partnership, you'll learn the body language of, like, you said it was going to be hard, but I saw you kind of, you know, look sideways. It probably means it's going to be even harder or, you know, you think it's going to be. But I find, and Chadi mentioned something earlier about hackathons. I think that one of the tools that PMs don't use often enough is, hey, I'm not. You're giving me this super wide estimate, and I don't really know what that means. How about we go take three days a week, what, one day, and we're just gonna, we're gonna throw away whatever we build, but we're gonna spend our time eliminating the risks and that we're gonna build a bunch of stuff. We're gonna, we're gonna throw it away. Hackathons are a fantastic way of doing it. And at the end of that, we're gonna have a much better sense of how hard it is and how it works and so on. And then you ask the question. Because you ask the question the wrong time, you're gonna be disappointed in the answer. And we can't use a ship vehicle as the way to ask that anymore.

I just wanted to say prototype the path to production. That is literally, that should be a mantra like, scope it out. Then you know the complexity and you get a much better estimate.

We're right at time, but it sounds like we have one more question. So I think he got to the. We'll stick around after, but we'll take one more and then we'll go. I'll keep it simple. I like your analogy about glorified note taking. I hope every PM agrees to that. The other side of that is the customer side. At times, product managers go and talk to customers, gather other equipment and they explain it to engineers. And there are issues in our engineers. I find it tough to convince engineers to get on call with customers. The question is how important is for engineers to talk to customers directly for the joint?

Yes, actually I'm going to talk about that because that's one of my most important thing. I have said this rule. I haven't been completely successful, I have to admit, but I want each engineer to get on a customer call once a week. It's a big hack, you know, big hack. Because if they get on a customer call, they understand because as I said, one of our values is owning the product experience. They understand why they're building it, what is the problem that they're solving. So. And engineers make trade offs, so many trade offs while they're building that and having that perspective helps them a lot. And actually we don't develop a feature unless we have a customer development partner because we don't want to develop in vacuum. If there's nobody interested in developing with us, we shouldn't be building it. And I think that's important that you get that. But at the same time, you have to make sure that you're not biasing all of your decision on one customer. So you have to be thinking about, okay, I need to move the metrics and I need to be seeing across the board what's happening. But I think this is so important to get engineered on customer calls because the whole point of them being there is the solving customer pain. They need to know whose pain they're solving.

Agreed.

Customer empathy for the win.

Yeah, we're short on time, so I'll give quick tips on it. Support and customer calls, you know, go, man. The support queue is as important the angry customer, the frustrated customer, so on is as important as the dreamy customer that your sales team is working on. So I think that's very important. And then the other thing I was gonna say is we're in a different world and gong is your friend. If you guys don't, if you don't, gong or its equivalence is there's a few others out there we use gong. You don't necessarily need to actually go on the call, you just need to watch the video and that can be very impactful. I do have one more. We run. We did one, one of our rituals. We combined what was normally a stats meeting. We call our metrics meeting and we now call it stats and stories. SNS is what it's called. And it's very simple. It's, you know, it's an hour long every two weeks. And the data team goes through all the metrics and the research and so on. And then when we have a half hour of customer stories, and many of those will watch gong calls where we'll go through support tickets, but, you know, everybody can come to that. And then one positive, we watch it together so we all can have a chance at a shared conversation of what do we all take away from that? But those are some hacks for making sure everybody in the company, but especially engineers, have some empathy for what the customer's experiencing.

Absolutely. I really want to echo the gong thing we actually have. Sometimes gong lunch time, people are sitting in the room and eating the lunch and watching and then discuss about that. This is so valuable.

Okay, we're over time and I'm getting my. My signal there. Thank you very much for attending, for the great questions. If you have any other questions or thoughts, we'll. We'll stick around a little bit afterwards and have a great time at Saster.

Thanks, everyone.

Thanks, everybody.