#164 – The role of Product Manager in tech startups: Ownership, communication, and leadership | Patrick Malatack & Maz Brumand

A Product Manager’s goals are advocating for the needs of their clients and their team. A good Product Manager doesn’t just dictate orders to their team; they guide the team toward success. Patrick Malatack, VC at Matrix Partners, offered us a look into what the Product Manager role in tech startups looks like in terms of ownership, leadership, and communication.

06:07 – Help your team be successful

A lot of people think that being a Project Manager means being the boss. But really it means doing everything you can to help the team be successful.

I think a lot of times folks start with that like you’re the CEO of the product mindset and that lends them I think down the wrong path, which is like, hey, I’m the boss. And that’s not actually your role on the team. Your role on the team is to help the team be successful and do whatever it takes to make that happen. And so, I think it’s… when you say CEO, I think it doesn’t generate the behavior that I found, create the most effective PMs in the organization. So, that’s one way I always talk about your role within the team is just look around, see what needs to be done, and if no one’s doing it, you should be doing it or find someone else to do it in the organization.

07:43 – Advocate for the needs of the customer

Make sure your team prioritizes the needs of the customer and advocates for what your clients need the most.

The role within the company is around making sure that you’re advocating for the needs of the customer. And I think in some companies, you have a pretty clear understanding of what the needs of the customer are, you may be a customer of the product yourself. In another environments, that’s not the case. And so, I always work from how do we make sure that we have a team that’s advocating for what our customers are really advocating for, independent of all the other things that are going on and making sure that product managers see that that is their responsibility ultimately. Are you spending time with the customer support team and understanding what challenges customers are seeing every day? Are you thinking about the needs of customers you might not even have today? Doing interviews on prospective customers and really advocating on behalf of customers.

11:45 – Don’t give employees responsibilities they don’t own

Don’t give someone on your team ownership and responsibility for a problem they don’t—and can’t—own.

One of the biggest failure modes, and I’ve made this mistake as I’ve structured teams in the past is giving someone ownership and responsibility for a problem that they don’t actually can’t own that requires too many, well, to get that done we need to go up the chain and then back down the chain. And they’re not really autonomous to go after whatever that objective is that they own. And so, one of the big things I tell folks is like you want to make sure that when you’re giving someone a problem, you’re chartering them with ownership over a particular problem that they have end to end ball control around solving. And you don’t want to find yourself in a spot where it’s like they actually can’t actually achieve those goals with the resources that they have in front of them. And we want to be creating owners but also giving them a scope and autonomy within that area so that they can be responsible for those outcomes and you can hold people accountable. And I think a lot of failure modes in product teams, both that I’ve made mistakes of in the past and have been a function of this, hey, you own something but you don’t actually own it and it’s a shared responsibility across 15 different teams, and the PM is just only negotiating all day long but not actually accountable. And I think that can be a failure mode in a lot of organizations.

14:43 – You shouldn’t need committees

If people in your organization are self-creating committees to solve problems, you’ve probably done something wrong as a leader.

Anytime that I found the organization self-creating a committee for a thing, I’m like, “Oh, I probably did something wrong here as a leader.” If the only way we’re solving this is some weird committee that’s been set up, it’s like there’s probably not the appropriate responsibility and ownership here that a committee needs to be put in place. And so, I was one of the organizational words I would listen for is like, “Oh, no, we have a committee that’s solving” that I’m committees don’t solve things particularly efficiently. And so, that was of one this warning sign for me.

24:00 – Use your own product

If you want to understand your customers, you need to actually use the product you’re trying to sell to them.

You should be using the product every day. And I said I hired mostly technical PMs because we had a technical customer and folks knew this about me before we launched any product, I would use it. I would typically break their product in some way, shape or form. They’re like, “Oh, crap, Patrick’s using this thing in a way we didn’t attend.” And so, I filed a lot of early bugs. But for me, that was about making sure I had the customer empathy and making sure that I was a user of the product as well. I think it’s hard to be a good product manager if you don’t really understand the needs of the customer. And so, doing everything you can to put yourself in their shoes I think is really, really important.

28:29 – Cut bad features

Good product managers aren’t afraid to cut their own features. Their goal isn’t to keep the features they’ve created, but to solve problems for the customer.

The other thing I often told folks in my organization is like, listen, good product managers will cut their own features. They will realize they go down the path, someone in the organization said, “Hey, we need to solve this.” They go explore it and they find out like no, it’s actually not the right solution. There might be this other solution over here that we should actually pursue, and that’s okay. And you shouldn’t be afraid of real spending the time fleshing out what the thing is and deciding, hey, this probably isn’t the right investment for us and here’s why. That’s actually a sign I think of a healthy product manager and a healthy product team that they went after something and they came to a different conclusion that actually more important is to solve this other thing over here. So, those were some of the things we would do before we ever got to that PRD.

31:09 – Be efficient with your time

The best product managers have an enormous amount of capacity because they’re so efficient with their time.

The best product managers I know just seem to have an absurd amount of capacity. They’re the first to respond to every email. The type of people that I think are attracted to doing that type of work tend to just be very efficient with their time and very, very focused and able to get a lot more done than you might think. And I think ultimately, I think you run the risk if you have too much product capacity, which I think is far more damaging than too little. You run the risk that ultimately people are creating work that doesn’t really need to be done. And at the end of the day, I always talk about product managers create work, engineers… to solve it. And as you’re growing as a business, as a company and trying to improve your product, you do need to create work, but that is the role of product. And so, if you have too many product managers, you’re going to have way too many things not getting done. And I don’t think that’s good for the product managers either, they’re feeling demotivated that they don’t get a lot done.

34:39 – The difference between stress and pressure

Pressure is good and forces you to do your best work. Stress, however, is when pressure gets compounded and ends up slowing your progress. Aim for pressure instead of stress.

There’s a difference between stress and pressure. Pressure is actually really, really good. And I actually think most people like pressure because it forces them to get the best out of themselves. It helps you get clearer about what’s important, what’s not important, how you spend your time, how you shouldn’t be spending your time. And so, I think there’s a difference between stress and pressure and ideally where you want teams. And I think teams are most happiest, frankly, even more happy than really bored is when they’re in that I know there’s a lot of pressure on me, the organization’s expecting me to deliver. I think that’s great. It focuses my energy versus stress. And what happens when you get stressed is you see yourself cycling the same thing again and again and again, and you’re not actually making forward progress. And so, to me, the way I always looked at it is we want to make sure that the teams we have are feel like there’s pressure on them to deliver. There’s pressure on them to deliver on behalf of the customer and I think that that is generally healthy. And you can see it from the teams. The teams get excited. They’re excited about what they’re building when they’re in that pressure zone. When they’re in that stress zone, it generally moves away from excitement into the despair. And rather than saying, “Wow, that’s a lot to get done. Let’s figure out what we need to cut to make sure we’re able to hit that date” which is of somewhat in pressure, that’s what they’re thinking.

38:55 – Communicate the company’s goals

People need to know that what they’re working on is critical to the company, which means you need to be able to communicate the company’s goals clearly.

