Podcast: Play in new window | Download

Sean [00:00:18] Hi, welcome to the Product Momentum Podcast, a podcast about how to use technology to solve challenging technology problems for your organization.

Paul [00:00:28] Well, hey, Sean, how’s it going?

Sean [00:00:30] It’s going good, Paul.

Paul [00:00:31] Excellent. So we just talked to Christopher O’Donnell. That was a fantastic conversation.

Sean [00:00:37] Product leader at HubSpot. Brilliant mind.

Paul [00:00:40] And I think the thing that I’m most impressed by is the level of trust that you’re going to hear in this conversation coming up.

Sean [00:00:46] I mean, he just ripped the covers off and showed us everything. It’s amazing.

Paul [00:00:50] I think the way that you build trust in organizations is a lot of the same way that you build trust in the products that you’re shipping. And I think it starts from the top down. And as a leader in an organization, you’re not going to get to a more genuine perspective than the conversation we’re about to have with Christopher. So let’s get after it.

Sean [00:01:08] Let’s get after it, man.

Paul [00:01:13] Well, welcome to the show, everybody. Today, we’re excited to be joined by Christopher O’Donnell. He’s the chief product officer at HubSpot where he drives product management, design, and user experience for HubSpot suite products. Prior to this role, Christopher led the product team building the HubSpot CRM and HubSpot Sales Pro. Upon joining HubSpot, Christopher led the rewrite of HubSpot marketing product, culminating in HubSpot Contacts and the release of HubSpot 3 in 2012. Previously, Christopher was director of product at Performable before it was acquired by HubSpot in 2011, and he’s been a startup founder, advisor, and a product UX leader. Christopher, we’re so excited to have you. Welcome to the pod.

Christopher [00:01:51] So excited to be here. Really looking forward to chatting with you guys and learning something myself today.

Paul [00:01:56] Fantastic. Hope we can teach you something. We’re looking forward to learning what you have to say. And just to jump right in. I want to dig into culture and trust specifically. The way the HubSpot team works seems to be based largely around this feeling of trust. You’ve opined that as V.P. of Product even, the first time you see features is often live in demo on production. And that’s a good thing, right? You’re not surprised or offended that you’re not being given information?

Christopher [00:02:28] I’m delighted.

Paul [00:02:29] So can you tell us, what does it take to get to this level of trust in teams in an organization?

Christopher [00:02:34] Right. And I guess even backing up to think about why you would do it. You know, the idea of teams having a lot of ownership, from a selfish perspective, you know, you can attract really great people. You can retain really great people, and they will do things that are better than what you could have told them to go and do, you know. And so I’m never surprised by something that I see that they went to solve that problem. The problems are never a surprise. The solutions are often a delightful surprise because the teams have found a better way to solve the problem than what leadership would have given them if we had just given them marching orders.

Christopher [00:03:13] So, you know, it’s not just a touchy-feely, let’s all hang out at summer camp kind of culture. It’s hard work and the problems are hard and the customer demands are very high and challenging. And, you know, building business software, people are betting their careers and their livelihoods on this. And so we have to perform at the highest possible level that we can perform. So how do you get there? Well, we don’t give people projects ever. We never use the word project. We give people products and they get to work in small teams on those products with very clearly defined goals and guardrails for those products. And they get to work on those together for a couple of years, a few years and really own the successes and failures along the way. And it just changes the whole experience of building something when you really have that level of investment. And again, selfishly, people stick around and, you know, really great people kind of hear about that and they come knocking on the door and they say, “is this real? Do you really ship to production a thousand times a day?” “Oh, yeah, actually, we do, and only shipping more and more as we get bigger and bigger.”.

Christopher [00:04:21] So, you know, it really comes down to giving people products as opposed to projects with clear goals and guardrails. And even better than giving them products, you know, what we’re moving toward is giving them problems. And if the right way to solve that problem is to kill the product that you own, which we’ve seen some very brave product managers do in the past, then you should do that. If you are the product director running SEO optimization tools for marketers and you own a keyword optimization tool, and that’s just not the way the world works anymore, you should kill it. You should build the solution that the world needs. And that’s a real example. And we saw somebody, you know, have the bravery on our team. Angela DeFranco was brave enough to actually make that call and defend that call at the highest levels, and she was right. You know she was right to do it. So, you know, again, it’s the old Steve Jobs thing. You do want to hire people and tell them what to do. You want to hire amazing people and have them come show you the path forward and give you ideas and solutions that you never would have thought of in leadership. And on a good day, we actually can pull some of that off.

