Episode Thumbnail
Episode 174  |  21:48 min

#Build 9: Product Managers: Want To Work Better With Engineers? Here's The Secret.

Episode 174  |  21:48 min  |  10.26.2018

#Build 9: Product Managers: Want To Work Better With Engineers? Here's The Secret.

00:00
00:00
This is a podcast episode titled, #Build 9: Product Managers: Want To Work Better With Engineers? Here's The Secret.. The summary for this episode is: It’s a special episode of #Build. Host Maggie Crowley is joined by members of Drift’s Product and Engineering teams. Meet Alexa Nguyen, Senior Product Manager, Trevor Rundell, Director of Engineering, and Peter Karl II, Lead, Product Efficiency. The group chats through how product and engineering can work together most efficiently. That means breaking through the perception that engineers should be wholly removed from the customer. To tackle this problem at Drift, tech leads here are directly responsible for the outcomes of the products they’re working on (where at most organizations, that’s the Product Manager’s responsibility). This gives engineering more context around the products they're building. And empowers them. They’re expected to be on the front lines answering questions from customers. Because at Drift, it’s all about putting the customer first. Learn more about story time and how to get your engineering and products teams better aligned in today’s episode of #Build.  Before you go leave a ⭐⭐⭐⭐⭐⭐ review and share the pod with your friends! Be sure to check out more insights on the Drift blog at drift.com/blog and find us on Twitter @maggiecrowley, @drift and @seekingwisdomio.   In This Episode 0:37 - Introductions of Alexa, Trevor, and Peter 1:44 - Tech Leads vs. Product Managers 3:48 - Creating a space of forward-thinking work called “Story Time” 5:50 - When to bring an engineer into a project 6:30 - Starting Story Time with a well-defined problem 7:44 - What does the customer want? 8:36 - The team discusses their first Story Time. 10:24 - Pencils Not Pixels 11:04 - How to communicate this idea with new engineers 12:00 - What is the role of conflict/disagreement? 12:34 - Do not mistake feedback for criticism. 14:00 - How to disagree with respect 14:36 - One-on-one meetings explained 16:19 - The best PM to work with 17:18 - Practice at work 18:12 - Experience working with Drift’s co-founder 20:26 - Advice to the listeners
It’s a special episode of #Build. Host Maggie Crowley is joined by members of Drift’s Product and Engineering teams. Meet Alexa Nguyen, Senior Product Manager, Trevor Rundell, Director of Engineering, and Peter Karl II, Lead, Product Efficiency. The group chats through how product and engineering can work together most efficiently. That means breaking through the perception that engineers should be wholly removed from the customer. To tackle this problem at Drift, tech leads here are directly responsible for the outcomes of the products they’re working on (where at most organizations, that’s the Product Manager’s responsibility). This gives engineering more context around the products they're building. And empowers them. They’re expected to be on the front lines answering questions from customers. Because at Drift, it’s all about putting the customer first. Learn more about story time and how to get your engineering and products teams better aligned in today’s episode of #Build.  Before you go leave a ⭐⭐⭐⭐⭐⭐ review and share the pod with your friends! Be sure to check out more insights on the Drift blog at drift.com/blog and find us on Twitter @maggiecrowley, @drift and @seekingwisdomio.   In This Episode 0:37 - Introductions of Alexa, Trevor, and Peter 1:44 - Tech Leads vs. Product Managers 3:48 - Creating a space of forward-thinking work called “Story Time” 5:50 - When to bring an engineer into a project 6:30 - Starting Story Time with a well-defined problem 7:44 - What does the customer want? 8:36 - The team discusses their first Story Time. 10:24 - Pencils Not Pixels 11:04 - How to communicate this idea with new engineers 12:00 - What is the role of conflict/disagreement? 12:34 - Do not mistake feedback for criticism. 14:00 - How to disagree with respect 14:36 - One-on-one meetings explained 16:19 - The best PM to work with 17:18 - Practice at work 18:12 - Experience working with Drift’s co-founder 20:26 - Advice to the listeners

Maggie: Okay. Welcome to Build on Seeking Wisdom. This is Maggie, in the flesh this time, actually on camera. We have a special episode today because we have these three all- stars in the room, all stars of Drift, and what we're going to tackle today is how you actually work with engineers. A topic that as a PM, I hear about constantly from other people in the product community. So before we get started, just introduce yourselves.