I’d also check in on how I was doing communicating when I thought were the company’s goals. Because I think some of this is also knowing that what you’re working on is critical to the company. I think it’s pretty important to help folks feel like they can tackle what’s in front of them and that they have supported the organization. And so, one of the things I started doing later on was in my one on ones with team, I’d say like, “Hey, what do you think are the top three goals you think I have for you?” And so, it was like there could be no wrong answer. I would look the other way and let them write it on the whiteboard. And then, we’d turn around and I would have what my top three goals for them were. And we’d see, is it the same or is it different? And it’s not like anyone’s in trouble if we’re wrong. If anyone’s in trouble, it’s me because I’m communicating what I expected the team. And so, we would basically do that as a calibration exercise. And the first few times you do it, you’d be surprised. Some leader that’s responsible for a really important area thinks what you think is important. They think a completely different set of things than you do as their manager. And it’s like, wow, it’s a good way to get to truth real quick and get everyone aligned. And for me to get feedback on how well I’m communicating what’s important to the company too.

41:54 – Let people call you out

High-performing employees are not afraid to say, “You can’t hold me accountable for that because I do not own it.”

One of the things I’ve noticed about high performing folks is that they will usually call out very directly. Like you can’t hold me accountable for that because I do not own it. And it’s like, oh, great. And now, we’re having the conversation up front around what it would mean to hold them accountable for a particular outcome and what they would need to own in order to do that. And that’s I think one of the things is that there’s a set of folks that, at least in my experiences, are much more willing to push back around ownership of areas they don’t feel like they can fully execute against versus folks that oftentimes just don’t vocalize that. And you don’t find out until the thing is already not succeeded or it’s off the rails, and I think that’s one big thing. I always encourage folks, it’s like you got to speak truth to me and this is a safe place. Any conversation is okay. If I define the problem wrong, I made plenty of mistakes around here and I do want to hear about it.

Patrick Malatack (00:00:06):

We do want teams to feel pressure, that’s what a high functioning organization is doing. But they shouldn’t feel like they’re despair and there’s no way they’re ever going to accomplish this thing because it doesn’t lead to effective action. I think the number one thing though is creating that ownership.

(00:00:21):

A lot of things that might have felt like despair don’t feel that way because you feel like you’re an owner, you feel like you’re responsible for your outcome. And so, that earlier conversation around defining ownership, defining ownership allows you to put people under some amount of pressure and them to actually feel right about.

Ben Grinnell (00:00:45):

I’m Ben Grinnell, part of the early startup team here at Levels. We’re building tech that helps people to understand their metabolic health and this is your front row seat to everything we do. This is a whole new level. Product is what we do, it is levels. Levels in every way.

(00:01:16):

We make a software product built on top of hardware, the CGM. So, Maz Brumand had a product, he sat down with Patrick Malatack. Patrick spent time at Twilio as VP of Product for seven years. And he had a lot of learnings, a lot of the takeaways of how a product manager or somebody who’s leading product can think very much about this idea, this role.

(00:01:38):

Really, what it comes down to is a lot of the same principles that we discuss time and time again. Things like gleaning insights from talking with different users or as we call them members, things like taking feedback into account and building continuously iterating and experimenting as fast as possible.

(00:01:55):

So, Maz and Patrick sat down and discussed all these different principles of product, how to think about the role, really what it does and how they can be the most effective to continue pushing things forward. Anyway, no need to wait. Here’s where they kick things off.

Maz Brumand (00:02:09):

One of the things we think about is, I think even starting from the top, really defining the rule of the product manager. That’s something that I think very different people have different views anywhere from the PM is the CEO of the product to the PM is arbitrary of priorities to… no, there are many different definitions based on what the specific need for the company is.

(00:02:43):

And you know in using the product, our company is very much consumer focused, and it’s very much in the business of building trust for members or solving problem and delivering value. So, it’s very consumer member centric. And so, we think about product with that lens.

(00:02:58):

And what we’re trying to do here is really provide an experience that people get out of it and say, “Wow, that really helped change my life. And something that I want to actually use as part of my wellness journey for many years to come.” It’s not something that is just here and now and when I learn something and I walk away, but really something that will become a core staple and a trusted department in people’s health journey, specifically [inaudible 00:03:24] health.

(00:03:24):

So, that’s our north star. And obviously, we’re building towards that and really right now, we’re focused on helping that 30, 90 days to a year experience to make sure people really understand how food affects their health and build from that into something that becomes a part.

(00:03:40):

So, with that context, the first question is what is the role of a product manager in that world? So, love to hear your thoughts on what do you view a product manager’s role to be?

Patrick Malatack (00:03:52):

Yeah. I mean I’d caveat everything, with my experience was not really on the consumer side, more on B2B. But I do think this is at least the way I always thought of the product role and it’s a little bit different than that. Hey, you’re the CEO of that product line.

(00:04:10):

And I think a lot of times product managers get the wrong idea of what they’re supposed to be doing and how they’re supposed to be operating within a team. And so, I think there’s both how I describe it as your role within the team and then the objectives you’re trying to carry out for your customer.

(00:04:30):

And within the team, I always say the role of the product manager ultimately is to look around the team to see what really needs to be done for that team to be successful with whatever their goal is in the organization. See what isn’t getting done that needs to be done for that team to be successful.

(00:04:51):

And ultimately, it’s to go figure out either who should be doing it, or do it yourself. And the way I think about it is there was this TV show back when I was growing up called Quantum Leap, I don’t know if you’re familiar with the show. But in Quantum Leap, you would basically materialize inside of someone’s body and then figure out what he’s doing.

(00:05:15):

And part of why I want the product all along was that notion of you’re a jack of all trades and master of none. And I think product managers tend to be that on their team, they have a bit of business skills but they’re not the BD person. They have technical skills but they’re not running code every day.

(00:05:34):

And they have obviously some experiences in pricing and evaluating business performance and metrics, but generally they’re not in finance. And so, you tend to be the jack of all trades, master of none, that’s the role. And what makes you most impactful I find in teams and organizations is seeing what really needs to be done that isn’t currently assigned to someone.

(00:05:56):

Either going and doing it yourself if it’s appropriate or making sure that someone in the organization is putting attention on that thing that still needs to be done. And I say that to say because I think a lot of times folks start with that like you’re the CEO of the product mindset and that lends them I think down the wrong path, which is like, hey, I’m the boss.

(00:06:18):

And that’s not actually your role on the team. Your role on the team is to help the team be successful and do whatever it takes to make that happen. And so, I think it’s… when you say CEO, I think it doesn’t generate the behavior that I found, create the most effective PMs in the organization.

(00:06:38):

So, that’s one way I always talk about your role within the team is just look around, see what needs to be done, and if no one’s doing it, you should be doing it or find someone else to do it in the organization. And I always joke with folks. Oftentimes, that’s like, listen the team staying late and no one has ordered pizza at the office or whatever.

(00:06:59):

Or, working from home equivalent of that is those are the things you should be thinking about as a product leader in that team is just like, what does the team need? How do we help each other? And I think when product managers approach the job that way, their role within the team, it’s actually, you create a lot more trust within your team.

(00:07:21):

And folks are servicing a lot more things that they think are broken to you even if it’s not something that is within their control, but it might be something that you know how to go ahead and solve. And so, I like to talk about people working within their teams that way. You’re sure a servant for the team and making sure that they’re most successful.