Sean [00:05:25] I love that, Paul, you probably see me chomping at the bit over here.

Christopher [00:05:28] I have, yes.

Sean [00:05:29] We’ve touted the product versus project mindset for years and I love to shift into problems as a strategic direction for every product team. The late Stephen R. Covey had a quote that I’m going read out loud here. “You can buy a person’s hand, but you can’t buy his heart. His heart is where his enthusiasm, his loyalty is. You can buy his back, but you can’t buy his brain. That’s where his creativity is, his ingenuity, and his resourcefulness.” And I think, you know, that is the fundamental human level, the difference between extrinsic motivation and intrinsic motivation. You have people show up for their job because they’ve got to get paid and they’ve got to get a fair wage for the work that they’re doing and the knowledge that they bring to the table and all the experience that they’ve accumulated. That’s a necessary thing. But if that’s why they’re showing up to work, you’re gonna get a crappy product at the end of the day. You got to hire their hearts and the way you hire their hearts and their minds is by showing them the problems that they can take their creativity and go solve. I love where you’re taking that.

Christopher [00:06:27] I love that quote. The one that we, sort of similar, that we show internally and when we talk about our culture, there’s this French aviator and writer who wrote The Little Prince. And I don’t speak French, so I’m not going to say his name right, but Antoine de Saint-Exupery or something. And he said, “if you wish to build a ship, do you not divide the men into teams and send them to the forest to cut wood, instead teach them to long for the vast and endless sea.” And so that’s absolutely it. You totally nailed it. You know, in terms of organizational design and promotion criteria and culture, we very actively are tuning for intrinsic motivation. You know, I have a spreadsheet actually now of all of the different behaviors that we want to reward, all of the different ways that we can reward that behavior, and does it enforce an intrinsic mindset or an extrinsic mindset? For my part, I have a fancy title and stuff, but I’m not a big believer in title promotions.

Sean [00:07:23] Yeah.

Christopher [00:07:23] If it were totally up to me and I could start from scratch, everybody on our team would just have the title product because it really doesn’t matter. If you’re an APM on our team, you own problems and you own, you know, finding the right solution to those problems all the way up through a V.P. or anything else. It’s all kind of the same job and the more that people can find the reward from solving those problems, the more, first of all, you know what we start to see is we start to see people lifting each other up because there’s no limit to the resource of intrinsic motivation. There’s a limit to extrinsic. There are only so many people’s names that the CEO can say in front of the company at a company meeting. There are only so many promotions that you can give before you start getting into this insanity of, you know, senior product manager level three or whatever else. That’s a finite resource. And when you start people down the extrinsic path, that’s what they look to and that becomes the cultural norm. You start people down the intrinsic path, then all of a sudden, “Hey, if Paul has a problem on his team that I can help him with, I’m going to help him,” because that becomes cool. It feels good for him. It feels good for me and, you know, hopefully, the reward system is going to notice that and say, “look, that was a good job, Christopher, like, you made Paul better today.” It’s sort of like trying to get the star basketball players to stop shooting three-pointers all the time and to start passing the ball and setting up plays. You know, that’s a championship team. And so, no, I could not possibly agree more with the idea of Covey’s quote there and huge, huge emphasis on intrinsic motivation.

Paul [00:08:57] So this is a great segue way into a mainstay, a mainsail, concept that you’ve talked about at length on the blog and others have talked about on the blog. Mainsail is something that HubSpot has sort of adopted. It’s an analogy based on what I think you said it based loosely or tightly on Maslow’s hierarchy of needs, right?

Christopher [00:09:16] Yes.

Christopher [00:09:17] Is it a measure, a set of metrics on product or process, or a combination of both? How does Mainsail influence this culture of trust that we’ve started to pull the thread on?

Christopher [00:09:25] Yeah, it’s a zero percent on process. You know, we’re very light and kind of high-level in terms of, we have an operating system, we have a roadmap. We have a big event with 25,000 people every year where we do product launches. I mean, we are, in fact, grown-ups. We have a product marketing team. We have hundreds of people selling the software. So we do have enough of an operating system so that it’s somewhat predictable what is going to happen. But we don’t really reward process excellence very much at all. And, you know, what you get out of that, the last demo that we did, and we’ll talk about Mainsail, but we do a monthly demo called Science Fair, which I’m sure we’ll talk about. But the last Science Fair that we had was just a few days ago. And we do, you know, post-Science Fair NPS on this stuff. It was rated in 97. Brian Halligan, our CEO, got on to a company-wide call that happened to be right after the Science Fair, and he was shaken, you know, and he said, “what we just saw at the Science Fair was effing ridiculous.” And, you know, that took process. And we do dry runs and we schedule it and we have a roadmap for them and all the rest of it. But it’s much more about, do the teams have the impact for customers and can we celebrate that?

