Build has a brand new dedicated feed. You can subscribe here to stay up to date when new episodes drop.
Today on Build, host Maggie Crowley sits down with John Cutler, Product Evangelist at Amplitude and former Senior PM at Zendesk and Pendo.
Together they discuss what Product Evangelist actually means. Plus the importance of value creation over output, how to implement the pull system, why limiting your product backlog is a good idea and much more.
You can get Build on Apple Podcasts, SoundCloud, Spotify, Stitcher or wherever you get your podcasts. Or listen to the full audio version below ?
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️⭐️ review and share the pod with your friends! You can connect with Maggie and John on Twitter @maggiecrowley @johncutlefish.
Subscribe & Tune In
In This Episode
0:07 – An introduction to John Cutler
4:15 – A pull system helps you focus on actual demand
6:30 – The goal is to fill customer needs and create smooth production flow, not keep everyone busy
9:04 – The North Star Metric Framework
9:31 – Re-framing the manner of describing the missions of their teams
11:00 – You have to learn how to communicate differently about your work
11:17 – Don’t outsource your product strategy to the sales team
12:17 – Use the 1-to-3 Game to explore the nested complexity of product development
15:34 – Talk about the components of product development as bets and nested bets
15:54 – Product development is a game, not a science
16:20 – The best way to hit deadlines
22:00 – ‘Done’ actually means customer adoption and usage of your product
25:05 – The nested bets reasoning process
26:38 – The belief / assumption mapping exercise
29:08 – Always have your updated and correct belief map
29:45 – The best product leaders are super crisp and coherent in their communication
30:15 – Always hold in your mind the persistent message about why you’re doing your product development
30:51 – John shares 3 key pieces of advice for people to be more effective in their work:
31:12 – 1: Don’t worry about keeping people busy
31:34 – 2: Your goal is to create an environment where the best decisions are being made
32:33 – 3: You need to learn, and convert to value faster than your competitors
34:39 – Only regular learning and improvement help you advance
Full Transcript
Maggie: Welcome to Build. This is Maggie. Today, I have an amazing guest that I found in very typical Drift fashion via Twitter. John Cutler has a long career in product at places like Zendesk and Pendo and is now a product evangelist at Amplitude. He has an incredibly deep understanding of the different processes we use as product teams and I’m super excited to learn from him today. So John, welcome to Seeking Wisdom.
John: Yep, thanks for having me. I’m looking forward to it.
Maggie: Great. So, if you could just give us a sense of how you got into product. Before we were chatting, you mentioned that you were in bands. How did you get into product? How did you become a product evangelist at Amplitude and what is that?
John: Sure, yeah, I wasted away my 20s playing music, but I think it was really fun and I got to travel a lot. And I think it’s actually important that I did that because this idea of kind of being in a small van with a bunch of creative people, sometimes strong willed, that had like a really strong impact on me. So I’ve kind of taken that with me for a long time. But I had a startup also where … I had a startup making a bartending video game, so I started to kind of experiment with different things. A couple startups when I was living in New York. And then I just kind of drifted into product roles, UX research, product management, different stages of companies from really big to really small. So I had a son seven months ago.
Maggie: Oh, congrats.
John: And so I was consulting. Yeah, no, it’s … Oh my God, it’s hard. But yeah, it’s the hardest product ever.
Maggie: Yeah, I can imagine.
John: But you can’t manage it basically. So then Sandia from Amplitude reached out and she had kind of read my writing and bits of work and I really liked the mission for the role which is to up-level product teams in general, not just with their product, which is a product analytics platform I guess. But overall, and I think that that was kind of a good fit for me because I understand how important it is to have the right tools and have the right supportive accompany that’s kind of in your corner. But a lot of being impact driven is about … It is a bit of a mindset shift and a structural shift in how you work and a bunch of things, and that’s what I’m a big time nerd about. So it was a good fit and I was excited to do it and she persuaded me to join up and I’ve been enjoying it so far. So that’s where I’m at now.
Maggie: Awesome. What’s sort of the day in the life of a product evangelist? So I understand this idea of up-leveling a product team, but what does that actually look like for the team at Amplitude?
John: That’s a great question. I’m not 100% comfortable with the evangelist part of it too, because I feel that that … But it is kind of what they’re called at the moment. We can’t find a better word, maybe advocate or something, but a day in the life is me writing, me meeting with prospects and customers, me keeping a finger on the pulse of where kind of modern product development or product management is at the moment. So I can work with people, doing workshops. Actually the workshops are a great example of like a dream come true in the sense that we do these for prospects and for customers, for anyone really, so it’s an opportunity to kind of keep my finger on the pulse of everything that’s going on in product, which is kind of a dream.
So that’s a day or week in the life, writing content, working, doing learning stuff, and then also actually helping internally kind of up-level people in their perception. A lot of sales folks or customer success folks, or customer service folks, they’re really passionate about, but they haven’t sat in the shoes of a product manager or a dev manager. They haven’t sat in those shoes. So a lot of it’s actually building empathy internally for the plight of product managers.
Maggie: Right. And how they make decisions and why that feature that’s so critical may or may not be getting built.
John: Oh yeah, yeah. That’s a lot of it.
Maggie: Yeah. Okay. So that’s a great segue because I think the thing that brought us together was the series of tweets that you had a couple weeks ago or a couple days ago that had these amazing GIFs that describe different ways that feature or projects might move through a product team in terms of the status. So you know, ready to do, in progress, done, and this idea of a pull system versus some other systems. So can you describe, sort of without visuals, exactly what that pull system is that you tweeted about and sort of how that came to be and where that came from?
John: Sure. The idea of pull systems is part and parcel to lean product development. And the whole idea is limiting work in progress. And another way of saying that is kind of limiting inventory. So if you think of a traditional production process, inventory is waste. You’re actually kind of pulling from the customer order. The product analogy would be like any idea sitting in a backlog is inventory, it’s aging, you’re learning new stuff about it. You could also view it as an option. And so in knowledge work, I think it’s important to mention having a huge backlog of stuff, that means having a lot of options potentially. So how that inventory depreciates is another question, but the whole idea of a pull system really goes back to lean and lean product development.
Specifically for that tweet thread, I think maybe a story is a good way to describe what I’m talking about and maybe even thinking about your personal life. Like I have a lot of projects around the house that I’m sort of dripping away at. Like I’m doing a little bit of it, and then I have this great idea for a podcast or writing a blog post, or, “Oh, I have to do this new thing.” Or I’ve been trying to work on this book. Well, “Oh I’ve got to write this other thing.” All of that is kind of sitting in my head. And a pull system has a number of components. One is this limiting of work in progress. So if your team was blocked, for example, by something, instead of pulling in new work, kind of waiting and wondering whether that thing would get worked out, you’d actually swarm on that problem and unblock that problem. You wouldn’t take on more work. So that’s one little element of a pull system.
A more philosophical element is this idea of the customer has a need which creates a kind of spot, and you’re pulling work into meet that need and only that amount of work, not extra work. And this is especially hard for startups that are growing rapidly because they feel that because they’ve got everyone there that they have to build a ton. And one view of this is well, you’re never going to have enough people, you’re never going to be able to build enough. So you might as well keep everyone super, super busy. In a flow based system or pull based system, the goal is not to keep everyone busy, the goal is to fill these customer needs and to limit your work in progress and create flow. Hopefully that made some sense.
Maggie: Yeah. Yeah. I want to dig into just a little bit more about this idea that limiting the work in progress is important and it’s wasteful. So I think a lot of PMs are writing specs, or we call them one-pagers or whatever. They’re doing all this work to generate a backlog and things that they could or should work on they think is important and they spend some time prioritizing it. And so is what you’re saying that some percentage of that backlog is sort of useless and shouldn’t be there, it should be much smaller? Dig in a little bit on how a PM should approach limiting that piece of it.
John: Well that’s a great point and I think one important point about a pull system is we tend to keep too much in inventory. That’s like a kind of human nature, but there is an optimal point of inventory. So a great example of this is like if your team is moving through one particular goal between every 10 and 30 days, it doesn’t make sense really to do a lot of documentation or a lot of research on the 15th thing in line. In fact, that’s probably wasteful research. And what tends to happen in an organization that doesn’t really think about work in progress limits is everyone is so busy that nothing gets done, and when nothing gets done, the only thing that the, “Idea,” people or research people, or whoever, business people have is to dream up more work to do.
So they dream up more work to do, things are not moving, and then you have to start prioritizing silver bullets which keep people even busier and less gets done except for the silver bullets. And then it just becomes this sort of wicked cycle of not really focusing on what’s important. The goal is not the output of features. The goal is the velocity of learning and the velocity of value creation. And I think that if you take that mindset and if you understand that, you are able to be a lot more strategic and effective as a product manager. Granted ,you’re going to have people push back on you because for a lot of people they’re only perception of effectiveness is output. And so you have to juggle that.
Maggie: Right. That was going to be my next question, which is, okay, this sounds really great, but then when as a PM, you’re supposed to be telling other teams what you’re working on and what you got through, how does that change how a PM measures their own value and what they’re contributing to an organization if they can’t say, “Well, we shipped these 10 features?”
John: And I think this is actually a great question. At Amplitude, we follow the sort of North Star metric framework. So in North Star framework, for us it’s weekly querying users, not just weekly active users, sort of weekly querying users. That’s what’s really important to us because it demonstrates that people are getting value out of our product. And from that are a number of input metrics. Like there’s a number of things that we believe contribute to that north star. We align teams around moving those particular metrics with sort of missions of things that they’re doing. So I think that a lot of this transition for product managers comes from reframing how you talk about the missions of your teams. Instead of, “Our goal is to ship this feature,” it’s more like, “Our goal is to make this, for lack of better word, persona awesome at blank.”
Maggie: Yep. Yep.
John: And what’s very interesting there, I always tell this story, but I had a friend in sales and I was working at a company. And they were totally obsessed about having a tool in Salesforce which listed all the features and where they were at. And this caused a ton of planning inventory in the company, a ton of dependencies, things we’re kind of grinding to a halt. There was a web of promises that no one could keep. And basically over time, the product team just demonstrated that it could create outcomes. And the salesperson had this great quote. They’re like, “You know what? I don’t care anymore. Like I sell what we’ve done in the last year, and people’s mouth drops and they’re like, ‘Oh wow, you guys keep innovating.’ I don’t need to future sell anything.”
Especially in software as a service, it’s a relationship you’re building with the company. They’re hiring you to innovate on their behalf. So this whole idea … Like granted features can help sell your product against a competitive product, but if you’re down the level of feature by feature win loss, hopefully you haven’t slipped into being a commodity. Like you have to have something more as a business. So I mean this is all pretty philosophical, but I think there’s real application and you have to learn how to communicate differently about your work, and if you show the outcomes, then people start to trust you and you don’t need to talk as much about features.
Maggie: Right, because those outcomes are outcomes for your customers, not internal metrics that you’re using to judge, “Did we get enough things done that day?” Or whatever.
John: One quote that I use is that you don’t want to outsource your product strategy to sales because they will fill the void. No one wants anything more than that amazing case study, and salespeople love to sell on outcomes all day. But if you don’t give that to them, they’re very driven people, they’re just going to default to what you have. And so suddenly you’re going to stumble in on a call one day and look as I’ve done in the past, like you’re looking at a presentation and realize that sales has cobbled together like 35 different presentations to try to talk about the product strategy, and then it hits you like, “That’s on us. It’s not on sales. It’s on us for doing that.”
Maggie: Right. Okay, I want to get into this idea of outcomes in a second, but before we move to that part, still on this idea of the pull system, making sure that you’re outlining and creating a story or narrative or a mission. What does that look like for a day to day of a PM? Because I think it makes sense when you’re thinking about, “Okay, for this quarter or this month, this is the mission that we’re driving to. We’re planting our flag here and we’re going to make this outcome possible for a customer.” But then when you’re in the day to day, what is this specific project that they’re working on? How do you bring that even down to that level?
John: I’m huge on coherence. I have this game that I call one to three, which is go from one to three hours, to one to three days, to one to three weeks, to one to three months, one to three quarters, one to three years, and one to three decades. Every company is a combination of nested bets within those ranges. And so you should be able to go from the thing that the person is going to take one to three hours on and be able to go and say to them, “How does this fit into our one to three decade bets?” And they should be able to walk that tree. They should be able to go up to doing that particular thing.
And this is a huge deal. I wrote a post called Beyond Outcomes Over Outputs because people take a super simplistic view of this. They think it’s this binary thing that you’re going to do one or the other. The reality is is that every problem is a nested solution to a higher level problem. So you will need output. To learn, you will need output, you will need to ship something. Many times. Or for some learning you will need to. And so the day to day is still about getting stuff done. You’re going to have to draw a little box around that work. The difference is that you’re always holding that coherence there. So for day to day it would mean, let’s say you’re doing scrum and you do some kind of demo weekly, the PM will take a step back and say, “Okay, I just want us to look at the big picture again. How is this tying in at a minimum to your one to three month work?”
And I find that the most passionate people on the teams, they need that information. Because a great example is someone says, “Oh, we’re moving up into the enterprise.” That’s actually a solution to a higher level problem. So the really savvy person on your team is going to be like, “Why? Why? Why do we need to move into the enterprise? Are there not enough SMBs left to do well? Why aren’t we moving into the startups that are going to become enterprises?” So any savvy person on the team who’s done this will see immediately through any attempt to create a false definitive problem. So I think that once you embrace that on your team and you don’t try to hide that or gloss that over, then it ties in this question of what you do in the day to day. And I think that’s essential.
Maggie: Yeah. And then with the subtext being, if you can’t tie those things together, then you probably shouldn’t be doing that thing that you’re talking about.
John: Yeah, probably. It’s funny because I wrote a post for Amplitude recently about experimentation. And I think experimentation sometimes is actually used as a trust proxy. It’s kind of like, “Okay guys, let’s just run an experiment. Let’s go, let’s run an experiment. Let’s just do this.” It’s kind of, “Trust me, let’s just keep moving. Let’s keep doing this.” They’re not really running. There is no like spirit of learning. And then if you ask how many of your experiments have failed, they’re like, “Oh wait, wait. They never fail.”
Maggie: Right, So they use the experiment as the first step into building thing that they want to build anyway, but because they started with an experiment, it’s an excuse to get started without doing all that research.
John: Yeah, and I think that the reason why everyone hates MVPs, because it’s a ploy, it’s a game used to kind of get something minimal out the door. It’s actually supposed to be a learning tool, and I think that savvy developers and savvy UX see through this. They’re sitting there with an associate PM who’s been assigned to their team, and they’re talking about the PM, and these other people have been around the block a lot and they’re just like, “Oh, just spare me.” I think that that’s really, really important because I like to talk in terms of bets.
There’s a Spotify thing called bets are dibs, which is, data insight, beliefs, and bets. And I think that’s right. think that if we talk more clearly about them as bets and nested bets and things that we need to do to learn, it’s actually more conducive to product because product is not science. Maybe we apply science in product, but it’s a game. I mean you’re an athlete, like you know that it’s a game. This is a sport in some way, right?
Maggie: Yeah, absolutely.
John: This is that it’s maybe a team sport. So anyway, you get the idea. I think that there’s something to be said there about reframing how we think about this stuff.
Maggie: Okay. Yeah. So I have one last question on this idea of the pull system and outcomes in general, which is dates are really important and I think especially you mentioned moving up into the enterprise. As you move up into the enterprise, and you have larger customers, you do have to do more communicating around when things will be done and when things will change, and there’s some sense of giving your customers an idea of when things will happen. And with a pull system, how do you manage to those dates? Do you at all?
John: Yeah, that’s a great question. Obviously people use lean to hit dates. Toyota hit dates. And the point is, and actually this is a really interesting thing, it’s kind of counterintuitive. The way to be able to hit dates is to be able to work in small batches and have a lot of flow and have a lot of options with how you’re working.
Maggie: Yep.
John: So this idea that you need to get good at hitting those dates, you almost counterintuitively shouldn’t be worrying as much about those dates. I mean they’re going to sit there hanging over your head no matter what you do, right?
Maggie: Right.
John: I’m really into being very customer centric about this and there’s totally domains were dates matter and giving them a sense. I also know how powerful it is when you have a pull, flow-based system involved that you can look at any reference piece of work and be like, “Stuff generally takes 45 to 60 days.” That’s it. And we know. Like you draw histogram, we know. And in fact, if you hit those types of ranges, if you’re able to consistently say to customers, “Yup, that’s in the next quarter.” What you’ll find is you build the trust with customers. They’re like, ‘Oh, we didn’t need an exact date anyway. We just needed to know generally.” Especially in software as a service when you’re going to be getting that.
The other thing that’s important is that there is this perception that unless you give a date, people are going to get lazy and are going to take forever and they’re not going to do it. And that’s where teams should invite forcing functions into their work to help kind of keep them honest with where it’s going. But it’s an invitation, it’s not an imposition. So as a team you would say something like, “You know what? Any kind of story or mission that seems to just feel like it’s going to take more than a month, we should break down. Or if anything has been hanging out in the pull system for more than 14 days, that’s an immediate retrospective.” Or any number of things. So it doesn’t preclude you using any number of techniques to make sure that you’re de-risking and you’re creating small batches. So I don’t know, hopefully that answers your question, but counterintuitively, to be able to do that, you need to practice and that’s what you need to do.
Maggie: Absolutely. Well, I think one of the things that I try to do is understand how do we go from that really awesome looking GIF that seems super simple and like a magic bullet for how to do product and actually pull it back and look at it inside of an org and say, “Okay, what does this really mean?” Because I think it’s sort of easy to read a Medium article or something and say, “Oh yeah, that sounds like a great idea.” But then you sit down to do your work and then you’re faced with that question of, “Okay, well I want to have a pull system but I still have to hit that deadline.” So it’s really helpful to hear that those things aren’t in conflict like you mentioned.
John: Just quick thing to that, in one of those GIFs shows what scrum was supposed to be. You have a sprint goal. That is your goal, and the whole team is aligned around that goal. Not individuals with their own little mini backlogs, not keeping everyone busy. The team is aligned around making that sprint goal happen. And they don’t even figure out all the stories ahead of time right in the beginning of the sprint, they do just enough to get started and they have the absolute ability to remove scope or do whatever’s possible to try to get something that’s potentially releasable by the end of that thing. And so this is often missed. And what happens is a push system in that sense is the team pushes a big batch of stories and the only thing that equals success is getting all those stories done that were never designed to be like that.
And that’s kind of a … That teams are bludgeoned with that all the time. And it’s not great that that happens. Because I mean, I think I read a little bit about how Drift does some work, in this idea of like releasing a product each month. I’m not sure if you’re still doing that, but that forcing function is brilliant. Provided that teams are trusted and have safety to reduce scope and keep quality and craft high.
Maggie: Yes.
John: The worst thing that would happen is you drop all these balls and cut all these corners to be able to do what you said you were going to do every single month, and then a year later you’re completely drowning in nonlinear complexity and you can’t get anything done, which are the risks you understand, right?
Maggie: Yeah, I live those risks every day and I think you’re right. I mean we’re not by any means perfect, but the way that we approach it is more of an outcome focus, or our missions. We say, “Okay, here’s the mission that we want to ship.” On whatever month that we’re thinking about, and then we work backwards and we say, “All right, what is the simple, lovable and complete version that we could have? And then what are the iterations that we might want to do on top of that based on what we learn and then how can we work backwards from where we’re trying to go?” And it’s the full team that’s involved in that full process. So it’s not just a PM in a corner doing the work, it’s the whole team.
John: I thought the brilliant thing about that in the original post about marketable moments, I think. I forget the exact post, but it basically said, which I’ve shared with tons of people now, is that the company realized that the actual … And this is part and parcel to a pull` system as well, is that SAS, really the company is the product. And everyone needs to align. Marketing needs to align, customer success needs to align. You need to be able to share with people. And here’s one thing I’ve found is that with SAS, like it’s so easy at least initially to create output. There’s great tools out there. We can build so much faster now than we could 10 years ago. But our companies haven’t actually caught up.
So this is actually part of what a pull system does is by using a pull system and work in progress limits and progressively kind of analyzing the work, you would have noticed like, “Wow, done means customer adoption and usage of this thing.” And marketed message and the story and the ability to support it. We’re just piling up a ton of inventory for those teams and they don’t know what to do it. So I thought that that posts was brilliant. It actually demonstrates a pull system in an amazing way.
Maggie: Yeah, it’s interesting. I think that’s why we were also intrigued by the diagram that you had because I don’t think we had been, or at least I hadn’t been thinking about what we do as a pull system, but you’re right, it’s a little bit of a different way to approach the process, which it makes it a little bit easier for the team to show.
John: Pure pull system. You wouldn’t worry that it’s going to be exactly every month. You kind of … You’d be like, “Oh, this will take 20 days. Or maybe at the moment customers can only absorb every 45 days.” But I think that’s a great point too, that this is not some like definitive thing. You can create a system which has elements of both. It’s sort of fractal in some ways how you work, and your one element of it can be you can use the time box as a forcing function, but you could imagine your month goal backlog. You just decide to size them by 30 days. It’s a great example of that it’s not purists pull all the time, that there’s other approaches to doing it.
Maggie: Yeah. I think, again, we’ve sort of said this word a couple of times during this conversation, but the idea of focusing on an outcome versus a specific product is part of how we’re able to do that. And so it’s something that I’ve been talking about with a couple people on the podcast and sort of informally here and there, which is it seems that product is shifting away from, “Okay, we’re solving these customer problems,” to, “We’re trying to create these customer outcomes.” So in your work as someone who thinking about sort of modern product development and what’s new, how do you think about this idea of an outcome and how does it play into how we work?
John: So I would go on this thought exercise. Imagine level one work being me telling you to build exactly this.
Maggie: Okay.
John: I’ve given you a spec, like you can’t go wrong. It’s like build exactly this to a team. And then a level eight is like create a multi-year long business outcome. I think you bring up a good point why this discussion of outcomes gets kind of messy because think about that spectrum and all the steps in between. There is something like solve this customer problem, allow this customer to be able to do X, optimize this metric, create a short term business outcome, solve a problem for this segment of customers in a more open-ended … I’ve actually written about this and I can share a link for folks for the podcast, but the idea there is that again, this idea of problems being nested solutions to higher level problems like it is the same thing.
The team that said before that we’re going to solve this customer problem. That in itself is a totally valid outcome. Is it creating a business outcome? No, but can you link it to the business outcome? Yes. When you think of this idea of nested bets, you would go something like, “We need to make that button radius three PX. Why? Because we want this flow to be optimized. Why? Because we want accountants to be able to move quickly. Why? Because our larger enterprise customers have large teams of accountants and they have tons of work and to be able to sell into that, we need to make them efficient. Why? Because we need to go up market because there’s only a limited number of small, medium size accountant firms, financial firms, and at a certain point we need to go to that market, otherwise we’re just going to be limiting our growth. Why? Because we believe that we need to change how small business finance works around the world.” I’m like kind of making it up, but you get the idea, right?
Maggie: Yeah. Yeah. Which ties back to the point you made earlier about being able to say one to three hours, all the way up to three years, three decades, being able to walk that line between what you’re doing and where you’re going.
John: Yeah. And one important theory, it’s not about having a full sense of certainty. If you kind of know about Bayesian belief maps or other things like that, like we’re making money or you have investors and we have investors because people believe that there’s an opportunity here. It’s not certain by any stretch. And so the bets are linked by beliefs and assumptions. And so the mistake, I think, for a PM is to convey a false sense of certainty. “If we don’t go into here, this is not going to whatever, whatever, whatever.” How many times do you say that and a year later you look back on and then be like, “What were we stressing about then? That’s crazy that we were worried about that.” And so I think part of it is I do this kind of belief mapping or assumption mapping exercise where each goal, you break down the kind of because, you break down the by trying, you break down what you know, what you believe, and then the guard rails that you might want to create in trying to get that solution.
So we have a goal but we don’t want to like cannibalize clicks from somewhere else or do something else. And the interesting thing is I’ve done this exercise with teams. You start at the main goal of the company, but it’s seven levels down before you get to what the teams are working on right now. It’s the problem I have with OKRs, because there’s no assumptions baked into OKRs. You give them to team, teams are said, “Get your OKRs done, you’ve got 62 business days per quarter to work and you have to fit in five to 10 days of planning because there’s this thing called OKRs.” It’s kind of like every OKR, back to this idea of spectrums it’s like, “Well, it’s not exactly a key result, but it influences this other thing, multiple things. What are the assumptions? Why is it important?” And missing, I think, in a lot of goal setting frameworks, it’s the belief map is not there.
Maggie: What the belief map does is allow you to call out those places of uncertainty, or where you’re making assumptions that you might want to test, or think about as you’re building.
John: Totally, and that’s where you want the engineering doing the one to three hour tasks to be like, “You know, it’s been sitting in my mind that we keep thinking …” A great example is allowing customization in your product. It’s always a leap of faith. So on one, side you believe that if you can let customers customize, then they’re going to be able to get their particular work done. There’s another party that says something like, “Don’t let them customize because they’re going to actually not get the same outcomes that we know the best way, so we should tell them how to work.” And then there’s a third way that says, “Don’t let anyone customize because it’s technically very difficult.” So that’s a common balance. Now, unless you’re a company has a perspective on that bet, because it is a bet. If you build too much customization, your product gets too complex. If you solve it with an ecosystem instead of in your product that offers other things and other … Anyway, you need the person working on the ground to understand that that is an ongoing concern.
Maggie: Right? Not just a given the fact that they have to accept.
John: Yeah, the jury is not out yet on that.
Maggie: Okay, So then let’s say you’re an individual product manager on a team, how do you approach your day to day with this mindset? So I think it’s one thing to be at a level where you’re sort of setting strategy and you’re setting those goals and your thinking about this at a high level, but if you’re sort of on the ground, how should this mindset change your day to day work, if at all?
John: So what I think one of the things that when I’m coaching PMs, I say always have your belief map. Don’t wait for other people to ask you for it. So every day keep a diary. Keep a notebook, have your belief map updated and be able to have something that’s pretty much always correct. Someone should be able to get you in the hall and say, “What’s going on?” And you need to say, in tweet length, “We’re doing this to move this, to move this, because we think this will happen and we assume this will happen.” My experience with the best product leaders that I’ve known, and I’m not actually that great, I’ll be honest, because I’m pretty wordy and I like to think about the ideas behind it. But the best product leaders, they’re just super, super, super crisp and coherent in their communication every day
And you asked about day to day, and that might not be answering the question, but I think it’s like you have to treat this coherence challenge as your day to day meditation almost. And leave time for it. If you go a whole quarter and you’re like, “I haven’t even had a chance to think strategically.” You’re not doing your team justice. I actually think it works into the day to day and I think it also means that you have that persistent message in your mind about why you’re doing this. So I think day to day, allocate 20 to 30 minutes to write in your diary problems that you’re having, notebook. Then revisit your belief map. Is everything still holding together? And then have you detailed maybe the risks that are on your mind right now and what you’re going to do about it? So keep that meditation going day in, day out,
Maggie: Right. Listen, incredible. Thank you. I’m writing down a million notes to go back and take this into my life. So okay, we’ve talked about having a belief map, making sure you’re updating that every day. I love this idea of it being sort of a daily meditation. If you had to take a step back and think about sort of a couple of pieces of advice that you might give to people listening who want to either start to move towards a pull system or think more about outcomes, or just be more effective in their jobs as part of a product team, what are the three key pieces of advice that you’d give them?
John: Oh man, that’s where the having too many words comes in. Let’s see what’s on my mind this morning. I think that the first thing is don’t worry about keeping people busy. And that seems trivial and seems like, “Oh, that’s common sense.” But that belief as a PM, or whoever, that you need to keep everyone topped up has massive ramifications in everything you do. So I think that that would be one of them. This is what on my mind this morning. So if you asked me tomorrow, it’d probably change.
Maggie: It’s perfect.
John: The second thing I would say is I believe that your job is a PM, and this varies by organization obviously, but sort of in my version of it, your goal is to create an environment where the best decisions get made, not necessarily that you make all the best decisions. And I think that thinking about that sort of to up-level what you’re doing, I think is an important thing. And I think it’s very, very important if you have aspirations to become a product leader, or become a VP, or become a CEO of your own company.
Not that I think you should be the mini-CO, but if those might be long term aspirations for what you’re doing, you have to stop this kind of hurting me decision mentality, and you can’t get talking by the team to doing it all the time either, because you will limit your career growth. You need to be a force multiplier. If your only value is your best idea that day, or your best decision, unless you’re the best decision maker in the world, it’s a limiter. So I think about that from a career standpoint to do that.
And you know, I think I would end on this idea of this is not easy. This whole idea that you somehow like walk into work one day and say, “Hey, we’re going to take this outcome driven approach and that’s what it is.” I talked to a CO the other day and they were talking about some of my blog posts and they said something like, “John, you position it like all we need to do is walk in one day. It’s really hard. You don’t think I want outcomes? You don’t think I want to be able to talk about this all day?”
And I think that that’s where the mindset of you need to kind of encourage your team to continuously improve an experiment in how you work, not just like the experiments you’re running for your product. And then also that this is a progression, I think, is another kind of north star. Like you need to learn faster than your competitors and you need to convert that learning to value faster than your competitors and the people who will potentially disrupt your business. So that’s your bar and you just need to keep moving where you are at. It’s not going to happen all in one day. That would be my final bit today, but maybe I’ll have three more tomorrow.
Maggie: That’s perfect. I love it. I think, again, I’ve definitely felt all three of these, so don’t worry about keeping people busy. Definitely guilty of that in the past. This idea of making your goal to create an environment where other people are making amazing decisions. I have to think about that. I think that is an incredible statement and something that I think every PM needs to think about probably every day, because a lot of us, at least I’m guilty of getting impatient or frustrated and wanting to just make decisions just because, let’s move fast, let’s get going. And then you’re right. It’s not easy, and I think especially as someone who’s on a team and maybe not a product leader, or not in charge, wanting to change can be especially difficult and the idea that it’s going to be a progression, you can experiment your way towards it is I think really powerful.
John: I attract a lot of internal change agents on Twitter for some reason. Because I am one. I’m one too. I’m not a VP or CO or anything, so I’ve been in that role where you feel like you’re getting frustrated, you feel like your org just doesn’t get it. Like if you could just move beyond this thing, everything would work out. And you know, over the years I’ve realized that you’re never seeing the full picture. It’s never as easy as you think it is. It’s that regular learning and regular kind of just sort of nailing it and getting better that helps you advance, not, “I talked my whole organization into doing the Spotify model.” They didn’t arrive at the Spotify model one day, it was a process. So you need to figure that out for your own company and figure it out for yourself too.
Maggie: Awesome. Well thanks, John. I really appreciate you coming on the podcast and giving us all of the wisdom on how we can do better. For everyone listening, give John a review, shout him out. Give us six stars only obviously on Seeking Wisdom. That’s what we’re going for. And please let me know if you have any feedback or any comments on today’s episode. Thanks.