(00:07:39):

I think ultimately though your role within… the role within the company is around making sure that you’re advocating for the needs of the customer. And I think in some companies, you have a pretty clear understanding of what the needs of the customer are, you may be a customer of the product yourself.

(00:07:56):

In another environments, that’s not the case. And so, I always work from how do we make sure that we have a team that’s advocating for what our customers are really advocating for, independent of all the other things that are going on and making sure that product managers see that that is their responsibility ultimately.

(00:08:15):

Are you spending time with the customer support team and understanding what challenges customers are seeing every day? Are you thinking about the needs of customers you might not even have today? Doing interviews on prospective customers and really advocating on behalf of customers. And so, at Twilio, a lot of our product management team really had come from technical backgrounds and many of them had actually been CTOs of a startup before they joined Twilio.

(00:08:41):

And that was something I really looked for because that that’s who our customer was, we’re selling to developers, and so I wanted folks on the team that knew what it was like to build and knew what it was like to write code every day. And so, I think what the profile of that person looks like may vary team to team and depending on the type of problem that you’re solving.

(00:09:01):

But I think the biggest thing they need to be doing is advocating for the needs of the customer is what they should be injecting into the team. And then, with respect to the team, it’s figuring out what all needs to be done that isn’t being done today that’s blocking the team from being successful and making sure that that gets resolved. As I said, it’s this jack of all trades, master of none.

(00:09:23):

You need to really just embrace that as a product manager and just assume if something isn’t getting done that’s really critical for the company, for the customer and for the team that’s on you to go figure out how to make it happen.

Maz Brumand (00:09:34):

I really love how you reframe the concept. I think CEO is a shorthand. And I really like how you reframe the concept of servant leadership, which is I’m here to help people get their job done most efficiently within the team and also make sure that we extract the needs from our members.

(00:09:52):

So, really, they’re serving the member answering the team to get the job done effectively. And I think the concept of CEO, your right can be conflated with the person in charge versus the person that their role they, they’re going to own the outcome. They see themselves as the owner of the success of whatever feature product they’re working on.

(00:10:11):

And to do that, they’re basically serving both number one, obviously, the member, because we don’t get the need and understand it and not through advocate, missed the mark automatically. And then, second is once you understand that, how can I help the team achieve what they need to do if its people are working really late and they need the pizza, that’s what it is.

(00:10:29):

If it’s understanding there’s friction between product and design and engineering, figuring that out and making sure that people are really working at their best, that seems to be the theme I witness. And I think what you just explained.

Patrick Malatack (00:10:44):

Absolutely. And I think that ownership concept I think is super important. And I said, every team looks quite different depending on what type of problem you’re trying to solve on behalf of customers. Some teams at Twilio were design heavy because there was user interface, onboarding, those types of things.

(00:10:59):

And some teams were like, listen, we’re doing the API infrastructure and our customers cares about latency and they care about rotating tokens. And so, it isn’t super heavy. And so, you don’t have a ton of design folks on those teams. And so, I think the makeup of the team needs to ultimately be geared towards the problem that that team is chartered with solving and that they own the outcome for.

(00:11:23):

But the product manager needs to be flexible enough that in a team with a designer, you’re having the appropriate role in a team that has, maybe owns a business metric, you have the appropriate role. And so, there are various different ways to be that.

(00:11:40):

But ultimately, I think you need to be an owner, you need to be responsible for that outcome. And I think in fact one of the biggest failure modes, and I’ve made this mistake as I’ve structured teams in the past is giving someone ownership and responsibility for a problem that they don’t actually can’t own that requires too many, well, to get that done we need to go up the chain and then back down the chain.

(00:12:02):

And they’re not really autonomous to go after whatever that objective is that they own. And so, one of the big things I tell folks is like you want to make sure that when you’re giving someone a problem, you’re chartering them with ownership over a particular problem that they have end to end ball control around solving.

(00:12:23):

And you don’t want to find yourself in a spot where it’s like they actually can’t actually achieve those goals with the resources that they have in front of them. And we want to be creating owners but also giving them a scope and autonomy within that area so that they can be responsible for those outcomes and you can hold people accountable.

(00:12:44):

And I think a lot of failure modes in product teams, both that I’ve made mistakes of in the past and have been a function of this, hey, you own something but you don’t actually own it and it’s a shared responsibility across 15 different teams, and the PM is just only negotiating all day long but not actually accountable. And I think that can be a failure mode in a lot of organizations.

Maz Brumand (00:13:05):

So, how do you handle that? Because I mean, most of our stuff, most of product features are going to be cross-functional, they’re going to… functions anywhere from hubs to engineering to design data science, clinical, it’s going to touch many, many aspects. So, almost most features unless it’s a small one is going to be cross-functional and they have to go opt down and sideways. And how do you manage that with giving them enough autonomy and support really as the leadership?

(00:13:39):

How do you give the product manager enough support to be able to pull it? Because ultimately, all those functions have a part to play, but there’s only one person that needs to say, “Yup, I think we can get it delivered.” And really minds the gaps. The gray areas are the ones that if you don’t have a single point of responsibility of what we call directly responsible individual, DRI.

(00:14:02):

If you don’t assign a DRI that has that control, there’s a lot of gray and a lot of tradeoffs that you need to make between the different teams that nobody would own, and therefore your product feature would fail. How do you sell for that?

Patrick Malatack (00:14:17):

I think it is in how you break down the problems as a leader. And listen, nothing’s perfect here, so I’ll caveat out with you will get this wrong. This is always the case and there’s always the 20% that it’s like is negotiation ultimately. But you want to try to make sure it’s the bulk of the work isn’t that.

(00:14:36):

And so, I can give you a concrete example. And the patterns that I would look for, one, anytime that I found the organization self-creating a committee for a thing, I’m like, “Oh, I probably did something wrong here as a leader.” If the only way we’re solving this is some weird committee that’s been set up, it’s like there’s probably not the appropriate responsibility and ownership here that a committee needs to be put in place.

(00:15:01):

And so, I was one of the organizational words I would listen for is like, “Oh, no, we have a committee that’s solving” that I’m committees don’t solve things particularly efficiently. And so, that was of one this warning sign for me. But I’ll give you a concrete example from some time at Twilio to give you an idea of it.

(00:15:19):

If you don’t have a team that’s responsible for… so, we had two key product lines at Twilio in the early days, we had the voice product line and the messaging product line. Those are, I think, most people think of messaging exclusively when they think of Twilio, but it’s a sizable business doing voice communications.

(00:15:37):

So, it took different product lines, they had very different needs, what customers wanted was very, very different. And an example of a failure mode that we did go down the path on and ultimately, I think course corrected was having a user interface team.

(00:15:54):

So, a user interface team is not a useful thing in the sense that the customer problems of voice users were very, very different than the customer problems of messaging users. And yes, they had some overlap between them, for sure, but they had very, very different needs.

(00:16:10):

And so, you end up in this spot when you create ownership, and this is one of those ownership areas that you can’t… no matter what you do, someone’s upset. Either you spend the time for the [inaudible 00:16:21] folks and the… let’s see folks are upset or you do vice versa.