Christopher [00:10:37] And that demo was actually effing ridiculous. And we saw, you know, some big banner launches that’ll come at some point. And we saw those in the first 15 minutes and then there was 45 additional minutes of stuff where we were just like falling out of our chairs. And it was kind of funny, the team decided to do a Drake-themed presentation. So it was over Zoom, so all the product managers presented from different parts of Drake’s house and all the business cases were sort of, you know, using Drake and all the rest of it. So there is an enormous amount of creativity for them to deliver within that.

Christopher [00:11:07] However, the creativity comes from the constraints. So imagine being a product manager on our team and hearing from me and from other folks in leadership, “you need to care about support ticket resolution times for these types of issues when customers call in and you need to care about backend API error rates for your part of the product and you need to care about front-end performance and availability and latency. Oh, and by the way, a lot of teams are starting to look at seven-week free user retention of their free tools,” and all this kind of stuff. And you’re sitting there as a product manager and at a certain point you call B.S. and you say, “look, how am I supposed to optimize for all of these things? You say that I have autonomy, but it’s impossible for me to come in in the morning and even know where to start, even know how to spend my time.” And that that would be fair pushback. And that was the pushback we had, you know, say, two, three years ago where the fully ad hoc goals and guardrails kind of process started to break. I mean, we have 80 or 90 frontline product managers now, so we need enough of a playbook so that people know kind of what to work on.

Christopher [00:12:14] This is where we entered into taking all of those metrics that we thought really mattered and kind of putting them on a table. You could almost imagine like a card sorting exercise with all of these, and we put them into different buckets. “Oh, OK, here’s one. It’s a performance, front-end availability and latency and that level of user experience, that’s a bucket. OK. Then there’s useability and supportability of the product. And that’s CSAT and task completion rates and usability bugs that come in from support. OK. That’s a bucket.” So we came up with these buckets and then what we noticed was that they absolutely go in order of importance. So just like Maslow’s hierarchy of needs, you know, you’re not going to focus on self-actualization if you don’t have a roof over your head. You’re not going to focus on having a family if you have no food source, right. So these things actually do come in order and it is like a law of nature that these things come in order. And so it’s very easy to remember and it has the benefit, always good in a leadership message, of being totally true.

Christopher [00:13:14] And so we built this hierarchy of needs that we call the Mainsail. The bottom is security because if you have a security issue with something you’re working on, you do not do anything else. That’s very clear, right. Above that is all the backend stuff, which we call collectively infrastructure reliability. Then you get into the front-end infrastructure and performance. Then you start to get into the more qualitative stuff, which we try to quantify, but it’s more qualitative, around usability. And then there’s kind of a line above which you’re doing the stuff that product teams and product managers usually think about, which is like feature value and then growth. So, you know, feature value has been something we’ve been good at, I think, for a long time. You know, product managers come in, we talk to customers, we have a million ways that we get input. We try to make some good decisions. We try to have a great level of usability, and then we build features into the product. Customers are happy.

Christopher [00:14:08] And then over time, about 2014, 2015, we started getting into, above that, growth. Looking at activation rate, deep activation rate, user retention, starting to think about how we drive demand for sales, you know, and made some progress there. But we didn’t have a whole bottom of the Mainsail just intuitive where you could go to any team and say, “how are things going?” And they’ll tell you very crisply in a narrative exactly how they’re doing. So from a leadership perspective, we realized we really needed to give those guardrails to the teams just so they knew where to start. You know, even if you look at it and you go at you, “yeah, actually we feel pretty good about the bottom of the Mainsail, we’re going to go back to feature work.” Great, well now you know, you know, and if teams are actually struggling in those, we’ll pull them down into a mode where they have to focus on the lower part. And that’s not a punishment. That’s sort of like, “Hey, we’re going to give you air cover to really get the stuff right.” And we’ve seen, you know, user NPS really respond as a result of this, and our own confidence in the product, it has been absolutely game-changing.

Sean [00:15:13] There’s a whole bunch of things to pull on there, I don’t even know where to start. So, first of all, it’s clear to me you guys have a mantra around goals and guardrails.

Christopher [00:15:20] Right.

Sean [00:15:21] Which I think is a fantastic mantra. It’s autonomy-supportive, like…

Christopher [00:15:26] Right.