Alexa: Hi, I'm Alexa. I'm a senior product manager here at Drift, and I've had the pleasure of working closely with Trevor and Pete.

Trevor: I'm Trevor aka T- run, director of engineering here at Drift.

Pete: I'm Pete Karl II, some call me PK2. I'm the lead for product efficiency at Drift.

Maggie: All right. So, the question that I want to talk about is how I've heard so many times in basically every product event I've ever been to, the question of how does one work with engineers? And I feel like everyone always talks about it as if you're this weird species that we need to approach. I don't actually believe that's true, what are you?

Pete: No, we seriously are a different species. But, we're trained by the industry to think of ourselves as a different species, which is funny.

Maggie: And how does that show up in our work?

Pete: At Drift, we untrain that. We teach engineers, some of them who are hardcore about this other species thing, how to be real human beings again. And I think we work, because we don't differentiate. We're just like," Hey, you...."" Hey, adult person, do the thing."

Maggie: To new engineers that join the team, how do you describe the role of engineering here versus product?

Trevor: Well, I think one of the things that we do a little bit different than some other companies is the responsibilities that tech leads have versus product managers. So specifically tech leads are the DRIs for the actual outcomes of the product at the end of the day, be it the actual usage of the feature, the success of the feature, the reliability of the feature. I think in most companies it would probably be the product manager who's usually in charge of those metrics. But, it forces the tech leads specifically, but everyone on the engineering side, to have a lot more context about the products that we're building.

Alexa: What I love about that empowerment though, is that it also comes with a lot of accountability. So if a customer comes to Maggie or I, Maggie's also a product manager, the tech lead is the first person we pull into the call. You guys... With the power comes all the responsibility of making sure the feature actually works, being on the front lines with the customers. We don't shield you guys from any of that, which I really like.

Maggie: How do you balance that with actually having to produce features? Because, that sounds really nice that the tech leads are responsible for all those different things but at the end of the day, the tech lead is also a contributing member of a product team. So how do you do both those things at the same?

Pete: There's two ways to look at that. One is you just be a good time manager. When you sit down, you do your work. Another way to look at it is Drift puts demands on people that they don't get in their other jobs. And I mean that in the best way possible. People maxed out at other jobs have a ton of free time because they just aren't challenged. And here, tech leads especially, it's like," No, you're expected to rise to the challenge." You got to do your job and synthesize results and drive the product forward and be an advocate for your tech people, for infrastructure, all the stuff at once. And I think we start to approach it at Drift. We push people and they respond really well.

Alexa: I think it's also about creating the spaces where the team is doing more forward thinking work. And so the way, at least on my team, we think about the different work we do; we have the future planning and then the daily execution, and we have created this space around the future planning that we call story time. So, it's a way of introducing our teams to new problems that we are looking to solve and introducing everyone in the team to that context. And so you put that on the calendar two or three days before. Everyone reads up on the context, because the product manager posts the one pager, and then you enter this space where everybody has room to brainstorm, really absorb those problems and then when you're outside of that space, you're executing on coming up with a plan, doing the research, shipping the features that you storytimed last week. So being very deliberate about what phases you are in.

Trevor: The deal with story time is we kick off all of our, I'm going to say major product features, but a major product feature for us is something on the scale of a week to a month let's say, we keep things pretty incremental in that sense. So, story time is an opportunity for everybody to get in the room at the inception of that project and to ask a lot of questions. So we have one artifact coming out of story time, which is open questions. And every engineer, every PM, every designer is expected to come out of that meeting with some open questions, which are the work items that they need to actually check off in order to know that they're able to actually technically prove that this thing is possible, or whatever user research they need to do to verify that this is actually something that's valuable or the solution that we're thinking of as valuable. So there's a lot of concrete action items coming out of that meeting, but it's very, high- level, it's very...

Pete: It's high level. But, I think story time is just superb. It's a thing that we execute on very well compared to how other people get engineers involved in the process.

Maggie: I had a question from a friend who emailed me the other day, she emailed a group of PMs and she said," When is the right time to bring an engineer into a project, because I don't want bring them in too early because they're going to go down rabbit holes and they're going to lose the context and they're trying to go too deep on technical solutions and they're not going to be able to have that higher level conversation?" And so it sounds like this is how we've figured out how to solve that problem in some sense.

Alexa: That's what I love about story time. And I'm going to gut check you a little bit, because at the beginning of it, you said," We bring in a feature that we're going to start working on." We don't start the story time with features, which you know, but it was probably a miss communication.