(00:16:24):

You have two folks that are never going to be happy. And I joke it’s prioritizing between an apple and a pizza, like is an apple good? Yes. Is a pizza good? Yes. So, good at very different times. But you could probably more reasonably prioritize between an apple and a banana. You might have a preference, you might be able to say, “Oh, no, no I want a banana because they’re more alike.

(00:16:52):

And so, you want to enable product owners to be prioritizing between apples and bananas, not apples and pizza. And so, ultimately, what we ended up doing there was instead of being the user interface team, they became the team that built the toolkit for the other teams to actually build user interfaces.

(00:17:13):

So, that the other teams would require way less resources to build whatever user experience they wanted to build, because there was an entire tool chain that was built by this other team. And that way, then you don’t dictate to the product owners, let’s say, on the messaging team or on the voice team, what their user interface needs to look like.

(00:17:31):

No, you dictate the tool chain, you dictate what the Twilio user experience ought to be like. And then, they should know their own customers far better than a shared user interface PM for what their needs are because they’re talking to their customers every day about what they want from messaging versus what they want from voice.

(00:17:49):

And that example I mean is you need to frame the problem in a way that you don’t have the user interface team. Instead, what you have is the front-end toolkit team. And their goals are very, very geared towards, okay, that we even did internally at Twilio as we started to build these things is that you would get NTFs from the teams that consumed your services.

(00:18:11):

Those are your customers at the end of the day even. And so, you try to basically goal them around something that they can own. And it may mean, in this case, we had to put some customer user experience resources into the messaging team and into the voice team.

(00:18:28):

But the reality is those teams are taking those resources anyway because they’re asking for certain features to be built. And so, rather than centralizing all of them in one place that had all the designers, it’s like no, there’s a team that works on the design toolkit and user interface components, and then there’s a center team that is responsible for the different experiences in those products.

(00:18:51):

And then, there’s a set of things that were shared in the Twilio product like login. It’s like, well, great, they actually can own login because I don’t think the messaging team cares a ton about what that login experience looks like. And so, that example, creating the right ownership rather than saying you own user interface. There are too many constituent parties that you can’t please any of them.

Maz Brumand (00:19:15):

Conflicting. It’s almost like you want to build the rail and then allow the product managers to use the rail to create the purpose-built feature.

Patrick Malatack (00:19:22):

And that was the pattern, I think, that when I look back on my time, that was a pattern that you always are too late to embrace that. And then, after you do it, you’re like man, I really should have done that a lot long ago. You’re always like, well, we don’t have enough people.

(00:19:38):

Because it is a bit resource and efficient. It tends to require a little bit more people to move independently and autonomously rapidly. But if you are on this trajectory where you’re continuing to scale, you’re doubling your organization size every six months or something like that, then really the time to do it is actually before you’re experiencing the pain from it, not after.

(00:20:04):

And it actually can be difficult when you’re after because… then you’re in a spot where you’re a bottleneck, and that was another big thing we looked for. So, I mentioned looking for things like the committee. The thing is just anytime something seemed bottlenecked by the same team over and over and over again, I think that people’s natural inclination is their performance issue with that team.

(00:20:24):

I actually think the opposite, it’s frequently did management scope their responsibilities in a way that they’re too large or have too many competing priorities that you’re asking them to… those teams to prioritize between apple and pizza rather than things that are more similar.

(00:20:43):

And frankly, I think you end up with better outcomes. When you ask a team to prioritize apple and pizza, it’s like it’s just a crapshoot as to what gets prioritized and why. And I think you frequently end up with a situation where it’s like the person that is yelling the loudest ends up winning and that’s not right for customers at the end of the day.

(00:21:02):

And so, a lot of what I think you should be doing as an effective product leader is making sure that you’re breaking down ownership responsibilities where your teams can be effective.

Maz Brumand (00:21:13):

Yeah, it makes sense. It seems like it at least on the products that needs to be autonomic versus creating one monolithic team that have different priorities and different objectives, and now they’re getting pulled between the two where they can make decisions between two things that are completely different. So, context matters but they can’t just disambiguate that. I think between bananas and apples, I would definitely go for apples if you use that.

Patrick Malatack (00:21:38):

I’m more of an apples guy, as well but it depends. Some days I like a banana. There’s certain if I’m doing a race, something like that.

Maz Brumand (00:21:47):

That was one of my big [inaudible 00:21:49] when I had a banana and I saw a 70-point jump and it’s an out for me.

Patrick Malatack (00:21:56):

Unless it’s [inaudible 00:21:57] fan, not touching a banana.

Maz Brumand (00:22:00):

True, bananas for me, for sure. One of the things that I think would been also attract to define is in reflecting on this, product managers are not or have to read rules. One is really understood what the need of the member is, one of the… and be able to stack hack, the problems that we need to solve to address metabolic health conflict, what are they? Really understanding that.

(00:22:23):

The second one is really being able to translate that into product specs and that’s a skill that people devolve over time. How do I break it into the right size? How do I communicate, connect to engineering? How do I phase it? That’s a skill that’s many needs to product managers to be able to take really distill a need down to something that people can build.

(00:22:43):

And then, the third part is really interfacing with engineering and make sure things are on track and make sure that we’re deliver it to what we expected. And then, obviously, doing retros and test it and refine it, seems like those have been the role that RPMs have played.

(00:23:01):

Does that sound right too? It’s different in maybe a different business model where maybe it’s not as designed heavy. But does that sound right to you based on-

Patrick Malatack (00:23:11):

Yeah, I think that’s the right way to think about it. I think one of the big challenges that I see in where things can go off the tracks in that process is there’s first and foremost do you really understand the needs of the customer? And I think every product manager could spend more time with customers at the end of the day.

(00:23:29):

And I think sometimes folks are like, “No, no, I really get it.” But customers come in all sorts of different shapes and sizes. The needs of enterprise customer of Twilio are very, very different than the needs of a startup, for example of Twilio and a developer that signed up with their credit card versus someone that needs to go through procurement.

(00:23:48):

They have very different processes and security requirements, et cetera. And so, I think a lot of it starts with just making sure you understand the customer. And I always encourage my team, you should be using the product every day. And I said I hired mostly technical PMs because we had a technical customer and folks knew this about me before we launched any product, I would use it.

(00:24:13):

I would typically break their product in some way, shape or form. They’re like, “Oh, crap, Patrick’s using this thing in a way we didn’t attend.” And so, I filed a lot of early bugs. But for me, that was about making sure I had the customer empathy and making sure that I was a user of the product as well.

(00:24:33):

I think it’s hard to be a good product manager if you don’t really understand the needs of the customer. And so, doing everything you can to put yourself in their shoes I think is really, really important. I think the next point you talked about is, all right, now, how do I go from I do understand the needs of the customer and then how do I go to the next step?

(00:24:54):

What do we invest in, what do we prioritize? I think that’s where actually a lot of bad product decisions get made. I think in general folks understand customer empathy is key to this job, but I think there’s a step where what we would do and we stole from Amazon, it’s certainly not novel from Twilio.

(00:25:15):

But we would write the press release before we made any new product investment. We just start off first, what do we think the customer needs are, spend time with customers and understand that. And then, it was like, all right, can we simply articulate what we’re trying to solve?

