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 Shashir Mehrotra.

Pick the right seat.

I know, make sure you sit on the right seat.

Let's see. All right. Hi, everyone.

Hello.

So fun to be outside for these.

Yeah, it's actually very exciting. I was telling that when you are 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 Saastr. 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, you know, these two roles often have some built-in tension, 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. Um, 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. I'm currently— I'm SVP of Engineering at Amplitude. I was born and raised in Iran. I went to undergraduate there. Then I left Iran, went to Canada, got my— 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 management track. Prior to Amplitude, I was a VP of Eng at Palo Alto Networks, and I've been at Amplitude for 3.5 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 5 minutes, and what fun can I say? I actually have 3 citizenships. So I'm Iranian, Canadian, and American, and my partner is French. So if I want to collect another 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. All right, Rukmini.

Hi, everyone. I'm Rukmini. My pronouns are she/her. SPP of engineering platform. I am also an immigrant. I began my life in India and moved here 20+ 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 3 teams. So nice to meet you all.

Hi everyone. So I'm Shishir 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 or blocks, I have a garage full of every type of LEGO you can possibly imagine. And we've probably built everything you can think of. But happy to chat about that. Also a great way to learn about teamwork, watching kids do it. OK, so that's a great round of intros. So 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. You know, he's the product guy. I'm the engineering. We have to make sure that we work together. We're trying to find something in common. And we 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. OK, 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.

[Speaker:SHADI_PASHA] 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— I own the 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 and engineers 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 2 in a box or 2 in a box with a designer. 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 needs 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 users. So their goal is to increase that number, but that's the entire goal. And of course, they're delivering features, 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 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. 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's successful.

[Speaker:JASON M. LEMKIN] I think it is the most important basic thing to start with. Whenever I get asked this question about when product and eng 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 one 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 going to 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 he wanted to reorganize the team. We're going to change code files. I said, I can't make the product team match that. And we said, all right, here's what we're going to do. We're not going to change anything for a few months. And we just took a section of his whiteboard in his cube, and we just drew a few different structures and said, every week we're just going to 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, 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 the magic answer emerged, and we ended up with a sensible way to align them. and then we rolled it out. But I, Rukmini, 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 teams aligned. 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 startups face, 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 it's 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 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 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 it. The other way is like using verbs. Like what is it that you wanna 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 Shadi just described is my dream. I like to have just one product counterpart, one design counterpart, but it's just not practical.

[Speaker:SHADI_PASHA] I think I've seen three different ways to do it. You organize what I call by mechanism, by goal, or by audience. Goals often feel like 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. It could be a part of the code. It could be something else. Or audiences, like for YouTube, it was the viewers and the creators. For Coda, we end up talking about publishers and makers 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 us forward to topic number 2. 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 2 in a box, 3 in a box actually turns into the right kind of partnership? Brooklyn, I'll let you start.

I always, 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 2 years ago, June of 2020, we don't wanna go back there in time, my product counterpart had also just joined, right? And we had this meeting on the first day. We sat down, we were like, okay, here's 2 execs who've never met each other in the midst of the pandemic having to solve this large business problem together. And there were 3 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 an upcoming, there's something under, you don't wanna know, potential reliability concern that's gonna come up or there's a loss of talent or, you know, we are 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 unblock your organization further. That's the first thing. The second thing and the most important thing that I 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 is going great. I'm shipping 5 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 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, who— raise your hand if you identify 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.

That'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 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. 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, it'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? I 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 the product manager engineering relationships get born out of a sequence of partnership stages. And sometimes I think it's 4 stages. And 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 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 going to write down what you want to work on. At some point, that product manager evolves to being the broadcaster. They say, hey, I'm not only going to 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— but don't worry, I'm going to tell them exactly what you want to 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 what they earned 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 have a very similar story for the designer who says the PM won't listen to him. The marketer says the salesperson won't listen to him. You know, 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 we 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 isn't a demeaning role at all. 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 PMs 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. Going in competition. And one other thing 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 selling 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, I make a joke about is 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's going to be pretty but it turned out to be ugly, that's OK. We all make mistakes and we are learning from that. But if I feel like that Shashir is helping me become successful and win, I will definitely trust him more. And that's very important.

Back to shared success.