Pete: He's a martyr.

Maggie: We start story times with a well- defined problem and we bring the team around that problem and given the landscape of learnings that we've made, the infrastructure we've built, like," How might we go about solving this problem for our customers?" And what I love about the goal of developing open questions is any time you start to rabbit hole down a," Well, we have to build it this way and connect it this way," you say," Pause for one second. How can we develop this? What question could we write down on the board that would help us solve this later, so we can stay focused around other potential ideas?"

Pete: Well, I think the trigger for story time is this one pager that you mentioned, right?

Alexa: Sure.

Pete: Right. So this is our product management document that states the job that we're trying to get the customer to do or trying to help them do. And I think that's actually the secret sauce in here. We've got open questions, but independent of customer pain or a better version of the customer, you're just going to go down rabbit holes. This provides the directionality we need to be at the product level, and at the customer level, and not at the widget level.

Alexa: Yeah. And that's what I love is we focus less on the solution and we focus more on what does the customer want? What it corrects a little bit is instead of the product manager being responsible for coming up with what they think might be the solution and introducing it to the team, the team is the one gut checking like," Is this the right problem? Did we scope it down far enough? What else have we missed that we should be looking at?"

Maggie: But it's not like you guys, when you started here or whatever, that you just walked into story time knowing exactly how to do it, right?

Alexa: Is that a leading question there?

Maggie: No, because I know that in the past I've written specs at other companies where it was the problem we wanted to solve, but really it was like," This is what I want to be built."

Alexa: "Theproblem we want to solve is to build a reporting dashboard." And it's like," No."

Maggie: Exactly. So, how did you get to this point?

Trevor: Just thinking back to that first story time that we did, and the thing that actually got us all on the same page is when we came up with that tagline, it was like- Yeah, well, not'develop open questions', but the actual outcome that we were trying to solve for, which was like," Greet your prospects with a personalized message on your site."

Alexa: This is a project that we worked on probably a year and a half ago. Almost a year ago to this day. crosstalk

Trevor: I think once we had all had that same story in our mind of like," Okay, does the problem that we're actually putting forth or the solution that we're putting forth, solve that problem?" We immediately all refocused on a much narrower idea. I think that eliminated a lot of the conflict that we had early on. Just trying to butt heads and like push our own agenda forward, where we really needed a line.

Maggie: It's almost like a leadership principle, except using that same tagline approach within your product building.

Alexa: Yeah. But it's like," All good process is born out of necessity." Right? So, like Pete said, we were arguing a ton about," Oh, we need to go build this. We need this. This is an important problem to solve." And when we-

Pete: We both had the wherewithal to say that we're arguing to get to the other side of something. We just need to figure out what it is.

Alexa: Right. But, what all of our spiraling arguments always ended on was," Wait, what was the problem that we're trying to solve again?" And so we realized we needed this strong, simple tagline to latch onto. And we try and come out of every single story time with some hashtag or some one- liner that is simple and repeatable and that everyone can grab onto when they're making decisions in their everyday job.

Trevor: Absolutely. And you carry that title on, all the way down the line. But, I think there's another tagline that I really love.

Alexa: It's in some of our press releases too, which is like-

Trevor: Oh, for sure. I just saw it like last week. So it's being reused, even a year later, which is cool. There's another tagline that I really love that I think fits really nicely into that process. And I think I stole this from an envision blog post from last year, which is," Pencils, not pixels." So, early on in the process, you really want to focus on that pencils level, just sketching, wireframing of an idea, rather than going straight for the very specific, technical or graphical design. It keeps everybody at that high level where you're repeating the story back to each other and developing those open questions as opposed to going down the rabbit holes. As soon as you start actually putting together actual hard designs, things get very over specified very quickly.

Maggie: Pete, when you're bringing new engineers in, how do you communicate that? Because, I think it's really simple to say," Pencils, not pixels", but-

Alexa: What the heck does that even mean?

Maggie: Even when you say that it's like," Well, I can use a pencil to draw a release specific design."

Pete: I break it down in as simple terms as possible. And I basically say," Look, your singular goal here is to synthesize results. Not predict, not plan for, not create a roadmap for." Right." Your job is to not try to predict what's going to happen, but to create what's essentially experiment." Right. Break your problem down so small that you can execute on it immediately. Right. They plug right into that once they see," Oh, well, what about this?" Or" We don't have to be concerned about this weird performance thing." And they start to wig out and I'm just like," No child." It's just about bucketing, all your thinking so that you can focus 100% on each task you're working on.