(00:25:31):

And can we do it in a way that’s understandable by… but you write it as a press release, so will customers understand it? But also, if we can write it in a way that simple enough that our own customers are going to understand, likely, all the other parts of our organization are going to understand it.

(00:25:48):

The people in finance that are like, “Wait, why do we need this many engineers to go solve this problem?” It’s like, “Well, hey, can you read this thing?” And it’s a one-page doc, it’s very, very straightforward. It should be pretty clear what you’re trying to solve.

(00:26:01):

And that document is as much to get clarity in your own mind around what you’re investing in as it is to then prove as it… put, be a point of reference for everyone else in the organization going forward. And so, we would spend a lot of time on getting those right before we dove into writing a PRD and going down the… breaking down the problem any further.

(00:26:24):

It was like, are we solving the right problem? Is this the problem that customer care of? There were a lot of times where we would write that and then we wouldn’t invest, we would do it. Sometimes, we’d sit on the shelf and we’d say, “Maybe we should invest in that later” we are well articulated the problem.

(00:26:40):

But when we got there, we’re like, “Well, maybe we should solve this other problem over here.” And so, we would spend a lot of time on that process before we would even jump into stuff like a PRD. And then, the other thing we would do as pre-work before getting into requirements is we had a process of this, I think, was probably unique to Twilio, but we called it write the docs first.

(00:27:06):

So, since our product ultimately was an API, we would write all the API documentation first. As though this was a public… any development who show up and it just sign up where we wrote all the documentation, we had code samples we had… and next thing I know we’re arguing over API design and a bunch of things like that when you’re like, “Oh, well, this are the wrong codes, I would do it this way.”

(00:27:30):

And we were pretty meticulous about doing that before we’d even invest in the product, we wanted to see what it looked like. And I think in non-API businesses, I mean, this is wire framing, rapid prototyping, doing those types of things well before you’ve invested in a lengthy PRD document.

(00:27:51):

Because I think a lot of times folks will fall in love with the PRD that they wrote and all the time and effort they put into that rather than staying focused on what they should be on early on, which is like, hey, a bunch of this stuff is going to… could potentially get thrown away, this is discovery and we’re trying to validate this.

(00:28:07):

And we would take the docs back to customers that we thought would be good users in that feature. Like hey, there’s a new feature coming out, it’s not yet available, but we do have the docs ready to go, we’re curious just to take a look at that we think, what’s missing? What would you add?

(00:28:22):

And so, we would spend a lot of time in that iteration mode. And I think the other thing I often told folks in my organization is like, listen, good product managers will cut their own features. They will realize they go down the path, someone in the organization said, “Hey, we need to solve this.”

(00:28:40):

They go explore it and they find out like no, it’s actually not the right solution. There might be this other solution over here that we should actually pursue, and that’s okay. And you shouldn’t be afraid of real spending the time fleshing out what the thing is and deciding, hey, this probably isn’t the right investment for us and here’s why.

(00:28:58):

That’s actually a sign I think of a healthy product manager and a healthy product team that they went after something and they came to a different conclusion that actually more important is to solve this other thing over here. So, those were some of the things we would do before we ever got to that PRD.

(00:29:15):

And then, the last thing we did and that prep work is we tried to give it a code name that clearly was not going to be the actual name. We would just make something up that was like if anyone was reading that thing, they’d say, of course that’s not the name of the product.

(00:29:32):

Because when products or features, when they get a name, they take on the life of their own and that’s when I think the people working on them can get attached to them. And I always tell partners, a lot of what product managers do gets thrown away and that’s okay.

(00:29:47):

The idea is your work gets thrown away, not a bunch of engineers. And that’s the way you need to be thinking about the job that you’re doing is that there is going to be waste in the work that you’re doing. But ideally, there’s a lot less waste for both, the rest of the organization as a result.

(00:30:02):

And so, those are some of the things that we did early on before we even got to PRD is we really spent a lot of time upfront. So, that by the time the PM is invested in that PRD and they’re pulling in an engineering manager, and talking through a bunch of the details on it’s like we feel pretty good that that’s a thing that we want to build.

Maz Brumand (00:30:21):

How do you think about capacity and resourcing? All that takes a lot of time and resources and think or obviously it’s good to do it because it’s a levered play. If they spend a couple of product managers doing that, it’s much better than a whole team of engineers building and throwing it away.

(00:30:40):

But then, how do you think about staffing your product teams to be able to do that? Obviously, there’s a ton of work to do into figuring out what the need is, distilling it down, writing the press release, creating the mocks, getting user feedback, iterating. How do you think about capacity of product managers to be able to do that and not take shortcuts?

Patrick Malatack (00:31:03):

I mean, I think one, just one, just pattern I always look for is the best product managers I know just seem to have an absurd amount of capacity. They’re the first to respond to every email. The type of people that I think are attracted to doing that type of work tend to just be very efficient with their time and very, very focused and able to get a lot more done than you might think.

(00:31:27):

And I think ultimately, I think you run the risk if you have too much product capacity, which I think is far more damaging than too little. You run the risk that ultimately people are creating work that doesn’t really need to be done. And at the end of the day, I always talk about product managers create work, engineers… to solve it.

(00:31:56):

And as you’re growing as a business, as a company and trying to improve your product, you do need to create work, but that is the role of product. And so, if you have too many product managers, you’re going to have way too many things not getting done.

(00:32:09):

And I don’t think that’s good for the product managers either, they’re feeling demotivated that they don’t get a lot done. So, the ratio that we operated at Twilio was about 10 to one, 10 engineers. And I’d say engineers loosely, it’s 10 folks doing the work.

(00:32:26):

Sometimes that’s designers, sometimes that’s DevOps, sometimes that’s a bunch of different roles within an organization to one person creating the work. And that’s generally how I would look at it. And I think different problems require a little bit of a different ratio.

(00:32:41):

And so, I think every business is different. But I think that’s a healthy balance. And I think generally, what I’ve found is that oftentimes, we would… the PM would go out ahead, exploring an area and uncover a bunch of different things that were there.

(00:33:00):

And then, they would have to make the case of the organization that we actually need staff, a team against this. And so, there were a bunch of times where there was a product manager on an area and not yet any engineers on it, and I think that’s fine.

(00:33:13):

But I think if you add too many PMs into the team, I actually think it can be problematically because they’re creating work that isn’t necessarily the highest priority work that the organization needs to be tackling.

Maz Brumand (00:33:25):

That makes sense. I think that experience and also design in the same boat. If you have too many designers [inaudible 00:33:29] then you’re creating or if that never gets done, and so they feel like they’re turning. Also, I think constraints breed focus as well.

Patrick Malatack (00:33:38):

Absolutely.

Maz Brumand (00:33:38):

And so, really being wise with your resources. One of the-

Patrick Malatack (00:33:43):

I think that’s true with engineering as well, actually. I think the constraints breeding focus, I think. We ran a lot of teams hot at Twilio is the way that we would talk about it. But man, you’d be surprised if what folks are able to accomplish and they know they have limited resources, and they need to make super hard prioritization decisions to achieve a particular objective team.

(00:34:08):

