Episode 163: A Mold-Breaking IPO and the Power to Redefine CPO & CTO's Role with Tim Armandpour at PagerDuty
In this episode of Product Thinking, Tim Armandpour, Chief Technology Officer at PagerDuty, joins Melissa Perri to explore leadership qualities, product & technology roles, their challenges, and the importance of an overarching company vision. They discuss user-centricity, product-market fit, and aligning teams.
You’ll hear them talk about:
[02:04] - Chris Sacca tweeted that he wished he’d invested in PagerDuty after they’d come on the scene with an IPO that made people sit up and pay attention. Tim says the founders' brilliance in attaching to a problem space with broad applicability had a lot to do with its success. He mentions PagerDuty’s significant product-market fit, as it plugs into anything that speaks over HTTPS. It grew through a natural network when teams started seeing other teams successfully using it. Further, the company was taking aim at user centricity and the notion that it should ‘just work.’
[08:34] - Ensuring clear communication with your team optimizes the product's success. Communication is a balance, and you don’t want to tilt into micromanagement. So, Tim suggests building guardrails and aligning the team with a company’s overarching vision to answer all the important questions. If you have a vision, you’re able to work backwards from your goal and implement what everyone needs to do to make it happen.
[27:05] - Tim’s decision to combine the roles of Chief Product and Chief Technology Officer provides him with the ability to lean into almost all parts of the business. Combining these roles isn't for everyone, but it does have its advantages: one less negotiation cycle and finding new synergies. PagerDuty combines and splits the role numerously; combining the role is about how the business is operating at the time and which role serves the present needs. Ultimately, putting the two critical functions together aids in compressing the decision, delivery, and development cycle time. Even when the role is split, at PagerDuty, they always share a common goal and vision.
[43:28] Preparing to scale the team to support a transition from CPO & CTO to CPTO requires consideration of strategy and support. According to Tim, one thing to follow is the strategy; along with leaders' ability to adapt and while maintaining a clear structure. Additionally, Tim believes in embracing opportunities even when they’re outside of your comfort zones. It broadens perspectives, empathy, and understanding within teams, improving organizational success.
Episode Resources:
Other Resources:
Intro - 00:00:01: Creating great products isn't just about product managers and their day-to-day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary-pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is the Product Thinking Podcast. Here's your host, Melissa Perry.
Melissa - 00:00:37: Hello, and welcome to another episode of the Product Thinking Podcast. Today, we're joined by the CTO of PagerDuty, Tim Armandpour. At PagerDuty, he manages all of product development, from product management, design, security, to engineering. He's a tech exec who's been working across product development in his entire career, previously leading teams at PayPal, Yapstone, and SendMe. But before we start talking to Tim, it's time for our segment on Dear Melissa. This is a segment where you can ask me all of your burning product management questions. Just go to DearMelissa.com and drop me a line about what you want me to answer in an upcoming episode. Here's this week's question.
Dear Melissa, I joined a startup which is transitioning from a consulting company to a product company. The play is to productize the consulting service into a self-serve SaaS platform. The core competency of the consulting team is data, and mathematical algorithms used to generate recommendations for project teams that design and construct sustainable buildings. The company is being funded by consulting revenue and seed funding. Upon joining, I discovered that we have a fairly big product, two to three years of development, with no users. The consulting team has been serving as a proxy for users, steering development to build a full featured product without any user testing or product market fit test. We continue to develop towards this vision of replicating much of what the consulting team does before we even approach potential users, fearing loss of reputation in presenting a less than full featured product. What do I do to change this way of thinking when the team lacks basic product thinking?
All right, so working with consultants here, they probably don't quite understand the concepts of building software. They also have a reputation online, and you do have to empathize with that. They've been successful so far. They have clients. Clients expect a standard of service. What they're confusing, though, is that part of a product doesn't necessarily mean it's any less valuable. Even if it doesn't have every bell and whistle in there, it doesn't really equate one-to-one with the value that a customer could be receiving. What I've seen a lot of consulting companies actually do that works well is they use a lot of software stuff on the back end that helps them streamline their services and productize it a little bit more. So is there an opportunity for you to use that product in the back end without showing it to customers to help automate a lot of the things that you're doing? That's what I would look at first. But it also sounds like you're using this as a self-serve platform. So the idea here is that you want to turn it around so that you can open it up for users and see if they can answer some of their questions. There are ways to slice and dice this so that you can see how far they can get and how much value they can get by pulling some of this stuff on their own. I've worked with a lot of products actually that started off as consulting and ended up as a SaaS platform for data. Exactly in this situation. Many, many companies have started this way. So what they really looked at was how do we offer some of the functionality that we do as humans to other people to pull that when they want it? So you might slice this down and say, hey, if our value proposition here is having a lot of data and all the data. And we believe that we can build something quickly to market that allows them to do a couple different types of analysis on it.
I would slice the platform down and open that up to people who have that specific problem. You can qualify them by going through sales and figuring out what types of data they want to do with consulting and pitch them the product and say, hey, we've been working on this. It's a product that we do want to sell eventually for SaaS, but would you be interested in trying it? Could we start there and give us some feedback on it? If you find people who have the problems that you're trying to solve, which sounds like you do every day, I would get the consultants to show them the product. It doesn't have to be perfect. That's not the point of product development. What you want to do here, though, is get people more comfortable with showing their work and getting good feedback. Figure out what the problem is. Why won't they really show it? Are they worried that because it doesn't have all the features and replace a consultant completely that they can't show it? In that case, sell it alongside with consulting. Make it a package. Say you're going to buy this and I'm going to give you this platform to use it, but then we're also going to give you a consultant to work with you. And anytime that you have trouble, you can ask that consultant questions. That's fantastic. Now we have a consultant actually watching them use a SaaS platform, giving them some advice, and we're offering a services component. A lot of really great companies out there offer a services component. Can you think about it in that direction? It doesn't have to just be releases out to the world and let anybody use it. You can do this in a confined way so that you're just picking and choosing some customers to first get on it. But you know those customers. You have a handle on it. That's how great software companies get started. They stay close to their customers.
They release it to some people, and then they keep growing and growing and growing as they get feedback. So you're going to have to figure out what the hesitation is for them to release this. And then you're going to have to try to quell those myths or those fears that they have there. Maybe pairing a consultant with this SaaS platform is a way to go because you do have some control over the narrative and what people are doing. But at the end of the day, if they don't get that product out to market and they don't start getting feedback, they just wasted a bunch of money building something for nothing. So either learn how to use it internally so that the customers don't see it, if that's the way you want to go. But if you want to sell a SaaS platform at the end of the day, start showing it to customers. Slice it small. Maybe start with one piece of functionality. Only give it to the people who need that functionality, not all the functionality. You don't have to market and launch this thing to everyone. You just have to do it to some people so you get some feedback. So maybe take that approach and help de-risk the situation.
So that's it for Dear Melissa this week. If you have a question for me, go to dearmelissa.com and let me know what it is. I will answer it on an upcoming episode. Now it's time to go talk to Tim.
Advertise - 00:06:20: Did you know I have a course for product managers that you could take? It's called Product Institute. Over the past seven years, I've been working with individuals, teams, and companies to upscale their product chops through my fully online school. We have an ever-growing list of courses to help you work through your current product dilemma. Visit productinstitute.com and learn to think like a great product manager. Use code THINKING to save $200 at checkout on our premier course, Product Management Foundations.
Melissa - 00:06:51: Welcome, Tim. Thanks for being on the podcast.
Tim - 00:06:53: Thanks for having me.
Melissa - 00:06:54: So you have had a wild ride at PagerDuty and PagerDuty's growth story is really, really interesting. I was wondering if you can take us back to when you joined, tell us a little bit about the company and how did it grow all the way through IPO?
Tim - 00:07:09: I joined PagerDuty in April of 2015. So going on year nine and then seven here. Company's about 15 years old. So I was a happy end-user and buyer of PagerDuty in prior leadership roles at prior companies. And so when I got that call to go meet the founders, it's honestly one of the easiest calls I took just because I was enamored with the problem space. You know, when I joined PagerDuty, I think the company was somewhere between 60 and 70 people. We just hit $20 million of annual recurring revenue, raised a B-round. And the founders were ready to bring in some other folks to help scale the company at the end of the day. So I joined as the company's first VP of engineering, about 30 people in engineering. They give you an idea of like where we're at today. We're about almost a little bit shy of 1300 people globally. And then all my originals to me, that's about almost 500 people.
Melissa - 00:07:54: That's awesome. So I remember when PagerDuty IPO'd, everybody was looking for, I think it was around the same time as like Uber's IPO, Shopify, Stripe. And PagerDuty came out and IPO'd and people were like, PagerDuty, wait a minute, what's that? And it had a phenomenal IPO out there. It made everybody kind of sit up and pay attention. And Chris Sacca tweeted, man, I really wish I invested in those guys when they first came to me. From the journey from when you were small to being able to IPO, what do you really feel like was the secret success for the growth of PagerDuty?
Tim - 00:08:26: Two things stick out. One was just, I think, the founders and their brilliance in attaching to a problem space that had a lot of broad applicability. Like if you really think about it, PagerDuty can plug in almost anything that speaks over HTTPS. So all software can plug into PagerDuty. And they realized really early on, which is one of those really awesome stories about PagerDuty, just fantastic product market fit. And then that became very foundational in a lot of our product-led growth types of motions and movements where, honestly, it was like this natural network effect. If a team of three people in a company and their manager started to run a trial of PagerDuty, they liked it. They then put their credit card on file in the early days, and they started using it. And then other teams inside the company says, whoa, whoa, whoa, how'd you get ahead of that issue? How'd you know about that? It's like, oh, well, we've got PagerDuty. Oh, well, we want to work like that. And it became like a network effect within companies and organizations. First, I want to say eight, maybe half the company's lifetime really, really honed in on that product-led growth, kind of that user centricity around ease of use, get up and running quickly. And ideally, we aimed at the scenario like it should always just work. We're like the dial tone. We always need to be there. And that I think we're able to piggyback on to grow pretty rapidly. I mean, we got to $100 million of revenue in under seven years, somewhere around there. And that really became that launch point around a certain market sentiment threshold around, ah, you're now starting to reach a different scale factor. And you run a pretty good business. And you have these marquee customers. And you're still growing. Ooh, that looks interesting. And then we went IPO in 2019 and haven't looked back since.
Melissa - 00:10:05: So when you think back on when you first started at PagerDuty, how has your role changed from then to now?
Tim - 00:10:12: It's changed a bit, for sure. Just with growth comes, I think, a need for one to really hone in on that it's important to be adaptable and amenable at the end of the day. But being a company like PagerDuty, where we've been able to grow, I've also been lucky enough and afforded to have a boatload of opportunities to learn, to help, to contribute, to have impact. But, started as a VP of engineering at a point in time where I was running product design, product management, engineering, internal systems, things that make the business go on behind the scenes. And then we branched back out to splitting up and the world of engineering. So then I was only running engineering again. And then we converged again about a year and some ago with also the advent of we brought in both product, product management, product design, engineering for our products and services, engineering soup to nuts, infrastructure, products themselves, all the moving parts. Also, our CIO rolls up to me. So all of our internal systems and kind of the general corporate environments. And also our security and compliance organization also rolls up to me. So our chief security officer and all the things that help us stay safe and sound and keep all of our customers data, safe and sound also rolls up to me. So it's meandered a bit. It's definitely kind of either grown and expanded or actually became focused for some period of time by design. I think it's a story of be adaptable, be humble. And it's very much, I mean, at the end of the day, it's a team sport to keep a company on 15 plus years.
Melissa - 00:11:39: What did you have to learn or maybe unlearn about, you know, your current role when you were scaling from VP of engineering, which is 30 people and hitting that like growth spurt where it's like, oh, I don't just have engineering. Now I've got product design, security, all these people underneath me. What did you have to break a habit of from the old days of managing like a couple people?
Tim - 00:12:00: One of those things you learn, usually the hard way, I'm not immune to like, I definitely learned multiple times the hard way is how you spend your time at what level, where you get involved, where you don't, where you establish direction versus being the one to make the decision. As you scale up with the company scale, the need to the company, needs of the customers, also your people, where you hover, which altitude really becomes really critical. And the only way you can hover at a higher altitude is if you are in the business of actually growing and or bringing in some really, really crazy, smart, crazy capable people, right? So even my own ability to rise up, so to speak, and take on more or help where I can, I'm afforded that opportunity because of the people that I have around me. And so, you know, instead of being, you know, critical path for a decision, you end up spending your time around the directional nature of types of decisions, what kind of choice points I might still weigh in on. But more often than not, you want to create at least more or less an environment where people can roam within the established guardrails that really are tightly connected to the overall strategy. Much easier said than done. I mean, you have to learn hard about either your decision cycle times are too slow or they're on point. You make enough wrong decisions and learn how to either get picked up by others to course correct and learn or pick yourself up and course correct and learn and stay humble along the way. That's usually the name of the game as you scale up and take on new and different, especially as the company changes parts of, you know, how they operate and how they need to position themselves to be successful.
Melissa - 00:13:26: When you think about giving direction to your teams too, you mentioned trying not to hover, right? Trying to give them enough space to go out and do that. How do you develop your strategies and how do you communicate it in a way where you ensure you're not just dictating down very fine-tuned solutions to people, but you're giving them enough room to go out and explore and come back with interesting ideas?
Tim - 00:13:48: Much of strategy will start with what's the company's overarching vision. That's where it looks like your natural starting point. You have kind of the top level corporate strategy that incorporates a lot of moving parts and inputs across the entirety of the business, the market landscape. You try and predict where the puck is going to be in three to five years time. Now you go to that next level around, okay, now how are we going to then, from a product development, product build perspective, support and give us nothing but a chance of success there? Examples are, you establish certain kinds of like, almost like frameworks and methods of communication, I want to say, around the guardrails. And I usually start with outcomes. So, if in three years time, we believe we're going to have a financial profile of X, we believe that from a product or platform perspective, the changes and shifts are going to be defined by a certain set of tactics and or things that we expect to happen. You start to work backwards on what do we need to make true in year one, year two, and year three. And so, for example, I'm not involved in, let's say, week-to-week kind of scenarios. More like month-to-month, quarter over quarter. But in this year's time, this coming year. What are the top five things we have to make true? And now you work backwards in order to say, what are those pathways that need to be developed to allow the teams to start to roam and figure out the how? I am not in a role to dictate the how, but I can influence and, or even at times, if it calls for it, prescribe the what and parts of the why. And I think if you're able to do that, you're arming teams with context, with space, and with a feeling of, I want to say, empowerment to drive. Because in a company like our size, even a company of 30, you can't do it all yourself. You have to self-realize that to be comfortable with that. And if you want to do it yourself, you should probably just go become an individual contributor to that.
Melissa - 00:15:26: That's a good point. Yeah. And I think a lot of people do get stuck in that, you know, I see type mode when they try to move into leadership where they just can't let go of the tactical pieces. They want to be in the code. They want to do the things right. They don't want to just help guide people in the right direction.
Tim - 00:15:40: I think there's a natural sense of lack of patience that kicks in in people that have leadership-like responsibilities, a natural internal motor that runs, that you're really a driver in that regard. And so there's times in which you want it because you can see it so vividly, what you want to create or what you want to have happen. You might have a tendency to dig in there and say, okay, I'll just do it. And then share it out. And you think you're doing a good thing, but then all you're doing is you're probably upsetting quite a few people that were already tasked or already have that responsibility. And now you just undermine. So you got to be careful about not crossing that line over time. Because the more you do that, the more you're actually creating distance between you and your people and their work. And the whole part of like, you know, as far as leadership, especially with respect to people in groups is you need to be able to find those synergy points and be able to really create like some cohesion amongst everybody and all their efforts so that, you know, you can produce these fantastic outcomes that create success.
Melissa - 00:16:30: That's such a good point. The undermining piece too, I didn't even come up with that like off the top of my head when I was thinking around reasons, but that's a really big one there. It's like, you don't want your leaders to do your job for you. It makes you look bad. They're going to think you don't like what they're doing. And maybe you just really like being lead. One of the things you also mentioned here was that sometimes you dictate the what. And I think that makes people touchy sometimes, right? There's a lot of product people and engineers as well out there who are like, no, no, no, don't tell me what I'm supposed to build. I'm supposed to tell you what we're going to build. And that's our job to go figure out the solutions. I'm a very pragmatic person. So I always feel like there's some kind of balance in there. How do you weigh that balance and say, this is the times where I have to be prescriptive and I must tell you what versus these are the times where I can give you a box to go play in and then you can figure out what exactly we're going to build?
Tim - 00:17:21: Yeah, I think it depends on the profile, the outcome itself. So sometimes things are very nebulous, ambiguous, unless you've been in some of those direct engagements where you're hearing, let's say, for example, I spent quite a bit of time engaging with a lot of other executives at customers and prospects. There's a certain perspective you gain from those conversations that you might not get from other roles within an organization that are lower than the CTO, the CIO, the CFO, etc. And based on that, you're going to start to form some opinions and some perspective that I think part of my job is to help ensure we're making more right decisions than not right decisions. If we make a not-so-right decision, how resilient are we to course correct, learn from it, adapt, and make it better? And so I'm definitely the believer of that. As you rise up in the organizational chart, you do need to be more right than wrong. The notion of like, oh, you can just keep failing, keep failing fast. No, you really can't. Like as a CEO of a public company, you can't fail fast. Sorry. It's just no tolerance, right? So I think that kind of stems from there. But you get this perspective and you still want to open up a conversation with your groups and your people and your stakeholders and whatnot, because you want to create some shared context. I'm a big believer that, get to a point where you time-bound these things, and then you get almost in a way, in a healthy way, somewhat declared. So, for example, you might just be absolutely convinced that you've talked to 10 different CEOs. They're all kind of saying the same thing. You've developed this pattern, and you believe that that's the thing you've got to build this year. Because you've actually identified a demand signal and a potential value realization scenario that isn't sitting tip of the tongue of some of the lower levels.
But I'm talking to the person that controls the purse strings of something that they're willing to pay for. And we have an opportunity to actually deliver that solution to make them crazy successful. So that's where some of the maybe a bit of the declaring the what comes in, and enough time has gone on. We haven't come to that conclusion. Then, yeah, I'll sit in and say, here's the deal. We need to build this because the cost of not doing it looks like X, Y, and Z. So we got to be really, really, I guess, cognizant of that scenario. And what becomes most pressing is then starting to then go in the next level, which is then the fine line of like how much, how involved you guys like, okay, what does it take to deliver that thing I just declared? And if you say, all right, I want three proposals by the end of the week. And people show up and say, here's option A, B, and C. We like option B the best for these. Okay, well, absolutely. Again, there's that sense of empowerment. Can you go and help figure this out? Because it's a hard challenge. If it was easy, everyone would do it. But it's not. So that's our job. Go figure it out. But still, I would retain that notion of veto rights. And that's kind of like a certain operating model, I think, that you develop over time as a growing leader. It's like, where do you want to have veto rights? Or where do you want to have discrete approval rights? Because I think those are two very different worlds to operate in. I like the, I'll reserve veto rights, but you keep going kind of scenario. I think it's a bit more empowering. It's a bit more scalable over time. Because I should not be the choke point or the bottleneck for the org on every key decision.
Melissa - 00:20:22: I like the way that you think about balancing that too. And I've heard other leaders put it into perspective as also in like times of crisis, I don't have time for you to go figure out what it is that we need to do. We need to make decisions. So there'll be a little more heavy handed there. But I like the idea too of, I've seen people struggle direction where you do give them the opportunity to go explore, but then they can't get to a decision, right? Or they can't get to the right answer. And at that time you're like, I just need to step in, right? I need to make a decision because otherwise nothing gets done. And I think that's healthy for everybody in an organization to actually understand.
Tim - 00:20:57: I've either a bad habit or notorious, or sometimes it works depending on who you are on the other end of this, where we will spend a certain amount of time talking about a thing, working through solutions or scenarios, et cetera. And then I'll say, okay, what's good timing to come back and create the decision? And someone might say, okay, give me a week. Okay, week is solid. You're good with the week. Let me know what you need, what help you need. But if we're not at that decision at the one week mark, then I'll be deciding you're going to have to manage through a deal. And, I think that also helps, again, creating that environment of like, please don't make me make the decision, right? Let's make sure we can make as well-informed of a decision as possible, knowing all the things we know. And it's okay if it's not perfect, but we do need to make a decision. And so if one needs to be made, then yeah, I'm definitely unafraid to step in and say, we're doing this, we're moving forward, and we're not going to relitigate it.
Melissa - 00:21:45: I think that's a nice approach too, because it sets expectations up front. It's not like you're just swooping in and saying, hey, go build this, right? It's like, nope, I'm giving you the opportunity. But if we can't reach a decision at this day, I'm going to make the decision, and then we're going to go.
Tim - 00:21:58: Yeah, and there's also, you know, in leadership circles, a lot of us talk a lot about the difference between agreement and alignment. If you try and strive for nothing but agreement, you're going to be running to stand still for far too long, right? It's more about getting to alignment. And there will be that disagree and commit kind of scenario that pops up. But it's super important to get to share context and alignment. That's just crystal clear whether you like it or not.
Melissa - 00:22:22: I think a lot of organizations struggle with the alignment piece too, and specifically in communicating the intent, right? Like, where should we be going? What should we be doing? How do we all go in the same direction? What types of communication and rituals do you use to make sure that you've got a handle on, okay, we are all aligned, we're all swimming in the right direction?
Tim - 00:22:43: Yeah, I don't think it's like reinventing fire type story. But one thing that I found that works well is, you know, let's say with my direct reports, we just look at like the operating model of an organization. You think about, in order to set things up well, you want to have a structure in place that can help carry through the strategy, so to speak, right? Because if your structure doesn't match like, the strategic intent of your strategy, you're going to struggle. It just becomes very challenging, whether it's communication, execution, alignment, prevent silos, performing, duplicate of work that you can't afford, et. cetera. So I'm a big fan of really looking at like, ensure like you've got like some robustness and integrity in the structure. And if I've got my direct reports, I will always start a meeting with like, here's what I've come to know in the last week, whether that's through outside engagement, internal findings, direct from our CEO team that we meet with just prior to my weekly team meeting. And it really opens up, I think, communication lines, one of transparency. I trust you with this info. Use it for context in the grand scheme of things. I'll try and highlight what's really important, what's more like, here's some noise things. If you hear about this, don't worry about it. Inconsequential type of scenarios. And then I like the role of creating an operating cadence, weekly reviews of key things. Monthly, we get together across what we call our leadership team across product engineering, which is called out of the 400-ish, probably about 35 people, so about 10% that are in elevated roles and or play a key role in decisioning, implementation, et cetera. And it's not just people managers, it's individual contributors that play very specific key roles by virtue of their level.
So it's a pretty broad collection. It's not just the senior director and above kind of thing, right? It's about, you know, who are all the players that need to help this team be successful from a awareness, planning and decisioning perspective, right? That can really bring in some rich input. So we get together once a month. We do a review of the month that was. We checked in and say, how are we looking for this month? What's on track? What's not? What is just way out of whack? Because they're always something, right? And try and create an environment where people are unafraid to air their own dirty laundry. We are data junkies. We like to measure a lot of things. We'd like to make things very visible, red, yellow, green kind of scenarios. And we found that that definitely creates again, that space for people to really feel like people say, here's what went well, here's what we learned. Others can now learn from that. Here's what didn't go well, but here's what we're doing about it. And really gearing the organization towards, if it's not green, what are you identifying as those things that prevented from being green? And then what are you course correcting or changing or proposing and need help with in order to get on a path to green, right? And just getting people used to talking, especially in this virtual hybrid-ish kind of sometimes in office, sometimes on video, sometimes on phone-only type of world, creating those connections once a month has just been invaluable. And so we've even mandated that once a quarter, we get together in person, globally.
Melissa - 00:25:41: One of the things that you were just talking about is you're a data junkie too as a team and you're using these metrics to kind of see where you're at. What types of metrics are you measuring at your level to one, make sure your teams are on the right track from a strategy perspective? But then I'm also curious that they're healthy, right? If there's any metrics you're looking at for delivery or from a DevOps perspective, what do you kind of look at from a month-to-month or week-to-week basis?
Tim - 00:26:08: Yeah, I think there are two modes of metrics. One are, what are you looking at in terms of these leading indicators? And then there's the lagging indicators. I think it's healthy to have views of both in the grand scheme of things. What they have also aspired is that whether you're a product manager or in engineering doing the development, the design, the coding, etc., I've always had a view of if you have a product manager and engineering manager pairing, create an environment where they're actually interchangeable on a day-to-day basis because they understand each other's worlds intimately. And so I've imagined a dream where every product and edge person has two dashboards up. One is the business dashboards of lagging and leading indicators and what looks healthy. And then also the operational dashboard. How are the systems performing? What does our throughput look like? So on and so forth. And everyone can now have a combined shared language and be able to describe what's going well, what's not going well. So I think I've always tried to create that kind of base understanding. I think by approaching it that way, it actually forces people to engage very differently. It creates a tremendous amount of empathy and trust amongst team members because deciding on what to build and what value to go after and realize out in the market is a really hard gig, right? You often play the... You're in this center spotlight and nucleus of a company. And it's very easy to, when things don't go well, to look at product management, right? It's kind of like in sometimes an engineer, you know, infrastructure operations and engineering, no news is good news. And there's so much work and complexity and efforts that go on behind the scenes to make sure that when things are humming, it's just a steady state and it's almost invisible.
But it's really hard to do that really, really well. So how to build that empathy and such, I think creates a lot of, I don't know, healthy cultural norms amongst people to be able to be in the business and making hard decisions over and over and over again. So like examples of like the, you know, the lagging indicators are like, you know, revenue-like attributes attached to a particular part of the product. But if we know, like, for example, for these personas, we want them to be buying that product, then I'd be looking at leading indicators. And we try and bring in more than just usage of a product and engagement. But, we do analyze a lot of data. So for, I'll give you an example. We look at, for example, out in the market, types of impressions of certain types of phrases we've had out in the market. Or how many times did someone who's talking to an external audience use the words that we need them to use to be able to raise awareness of this part of the product to that persona? And if it's only happening one in every 10, we shouldn't be surprised if there's very little attachment. If it's happening nine out of 10, and it's still having a little attachment , well then, we've got a leading indicator and saying, you know what, the activity side of this, it's not helpful. We got to try a different route. So we try and kind of correlate those two aspects on a week in, week out, on a month over month basis, just to give us, you know, good, I think good opportunities to learn and iterate and adapt as quickly as we can. And it's not always easy when you're in B2B land, because, you know, the absorption rate on the other side, kind of fluctuates quite a bit.
Advertise - 00:29:07: Are you eager to dive into the world of angel investing? I was too, but I wasn't sure how to get started. I knew I could evaluate the early stage companies from a product standpoint, but I didn't know much about the financial side. This is why I joined Hustle Fund's Angel Squad. They don't just bring you opportunities to invest in early stage companies, they provide an entire education on how professional investors think about which companies to fund. Product leaders make fantastic angel investors. And if you're interested in joining me at Angel Squad, you can learn more at hustlefund.vc/mp. Find the link in our show notes.
Melissa - 00:29:41: As a technology leader, you're also overseeing product and that's in this kind of like CPTO role. And sometimes it's a little touchy subject in the product community because people are afraid that product reporting into technology won't be seen as like important. So I'm curious from your perspective, what have you thought worked really well about combining that role? And then how do you kind of think about managing all those different pieces, both product and technology and design and making sure that one's not like outweighing the other or one's not leading the other in bad ways?
Tim - 00:30:14: I think what works well is regardless of who is fulfilling that single role, they have to have, I think, an aptitude and a desire to lean into almost all parts of the business. I'm a technology leader that cares very deeply about the business outcomes. I don't care as deeply as like the shiniest thing that just showed up in open source land that everybody is trying to use kind of thing, unless it gives us a path to a pragmatic, durable, and robust solution that addresses, again, things that we need to be doing to put us in a good position to help our customers realize value. And a lot of times, sometimes you can see that with a very direct light, sometimes indirect, right? Direct meaning, oh, I developed this part of the feature set for the product. Look at the usage. It's driven all. Okay, great. Or indirect of, I'm in cloud operations and I'm ensuring that, you know what, no matter what, we're always pretty resilient to cloud hiccups that I don't control. I think it takes a certain kind of, I think, leader from a desire and interest and acumen aptitude perspective where it's not for everyone. The balance comes in, I think, when you look at scenarios of like, you know, when it works well in a single leader, one is, okay, it's one less negotiation cycle to go to, potentially. That's a nice benefit of it. Almost like a single back to path when things are going well or throat to choke when it's not from a higher up perspective. You know, and I think even when it's been split, one thing we've done, I think, pretty well here at PagerDuty, when it's been split between two roles, and I've been the other role as well, is we've always had a scenario where the goals between the orgs are shared 100%. So if there are, for example, revenue-based outcomes that are important for this area of the product, well, then if the chief product officer has that goal.
Then me as a chief technical officer running engineering, I've got that same goal. But I also expect if we say, hey, our service level objectives leading to our SLAs need a certain availability and reliability profile or security posture, then I'm expecting, again, another shared goal scenario. And we've hung that way for quite a number of years. It's definitely helped at least create an alignment scenario where then you can draft off of that. And then depending on the group you're in at, your contribution factors, certain things is going to vary. But you have clear alignment. It's not always perfect. But I'd say if you can solve for 80% or 85% of the trade-off scenarios that way, you're giving yourself a fighting chance to keep running. There will always, I believe, be a tendency to naturally lean into one side or the other based on potentially your upbringing in the industry. I'll readily admit I do lean in at off hours heavily into the engineering side. It's kind of how I grew up. But I care very deeply around the approach we take to product design, customer engagement, the choice points we consider across our various product lines, across our platform. And I think just finding newfound synergies and improving the overall cycle time is one of the benefits we found in combining the role into one person versus having two or more.
Melissa - 00:33:10: So you mentioned too, like PagerDuty started where it was separate role, then it combined, and then you split again, and now you combined. What really caused it, I guess, first to combine and then split? Was it the stage of the company? Were there certain factors going on?
Tim - 00:33:24: Yeah, absolutely. It was stage of the company. If I rewind history to combine, we felt we were starting to find opportunities where we could evolve our product offering fairly quickly. And so what that led us to say, okay, if we combine into one role, again, it's like one less decision cycle. And yeah, at the time we felt pretty passionate that was the right move. And it really helped us kind of focus our energy around some key things that we were looking to put a dent into. And one of them was around branching out from a single product and seeing that there are adjacencies that we're kind of dabbling in. And so do we set us up for a more durable business overall in the years? Because we've always had this line of sight in the long term. It's never been only short term. So we've had this belief that we're here to put a positive dent in the universe and we have like an enduring quality about us. So let's live up to that. And so what that means, we believe that going back to this probably 2016 timeframe, early in my tenure that we got an opportunity to go into some adjacencies. In order to do that, do it a little bit quickly. We felt, all right, let's combine into one role and we have a better chance to succeed. We split a couple of years later because as we went into the multiple products, it felt like, you know what, given where we were at and the scale, find the maturity of our own company and everything else we have going on, we'll be better served if we have separate focus on these newer products that were emerging. And then still the build side of it in the engineering area. Because especially with product leaders in B2B, you play like 12 different roles every day. You've got to go and engage in the field, probably with industry, probably with analysts, probably with your own sales team, with their own marketing team and coalesce and synthesize all these various inputs into then deciding, okay, here's what we're saying no to, try and do that effectively because good luck, that's hard.
And then also here's like the handful of things that's usually very finite, depending on your perspective that we're going to go focus on and build. And just to be able to separate concerns, we felt that was the right move. Come back again in about a year and a half ago, we said, let's put it into one leader because one, we felt that our operating capability around product, you know, conception to delivery and value realization was going pretty well, but we have opportunities to create more synergy in order to, I want to say, almost help amplify the platform offering that we've evolved into. So we've gone from single product offering to multiple products powered by a platform. There's always a lot more platform work to do than you originally estimated. We felt putting it all into one place would help us make better decisions faster about the most critical path items around ongoing platform how that shows up to our customers, how it shows up in the market. So we said, let's put it together, right? And then I've been I think fortunate enough to have some amazing people associated, that were also allows us to now give it our current structure. Also have a healthy eye toward what needs to be in three years time. We've hit a new maturity scenario where and predict financially where we're most likely going to be. And that has a certain scale factor of internals and things like that. Whether its architecture process related and design related that we can work backwards off the three-year view and then have a healthy carve out of folks that are thinking about and starting to really socialize. Here's like the, here are the principles we abide by. Here's what that shows up in terms of what needs to be true in three years, find creative ways to incorporate that into the annual build cycle or the monthly build cycle, depending on what area of the offering we're working in.
Melissa - 00:36:46: So there is this kind of trend out there too of, you know, we were talking about a little bit before we jumped on here, but this combining of the CPTO role like this. What have you been observing out there about what companies are deciding to roll it all up into one person versus not?
Tim - 00:37:01: Yeah, you know, it's interesting. I used to see a lot within the consumer landscape, whereas quite often where you'd have it more or less combined into the single role. Because you have very, I think, like discrete channels to push out to the market. And your demand signals mainly coming from like, you know, specific set of types of end users. So it has a different scale factor, whether it's systems, product experience, business. In a lot of ways, if you just look at it like e-commerce has a certain scale or a TikTok or a WhatsApp has a very specific scale factor. Whereas in B2B, five years ago, I hadn't seen too many of these single roles, but we're seeing them emerge more and more. I think what's happening is given how a lot of companies are going through some type of transformation. Often it's coined in the digital transformation landscape. What that usually involves is my business is going digital, right? Like digital first mentality. Everything that powers my business is not digital yet. So I got to play catch up fast. And I think by starting to put, you know, kind of these two really critical functions closer together, you get into the cycle time challenge. So, it's getting managed a certain way around whether it's decision cycles, design, development, delivery, etc. I think there's like this natural need to compress that. And I think maybe less cooks in the kitchen, it creates that. And there's so much where business and tech and technology are just so intricately locked in together that was like mandated to start to get more and more connected without having to have yet another meeting, yet another discussion, yet another person to convince or to fight with or to spend time negotiating with. I think the running joke I made to you earlier is like the flip side of this is like, I realize it's like cost optimization. We have one less person to pay. I'm not sure yet, but it's definitely a running trend. That's super interesting.
Melissa - 00:38:42: Yeah. One of the things I was thinking about too, is I feel like a lot of people will make the argument that products that are more technical lend itself more to a CPTO so that you've got somebody from the technical side leading product. PagerDuty is pretty technical with what it does. Do you feel like that's true? But you also brought up consumer side of products, which I haven't seen as much that trend. I primarily work in B2B. So I'm curious what you think about whether there's certain type of industries this leads better to or certain types of products or anything like that.
Tim - 00:39:12: I don't know if I've forward an opinion yet on that type of pattern, but it's interesting to look at because if something is technical, and let's take an AGR example, I think one challenge that exists with a single role is the scale factor that that individual can operate under. Because there's such demand to be in the market, to understand what's happening in the market, whether it's analysts, journalists, whatnot, but that also bring in a lot of those inputs into internals, and then running the ship internally to make sure you stay aligned and everything else. So just by virtue of where you're spending your time, it's an interesting, I think, just again, like how many hours in a day kind of dilemma, because we haven't even talked about that. You also have the engineering side. What about choice points around strategic areas of investment, like in the cloud, or other tooling, or the talent profile of your organization, so on and so forth. There's a lot that goes into that. So I think if you're able to do it well, you want to have some real sound structure and some fantastic people with you and under you, that can help make that work. Because if you do have a bit of a gap, you're always playing catch up. And the worst thing that can happen is like a role like this, where it's combined into one, is constantly being reactive, you have to find a way to get in that proactive state. If not, you got to go change something.
Melissa - 00:40:27: What do you do to be proactive? What types of things did you bring to your arsenal so that you could say, I can concentrate on strategy and this is how I make time for that?
Tim - 00:40:35: I try to be very methodical about how I spend my time in a given week. It doesn't always go your way. By the time you reach Friday afternoon, you look back and you say, wait, what happened? Literally, I try and block out certain pockets of time in the mornings on specific days for my thinking time. And my thinking time is I might be reading, catching up on email. I might just have an impromptu conversation with someone in the team or whatnot. But it's kind of like my space just to kind of be able to wrap my head around maybe one or two key things that are sitting at the top of the list or an emerging thing out in the landscape. Like when Jen and I started showing up left and right, I remember blocking off, I think, the entire day. And I said, I'm going to bring up my editor and I'm going to start coding with this thing. What's going on? What do we got? And I came up with a few examples just to kind of play with and say, and I shared it out with parts of the team and said, what do you think?
I was like, is this a thing? Dude, you're like two months behind. I thought I was getting ahead. But I do try and carve out blocks of time. I do try and create a scenario where certain parts of the day are in this operating manner, other parts are sitting with other peers in the company or our CEO on strategy. And then another part of the week is spent with the people. So I try and create those kinds of like, almost like guardrails, the box, because I'm not the type that can easily just juggle from one thing complete to the other within minutes. I do need a second. I think a lot of humans are wired that way. We kind of kid ourselves about, oh, contact switch. What a cool thing to be able to do. No, it's maddening. It's really hard. Don't kid yourself. So I do think. But you do need to be able to then have opportunities and work with your team in those different manners. Because again, in kind of like these types of roles that like someone like me sits in, you're responsible for integrity of the strategy, responsible for creating direction for your organizational strategy, support the higher order strategy. You're responsible for deciding on the things that will create the most value in the fastest amount of time. Oh, and also you got to build it well. So customers are always happy. It's a tall order.
Melissa - 00:42:27: It's a lot that goes in there. And from like a team perspective, I've seen some people who are holding both roles, right? If they do CPTO, where they might have like a VP of product, a VP of engineering, a VP of design underneath them. How do you structure your team for scale that way? And what do you think are the critical roles that you need for support around you so that you can spend your time how you allocate it?
Tim - 00:42:49: One thing I've aimed for is to really help follow the strategy, meaning I think organizations need to be amenable to shifts and changes, right? I've had it where a single VP of product and a single VP of engineering in place. And then there might be a VP of design, or maybe that's another level that reports in the VP of product. And then B2B software, we have an advent of also a very critical area of pricing and packaging that comes into play. That usually product ought to be in the position to drive. So I think if you've hit a certain, I want to say like certain, almost like a skill level, you would have that structure. Sometimes you might need to break things apart and bring some things closer to you because they're maybe a little bit newer, a little bit more emerging, but highly strategic. So you need to be closer because you're first on the accountability block in terms of like, where's it going? Where is it at? What does it need? Does it have a fighting chance or is an experiment to kill? So you might emerge out and actually bring some other people into that leadership level at like that level too. So, to speak, or you then might shift into a very functional areas. What I'm not a fan of, I can say that my personal taste is not to have too much matrixy kind of scenarios. I think that makes it hard to allow individuals to really hone in and develop their parts of their careers around the craft that they're most closely associated with, whether that's product management, whether that's design or software development. I think these are all creative crafts. And, it's important to have a bit of a conscience established around these in the grand scheme of things so that people can really grow and develop and learn from others and be super, super motivated to grow and develop while they're there with you, not go elsewhere, right? So it gets into the retention cycle that, you know, as leaders, that's always top of the line.
Melissa - 00:44:37: I think that's so important for people to remember too. So if you were to give advice to somebody out there who's maybe like a product leader going, should I take on technology or a technology leader saying, should I take on product as well? What would you tell them to consider before diving in?
Tim - 00:44:52: So personally, what I've learned, the best experience that I had is when I get to opt in to work in an area that I'm not very comfortable in. But someone has trusted me enough and felt that I'll get there, right? So if you feel like you've got the right amount of support to get there, even though it looks scary and crazy, my opinion would be dive right in because having the breadth of experience can really, really help round out your career journey. It doesn't, and again, career journey isn't like your current company's journey in terms of its career development. It's not name your company development. And so I think when product folks can dabble into the world of engineering or vice versa, it just creates so much more perspective and empathy and understanding of the complexity that goes into every single day. I'm a fan. I've done it a few times. I think the first time I went in kicking and screaming, but I'm very thankful for the opportunity. It just helps me understand things better and I think be a better partner to my other colleagues across the company at the end of the day.
Melissa - 00:45:50: And I think it's a testament that you came back to it still after you tried it for the first time. So that's good.
Tim - 00:45:56: I could just be crazy. I don't know.
Melissa - 00:45:59: Everybody's got to be a little bit crazy to work in tech, I feel like.
Tim - 00:46:01: It goes a long way.
Melissa - 00:46:03: Well, thank you so much, Tim, for being here. If people want to learn more about you and PagerDuty, where can they go?
Tim - 00:46:09: Usually LinkedIn, I tend to hover around the most. So if you look me up there and follow or message me, that's probably the best. That's probably where I tend to do most of my posts on topics like this or other nerdy, hair-brainy things.
Melissa - 00:46:21: Great. We will definitely put all those links for Tim in our show notes. So go to productthinkingpodcast.com to find them. Thank you so much for listening to the Product Thinking Podcast. We'll be back next Wednesday with another episode. And make sure that you get all your questions to me about product management at dearmelissa.com and I'll be sure to answer them on an upcoming episode. Thank you so much for being here. We'll see you next time.