Sean [00:15:26] You know, we have these best practices, not processes. That’s another thing I heard, right. So we have a playbook, but it’s not a process, which keeps the mindset that if things are not fixed like we’re always here to adapt and learn. So I love that. And then lastly, you talked about, I’m going to put this quote out there and I’ll make sure that it gets touted in the blogosphere, “creativity comes from the constraints,” yeah? So creativity comes from the constraints, the guardrails, so to speak, and the goals, like those are essentially your constraints. And I have this belief that sounds very similar that objective prioritization is impossible.

Christopher [00:16:03] Right.

Sean [00:16:04] What you have to do is put the guardrails and the frameworks in place so that people can make decisions at the ground level. So I’d love to hear maybe a little more about the guardrails and how you manage that distinction. It’s a great distinction.

Christopher [00:16:16] Yeah, absolutely. And we really do have a very autonomous culture. It’s the number one thing when people come in from, you know, other walks of product management careers and find themselves on our team, I have lunch with them about 90 days in and say, “you know, what do you notice?” And always the number one thing is the autonomy is actually real. These teams are actually making decisions for themselves. And to your point, Sean, autonomy is not chaos. Autonomy is not doing whatever you want and optimizing for yourself or your team above the customer. Autonomy, strictly defined, is something along the lines of being able to make very high-quality decisions without consulting a lot of people. That’s what it is. There could be one answer. Autonomy is not necessarily a choice. Autonomy just means that you know what you’re supposed to do without having to run it up the flagpole or look over your shoulder or put it through some huge process to do the obvious thing.

Christopher [00:17:15] One of the things that blows my mind when I talk to any startup product team or folks who just want to talk shop. I ask them this question, I say, you know, “walk me through what it would take to fix a typo in your product, like pull your product up. OK, great. So here’s the dashboard. When you log in, whatever it is. OK. That nav item right there. Let’s imagine that was misspelled” And they say, “well, yeah, yeah, we would fix that.” And I go, “no, no no. Walk me through exactly, exactly what you would do. Would you get up from your chair? Would you file a ticket? Would you..? Like, exactly what you would do and go through the process.” And, you know, I once talked to a team that walked through a six-week cycle to fix the typo. And then the punch line was there were four people on the team. It’s like, “guys, just fix the typo.” You know, I mean, if there’s a typo in the nav, just fix the typo. You don’t need to think about it as part of a microcopy review sprint. That’s going to be scheduled; it’s every third sprint, we do a quality sprint. And, you know, we would prioritize a microcopy one and all the rest of that, like, that’s just kind of B.S..

Christopher [00:18:20] So, you know, autonomy is absolutely giving people the tools to make great decisions and move really quickly without having to run it by a whole lot of other people. But you don’t get that without guardrails. You know, you don’t get going to production a thousand times a day without measuring the impact of every breath you take. The whole point of getting toward continuous integration, continuous deployment is actually that you get a much higher quality product and you get a much higher value product to customers because you’re not leaving inventory on the shelves. You know, leaving code on the shelf is economically as costly as leaving a car in a warehouse. And from a quality perspective, the larger your releases are, the harder they are to do in a really quality way. You know, small releases are higher quality. They’re easier to roll back and they’re easier to roll forward and just kind of fix. They’re easier to see the impact on the kind of business metrics.

Christopher [00:19:17] So that’s just one, I think, particularly pressing example of the guardrails around, you know, going to production and all of the checks and balances that are there to go to production. And those guardrails make it easier to go to production over time and give you more confidence in what you do. And there are other guardrails, you know, I mean, we have our Science Fairs. They’re themed now and so, you know, you definitely need to be showing up and, you know, presenting amazing stuff at Science Fair. You need to have a perspective on net promoter score and how you fit into that. You need to have a strategic mindset and be able to tell a story that connects from something our CEO would say on the news about what we’re doing as a business all the way down to, you know, one of 10 deploys that your team is gonna do that day. Like, those kinds of guardrails are kind of non-negotiable, but you can see they’re actually in service of doing a great job and not having to come run those decisions by me.

Paul [00:20:19] So, Christopher, I’m not going to lie, you’re hitting pretty close to home here. I think, you know, the voice that I try to bring to the shows is the voice of the day-to-day product owner, product manager, and I would say, I don’t have hard data on this, but I would say anywhere from 75 to 90 percent of the frontline product managers in the industry today are operating in a Scrum framework of some sort. It’s all customized and ad hoc a little bit, but I would say the predominant framework that the industry has adopted today at this point time is Scrum. And you’ve left Scrum behind at HubSpot. You broke up with it a couple of years ago and Science Fair is the demo end of what you have adopted.