Alexa: I'll bring back the question that you asked earlier, which was," What is the role of conflict in this?" Any new relationship requires conflict early and often. Right. To build that trust, to understand how the other person thinks, how they work.

Trevor: And I don't think it's conflict, I think it's more like disagreement. In order to ask a question, you have to be willing to disagree with the status quo that's already out there.

Alexa: Which can be hard.

Trevor: Yeah, exactly. And making a space where everyone's comfortable to disagree enough to ask that question, I think has been something that your onboarding process has actually been very successful at.

Pete: Yeah. Now that you mentioned it, I actually do... One of the things that I repeat over and over and over again is," Not to mistake feedback for criticism."" You're at Drift now. You are hereby being invested in by everyone around you." And so when people say," Hey, consider thi. Hey, try this, et cetera." We model feedback and candor really well everywhere. I think maybe some people are super compatible with responding to that very quickly.

Alexa: So, to bring it back to story time, what's interesting about always having that tagline upfront is the disagreement can always center around the outcome you're trying to drive the user towards. Right. And so you're not disagreeing with somebody's opinion, you're disagreeing with whether or not what they're suggesting will actually create the progress that you're looking for.

Pete: Right. It's not happening to you. It's happening because of you.

Maggie: Right. But, didn't you have a story time, Alexa? You had a story time where a couple of new engineers or people on your team didn't say anything.

Alexa: Yeah.

Maggie: Right.

Alexa: Yeah. And I think it's because they weren't comfortable. Right? Any new relationship requires that trust. And if you haven't practiced disagreeing before... T-run and I are in a fight right now, you might not know it. We had a big argument this morning. He's looking at me.

Trevor: We hugged it out.

Pete: They didn't hug it out. No, I'm just kidding.

Alexa: So, the reason why I appreciate my relationship with T- run so much is because we disagree constantly, but it is always on this foundation of respect and trust and knowing that the other person is trying to do what's best for our company and our customer, and it's not ever a personal. Right. But it took us a long time to get to the point where we are today, where we don't think it's personal. Right.

Pete: So wait, are you saying that the only way to form a long lasting relationship with an engineer is to just get in frequent arguments with them, which somehow lead to some resolution.

Alexa: Yeah. That's exactly what I'm saying.

Maggie: Let's talk about one- on- ones, because I think those have such a huge role in how you actually start this relationship. Because, I think it's, again, it's one thing to say," Pencils, not pixels"," Have conflict early and often", but how, right? Cause a lot of people, myself included, I'm an introvert, I don't want to have meetings. I don't want to have intense personal conversations, but you have to. So, one- on- ones, I feel is the structured way to do that. So, is that what you use, to do this?

Trevor: Put yourself in the other person's shoes and figure out exactly what it is that is pressuring them to argue that position. Is it some deep tactical knowledge that they have? Did they talk to a customer? Are they trying to save a customer who's trying to churn? Are they trying to like a get a deal done?

Maggie: Do they have a different understanding of one of those... Like a different perspective on that same fact that you think you both share?

Alexa: Yeah. It's usually that you're missing some key points of their perspective. Do you come

Pete: Do you come from a long line of product managers that you have to now... You're going to have to live up to the family.

Alexa: Definitely.

Trevor: Bosses is putting pressure on you is definitely a real thing. That is a thing that often causes people to do things that are out of character for them. And the faster you're able to recognize that that's the basis of their position right now, the faster you can actually come to some sort of agreement. It's like," Okay, I see where you're coming from now. Let's move past that and figure out a solution to that together."

Maggie: Okay. So obviously you guys have formed a really good relationship. I had that awesome interaction with Andrew the other day. I Actually had Luke tell me that he wanted to have more one- on- ones, because he wanted to be like you guys, which was really adorable. What is the, who is the best PM or engineer you've worked with? And what, of those behaviors, have you brought to this?

Trevor: So the best PM I ever worked with, my first boss actually, when I was in college still, and he later became my mentor and he's still very good friend of mine. But, I joined this startup that, at that point in time, was only three people. And the cool thing about startups at that stage is you get exposed to a lot of different hats. And he brought me on to a lot of customer calls and we did a lot of really white boarding sessions cause we're literally just figuring stuff out. And the thing that I think really took our relationship to the next level is at some point we actually just started on the weekends, getting in front of a whiteboard together and jamming on ideas that we thought were cool, and practicing that storytelling product or project breakdown process. And the exercise of actually breaking those problems down and going through the early stages of them was a really great way to build up a relationship and understand what the context and experience that each of us was bringing to the table was.