So, we’re always surprised, I mean, as to what they were capable of doing with a fairly small modest resource investment in terms of the number of people working on a problem.

Maz Brumand (00:34:22):

How do you balance? Because this is a dichotomy that I think confuses a lot of leaders is how do you balance burnouts with learning teams [inaudible 00:34:27] and really being motivated to accomplish way or punching way about their weight? How do you manage those two dichotomies?

Patrick Malatack (00:34:34):

I think the way I’ve always talked about it is there’s a difference between stress and pressure. Pressure is actually really, really good. And I actually think most people like pressure because it forces them to get the best out of themselves. It helps you get clearer about what’s important, what’s not important, how you spend your time, how you shouldn’t be spending your time.

(00:34:59):

And so, I think there’s a difference between stress and pressure and ideally where you want teams. And I think teams are most happiest, frankly, even more happy than really bored is when they’re in that I know there’s a lot of pressure on me, the organization’s expecting me to deliver.

(00:35:15):

I think that’s great. It focuses my energy versus stress. And what happens when you get stressed is you see yourself cycling the same thing again and again and again, and you’re not actually making forward progress. And so, to me, the way I always looked at it is we want to make sure that the teams we have are feel like there’s pressure on them to deliver.

(00:35:38):

There’s pressure on them to deliver on behalf of the customer and I think that that is generally healthy. And you can see it from the teams. The teams get excited. They’re excited about what they’re building when they’re in that pressure zone.

(00:35:49):

When they’re in that stress zone, it generally moves away from excitement into the despair. And rather than saying, “Wow, that’s a lot to get done. Let’s figure out what we need to cut to make sure we’re able to hit that date” which is of somewhat in pressure, that’s what they’re thinking.

(00:36:05):

In the other scenario, it’s like, there’s no way I can get that done and it’s like head in the hand. And those are the things that I look now that’s different for everyone. Everyone I think exhibits this in different ways. And I think leaders need to know their teams and understand and spend time with them too.

(00:36:24):

I mean, this is spending time in one on ones and really understanding how do you feel today and what’s keeping you up and what are you worried about? These are, I think, important conversations you having as a leader. But to me, I think that’s the way I always thought about it.

(00:36:37):

It’s like we do want teams to feel pressure, that’s good, that’s healthy, that’s what a high functioning organization is doing. But they shouldn’t feel like they’re despair and there’s no way they’re ever going to accomplish this thing because that’s not… it doesn’t lead to effective action.

(00:36:54):

I think the number one thing though is creating that ownership. When you create ownership, a lot of things that might have felt like despair don’t feel that way because you feel like you’re an owner, you feel like you’re responsible for your outcome.

(00:37:05):

And so, that earlier conversation around defining ownership. Defining ownership allows you to put people under some amount of pressure and them to actually feel great about it.

Maz Brumand (00:37:19):

So, unpacking that, it sounds like the difference between the spare and pressure are a couple things. One is, make sure that the person feels ownership and what they’re doing actually affects the outcome. They don’t feel like they’re just, no matter what they do, it doesn’t affect the outcome, so that’s ownership.

(00:37:32):

And also, having the right tools to get the job done. The second thing is just the amount of how much are you underwater? Just if you’re way underwater and you have let’s say 20 points to get done, but you only have time for eight, there’s no way you’re going to catch up.

(00:37:49):

And so, the amount of underwater nest seems to drive this difference between stress versus pressure. And then, also feeling like the people and the team were there to help you succeed seems to be the other differentiator between somebody that’s stress versus… really, that’s pressure. Is that right? Did I miss anything?

Patrick Malatack (00:38:08):

Yeah. I think that’s mostly that. And I use a couple different techniques with the team to help better understand where folks are. Obviously, just chatting with your team and checking in is critical. But they’re also, we would look at, all right, when a team started a sprint, some of this is team based and some of this is individuals.

(00:38:24):

But when teams started to sprint, how much of their sprint was stuff that came in that they didn’t plan for? It’s is like, oh, wow, this team is spending 60% of its sprint on things that I haven’t thought of at the start of. It’s like, what’s going on here?

(00:38:37):

And oftentimes, that’s a sign that one, the ownership’s not clear so that other teams are asking them for stuff they need, or it’s a sign that they’re underwater, that there’s a bunch of investments in critical scaling infrastructure they just didn’t realize that they needed.

(00:38:53):

And then, the other thing I would do is I’d also check in on how I was doing communicating when I thought were the company’s goals. Because I think some of this is also knowing that what you’re working on is critical to the company. I think it’s pretty important to help folks feel like they can tackle what’s in front of them and that they have supported the organization.

(00:39:11):

And so, one of the things I started doing later on was in my one on ones with team, I’d say like, “Hey, what do you think are the top three goals you think I have for you?” And so, it was like there could be no wrong answer. I would look the other way and let them write it on the whiteboard.

(00:39:31):

And then, we’d turn around and I would have what my top three goals for them were. And we’d see, is it the same or is it different? And it’s not like anyone’s in trouble if we’re wrong. If anyone’s in trouble, it’s me because I’m communicating what I expected the team.

(00:39:46):

And so, we would basically do that as a calibration exercise. And the first few times you do it, you’d be surprised. Some leader that’s responsible for a really important area thinks what you think is important. They think a completely different set of things than you do as their manager.

(00:40:03):

And it’s like, wow, it’s a good way to get to truth real quick and get everyone aligned. And for me to get feedback on how well I’m communicating what’s important to the company too. And so, that was of an exercise I also adopted over the years to help me be a better leader and better at communicating what’s important.

Maz Brumand (00:40:23):

That makes sense. A lot gets lost in translation and it’s your reality, my reality and then there’s a real reality. And so, that sometimes gets convoluted. Do you think this idea of ownership versus thriving under pressure is a type of person or do you think we should be hiring for that quality? Or, do you think it is naturally present in most people on just how you manage before on the expectations you set in the communication?

Patrick Malatack (00:40:55):

I think it’s actually present at most people. I really do. I think that there’s different people express it in very different ways. And I think that as a leader is something you need to be aware of is sometimes, we look for the vocal leader. And sometimes, there’s someone in the background that’s very non-vocal but really, really thrives under pressure.

(00:41:19):

But I think everybody has an element of this. I think the question is, really comes down to around ownership over problems. And are we giving people the appropriate ownership? And do they have some autonomy to execute against that? I think if you solve for that, I think you’d be surprised at just how well everyone can perform around you.

(00:41:39):

And I think when you fail to do that, I think honestly, that it leads to stressed out teams because they feel like no matter what they do, they won’t succeed because they don’t have actual ownership over the outcome. Now, I think one of the things I’ve noticed about high performing folks is that they will usually call out very directly.

(00:42:00):

Like you can’t hold me accountable for that because I do not own it. And it’s like, oh, great. And now, we’re having the conversation up front around what it would mean to hold them accountable for a particular outcome and what they would need to own in order to do that.

(00:42:14):

And that’s I think one of the things is that there’s a set of folks that, at least in my experiences, are much more willing to push back around ownership of areas they don’t feel like they can fully execute against versus folks that oftentimes just don’t vocalize that.

(00:42:34):