Christopher [00:20:59] That’s what we kept. Yeah, we kept the demo. We liked the demo.

Paul [00:21:02] I like one of the quotes that you put out there about, you know, demo it in production, “demo in production or it didn’t happen.” There’s no such thing as demoing with a mockup or demoing in proud or local hosting. But I want to talk to the product owner or product manager in the trenches right now today listening to this and trying to make a change where they’re at. Not everybody is at HubSpot, but they all are in product organizations and they can make changes where they are, grow where they’re planted. How can a product manager take where they’re hearing, these aspirational ideas of autonomy and goals and guardrails, and make a change within the constraints of Scrum, if that’s where they are?

Christopher [00:21:43] Sure.

Paul [00:21:44] Is it possible?

Christopher [00:21:46] Oh, absolutely. I mean, look, here’s the mantra: process should address the problems that you have in making things, and we all have different problems. The way that we build incrementally in small betas, hand-to-hand with customers, I mean, we’re very close friends with our customers. My wife’s company runs their business on HubSpot. All my friends with startups are running their businesses on HubSpot. You know, we’re able to work in a way that we couldn’t if we were working for Elon Musk at Space X, you know? So understanding the constraints that you have and adapting your process to address the real problems you have, that’s the mantra. And there’s nothing wrong with Scrum per se, in my view. There’s nothing wrong with it at all. In fact, the reason it’s so popular, I would argue, is a great one. And I’m not the world’s Scrum expert, but I have run religious Scrum, absolutely, like really detailed user stories, acceptance criteria, all this kind of stuff. And it has helped, actually.

Christopher [00:22:49] I see Scrum solving two huge problems. One is not being able to get to production and getting in front of customers. The second is getting hassled by everybody else at your company. Those are real problems and if you’re a product team and you’re trying to build software and you know, your releases are getting bigger and bigger and bigger and the scope is creeping and you’re having more meetings and all that kind of thing is happening, Scrum is going to help with that, very, very clearly. If you have the situation where product, you know, “oh actually, you know, there’s a Director of Product, but she actually reports to the Head of Marketing and the Head of Marketing comes around and taps the product managers on the shoulder and says, ‘hey, I need you to do this thing for this little deal I’m doing with an OEM partner,'” or whatever else and then all of a sudden, the teams are kind of, you know, knocked off the rails or the executive team meets on Monday morning and they come walking over to the Head of Product and saying, “actually, we’re gonna need you to change a few things in terms of your planning,” Scrum is going to help you there. It’s going to help you enormously. And by the way, from my limited experience, those are the two most common problems that software teams have.

Christopher [00:23:55] And so, you know, you’re 80 percent of the way there or 90 percent of the way there just by having the protection to actually ship and get it in front of customers and be able to sit down and have a conversation about how you think it went. Scrum is great. Scrum is actually great. And so to your question, taking inventory of the problems you have: if you’re using Scrum, take a look at why you’re using it. It may be that you’re working with really senior engineers that are subject matter experts in what you’re working on and they actually don’t like Scrum and they don’t like the process and all this kind of stuff. They want to be left alone but they have a hard time getting to production because they kind of go down rabbit holes. Well, OK, then evaluate. Is Scrum the best way to keep the rabbit hole-ing from happening? It might be. It’s a good way. It’s a very good way, but there may be other ways. Like for us, the idea of having protection from the rest of the company in terms of thrash, we solve that in other ways and we have an enormous investment in that. And we have a huge operating system that probably feels heavier weight outside of our teams than on our teams, because the problem is much more a communication to the rest of the company than, “Hey, this team that happens to be sitting in this part of the office that happens to be working on this part of the product needs to be told what to do.” “Oh, actually, they’re fine and they’re getting to production three or four times a day and they’re moving NPS on their product and so they kinda should just get left alone.”