It is totally about shared success. And I think you made a great point about building trust. I'm a huge fan of Brené 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 upfront. I think that's, that's an important distinction from early in my career to later in my career. Like you trust upfront. And then you believe in it and 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 a day and share information. And if we run out, we'll stop. He was my last meeting yesterday, 2 and a half years in, right? We haven't run out of topics. So we've— we're both busy people. We ex— 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, you know, people, you know, drew too many marbles What are the— what are the—

I can, 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? I was like, this is what I'm gonna 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 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.

One of the interesting— when you see those product and eng partners, this is not just true of product and eng, every partnership, 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 implied in some conversation, of course you'll do this. But I'm not going to do it and not tell you about it. I think that is a very common marble withdrawal, is drawing too hard a line.

Exactly. And as engineers, as you said, we're always late or things are not happening. And when the product counterpart says, OK, let's sit down and let's 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 gonna 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 view in here. Let's figure out that scope. That's where you're building that relation or filling up that gap. Jar that I'm here taking care of you.

And maybe to take the other voice for the product side, I think marble withdrawals— use your analogy, I really like it— I think that the best product managers, the easiest way to deposit marbles, I think two things come to mind. One is, and it 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 customers, understand the engineers, understand the counterpart, understand the CEO, understand all of it. I think that, you know, an easy way to withdraw or add a marble is, is to not understand well, you know, 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 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 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, propose, close. There's, like, 4 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, you know, 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, this 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. It's 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, ask the right question rather than coming and telling engineer you need to do ABCD and why are you too late doing ABCD and you're making me look bad. Ask the right question and people, when people come up with that answer, they're invested in basically driving that and making sure that happens.

[Speaker:JASON M. LEMKIN] OK, we'll jump to topic number 3. 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 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 3 characteristics. Number 1, they're named. Number 2, every employee knows them by their first Friday. And number 3, they're templated. And, you know, Bing always rattles off his list. Amazon has 6-pagers. Google has OKRs. Salesforce does V2MOM. 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, Rituals of Great Teams. 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 1, my first day, I show up and I'm like, what is this meeting? And it's like a cross-functional 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 PDE 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 cross-functional leaders on platform. 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 example? Oh gosh, I don't know. I love to speak 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 wanna 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, 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 offsite you planned or an activity, or a volunteer, something, some experience. We have an experience where we created our team values together. We said, what are our PTE team values? What is the product value you're gonna bring? Like I said, one of the architecture values we'll bring 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, you know, the jar of marbles, like it keeps eroding and you have to fill it back in. But these are like 3 examples that I think have transformed 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-hands. It's not engineering all-hands, it's It's not product all hands, it's a product development all hands. And one of the important ritual there is recognition. Recognizing people who are basically showing our values. And the way it happened that people are nominating each other. And a lot of time you will see the nomination, product person is nominating an engineer, engineer is nominating product, that are exhibiting the values that are important for us. That basically creates that camaraderie that I'm being seen, all of the work I've done, people are seeing what I contribute in that. So I really love that.

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

Yeah, they submit it and then call it out.

You should use a Slack channel for that. We actually have a thread called Awesome Sauce Time, which is a thread of like every— Awesome Sauce Time. 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, but just so you know.

Who said engineers can't sell? I'll tell you, I had—

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 really well— but in a different accent for each person. And it's just hilarious watching this thing get read 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 goals 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 feature and bets that we are delivering. And then we do a weekly 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 turns. It's not always the product manager who's coming and telling you their metrics are moving or not. Once a product— one week the product manager comes and shows how our metrics are moving. The next week the engineers come and show how our metrics are moving. 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 might be very focused in your own area, but I think it's very important that you see the common threads and you see what's happening cross-functionally. That's also very good. And then our favorite thing is hackathon. When you do hackathon and product manager for a week long, 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 managers that sometimes they code because they have been an engineer before. Or designers who are coming up. And there's so much energy in that when people— and actually, that builds a lot of camaraderie. I think that's a team-building event. And they go, and everybody gets excited to win and whatever. And we actually get our customers who come, and actually, we have a customer choice award that people are coming and seeing what are the works that people are doing. So these are some of the resources.