And you don’t find out until the thing is already not succeeded or it’s off the rails, and I think that’s one big thing. I always encourage folks, it’s like you got to speak truth to me and this is a safe place. Any conversation is okay. If I define the problem wrong, I made plenty of mistakes around here and I do want to hear about it.

(00:42:54):

And so, I think that’s a place where a lot of times folks don’t know about that because they don’t have the open-door policy and they think, oh, well, the boss wants this, so I just need to do what the boss says. I always tell folks, if you have a better idea, I want to hear about it.

(00:43:13):

If you don’t, we need to execute together, I don’t want us to be debating every single thing. But if you think there’s a better idea out there that we would all benefit from, great, let’s hear about it and discuss it.

Maz Brumand (00:43:25):

And I think being open to mistakes and learn but make sure that people learn from it is another angle too. Obviously, nobody ever gets hard things right the first time. Learning process for people. I think that’s another thing that helps communicating to the team that it’s okay to make mistakes.

(00:43:44):

We learn from it and we increase our velocity versus try to not make any mistakes and not take any risks and just playing it safe every single time. One of the things that happens in product world is entropy, which is how there is just the thing comes in, the requirement comes in and everybody’s going to be able they got to do.

(00:44:03):

And then, eight weeks later, 10 weeks later, you end up in a place that everybody’s wondering how do we even get here? That’s one type of entropy. And I’m talking about that. Another one is obviously you won’t get the best ideas from across the company invest in evaluation process.

(00:44:20):

And how do you set it up that it’s not creating a ton of noise, but it’s actually creating the right diversity of ideas and ownership that it brings from polar. Because you want the whole to be involved invested in the product. And so, how do you manage entropy effectively?

(00:44:36):

Whether it’s when an idea comes in and it ends up in a completely different place, or just generally being able to get the best ideas out of company without creating a ton of noise or signal noise ratio is too high.

Patrick Malatack (00:44:48):

I think the first type of entropy, I think what I discussed about spending more time upfront defining the problem and what the success criteria looks like and what this will do for customers on the, I think, that’s usually… when it occurs, when you start something and it looks… it’s completely different, what are we even doing here?

(00:45:04):

Usually, it means you didn’t do the work upfront. That’s that to me is you’ve not distilled into the most simplest terms what you’re trying to achieve. And it becomes confusing to the entire organization what you’re trying to solve. That to me is I think the best defense against that, is just really, really simply distilling down what you’re trying to solve on behalf of customers before any work gets done.

(00:45:29):

I think the second is quite different in terms of how you solve. And I think it changes the different phases in the company. I think the way I think about it is, early on in the company, the vast majority of customers you’re solving for our customers you do not yet have.

(00:45:50):

And so, when you think about what’s the ratio of stuff that is come from us, that we have this vision and it’s way more of what you’re building should be from the vision of the founder and of the leadership team and the agenda, the overall company vision, what you’re trying to set out to solve, then it should be from direct customer feedback because you don’t have a ton of customers.

(00:46:13):

And I think this is of the thing that keeps you from building the faster horse instead of going and building the car. And I think most companies, particularly startups, are in that environment. But as the company shifts, as you start to have a ton of customers that are coming in, you need to basically change the mix.

(00:46:34):

How much of it should just be our own view of what we think the future ought to be like versus the view of customers that are choosing this every day telling this is what they need. And so, that mix needs to be, I think, of it as a wine. You need different amounts of any particular varietal for the different type of stage in the company.

(00:46:56):

And so, the way I think about it is at the start, it’s very much founder driven, thesis driven, what do you expect the world to look like 10 years from now? And spending most of your time talking about the needs of customers you do not yet have. And you’re trying to understand them. You’re going out talking to books.

(00:47:16):

You’re not designing a silo, but it’s about customers you do not yet have. As you start having more and more customers, you need to actively engage in those customer channels. I think as a product leader to distill things.

(00:47:29):

And to your point of how do you make this not be noisy, how do you make it not be… you need to come up with a processes and systems that help it not just be the loudest account manager that owns some big account that’s really excited about one particular feature shouldn’t just be able to bully the organization.

(00:47:47):

And that’s why I think of one failure mode. Or, a product manager that cares about their vision only shouldn’t also be able to bully the organization. So, these different failure modes. And so, what we did, we did a few different things. One of them was we had a running, we called it the top 10 list.

(00:48:07):

And so, our sales slash sales engineering organization had a customer top 10. If we could only ask product for 10 things, this is what we would want. Because product manager can be at every conversation, they’re not in every account. They’re not in the… and so, hey, great, these are the top 10.

(00:48:22):

And in our organization, because we were a developer tool, it was typically a sales engineer spending time with the product managers to make sure they fully understood what that top 10 list was. And then, at the start of every quarter, I’d be asking the product managers, “What are we doing from the sales top 10?”

(00:48:39):

“Are we making steady progress against the things they think are our most important customer needs?” Because I think naturally the product managers are thinking about their roadmap, their vision, their long-term thing, which is a good… you want them thinking about those things, but you can ignore some of these.

(00:48:57):

And then, we did the same thing with customer support. Our customer support leader at the time is named Terry. We were like, “All right, what’s Terry’s top 10?” If Terry could get his top 10 built this corner, what would he want built? And so, we have those always.

(00:49:13):

And I actually had the product manager’s console for those areas to actually have that in our weekly status report. They knew it. And then, I’d be asking, what are we doing to address this quarter? And then, we had to a more shared larger tent forum where Terry was there and the sales engineering leaders were there where we could discuss these issues and make sure that they weren’t getting star.

(00:49:41):

But I think you need to actively create a process as you get more and more customer feedback to ensure that the right voices are heard. And frankly, we even end up in spot where it’s finance at some point as we got to a certain size, they cared about once this pricing that they’re going out and how are we communicating this change?

(00:50:05):

When are we implementing the sales tax in this state? And they have a difference of needs. And so, you want to make sure there’s a forum, but you also want to give those teams a means to prioritize for themselves. Because if they aren’t in that bucket where you’re asking them to prioritize.

(00:50:27):

And I just told you, I like to have teams that were very, very run, we run them hot. And so, there’s always a resource constraint. And so, you need to both help those teams be in a spot where they’re not just asking, I need this, I need this, I need this.

(00:50:42):

It’s like, no, which of these do you need the most? If I could do one or two things, which would it be? And then, we have a historical record too, because we had it in our weekly report. It’s like, okay, this thing’s been on Terry’s list for six months, it’s been number one, why have we not done it? And what are we doing to fix that? And those were the type of conversations we have as a team.

Maz Brumand (00:51:04):

I really like that distinction. Actually, it’s a very helpful one, which is different product market fit where you’re actually creating a vision and going to ask people what they want. For example, if you ask members, “How would you want us to be a partner in your health for the next 10 years?”

(00:51:16):

It’d be a very hard question for people to answer. So, before that product market fit, really working on vision and obviously having a pathway to test your ideas once, as you structure press release and marks and interviews, so get more confidence, but it seems like heading there.

(00:51:31):

And then, once you hit product market fit, then it becomes really important to make sure that we make the features that people find useful or find as friction and addressing those while we’re adding to the feature looking bats, which are of us.

Patrick Malatack (00:51:48):