Christopher [00:25:20] But I need to find a way for the work that they’re doing to get in front of the head of sales, to get in front of the founders, so that there’s confidence. And that’s where the Science Fair piece ended up being pretty magical because showing consistent progress, we learned, was the best way to build trust with the company and solve that problem so we didn’t need Scrum to solve the problem. And in a very product manager kind of mindset way, we’re kind of going at the root. Why do you need Scrum? Why are they changing priorities? And you get kind of back to the bottom of it and you have to take inventory of, you know, do you have a shared vision as a company? Does the product team have trust with the founders? Is there skepticism? Is there cynicism? And if you can find a way to go down and actually root that out, that’s when you start to have a lot more flexibility in terms of how you move and groove. But, you know, look, building you know, a switching control system for the Atlanta Light Rail or space shuttle operating system, or you know, or a medical device or SAS software or scientific analysis software, all of these things are very different in terms of how they’re used, the constraints you have, regulatory constraints, whatever it may be. And while there is no one size fits all, I don’t look down at Scrum at all and I think that it solves a lot of problems. Interestingly, the typo example I used, this was a shop that was religiously running Scrum because they had come from these big shops where that made a lot of sense. And it’s four of them sitting together and, you know, they’d be better off just spending half their time on the phone with customers and trying things in little betas and seeing where it went and writing it up on an internal wiki. Like that probably would have solved the problems that they really had. Their problems were not getting to production. Their problems were like really finding early-stage product-market fit. And, you know, Scrum wasn’t going to solve that.

Paul [00:27:03] So I love how pragmatic that is. So you just tied the strategic and the tactical together in this notion of you don’t need the die-on the hill of process just because it’s what everybody else is doing. You can make decisions and really, I think what I heard you say is you don’t just ask what to do next. You ask why you’re doing it next.

Christopher [00:27:22] Right.

Paul [00:27:22] And when you can answer, what problem am I trying to solve, then you can apply whatever process. You can take the tool out of your toolbox that you need to use and not just default to a hammer because everything looks like a nail.

Christopher [00:27:33] That’s right. I found out, you know, that a little pocket of teams were running Scrum and, great, you know. And I said, “well, how are they doing?” “Oh, they’re good.” “Cool. They happy?” “Yeah, they’re happy. They just, you know, a few of the senior folks have used it in the past, and they kind of like it, and it’s fitting in.” “OK. And can they tell a really clear story of what they’re doing and how it fits into what the company is doing? And do they know customers by name? And do they know what their titles are and how they get promotions and what they don’t like about their job? Are they thinking about how to get them out of the office an hour earlier to go to their kid’s soccer game?” “Yeah, they’re thinking about all that stuff.” “Great. Enjoy your sprint.” You know, see you at Demo Day. I hope you have a great retro, like, that’s awesome. And then there are other teams where people just say, “look, this is an infrastructure thing.” I mean, we have, I don’t know, 20 percent of our team that has zero product managers and they’re super, super high performing. It’s our infrastructure team and they solved that problem in a very different way. You know, they are responsible for all of our platform-as-a-service, our build and deploy, you know, all of our front-end infrastructure, you know, static bundling, all that kind of stuff. And they’re religious about quarterly NPS, internal NPS, of everything that they own and provide to the team. And they’re developers and so intuitively, they read the NPS from their friends, by the way, which is always humbling. And they look at the feedback and they go, “this makes a lot of sense,” and they go and they make it better and they move that NPS. You know, we have a build system we built from scratch that has a 70 NPS internally. It’s like better than any build system you can go and buy on the market. Zero product managers involved. So absolutely no one size fits all. And, you know, just being close to the customer and close to the problem tends to work out.

Sean [00:29:09] All right. So I’m going to twist your words a little bit and make sure I understand this for the audience. So Scrum is basically a set of guardrails.

Christopher [00:29:17] Absolutely.

Sean [00:29:17] Gives us some shared language. It’s better than working in complete chaos. It gives us protection from the thrashing, misguided priority schemes. But it’s just a toolset and if it works, you use it. It’s all about what works.

Christopher [00:29:28] Absolutely right. Yep.

Sean [00:29:30] Also, I want to pull on something else you said because it leads into another subject that I’m interested in hearing more about. You asked an incredible question to your teams do they know their customers by name and how they’re gonna help them get their kids to their soccer game on time, right?

Christopher [00:29:43] Yeah.

Sean [00:29:44] Getting out of their way. That’s the key thing we always find. Most people don’t, especially in the business world, they don’t come to a piece of software because they just want to use a piece of software. They come because they want to solve a problem and get on to the next thing. I think we sometimes lose sight of that as product leaders. That is our job is to get out of their way. And this is a function of empathy.

Christopher [00:30:04] Yes.

Sean [00:30:04] So it sounds like you guys have some pretty cool tools and language around building real empathy for your consumers. How important you think that is?

