A conversation with Matt Bilotti from Drift
During this week’s Product to Product episode, Amy Chyan Product to Product podcast producer & host, chatted with Matt Bilotti, Product Lead, from Drift.
Matt shared his core principles for building a product org and how these principles help drive business goals forward. By aligning his product management team on these principles, they’re able to solve customer problems and balance achieving business metrics like revenue. Matt’s talk is jammed packed with helpful information — we highly recommend watching it!
If you’re tight on time though, we’ve pulled out some highlights below.
Highlights
(The highlights have been condensed and edited for clarity.)
Falling into product (1:35)
Amy: So Matt, a lot of… Like a lot of PM’s, you used the phrase, “You landed head first into product,” and you’ve had a bunch of experiences at product companies, but can you share a little bit about your career trajectory?
Matt: So totally fell into it head first. My friend had just started a startup and I was looking for a gig and I reached out to him and said, “Hey, can I work with you?” Just because I thought he was really interesting to work with and learn from. And he said, “Yeah, we actually have this spot for someone to be a product manager on this new thing that we’re building out.” And I said, “I don’t know what that is, but if you think I could be good at it, sure.” And so I did that, that product and company crashed and burned about nine months later, it was quite an experience. And then after that, I just kind of kept following people that I felt like I can learn from a ton. And that led me through a couple other product roles, one at HubSpot, where I worked there for a while.
And then more recently, I joined Drift where I’ve been for the past five years now, which is way longer than I thought I would be here. But I joined as the first product manager on the team before we had any customers or revenue. And I’ve seen the company grow since then. And my product role has evolved quite a bit over the time there. And I’ve done product with a growth lens. I’ve done product with a product launch lens. I’ve done product with all sorts of stuff here at Drift, so that’s some quick background on me.
To ship or not to ship? (4:42)
Amy: So in our pre-interview, you talked about the importance of getting something shipped and then being able to iterate on it and that being a very valuable thing. But then we also discussed that this may not be the way that enterprise works since they tend to be legacy companies and with more red tape. So can you talk about the flexibility then, that a PM needs to tune into?
Matt: So the quick context on that is when I first joined Drift, we started as a free offering really and have moved up market. So the very first Drift offering of a paid account was $10 a month. And then we rolled out a $50 a month plan and then $500 a month plan, and now we have people paying us thousands of dollars a month for our platform. And so the types of process that we use to ship product when it was the free, low dollar value offering to small, medium businesses and all that, looks very different than what the enterprise offering is, which I’m learning today. And with low stakes, low dollar value, it’s really easy. And I would highly encourage to have a mindset where you’re just like, “Get the thing out, just keep getting stuff out,” learn as you go, ship the thing and iterate on it over time.
And the reality that I’m continuing to learn with enterprise is that the threshold for frustration is much lower. And additionally, the amount of time that it takes to get an enterprise customer up to speed with something new that you built takes a lot more, right? Because generally it’s not just three people operating on your tool, they’ve trained a whole team of 30 people using a part of the product and then something changes for all of them, right? All those people have to get retrained. By trying to solve their pain and shipping faster, we actually caused them more pain because of the internal change management that had to go on. And so the way that I’ve learned to think about that stuff is quite different.
Matt’s core principles for building a product org (7:07)
Amy: What would you say are some of the core principles for building a product?
Matt: The base has to be customer driven. I think it’s really easy to get caught up in making decisions as a product organization or as product people, or as product teams that are driven by the viewpoints of all the super talented folks on your team, right? So discussions turn into debate between the designer who wants it to look this way and have this UX. The engineer says that this part’s really complicated and the product manager wants it to operate like this other tool in the marketplace, right? And you wind up with those three competing opinions, but at the base where I think those teams fail is they make the decision based on those things rather than ignoring all of that and then making the decision based on the customer.
So I think the fall back and really the forefront of the decision needs to come from a customer perspective. I think I’ve also just spent two years running and operating growth teams within Drift. And the way that growth teams operate are very scientific method oriented, right? So what are the observations? What’s the hypothesis? What’s the process for experimentation and what are the goals and outcomes and did it work? That’s not exactly what the scientific method is, but it’s similar. And the way that those teams operate are super process driven.
Being experiment driven, hypothesis driven, goal and metric oriented and so that’s another principle that I think of. And then one of the things that we’ve started to do more and more of is set actual revenue goals for product teams. So for example, I mentioned that I lead one of the enterprise offerings that we have. One of the goals that I have set for that group over this quarter is to drive a certain amount of pipeline revenue for our sales team, as a result of that product directly attributed to them selling our product. And so I think that, that’s something that I’m seeing a ton more benefit of more than negative. I think it’s really easy to see that it’s negative, because it’s like, “We’re driving pipeline, but you’re a product organization, you can’t control that.” And so there’s a lot of tension with that, but I’ve found that the benefits outweigh the negatives in that case.
Balancing customer needs with business needs (10:13)
Amy: And so one of the cores is being very user centric and very empathetic towards the user. But then you also talked about having a business metric tied to growth and is that what I’m getting? So then how does that product team help drive the… How is that balanced? We always ask that. How do you balance that out with your customers wanting certain things, which you know is going to get you a lot of money versus your product team saying, “I don’t think that’s a timeline we can actually do.” How do you balance that?
Matt: Yeah. So here’s my take on this. Let’s use the example of driving pipeline. It is beneficial for me as a product person to anchor myself in. Can I equip the sales team to sell more or a similar goal can be retention numbers or upsell or expansion numbers on the customer success side of things? Can I as the product person build something that solves for driving more revenue or keeping more customers or driving new sales pipeline, because really the only way that I can successfully do that is by solving real customer pains, right? Because if I am rooting in solving the true pain, then it becomes super easy for the sales teams to sell the thing, right? Then they’re singing our praises all day long because they’re like, “I could sell this thing like this because I point it out,” and the customer’s like, “I have that problem too.”
And then they purchase because it’s very apparent, right? The tying of that is super clear and same thing with having the metric tied to retention. I also think that it’s really important because it forces myself as the product lead and then the PMs themselves, to not forget about all that goes into equipping the rest of the organization to make the thing work. Because if your metric is purely just, I don’t know, number of people that take an action within an app, a part of the app that you’ve built, it becomes really easy to just live in the product world and find places in the app to slap on little promo things like tool tips, or links to your new page that you built or whatever it is. And then your whole product organization becomes to drive this action within the product, but the best way to succeed as a company in serving your customer is to make sure that your support team knows exactly how that thing works.
Matt’s advice on what to do if you hit a wall as a PM (15:26)
Amy: In our pre-interview, a piece of advice you’ve historically given to junior PMs or APMs is something that was passed on to you, you said by your former boss and it’s that all PMs hit this wall around month two to four, where everything makes them feel like they’re not meant for this job. And so what are some things to do to help PMs get through this period? When they’re in the pits of despair, questioning their abilities and going through imposter syndrome, maybe they’re new at their company. So they don’t want to even slack someone and be like, “”Hey, I really need help. What should they be doing to ask for this help?
Matt: I think everyone goes through it in either the first role that you’re taking as a PM or in a new organization. I watch a ton of seasoned PMs show up at Drift and there’s always this pit of despair that folks go through and my best advice is one, you will not make it through and be successful unless you continue to ask questions and do whatever you can to learn about the customer and the problems that you’re solving. And I think the second piece is that often that happens because this feeling of I’m failing at this role shows up because you start hitting walls and maybe the engineering team’s telling you that this is way more technical than we can deal with right now. Or the support team is saying, that they’re like, “How can he be working on this thing. There’s these 12 other problems right now.”You start to get this cacophony of feedback from everywhere.
Two, you have to remove your own ego of having the right answers from the equation and three, having your own very clear prioritization system against it is critical. If you’re in that mode and you’re just trying to be reactive to stuff, it’s not going to work unless you have a really good system for yourself for organizing all of that, whether that’s your own system, whatever it might be, a tool, a spreadsheet, a note pad, whatever. You have to have some baseline there, or else you are going to get super overwhelmed and then start to break down in that place. And it’s a tough place to be, but it’s important to know your system, know that you don’t need the answer, you just need to find the right answer.
Should you try to solve everything as a PM? (18:17)
Amy: What do you say to PMs that think they can solve everything within their product work? Have they lost the idea of what a PM should be doing in that role?
Matt: So the way that we think about product management at Drift is that it’s actually not on the PM to craft the solution, it’s on the PM to frame, to give the clearest framing and understanding of the problem and arm the designers and the engineers to create the best solution. So I have found that this system works really well because I am not the talented designer and I’m not the person that can build the code. And so when you hand over the ownership of creating those solutions to those around you, and you pull in the rest of your organization, like your customer success managers, your salespeople, all that, into the solution crafting, you actually wind up with better solutions.
Building trust within your organization (20:37)
Amy: Do you have any advice on how to build that trust within even your team and cross-functionally as you’re working on something?
Matt: I think the trust gets built with very clear proactive communication from you as the product manager and then transparency into the decision making process. I think that the best path forward is to just point out where we’re going and help everyone see this new thing that’s being built and why it matters and why it’s important. And I think that the more transparent that you can be about this, all the blank space as to why you’re not doing this other stuff, I think you actually wind up in a better space with the rest of your team and your customers. It’s important to highlight what’s not being said as much as it is the thing that you’re bringing to the table, because that’s how you gain the trust, because then they can understand like, “Oh, if I were in your shoes, I would also make that same decision, right?” Rather than this black box of we just make the best decisions. I think that, that’s a really important way to build trust.
Audience Q&A Period
(23:19) So here’s a question we have. You’ve seen Drift grow while being involved with the product side. What was the biggest challenge you faced while scaling up and how did you ensure your customers didn’t lose interest in this period?
Speakers
Matt Bilotti is a Product Lead at Drift, where his team owns a recently launched enterprise product offering, as well as all of the product-led onboarding. He’s been with the company since they signed on their first customers and had many hats along the way, which include running the support team, a growth team, a business unit, and much more. Before Drift, he spent some time at HubSpot and other Boston-based startups doing product-related work.
Amy’s a Content Marketing Specialist at Roadmunk on the Marketing team. She produces Recess, the Product to Product podcast and video content. Prior to Roadmunk, Amy worked as a journalist in various Canadian newsrooms and wrote for publications like NBC, CBC, Vice and more.