Alexa: It's like you practiced working together.

Trevor: Yeah, absolutely.

Maggie: I want to know how to do that at work though. Right. That idea of practice at work is something I've been thinking about and, I think Pete, you were talking about that earlier today. Bringing that same sense of repetition and reps and sets, but actually doing it without... Because we still need to ship things.

Pete: Actually, I draw some inspiration from The Score Takes Care of Itself, which is superb, Bill Walsh book. You think about it, professional athletes are enormously good at introducing practice into their work. In professional sports you don't just give an athlete like$ 40 million and say," Go win some championships. Good luck." Right. I feel like the idea of drills is something that is so important. And I think having all the PMs in a room and saying," Look at that PM, do this." They're doing it right. They're doing it super well. Right?

Maggie: Yeah. Like tape review, almost.

Alexa: Yeah. We do try and visit each other's storytimes.

Pete: Yeah. So those sorts of things I think are... They seem like they're the key to getting this done. Yeah. I joined Drift at about 20 some' people and I had the pleasure of reporting directly to Elias Torres, our co- founder and CTO. So ET has been through this many, many times. I think he's got something like 20, he says 20 years of experience often. So he's like," I got 10 years when you." He really, really impressed me. In just a few short conversations, a few one- on- ones, he was able to surgically and very tactfully unlock some of that raw engineering expertise, which was just laying around. He did it mostly by helping me see, helping me understand how deliberately my actions should be when I'm working. He was like," Look. Look at me." He's like," When I sit down, I have 15 minutes, maybe 30 minutes in front of the computer. I have to get, I have to ship something. I have to say, I need to get something up and out in 30 minutes, what's something I can break down that small." Right. And that kind of discipline, caused by the fact that the whole company is riding on his shoulders, and DC's, was inspiring for me, and it gave me a model to work after. It was crazy. From that day forward, I sat down. I said to myself," When I sit down, I got to sit down to ship." He knows how to get you revved up around something. He's like," Okay. What'd you do? Okay. Pete, you're refactoring this thing. How long did you spend on that? You just put some new buttons on the page. That took you four days. Why'd that take you four days?"

Trevor: But, it's not comfortable, right? crosstalk.

Pete: ...100% on trial, but you're not defending yourself. You're you're not really on trial. That's him investing in you in shaping your perspective and just being like-

Maggie: How did you figure out that, that wasn't him just messing with you, right? How did you know that he had your best interests at heart?

Pete: It was faith. I just had to take it on faith. I was here to learn. Right. I was here to be invested and I think I just had to remind myself of that. Not to say that there weren't moments where my pride was... Bruised is putting it lightly. But, ultimately that was for my benefit. It was for Drift's benefit. It was for the team's benefit. It was for everyone that I worked on that. Not going to say fixed. It's still a work in progress for sure.

Maggie: I want to hear one piece of advice that you would give to everyone listening. If you had to help them go back to their teams right now and start to build more productive and better relationships.

Alexa: Fight more.

Trevor: Okay. Right to the point.

Pete: Can we edit in part of the Mortal Kombat theme?

Alexa: No, seriously. Don't be scared to disagree. And the more you do it, the more comfortable everyone around you is going to be with disagreeing with you, and then you'll build better products together.

Pete: On top of that, I would encourage everyone to have a conversation with someone that has nothing to do with work. Right? The two of you are going to work together, very close quarters, and you don't have time to experience months and months and months of working together to build a rapport. And I think the best way to supercharge that is to just go out, have a conversation, learn where each other came from, how you got into the business. Introduce a little vulnerability into it and you will fast- forward that rapport building. And that helps.

Maggie: Awesome. Well, thanks guys. I really appreciate you taking the time to come on the podcast.

Trevor: Yeah, no problem.

Pete: For us this was fun.

Maggie: Thanks. Now we can go back to having constructive conflict, with each other.

More Episodes

#171: Working Backwards with Amazon's Colin Bryar and Bill Carr

#170: Avoid Consensus (Unless You Want Average Results)

#169: Introducing The American Dream with Elias Torres

#168: Seek Arbitrage Opportunities

#167: The Culture Episode

#166: Why DC Went on a News Fast and How You Can Too