Christopher [00:30:14] Oh, it’s massive. I mean, we’re working on something that’s kind of exploratory now and talking to a ton of people and doing some product work. Just, you know, strategic kind of product work, the stuff to any of the three of us that’s just kind of like hanging drywall, just, you know, bread-and-butter kind of work. And taking three months to just do the interviews and sharing all of the interviews through, you know, Gong is actually a great tool. It’s actually a sales tool that records calls and lets you do all kinds of cool things with it. But I actually pay for Gong because it’s as valuable as a whole UX research team. We take detailed notes, we share these things. It’s product marketing, it’s go-to-market, it’s product management. The questions that are breakthrough for us are not like, “tell me what’s in your stack.” You know, “tell me what tools you use or what do you have to do every week or all the rest of that.” Yeah, you ask that stuff and that takes two seconds and very little of that is surprising. You ask questions like, “tell me about your career,” you know, “what do you love about your job? What do you hate about your job?” And we share stories, like, if I can ask a customer one question, it’s “tell me the story of the last thing that happened at work that made you fume over a glass of wine at night with your partner.” You know, that, my friends, is where product marketing is generated, where feature ideas are generated. And what you get also is a level of conviction.

Christopher [00:31:40] Because as product managers, I mean, to all the frontline product managers out there who feel like they’re faking it, we’re all faking it. It’s a game of incomplete information and you don’t know for years and years and years whether you were right. And even then you look back on it and you go, “well, you know, maybe I just joined the right company, like there was no way I could have messed it up if I tried.” I feel that way sometimes, for sure. And so taking all of that together, the best way to get confidence is to get to that human feeling. You know, back to owning the problem, what does the problem feel like? What do you complain to your friends and family about? What are the root feelings? Do you feel disrespected? Do you feel like you’re stuck? You know, do you feel trapped? Do you feel like there’s something unfair about your role? Like that’s what I want because that is really what breaks open the larger narrative. And then by the time you get to, here are the features we’re building and here’s a story we’re going to tell about it, you have so much more color. You know, you have so, so much more color about why somebody is there, and we’re probably indexed pretty heavily in that direction, but yeah. I mean, I guess in summary, I mean, business users of software are people. And they have people problems and, you know, we spent a third of our lives at our desks at work and if you’re making business software, there’s always a human story. I don’t care what you build, there is a human story.

Sean [00:33:03] There’s always a human story. The questions that lead to breakthroughs are those that power our empathy. It’s not the technical questions. That’s what I heard you say.

Christopher [00:33:11] Absolutely, and empathy gets thrown around as this like, you know, I have 110 designers on our team and it’s like, if I hear the word empathy one more time, I’m going to throw bricks through the window. But they’re right. You know, it’s a word that we hear all the time and for me, I just have to give myself a crystallized version of what that empathy is. And that’s why I like getting people to vent, you know, and vent about their jobs and really understand how it feels and then build to the feeling. Absolutely.

Sean [00:33:39] Yeah, it’s the empathy that creates the color and the context for our work, right. That’s where the passion comes from.

Christopher [00:33:45] Absolutely.

Paul [00:33:46] So I want to bring this back down to earth again and say, you know, I love the concepts that are starting to come out. And I think that one of the things that I am sensitive to is just how young this practice is. Ten, 15, 20 years ago, product managers existed but they didn’t talk like this. So the words that we’re using today and the thoughts that we’re expressing today are different. When you look out over the next five to 10 years as a practice, what do you see as the skills and the traits that will make a young product manager, or even, you know, somebody who’s still in school today, who might be studying music, for example, who might end up in a product role down the road, what can they start to build their practice individually around to be successful in the next five or 10 years?

Christopher [00:34:37] Curiosity and truth-seeking, you know, absolutely. I mean, for whatever you’re working on and also for yourself, do you have the real-time feedback on how you’re doing? And especially in this day and age, I mean, I hate to use the expression millennial, but it’s a common thing in managing millennials is, you know, this desire for rapid cycle feedback. And what I would say to that person in school or entering their career is to start very early on developing a system for getting that for yourself, you know. Get it from your boss, that’s fine. But get it from your friends. That’s the most unfair advantage you can build for yourself is to develop ways of getting feedback from the people who know you best and know your weaknesses the best. And those are actually the people you work with, not for, and as you get bigger, the people that you manage, those are the people who have all the holes in your game. Like you said, I mean, 20 years ago, product management was not what it is today and 20 years from now, it could be all virtual reality, real time code. I mean, who knows what it’s going to be? And I don’t know if I would know anything about building that kind of product. But, you know, I have some sense of confidence that I could figure out how to build a lot of different things if I had some amazing people around and they had conduits of telling me as the producer. You know, it’s like, it’s the same role as the record producer making a record. As the producer, the team saying this is what we need you to do.