And I think you shouldn’t be afraid as an organization to make cultural changes to how you do things to ensure this is just naturally happened. We had folks do customer support tickets at a periodic interval too. So, it’s like next thing I know, it’s like I’m VP product, but I’m answering our support tickets around how do I send this message into the UK?

(00:52:09):

And so, you’re seeing that direct customer feedback along with the support team rather than pushing the problem away from your product organization. You want it to be something that they’re able to see quite closely. And we worked… Another time, we had a series of outages that were really, really painful for our customers.

(00:52:28):

And so, we put the product managers on-call. We said, “Listen, I realize you’re not going to be restarting servers and you’re not going to be writing quick hot fits for code, but you should be managing communication with customer support while engineering is getting things back online.

(00:52:45):

And you should be writing the RFO that goes to a very upset customer. You should feel the pain of service availability just like our customers do and just the engineers here. And so, I think you need to be willing to prioritize even cultural changes in how you do things as the company progresses and as you’re in a different stage in terms of having customers versus not having customer.

Maz Brumand (00:53:08):

And we’ve been good at that where we have and everybody on support thing that anybody that joins the company will spend a ton of time with support and actually going through tickets. We really understand and build that empathy, which is important, you’re right.

(00:53:21):

If you just hearing from all the people’s very different than when you actually read the comments in its entirety from customers and already actually helping respond to some of these things, it creates a different level of empathy and it’s so visceral.

(00:53:34):

And one of the things is the bike shooting that kills most startups, which is we can make that graph as beautiful, and everybody has an opinion on the graph that you’ve created. You could spend ton of engineering, time on that graph or where your pre-PMF where you decide to kill a bunch of features that number of people liked.

(00:53:53):

And you’re going to get a lot of grief from externally and internally about killing these features. First of all, what’s your viewpoint on that when you have to make changes that some people are just going to hate, and it could be some of your best customers, unfortunately. How do you think about that in your career?

Patrick Malatack (00:54:11):

I mean, think to do all these things well, you need to have a very, very clear idea of where you want to be both of 10 years out, which typically the CEO vision level of the company. And fortunately, at Twilio, Jeff was phenomenal at setting that, this is where we should be 10 years from now.

(00:54:29):

But then, you need to also be able to work backwards from that to things that allow you to make decisions. Because frequently that’s not useful for making decisions, it’s useful for understanding general direction, but you then want to work backwards when it’s like, okay, if we want to be here in 10 years, where do we need to be 18 months from now?

(00:54:45):

Where do we need to be four years from now? Where do we need… and having that clear view of where you’re going and then the steps that you need to take along the way then allows you to evaluate some of these questions from the perspective of like, are we getting closer or from an air away from that vision?

(00:55:02):

And I think that’s the frame that I would do when you have to make those hard decisions. And oftentimes, you end up funding initiatives that maybe seem questionable at that time because it’s in further of that vision. And I actually think it’s really, really important to be explicit around not just what you’re doing but why you are doing it.

(00:55:21):

And I can think of a conversation around Twilio when we invested in our video product, early on it was not a big revenue driver. And there were a lot of questions, hey, we’re spending a lot of money on this. It’s not driving revenue on day one and why are we doing that?

(00:55:40):

And the question is like, well, we had this mission to fill the future communications that Jeff had outlined for the company. And it’s like, we don’t believe we’ll be feeling the future communications and we’re not feeling video communications. It’s like full stop that, that is part of what we’re trying to do here. And so, the question shouldn’t be around why are we doing video. It should be maybe we’re investing to that heavily right now.

(00:56:00):

But 10 years from now, we need to be doing this. And so, I think when you have a really clear vision from the CEO and then have… and I saw my role as a product leader to take Jeff’s super clear, here’s where we need to be in 10 years, to ask what would we need to be at five years, when all the way down to where do we need to be in 18 months?

(00:56:22):

And then, task my team with what are we doing in the next year in your area that you own? And how is it contributed to this thing that is where we need to be in 18 months. That’s I think the thing that allows you to make those decisions much more easily, because occasionally some things will come up and you’ll be like, “Is this part of feeling the future communications?”

(00:56:41):

You’re like, “No.” It’s like, all right, well, then, why should we be doing it? And sometimes, you still do those things. It’s like, hey, there’s a ton of revenue in this. It’s like, well, great, that revenue is going to help us fuel the future communications.

(00:56:54):

But sometimes, you say like, no, it isn’t actually contributing and there’s… it’s like, all right, then maybe we shouldn’t be spending our time on these things. And those can be hard decisions, but I think it ultimately it benefits the company.

Maz Brumand (00:57:07):

Have you ever made a decision specifically of killing a feature or an adding a feature, and then there’s a ton of pressure to either bring it back. Let’s take killing a feature because that’s hard, that has inertia in it. And you got a ton of pressure from people now you’ve got to bring that back.

(00:57:23):

But based on your north star metrics or the way you saw the product evolving, you made the call that no, we’re going to stick with it. Even a ton of pressure from both customers and internal.

Patrick Malatack (00:57:37):

I think one of the things that it did happen, but it usually happened way tinier batches. So, when we were building things out, we very clear alpha, beta GA. And in that alpha phase is where this happens the most. And that’s where it should happen.

(00:57:53):

By the time you made it available for folks and even if it’s not gotten SLA against it or whatever, it’s like you probably should have already gotten through this thing. But yeah, occasionally, we’d be in that alpha phase. We’d go down a path. Along that path, we’d come up with a better idea or a different way to solve that problem.

(00:58:11):

Or, we’d decide, hey, there’s not enough customers that need this or they’re solving it some other way. And we’d say, “Hey, we’re going to have to shut those down.” And it’s definitely difficult when you make those decisions. And I think the biggest thing you do to do that well is have a tight knit set of customers that you’re willing to experiment with and they know that you’re willing to experiment with them and there’s high degree of trust with them.

Maz Brumand (00:58:37):

Basically, external beta customers.

Patrick Malatack (00:58:39):

Yeah. There’s certain external beta customers and there’s a lot of trust. And in those instances, a lot of the sense of being relationship based, which is like, hey, I know we built this thing. We know that you’ve built this other that’s on top of it. We need tear it down.

(00:58:52):

We just need to see how we can help you best transition away. And we’re making our own personal commitment despite the fact that that’s time and resources that maybe we shouldn’t spend. Otherwise, when you look at the value of that customer and that relationship in the long term, it tends to pay off.

(00:59:10):

But there are plenty of things we’re like, hey, we rate this new adapter that you can run in host because we don’t think this should be part of Twilio, but we realize you need it now because we didn’t ship that thing. And so, there were a number of those experiences that happened along the way. Listen, they’re never easy.

(00:59:27):

And I think the best way you can of handle that with customers is to help them understand why you think that’s important and where you want to go with where the company is going and where the technology is going. And I think that’s useful for them because I think as much as… when someone makes a bet on your product, particularly in the API business, they’re really betting on your company and your team too.

(00:59:49):

You’re part of their product usually, in the API world, in the infrastructure world. It’s like they’re making as big a bet on us as a team as they are on the product that they’re using. And the more they have confidence that you understand what their needs are and you also understand where the long term is going, the more they’ll go on that journey with you.