[Speaker:JASON M. LEMKIN] I love the hackathon one. I have this love-hate relationship with hackathons. At YouTube, it ended up becoming very unsuccessful. Oh, really? The hackathons became almost— 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 at Coda, our hackathons have a very simple rule. Default is you're not allowed to ship. And it's amazingly 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 reversed because many hackathons are, let's go ship something new. But what it allows is a lot of people to take risks, allow people to work in areas they're not comfortable in. I would never let the PM write the code in this thing, but it's just a hackathon, it's OK. And we're going to work in this other space, and you don't have to worry about 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, the throw it away was a very controversial rule and not what most hackathons do. I'll share our, 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. It kind of solves many different problems at once. Um, it's a— the basic way it works is, uh, you know, in many companies you'll have a meeting and then people will ask— 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 Dory and Pulse. The way it works is, um, 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, downvote button. It's very simple. Dory's named after the fish who asks all the questions. Um, 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 3 upvotes. So you sort of went through the most important things and it's generally paired with something we do called Pulse. And Pulse is by far the most important is we ask everybody to write, you respond and 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 1 to 5 stars, whatever it might be. And you write and you say, this is, 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, it removes all the groupthink. So when you go around the room, it's like first person says yes, second person says yes, third person says yes, fourth person's 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 brings out 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, the whatever, whatever the structure is ends up dominating a meeting. So that's our Dory Pulse is our golden ritual. That's awesome. Before we turn back to all of you for questions, if you have questions, there are 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, you know, something we talked about or something that maybe we didn't talk about.

Yeah, I would say just embrace your one team. You are one team, and that— just embed that within your organization. It's— and model that behavior if you're leaders, because the organization is going to 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 make it happen.

Since the room had more product than engineering, I'll, I will, 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 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. OK, we have a few minutes for questions. And if people don't have questions— OK, go ahead. I think you can come to the mic.

Hi, 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 all that around estimates? 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.

I—

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. If so, 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. Like, 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. We were joking with the Dilbert cartoon earlier where the product manager is like, "What's the story with user stories? Give me all my stories or else." Right? So I would say less dilution, more focus. 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, but—

Do you have a magic answer?

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 have to be closing, and we need to do that. And there's another one that— and people take it. 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 3 weeks later, or is it 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 say, what is the right scope? Scope. Maybe we, we, we try to boil the ocean and let's, let's figure out what is the MVP. Still, it needs to be viable. I always say there is a V in MVP, 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.

You know, I, um, my short answer to your question is it's very important when you ask the question. So if you ask the question if you ask it too early, be ready to be disappointed. If you ask it too late, it's irrelevant. I remember, you know, 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 a long period, 'cause once you shipped the CD, it wasn't coming back. We all now live in this new world, for all its asterisks, where none of that's true anymore. There is no release to manufacturing moment and so on. Many of us ship every day. And in some ways, that's good because we can ship very fast. It makes that question really, really hard because when is this going to be ready? I can no longer just say, the train's leaving on this day. You're in or you're out. And 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 themselves, 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 going to be 2 months of work and it ended up being 8. And why was that? And in my experience, that usually happens because you ask 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, 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, and Shadi 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 3 days, a week, what, 1 day, and we're just going to throw away whatever we build, but we're going to spend our time eliminating the risks. And we're going to build a bunch of stuff. We're going to 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, 'cause if 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'll let, 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 everyone agrees to that. The other side of that is the customer side. At times, product managers go and talk to customers, gather other requirements, 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 it for engineers to talk to customers directly for the joint efforts?

Yes. Actually, I'm going to talk about that because that's one of my most important things. I have set this rule at my org, and 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 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. 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, OK, I need to move the metrics and I need to be seeing across the board what is happening. But I think this is so important to get engineers on customer calls because the whole point of them being there is 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. 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 going to say is we're in a different world, and Gong is your friend, if you guys don't know. If you don't, Gong or its equivalents— 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. Oh, I do have one more. We did one of our rituals. We combined what was normally a stats meeting, our metrics meeting, and we now call it Stats and Stories. S&S is what it's called. And it's very simple. It's an hour long every 2 weeks. and the data team goes through all the metrics and the research and so on. And then we have a half hour of customer stories, and many of those will watch Gong calls, will go through, uh, they'll go through, uh, support tickets. Um, but, you know, everybody can come to that. And then one, one positive is we watch it together so we all can have a chance at a shared conversation of what do we all take away, uh, from that. But those are some, some hacks for making sure everybody in the company, but especially, engineers have some empathy for what the customer is experiencing.

Absolutely. I really want to echo the Gong thing. We actually have sometimes a Gong lunchtime. People are sitting in the room and eating their lunch and watching and then discuss about that. This is so valuable.

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

Thanks, everyone.

Thanks, everybody.