Paul [00:36:06] Yeah. So there are skills that transcend that current ethos, right. Where we’re at right now, it might be good to be Scrum, it might be good to have Science Fairs. But in the moment, the only thing that’s going to give you that true north is whether or not you’re being authentic to that curiosity, that spark. You could be the most purist Scrum practitioner on the planet, but if you’re not solving the right problem and asking the human questions, then you’re going to be going a million miles an hour in the wrong directions.

Christopher [00:36:37] Right. Or you could fall into a situation where you’re running Scrum and it’s working great and you learn how to do that and that’s all you need to learn how to do to be a really effective, you know, member of that team. We could say to this next generation, you know, learn just general business, you know, just business acumen in general so you understand who the people are in the building that you’re working in and how your company makes money and how the whole thing fits together. We can say learn design, you know, and use your experience. That’s a very reasonable thing. We could say become analytical, learn Sequel, poke at data, ask questions, become proficient in that side of the world. We could say learn enough coding to be dangerous. Learn how the web works, HTTP and Web services, client-server, and the whole kind of Roy Fielding Ph.D., like go read that and understand how the web works.

Christopher [00:37:29] Like all of those things will help you, absolutely, but they are not going to add up to be a guarantee that you’re going to succeed in a role. To me, success in a role is, in an engineering team, being really excited and making a lot of progress and being proud of what they do. You know, that is success. I say to every, whether you’re an APM all the way up to a V.P., I say, “if the engineers lose faith, there is nothing I can do for you. I can think you are God’s gift to product management and if none of the teams are excited to work with you and don’t feel like you’re adding a ton of service-based value to them in their creativity, you’re done.” I’ve said this to my best friends, you know. And meanwhile, I could have the biggest impeachment or complaint for a product manager, go to their team and the teams say and the tech lead says, “look, we’re doing great. He or she is giving us everything we need. Every question we have, we get primary source information. They’re doing great.” Then I’m wrong. So, yeah, no, that’s definitely what it boils down to for me is the interpersonal effectiveness, the growth mindset. Back to Sean’s point about the intrinsic motivation, like double down on that, and you kind of can’t go wrong, whatever you work on.

Sean [00:38:37] Outstanding. All right. For the sake of time, we have a couple of questions that we always wrap up with.

Christopher [00:38:42] Nice.

Sean [00:38:43] One, because you haven’t answered it yet, sometimes it just comes out in the course of us asking questions. How do you define innovation? What is an innovation?

Christopher [00:38:51] What is an innovation? I think it’s one of two things. It’s either solving a problem that hasn’t been solved. You’d be hard to argue that that isn’t innovative, or solving a problem in a very different way. You know, a substantively different approach that has its own benefits. In The Innovator’s Dilemma, for example, that’s really what they’re talking about is missing the opportunity to solve the same problem but in a very different way and all of the economic reasons why as managers, we get wrapped around the axle and can’t do that. I’m a huge fan of Blue Ocean Strategy, by the way. I think that’s as good a framework for a product manager as anything, you know. And the example I would use for innovation is Cirque du Soleil innovating on the circus and almost a Monty Python-esque way. When you think about it, not knowing how successful it is and what a great experience it is. But if you just hear about, you know, Cirque de Soleil, it’s like, “OK, we’re gonna do a new kind of circus.” “Yeah, OK. So it’ll have animals? “No, no animals.” “OK, so it’ll have like, lots of danger?” “Well, not really.” “OK. So it’ll have like lots of clowns and humor and..?” “No, it’s not going to have that.” “OK, but we’re going to sell concessions, you know, in the stands and make our money that way?” “Nope, nope, nope, nope, nope.” If you describe Cirque du Soleil, it doesn’t make any sense, but it solved that same problem in a radically different way. It introduced music and art and culture and high ticket prices and fewer venues and all these kinds of things. That’s a great Blue Ocean example and to me, solving that problem in a very different way is probably the most common and applicable definition of innovation.

Paul [00:40:28] Well, Christopher, I didn’t think that we’d get to Cirque Du Soleil in our conversation. This has been a journey of an interview. I have so enjoyed our time together. Thank you so much for taking the time today and sharing your experience, your wisdom. I certainly learned a bunch. Thanks again. This has been great.

Christopher [00:40:46] Really appreciate it. Paul and Sean, thank you so much for inviting me on and I hope to do this again.

Paul [00:40:53] Absolutely.

Sean [00:40:53] Thank you.

Paul [00:40:53] Cheers.

Christopher [00:40:54] Cheers.

Paul [00:40:58] Well, that’s it for today. In line with our goals of transparency in listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get so please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch, and inspire the world, just like you’re doing. Thanks, everyone. We’ll see you next episode.