Episode 40: Identifying Patterns in Product with John Cutler
John Cutler is the Head of Product Education at Amplitude. He is a product evangelist & coach, who has spent his career wrangling complex problems and answering the ‘why’ with quantitative data. He joins Melissa Perri on this week’s Product Thinking Podcast to talk about the importance of product education and getting in your product “reps”, and the types of product patterns he’s discovered after working across industries.
Subscribe via your favorite platform:
Here are some key points you’ll hear Melissa and John talk about in this episode:
A product evangelist acts as the public face of a company, and connects with the people who use its products in unique ways. Product evangelists bridge the gap of need for education advocacy, helping teams see the future direction that they're going in, and product therapy. [2:04]
Product people tend to follow common patterns and principles when it comes to transformation approaches, but how they apply these principles can be different depending on culture. [6:08]
How to pivot to transform an organisation must be tailored to the position the company is in. [9:23]
Sometimes product people just need to empower their teams. However, there are often systems in place that prevent this. "If you go into an organization that isn't really aligned in a way to allow agency, where there is low confidence among the teams, a lot of dependencies between the teams and maybe they don't have the way to see if what they're doing is working... no amount of empowerment will help," John tells Melissa. [11:40]
A lot of organizations have people at the head who have had experience in the digital and processing development department, but they have not worked on a team in modern ways of working. They can intellectualize it, John says, but they can't feel it in their bones. [15:11]
Melissa talks about product people not being able to recognize product patterns and see how technology can completely change your product. They can't comprehend rethinking the way they approach product, or they don't consider platform approaches. "You can take the strategy of a different SAAS company from the product architecture and how they deliver value, and use the things that work in your company but just refine it and it's those types of things that I feel like are missing," Melissa says. [17:43]
People who have been doing product for a while may underappreciate how many signals and tacit knowledge that have been acquired over the decades. Because of this, communicating with someone who hasn't had those signals can be frustrating. It's important to step back and think about how you learned what you learned, when trying to teach other people. [21:25]
John talks about some of the core strategies of product leadership. [26:18]
Before teams decide to move on to strategy, they should do a simple linear regression and analyse the who, what, where, when and why of their product. Then start layering complexities and uncertainties. John describes a system he's created called Mandate Levels. [30:31]
Not everyone in the product world is fortunate to have job mobility, so organizations need to create an environment that gets outcomes going. [33:51]
Sometimes product people believe they're empowering their teams but they're not being sensitive and empathetic to the lives of their employees. How a product manager shapes the mission is important because it can leave enough room for people to take risks. [40:15]
Product managers must be clear and honest with themselves before they begin to implement change. They need to connect with their organizations and find the kernel of opportunity. [43:53]
Resources
John Cutler | LinkedIn | Twitter | Articles
John Cutler’s Product Org Expertise
Transcript:
Melissa:
Hello and welcome to another episode of the product thinking podcast. Today we have John Cutler with us. He was a product evangelist at amplitude, a prolific writer. You write more than anybody I've ever seen, which is fantastic to share all your knowledge with us and a good friend of mine for the past couple of years. So welcome to the show, John.
John:
Yeah. Thank you so much for having me, Melissa. This is great. And it's good that you got the podcasts going. So now at least when people tell you, you should have a podcast, you can be like, I'm doing it right there. So this is awesome.
Melissa:
So I'm anticipating needs a good product manager. Um, so let's talk about, uh, what you've been doing for the last, uh, couple of years. So you've been at amplitude as a product evangelist. Um, and you were just telling me you were doing workshops with all these teams. W why does amplitude even have a product evangelist? What do you do?
John:
Yeah, that's an interesting question. So, you know, product evangelists, different companies use that phrase. And in some, in some cases it's more like developer relations or sort of, you know, subject matter relations. So they really need a public face of the company who can connect with their personas or, you know, the people who use the product in unique ways. Uh, so the way you would think about that is that maybe in a developer relations situation, like when I was at Zendesk, suddenly these people started to show up from Amazon to teach us things. And we're like, great. This is awesome. It turned out that they wanted to sell us more stuff, but they were really helpful people to have around as we were making some transitions, transitions to stuff in the cloud. So that was an example, but an amplitude it's an interesting thing because, um, we cover have so much surface area as a company.
So you could think, well, it's analytics, so you need analytics literacy, but you kinda need product literacy as well. So you think like just having analytics chops alone is not enough. You kind of need to know the domain you're working in. So that's the product stuff. Now, if the teams aren't empowered to make any decisions, oh, well, it doesn't matter whether you have analytics and product literacy. You're not empowered to make any decisions. So you've got to think about that. And so I think that the role, um, you know, for companies like amplitude that are in an emerging space that has like layers of complexity and different personas, and it's sort of not just accepting the status quo, but it's also meeting these teams trying to quote unquote, transform or do anything. It helps to have a product evangelist there because you sort of fill this gap in this need for education advocacy, helping teams kind of see the future direction that they're going. And then honestly, just product therapy. A lot of my week is like 30 minute product therapy sessions with product leader. So, um, everyone needs another set of ears I've learned. So, um, yeah, that's, that's my Amplitude's doing it. It's, it's a great adventure for me just to be able to chat with so many teams. It's really exciting.
Melissa:
Yeah. And you, you've worked with teams now that are literally all over the world doing these different workshops. Like what, what have you seen in the last year as like some of the biggest product problems out there?
John:
Oh, well, what's funny is they think that I'm some clairvoyant genius, but when you've seen them, you know, a lot of teams, I'll crack jokes. Like, yeah, I bet that's kind of when the developer doesn't want to show up at the discovery session and you find out that they need to finish a project to get promoted. And everyone said, well, how did you know that? And then I'll crack a joke that, well, that's promotion driven development. So if you follow me on Twitter, you can sort of see like my mental journey across these. Cause like you start to see these particular patterns or you just learn how hard it is. I mean, in a lot of these large enterprises, it's not for lack of skill you're on this call and there's just so much thoughtful change agency. You know, you've got coaches there, they've got OKR coaches and they've got product thinking coaches and they've got agile coaches and there's so many people trying to help and you can just sense like the inertia in the organization.
John:
Like there's, it's still stuck. So you start to sense those patterns, you know, where, uh, you know, despite people's best efforts, it might be difficult for them to do that. But yeah, we can talk about patterns, but I think the funniest thing I I'm thinking about is, uh, the patterns become so clear and often I get credit for being able to like, how do you know that that happens in our organization and saying, well, you know, every company treats OKR is like a running of the bulls situation and quarter is 90 days and 61 business days. And I bet you spent the last 10 days freaking out about next quarters. Okay. Ours and you know, so I'll be right. Like most of the time, the same stuff like that. So yeah. You see the patterns among organizations. I think that there's, um, Joshua Arnold, who I follow on Twitter a lot and I met him a couple of times and I think he lives in New Zealand has this great quote about the reverse Anna Karenina Principle”. So Anna Karenina, just like the happy families have the same, the dysfunctional families are all different. And so his thing is the reverse Anna Karenina Principle where like the dysfunctional companies, And I don't even like the word dysfunctional, but you know, challenged in some way or another tend to have a lot of common patterns. What's really curious about the workshops is just how different the successful companies are in their approaches. People tend to think, oh, well, they follow all these principles, but they can be vastly different in terms of culture and stuff. So as, as a huge like nerd of all this stuff, doing all the workshops is just an amazing experience for me, uh, to meet all the teams.
Melissa:
Yeah. I find the same thing. Like I, when I've worked, um, with different companies and it's, it's really across industry too, I find that we, you know, we've, we both talked about this together a bunch, but everybody thinks they're their own special snowflake and all of their problems is unique to them. And I found that that is definitely not the case. And especially a lot of companies trying to transform or trying to move into more of a product led approach, but you're right. Like all the, all the successful companies are operating kind of differently. Like they have the core values, but the way they actually do product I find is, is completely different.
John:
Yeah. I mean, you know, I, in a, in a 48 hour period, I might be with one company that actually has pretty role, um, rigid role definition on product teams, uh, you know, an engineering manager, farms out stuff for developers product doesn't get involved in X there's a lot of, you know, strong, you know, directly responsible person culture. And it works at that company. And then, you know, the next call will be highly collectivist. You know, everyone is often if it's in a Northern European country too, it's like collectivists in an interesting way, collectivist, but not afraid to say what you mean. So a lot of the Northern Nordic countries are like that, but they're functioning in the same way too. Um, and so you even start to notice the difference in communication styles between teams. I mean, some like south American countries and even in APAC the other day, like 20 young, super hungry, super passionate product people they're taking in, they're like sponges of all this information.
John:
And I couldn't end the call, you know, I kept saying like, Hey, I kind of like to wrap it up right now. And everyone's so passionate about that. And actually a lot of, you know, open communication. And then you, you do walk into some teams where it's like, it's like crickets and you can tell, you know, what's going on, but yeah, back to the kind of healthy teams like taking all these particular formats, um, to do that, I think the other thing too, is the element of, you know, even at amplitude, we have some of the teams that write all the blog posts people point to and say, well, that's amazing product. And when you do workshops with those teams, I mean, it's hard, everywhere. Product is really hard. And in fact, the more outcome oriented or impact oriented you are, it gets actually really hard, you know, like you have to ask all these hard questions. And so there's definitely like a myth versus reality situation that you see. But yeah, it is fascinating to see teams that are struggling in different, everyone's struggling. It's just in slightly different ways to do it
Melissa:
Well. Like, so it's an interesting thing, you know, we could see all these patterns in, in the companies that are, um, not let's, let's say they're not there yet. Right. They're not successful when they're doing product. Um, and then we've got all these different ways of working for the successful companies. Have you observed anything that makes a pattern right. In the, in the successful companies about what they do?
John:
Yeah. I get asked that a lot, especially, you know, amplitude, like anyone I'll have someone from marketing said, Hey, you've got to make a maturity model, John or something. You know, what are the patterns to see that, you know, what some of the patterns are often have to do with where the business is at and how old the business is and what kind of, part of the cycle of their existence as a company is at. And we don't talk enough about that, but like, if you are a digital product, first company, and that's all you've ever known and you printed money off of that for a long time, there's a reason why someone like it lasts and spends 35% on R and D and 15% on sales and marketing versus the top financial institutions are investing 10% in quote, unquote it, and then e-com is down at six, you know, large retailers trying to work online around six or 8%.
Right. And so I think that one thing, one pattern you notice is the business model and where they're at is a super component, an important component of where they are. And transformation is hard. If you have a large organization optimized to make money, one way, spend money, one way, invest money one way. And that pivoting that needs to happen is really different. So I know that that that might not be what you're looking for, but these are the things I observed that, you know, how important that particular thing is. I think that the other thing too, is that there's a virtuous loop where often they have just enough people in the company who've done it. Maybe who've seen these irrational things. I had a great conversation this morning with a product leader. Like if you've been in a company and made $2 million in 48 hours or seen an eight month effort go completely wrong and know why it went wrong, not just that it went wrong or have a sense of why it went wrong.
Or if you've worked on a team that was given a three quarter mission and just pretty much left alone and just really knocked it out of the park. So what happens you notice in these organizations that are a little further along on this is they've created a virtuous loop where someone there has done it. And then that creates a little bit of boundary for people to lean into doing that. And then the outcomes create a virtuous cycle where the impact is there. The situational awareness is there that impacts the product strategy, which then gives the teams agency and moves around. One thing I've noticed a lot is that people take, you know, you are Marty Cagan or other people or me on occasion. They take our words really seriously. And so one thing I've noticed is it's one thing to say, you just need to empower the team, but you go into an organization that's saddled under tons of technical debt, where the org structure isn't really aligned in a way to allow agency where there's low confidence among the teams, a lot of dependencies between the teams and maybe they don't have analytics or way to be able to see if what they're doing is working.
And then the layer on the fact that the incentives are structured around the old business model, no amount of empowerment will help. In fact, you know, I was on with a large Northern European company, everyone in the room wanted so desperately to empower, right? But the reality was that they needed to work through the structural system level, things that were getting in the way of doing it. So to back to your question, one of the patterns is through some virtuous loop, they have situational awareness. The incentives are aligned. The funding of efforts is aligned with how the business makes money. There's a product strategy. The org structure is aligned around the strategy. There's not as many dependencies which allows agency optionality, focus, flow, better decisions. You can see that I've gone so deep into this, that I have this like causal relationship diagram in my head, but those are the patterns that I pick up. Um, I can actually share a link of that particular diagram I just talked about, and you could share it in the notes of the podcast, but yeah, these are the patterns that I pick up on and it is not a linear journey by any means. And it's not something you can just will into existence. It's like, this is a tough, it's really hard.
Melissa:
Yeah. I, everything that you just mentioned too, I I've seen, um, especially the blockers, like you just, I think things that made me feel so helpless in helping digital transformations, like big companies, I wanted to do this. It's just seeing so many people really excited to use the stuff they were learning and then just getting completely kicked by bureaucracy to not be able to put them in place. And it was just slightly heartbreaking. But one thing that you did mention that I want to call out, because I think, I think this is an interesting thread to go down to is, um, it's like when the leadership has actually done product right. Or has done those of things in these organizations to, uh, cause like you mentioned, if you, if you haven't really seen it before, where you don't have that successful part in there, it's hard to grow it. It's hard to see what's you're actually keeping,
John:
Oh, it is really hard. And this is, this is interesting that, so I have noticed people who are, have only worked in these kind of, yeah. So someone coming to me and say, John, I've worked at three jobs. None of them are like, I read that it should be it, there has to be a better way, but because they felt the pain firsthand, they can almost like impute in their head, the potential of things being better. Now, I think that happens a lot with like makers and systems thinkers and people who've been working with the stuff with their hands. And in that sense, it's like, even though they haven't done it, they can imagine that there would be a better way to do it. So the analogy that I use is, you know, I'm not like a great traveler for example, but if I'm sitting in an airport and it feels like I can't get anywhere in that city, I'm sure that like, okay, this is a major metropolitan area.
I am sure there is a super fast way to get around here. I've never been to this town before, but I have some knowledge of what it could look like. I'm going to invest some time in figuring out how to get around the city to do it now. But I think your point though, is that a lot of these organizations, you have people at the director, VP and above level in the business, the GMs of the business, and maybe they had an experience in some sort of building a software like 15, 20 years ago, but they have not worked on a team in sort of modern ways of working. And even if they, for sure they can intellectualize it. If you walk into a meeting and say, do you think that you could should experiment? Yes. By all means, do you think you should empower people?
Yes. I tried to empower people every day. Do you think that you should fund efforts based on like the, the project, the process, the progress of that? Yes. That makes absolute sense, but they haven't felt it in their bones. And so I think that that's like, what we'll see in the next 15, 20 years is as more people in these larger enterprise to actually go from the it org and then become the GMs of the other business units where, you know, the ability to know about creating digital experiences becomes, um, part and parcel at the top with whatever domain expertise you have to get the job and the business, like if you haven't done a digital product experience, you can't get that job as the GM of footwear X or something. I think that's what we're going to see in these coming, you know, decades of doing it.
But yeah, we underestimate how important it is to feel it in your bones. I would say to the change agents who are like, my company sucks, we just aren't empowered and we don't do design sprints, and we don't do all the things I've read about. They're also a little naive. Like it, it, you know, so you can sometimes get caught. I always say like lead with the why not the way. And one thing I've noticed is that those like internal change agents who want to up-level their career and up-level their org, they often just cite all the techniques and tools you should use. Instead of saying, look in three to five years, we're going to have a really tough time hitting any of our projections and margins, unless we can figure out how to deal with this new persona and product and design thinking, have a really good set of tools to grapple with a new persona and translate that better experiences. Oh. And one technique to do that is so they just start with the why don't we do X, which is a really funny, you know, so anyway, there's enough for everyone to learn there, I think.
Melissa:
Yeah. And now I completely agree. It's uh, you, you see a lot of people who haven't done product before completely gravitate towards the frameworks and the tools. And I think what they're, they're, they're missing the strategy piece to me. And I wonder if you you've seen this too. It was so hard for me to get, try to comprehend this. And I think I'm still wrestling with how to explain this in my head. I don't, I don't honestly know how to do it, but, um, one of the issues I have with people who don't get product or get product strategy is their inability to recognize product patterns and see how technology can, like the way that you change technology and the architecture you build things on can completely change your product. Um, I'll give you an example. I was working with a bank and there was this, uh, team that basically provided, uh, internal tools to the rest of the company.
And it was to do like basically the accounting that went across the rest of it. It was internal. Now I looked at that company like that, that business line that was managed by like, you know, a whole group of people. And it was huge and had thousands of people. And I said, you are the finance platform that the rest of the bank runs on. Like, that's what you should build. Like you need to build a platform that can manage the data from many different business lines coming in here. You have applications on top of it, which are the tools that people build. And like blink faces across the entire leadership team. That was the product team. And they were like, what do you mean a platform? I was like, that's what you are like to me. Like I looked at it and I was like, that's what you are.
Um, let's talk about product strategy. Like how do you get into that? And it's just like, they couldn't comprehend that it wasn't just building a huge subset of a bunch of different tools. It was like rethinking the way they were as a product, like a software product to the rest of the company and that you like that, that platform approach, uh, just never even crossed their minds. And it's that type of thing like that, recognizing of the products, the different patterns, the ways things are built, how you use API APIs, how like how all these things kind of come together to deliver value and how like you can take, um, I tell this to companies all the time. I'm like I work with healthcare companies that are like, oh, well, if somebody hasn't been in healthcare, I don't want to talk to them. And healthcare is very complicated, but I'm like, you can take the strategy of a different SAS company from the product architecture and how they deliver value and use the things that work in your company too. But you just refine it. And it's those types of things that I feel like are missing.
John:
Oh, it's such an interesting thing because I think it also relates to, I said the other day is like, I know what to Google in a sense that like, I have a pretty good sense now of what I don't know, you know? And then I think I also have a sense of like how to look for patterns for people who figured this out and be able to cut through the noise, you know, like that doesn't seem coherent. Oh, that starts to seem more coherent. And that, and so I think what we're talking about a lot is tacit knowledge. And I think that, I mean, you're teaching a class right now and I think the challenges, I do think some of this is teachable, but the question is how to get enough of the signals for people to start getting the patterns that they're doing. I did.
I did a really interesting exercise with someone named Cedric chin and he kind of did an analysis of my tacit knowledge and wrote a whole blog post. And you through a technique called it's called like task analysis or cognitive task analysis. Now, what was really funny is what I thought I was doing. I was not doing like my pattern matching across companies was pretty weird. And he picked up on that right away to do it. And he explained it like this, you know, for example, the military teaches people. There are people in the military who know how to find IEDs long roads. And so doing tacit task analysis, they figured out what were the patterns that person did. And, you know, they ha they have to be able to think like an insurgent, they need to be able to, they have so much feedback loops of seen this happen.
They've also been someone who's found IEDS. So they pick up on all the signals. And so anyway, roundabout stories, I think that people have been doing product for awhile under, they might actually under-appreciate how many signals we've accumulated over the decades to do it. And then when we're chatting with people who haven't had those signals, it can seem really frustrating. And then we can seem like, well, I just knew that, I mean, everyone knows what a platform is to do it. So I, I have to really temper that in, when I'm talking to teams about respecting, how many of those signals I've seen, like there's not many people in the world I realized who chatted with, uh, you know, let's say if it's two, a day and 90 busy, you know, I don't know, 150 people in the last couple of weeks in different companies. And so I underappreciate that. So I think that, I don't know if that helps with, withwhat you're thinking, but I, I have to, like, it really is important to step back and think about how we know what we know when we're trying teach people this stuff. So this is more about the teaching angle. I don't know if this is yeah. What do you teach your students at Harvard? So that's the thing. Yeah.
Melissa:
I think like, um, I think there's two sides. Like I, I feel like when I first started consulting, I was super zoned in, on the process. Right. Like how to do the agile process, how to be iterative, how to, how to, like, what is the process for strategy deployment, all of that stuff. Right. I was like process, process, process oriented person. Um, and as I gotten into more literally like designing the strategies of companies and helping with that, which I love, um, that's where I started to look at like, oh yeah, I've seen a million of these companies out here. Like you have to, I recognize patterns of like what works and what doesn't and put that in there. But, um, I'm starting to realize that that's a big gap that we don't really talk about in product.
John:
Oh, that's um, that's. Yeah. And I think that, you know, you mentioned if I'm thinking about like an MBA program, for example, so how do they teach MBA programs? It's just with a lot of case studies and they work through them. This is the fascinating thing about product. Okay. So maybe you could say like, what was the differentiator? Or you could apply those things, but, you know, you were talking about like how to think through meeting with 16 cross-functional stakeholders in the big mess of some large organizational thing. That's actually a pretty hard thing to simulate as you do that. And so we've learned that actually at amplitude, that there is a company called go practice with Sean Ellis and his, his partner. And I'm blanking on his name at the moment, but he's a data scientist from Google or Facebook, and together, they have a cycle go practice, which does take a cohort based approach to teaching amplitude.
They are doing a really, really good job because Sean is able to like, make it really feel like you're working at a growth, like on a growth team. And so they set up scenarios and then because of the founder's background in creating realistic data, it really feels real, you know? So it feels like that. And so it is, I mean, yeah, we could talk forever about like cohort based courses and all those things. But I think that the higher level thing talking to teams is just being appreciative of how much practice it does take. And then how really having seen things play out becomes a large part of our belief system. I noticed this a lot about, you know, diehard Agileists or whatever, where, you know, they're like, oh, you just don't need this. Or you just don't need that. Or you don't need that totally oblivious to all the experiences they've had in their life that suggests level of confidence or it's possible. It's actually almost sounds like they're being jerks, you know, when they're telling people to work that way or not work that way. So I don't know. We have to appreciate our like collective signal gathering is what I learned basically. Yeah.
Melissa:
Yeah. And I wonder though, like, if there's a way to distill that into teaching people about those patterns and signals, I don't know this is what I've been wrestling with in my head, because I'm like, we just started, um, so my course at HBS used to be purely practical where everybody worked on their startups and this year I started introducing cases. Um, and I like it. Like, it's, I've only been a couple of weeks into teaching them, but it's nice because you know, some of them are successes and some of them are failures and you read about these stories and they're very realistic. And, um, you're right. Like, it's like, I can't, I can tell somebody about, you know, managing a million different, difficult stakeholders, but it's different if it's like, here's the scenario? What would you do? And they actually have to think through it. Um, and I'm really enjoying the case teaching for that because I, I go into the class and I never know what to expect, like the answers I get, because everybody has a different background too. Like every answer I'm like, oh, well, okay. It just, threw out my plan, like right out the window, let's go in this direction instead. Um, which is very new for me, but super fun, super fun. Um, but I think there's something there I love like, like, what is these core strategies? Like, where do we get to? And I, I, and bringing this back to like, kind of what we were talking about earlier, I feel like that's the piece that's missing in the middle of leadership when we talk about transformations. And that's why I'm like, please hire somebody who's seen this before. Who's done this before, because they're going to be like, oh, boom, boom, boom, boom. Right? Like we're talking about, they do try to hire those people. And then those people leave sometimes because they're just, but, but I think it's also about being realistic.
John:
And this is another thing that I see with particular teams. So, you know, guns blazing, okay. We go through the agile transformation, we got through the dev ops transformation. Okay. Now we're going to do projects to products. And, and this is funny because what I'm seeing right now will make no sense to the Silicon valley crowd that I talked to a lot. Like, so I've just heard about this whole alternate universe, where literally you have to think about the shift from projects to products. So yes, this universe exists that I'm talking about, but you go in this organization, they've got the OKR coaches, they're doing all these things. And then, you know, I mentioned this earlier today to someone I worked at a really healthy company here in Santa Barbara. And if we had a new UCSB grad from the comp side department, join our company, I'd say it probably took about two years to get that person as like an engineer, as a participant on the team, to the point where their confidence was at that point.
Now we were shipping super frequently. We were going and camping out with customers at their house and that their business we were getting, you know, it was very healthy environment. And so it really forces you to think about, I think that some of these companies are jumping the gun, you know, they're jumping into OKR is because someone says what we need to be outcome driven or whatever, the teams I've never even done a small two week effort where they instrumented a form and found out how many people weren't able to successfully complete the form. The team has never seen that. And then they're jumping into these very like elaborate schemes for strategy deployment and elaborate ways of doing it. And so I think at least for that group, um, be much more realistic about what do you, the way I say it to people is what would you need to observe?
Or what have I observed that built that confidence, that something like that was possible. So I don't know if that resonates with you, but I think even from the course of, you know, so even in the case of Harvard business school, I mean, forcing someone to ship something in a week that no one uses is it is even just that like, oh, I'm just going to release a demo to my friends. It's gonna be amazing. I'll have a couple of hundred users, even something simple like that is like, no, without hassling my friends, my friends didn't really like it. I mean, I do that a lot, even with little mini projects, like I did a site called team prompts.com and I thought, oh my God, my prompts are so great. People are going to keep going to team prompts. No one goes to team prompts. Like no one likes team prompts, it's boring. It didn't like fill a need to do it. So I really feel that product people need to like force those realizations, um, as they do it. And sometimes it's just the simplest thing. Like they're talking about doing multi-variate experiments and AB tests and trying to do missions and doing whatever. And I ask, have you ever shipped something into production and just watched how many people use it? And they're like, oh, no, no, well, no, I haven't done that. So like maybe start with that. Right. Yeah.
Melissa:
Um, it's, it, it is amazing. Like I'm, I'm, you know, watching a bunch of people who've never done product before. And, uh, there there's a lot of startups at HBS, which is really cool. So, uh, and some of them make it really big, which is fun to watch. Uh, but they're all kind of incubating it and I'm like, just ship it. You know? Like you've been working on this thing for a long time, put it in front of somebody that I don't know if it's ready yet. I'm like, just do it, put it in front of somebody, just one person, two people you're going to get feedback. Um, and I, I think, you know, those first steps like you're talking about are super important with product teams too. Like you're, you're basically talking about, they're trying to run before they can walk. What do you, if you had to like codify, what do teams need to do before they're ready to move on to strategy before they're ready to move on to like the higher level stuff? What would it be?
John:
Yeah, I think, um, yeah, I can give an example and then we can try to extrapolate from that what that is. But I think that, you know, first of all, a lot of product examples and product curriculums use like Greenfield products. That's not what most people will enter their job for. You'll start a job. Someone will say, you're the PM of this. And it starts something as simple as like, what's what is a hypothesis or a small change? Who's the human being. You think it will help? Can you get in touch with that human being, ideally on the phone or on zoom, you have an experiment that you think you need to run. W w what's the baseline behavior, what do you think might happen? Forget AB testing or whatever. You can just do a simple linear regression. Like you don't need to worry about it.
And then just getting that muscle of what's the baseline behavior, who in the world am I trying to keep help? What promise am I making to them as to, as they're my customer, what's going on with my product right now? And what's one small change that I can think about. And then most importantly, what can I recap that, you know, four weeks ago we were kind of in this problem situation, I had a hypothesis that this was going to happen. And so maybe not even getting into the deepest parts of product strategy yet, but just building the muscle to improve something very incrementally and just run that, even if it's a very small change to do that. And then I think from there, you start layering on complexities and uncertainties, you know, you know, Greenfield, I do a thing in my workshops where I say, who on the call wants to take ownership for earning the company $10 million a year. And usually people are like, what did you say? And then there are a couple people like a VP or director of something. That's like, I'd actually be really excited by that. And I kind of go down the list. It's like, well, who might want to take on the challenge of like deeply understanding of persona and trying to figure out new and interesting ways to make that person's life easier job is your more hands go up, you know? Okay, what's the sweet spot, you know, does anyone want to be given a spec where you mentioned three, three pixel button radius? No one's hand goes up. So I, I have this system called mandate levels that I've written about, but the problem I was trying to solve with mandate levels is people talk in a very, like hand-wavy way about the sort of boundaries for the problem.
You know, give us problems, we'll solve them, or, you know, don't tell us what to do or empower the teams. So what I did with the mandate levels, things is create, I think it's like a through eye level. So a is built exactly this to a predetermined spec. B is do something that does this C is allow a customer to achieve this goal D kind of moves it up in terms of, and I is generate the company with a, with a multi-year business goal, like dollars or whatever. So that's been one helpful technique. And, you know, we could share links to some posts that I've written about that, but I found that to be helpful for thinking about really what, how to get that team kind of working on one level and then expanding out you need a safe environment to do that though. I think that, like I said, even in a very healthy environment, you will still need to learn. So if you, if you make the surrounding environment great, you put all the motivation in place, all the incentives in place, then it's a more pure learning journey that doesn't have all that stuff, weighing the team down, even then it takes reps to get through it. So, yeah, I always tell people, get your reps because the people in the big enterprises, when their careers get a little bogged down, because they say, oh, I worked at this big enterprise. I can't put anything on my resume cause we didn't really ship anything in two years. Meanwhile, there's a 24 year old. Who's never worked on a product team, but has none of that baggage. And you're a hiring manager at these companies that you want to work at. And I've spoken to these people and it's a little unnerving, but kind of makes sense. But doesn't at the same time, they're like, okay, there's this person who has no baggage about working in a big enterprise.
And I can't really make out what they were doing in the two years. They spent at Bitco they're new at this, or there's that, there's the big co product manager. And I'm just trying to, I want to help them out, but I can't figure they, they haven't really listed an outcome to what they're doing. So what I tell people in big enterprises is look, not everyone can just flip around jobs and everyone starts where they start. And certainly I've been really privileged as like a white guy to like work in certain places. You've got to create the environment, even in big code, a carve out some boundary that you can start getting the muscle going and get an outcome going and get something going. So I know we got into like career advice, but I'm thinking that part of your career choices need to be about getting the reps, because if you don't then that 24 year old, who spent half of the summer working in a consulting firm, who's never done product, but it's kind of fresh. And without the baggage actually does look better on paper. It's really unnerving, but it's true. So I think that this is related to our careers about how we have to build reps, no matter what environment we're in. Even if you need to ship a product outside of work, you work in some place that only ships every six months release a product outside of work to get reps, get your reps over and over.
Melissa:
Yeah, no, I think that's great advice. Like my students are getting ready this year to graduate and go find jobs. And a lot of them are like, how do I know what's the right company to go to? And they all want to work in a more fast paced place. And I said, you know, there, there are big enterprises where there are teams that do amazing things and they work really well. And then there are teams that just don't. And I said, you should ask them to me. Like the, the thing that I would ask them is how often do you actually ship code to customers? Like, cause you may find a pocket of a bank that does it every single day. You may find a different pocket that does it once a year,
John:
Susie. And or if, you know, you asked, you know, you're, you're interviewing your interviewer and you're like, Hey, can you just walk me through the, kind of the product that's for the last 12 months now, if they're like, well, we're mostly focusing on the new onboarding experience for the thing. Like, ah, I don't know what that sounds like 12 months that's for 12 months. That sounds like a lot. But, but if they can't remember, that's a good sign too, because that would mean that there's so many of them that they just can't like remember to do those things, but it isn't, it is an interesting, um, yeah, I think what we're zeroing in on though is the, the thing of like in these environments where there's a lot of tacit knowledge, there are some things that we can teach and bootstrap people, but how do you create the abilities to practice?
I mean, I think I was reading a book this morning, which is sort of, you could think of our gaps either. You know, this is probably familiar to people in education, but they're either knowledge skills, which are knowledge, times practice equal skills, or the gaps could be one related to motivation habits or the environment. So the environment or like incentives, tools, et cetera, habits are things you need to learn on. Learn. Motivation could be like, are you bought into the journey of what you're doing? And so the author of this was basically like the knowledge and skills are only ever 20% of the puzzle, you know, the habits stuff, the ability or the ability to practice, uh, and the ability to get your reps and like do that is one of the large parts about gain the skills we need as product folks. So, um, I think that that's like a super important part of learning and that's what we do with our workshops. Like a lot of the workshops, I only have them for like two or three hours or four hours. And so at some big company, but even through that, I don't worry about like, did we come up with our north star by the end of the workshop, I'm there to get them reps. So anytime I can get them to go to a breakout and like talk about the items or any time I can get them having their assumptions tested with other people, that's even in the four hours, I just look for reps over and over and over again, um, to learn these things.
Melissa:
Yeah. I think that, like one of the things you just mentioned too about, you know, getting the reps in an organization, we have to create like a safe space to do that. I find this trend with people who've been in larger organizations for awhile where the managers tell them, this is a safe space. I want you to experiment. I want you to do things. Um, but they're afraid to, which makes me go, okay, so it's, they may be saying it's a safe space, but it's not a safe space. Like what have you?
John:
Oh, that's interesting. I think it goes back to the, has the person done it? Right? So, so if you have like a, you know, digital product, first product manager who, you know, got to a VP at those companies and then was really curious about, of like mission-based company that was not a digitally first company. And a lot of people, you know, we make stereotypes for people. A lot of people get success doing digital product, first companies, and then want to change the world or want to change healthcare or want to, you know, love a certain shoe company or love Disney or love something like that. Right. So they pivot into those worlds. And I think that, you know, sometimes they have done it before and they just are not looking very carefully into what the incentive structures are in the organization. They're just like, well, you know, what's the worst thing could happen.
Well, frankly, maybe they've have a lot of job mobility. So the worst thing that happens to them is they just find another job at a big company. But maybe in that environment, it really is, you know, the person's like, well, I've observed what happens when we experiment and it's not quite what you're making it out to be. Um, or, you know, I use the example the other day that, you know, the developer who was like, you talked about experimentation and we did that for a couple of weeks. And then the VP just came in at the end and told us what to do. So if you've been in an environment where that tends to happen, even if that person has the background in these companies and says, I want to empower you to do it. It's only have a couple set of things either. They are truly scared in terms of those mandate levels.
Like they've never taken on a D E or F level effort that was more open-ended or they've seen what happens to prior people who do that. Or for example, in the case of engineering orgs, it's always, you know, classic question I get is John and wanna engage the engineers more than my team. They don't seem interested and I'll say, well, how are they incentivized? Oh, our engineering org incentivize people to finish projects. Oh. So you're asking them to do the work that you want outside of normal, their normal business as usual. Well, yes, shouldn't they want to, because they should want to be like good product. People will know. We only have 40 hours in the week. And have you ever been an engineer? And like, literally if you make a mistake, you can bring the whole system down and people are barking at you. Where are your JIRA tickets? Product manager? Oh, I just write them. No, but you're writing these T like, can you imagine what your day would be like with a big line of JIRA tickets and everyone's scrutinizing your work and having to do code reviews every couple hours and breaking systems and then having to reroll machines and that taking 24 hours, that's a hard job. So I think one thing that happens too, is sometimes product people are like, I'm empowering the team, but they're not really being sensitive or empathetic to what the incentives and what the day to day are like for that. So, um, I think that that's like, and that's where as a PM, how you, whatever use the word shape or decompose or scope the mission is so important because if you just slight differences in how you frame a mission could leave enough air and space for people to take risks. Versus if you kind of go in slightly different direction, it could be more prescriptive. Um, so I don't know. Those are some thoughts, uh, related to what you asked.
Melissa:
Yeah. Um, so which will the previous episode to this product thinking thawed gas will be with Kent Beck. And can I just talk to like the other day while we record this, but everybody will have listened to this two weeks before they listened to you. And that is what he was saying about, uh, the adoption of XP and agile to, from places he's been in coaching is just, the incentives are not aligned for people to operate that,
John:
Oh, it's big in the bay. I mean, I have, you know, people from Google will say, yeah, we do promotion driven development and that's what they do, you know? And it's like, you know, because they're trying to, what does it optimize for? It's actually optimized for keeping those engineers interested, not necessarily for achieving some outcome in the world and maybe that works for Google. And maybe by having those people interested, it lets them do what they need to do as a particular company. But yeah, people vastly underestimate the incentive structures among engineers. You know, I've had an engineering manager say to me, we'll never pair here. Why I won't be able to tell who contributed, what if they, why do you need to tell who contributed what, while I'm on the hook to do performance reviews. And I need to be able to decouple that person's work from the other person's work to do it. So yeah, they'll have heard the other episode. And so then we'll have some common themes here, but it's certainly, um, yeah, big, big topic. I think
Melissa:
It is interesting to, right, like a, you know, Kent and John don't talk all the time and it sees patterns that you see though, when you work with teams and that was what Kevin was doing for a long time too, is, you know what we're talking about here, we're talking about a lot of the product patterns that make people successful, but there's this underlying theme of incentives. I think that we've all observed as well, that are the big blockers for people being able to adopt what we teach. Like everybody pays lip service to wanting to, um, have a functional product organization and, you know, produce customer outcomes. But like, what are you doing to really enable that? Besides just putting somebody in a training program?
John:
Oh, you know, what comes to mind there too is one thing about, I used to be one of those people who, um, you know, when someone said, well, at the end of the day, people just want to make money, you know? And I'd be like, well, that's not true. There's other people that alternative agendas, there's all sorts of things. So I kind of, I was never really into the like incentives, explain everything argument because, uh, I was, I was sort of conditioned to see what that person was saying is meaning money as incentive is what drives people to do the things. But I have come not around that way of thinking necessarily, but I, you know, I will say, uh, you know, what are you, what process are you doing? I'll say XYZ and XYZ. Well, show me your calendar. Okay. That's the framework you're using.
Show me your perf. Like, what is the career ladders look like? That's the framework that you're using. So people are like, I'm using agile or I'm using scrum or I'm using whatever method or I'm using shape up or anything that only tells you like 20% of the situation. That's why people can do 10 different ways of working and all do well. That's culturally dependent because those things really, really do matter. And so what, you know, often I say to a PM, you know, oh, you know, how do you turn something into habit? And so I'm working on a book, um, with Holly Chaisson, who's, who's sort of a design thinking person and a coach. And she said something really interesting. We were thinking about how to think about change. And our basic thing was first, you have to get clear with yourself. Then you need to connect with people in a nonjudgmental way without an agenda.
Then you need to connect with your organization to understand what the hell is going on in general. And then you need to find the kernel of the opportunity. So instead of saying, I want to do design thinking, you need to say this, you know, I hear the CEO talking about this big opportunity and that's a perfect opportunity to apply these methods. And then the first thing we got back in the changes get situational awareness. So the easiest thing you can do is just sense what's going on. The next one was hack all the existing rituals. You know, so if you have a meeting that happens every two weeks, you know, often when people to do these new efforts and product can, we're going to add more meetings, we're going to add more stuff. We're going to add new documents. We're going to add new rituals. And Holly made the great point that like, no, that's terrible design of a new way of working. Like, can you slightly hack or repurpose the existing meetings? You know, if you're a PM and you do a meeting, one way, can you use the last 90 seconds that meeting to say, I'm going to do a quick review of that couple stuff we had in production right now and talk you through these things or, you know, so I think that, that was an interesting idea where it's basically, before you start trying to create new habits as a team, can you sort of Trojan horse your existing rituals because that's, people's calendar that's people's time and everything. So I think that that's like, it was a good point, um, to that she was getting at it's hard, uh, when people do that, that's why you see VPs of product drift away for a couple of weeks at the end of the quarter to work on the new framework. It's not because they want to do it in private it's because they're not willing to tell everyone like, okay, stop what you're doing and help me. So it's really hard count calendar driven development. And then a career ladder driven development is what I've been thinking about today.
Melissa:
I've got so many more terms now after this podcast to throw into my lexicon, which I love amazing. Well, it's been so good to have you on the show, John, thanks for sharing your patterns with us. It's been really fun to see, um, to see what you've been observing and see how it lines up with what I've seen too. And if anybody wants to learn more, where can they find you?
John:
At the moment still it's Twitter. Like Twitter has become my second brain as a really tired parent. So I searched to find my own stuff on Twitter. Cause I can't remember. So that's a good place to do it. And I do a weekly newsletter. I'm on week 90, but we're getting there yeah. Week 80 or 90 in a row, some 90 episodes of that. And that's called the beautiful mass and you can just sit on sub stack and I write that. So that's a decent place to get in touch. And then yeah, if you work at a huge company with an amazing logo name and you want to have me come and speak at your company, no one stops me at amplitude. I can tell you that person to do it. So I'm happy to do workshops with people and, um, or even just do these product therapy sessions, if you just want to have talked to someone about it and yeah, I'll, I'll, I'll bring out my flywheel diagram and just bore you for 30 minutes about how you can get a virtuous loop going in your company to do it. So yeah, that's where they, that's where they can find me and yeah, good luck with this pursuit and the teaching as well. And the, uh, I do follow you on, on, I see pictures of your housing project and I'm just like, I'm like she's teaching and has a housing project and that's pretty amazing. So yeah, the center island looks beautiful. I'm going to thumbs up on that part of that routine.
Melissa:
It's um, I said, I keep joking that my next book will be on I'm managing renovations, like a manager.
John:
Oh, that's the most humbling thing for a product manager to see how much they know is to see how little they know when you put them in another type of thing, you know, it's like, oh yeah, can we just iterate on this plumber? And the plumber is like, no, we're not going to be doing that right now. Like you're going to be paying me a couple thousand dollars and then I'll discover the problem and then charging you
Melissa:
Anytime. I like tried to question what the contractor was doing. It was just like, when I used to question developers, it looked at me and be like, yeah, you wouldn't be able to do this yourself.
John:
So if that thing of like trust though, I, you know, it's funny, you know, I use the example. I have a mechanic here in Santa Barbara that I just dropped my car off. He has a blank check to do whatever he needs to do to the car. Cause he he's really so good about thinking about how my economics would work. So if he sends that I would need to buy a new car, it's like a 2003 Honda element. He just has a good sense. And sometimes he's been like, this is borderline. We can see where it goes and then there's other people. Like I would never do that. So it is a kind of interesting question of trust. We talk about trust and autonomy in the organization that like, it's really hard unless you've seen these things play out for that digital leader. If you've never seen a team, knock it out of the park after kind of wandering around for a couple months and then really hitting a home run. It's very hard to tell them. Yeah, just here's a blank check for my, my car. So yeah, we can talk about that another time. Yeah. Budgets and home improvements and then trust among vendors is an interesting discussion. So yeah. Cool. Yeah, this is fine.
Melissa:
Thanks so much. And for those of you listening, uh, tune in next week for the next episode of the product, thinking podcasts, we're on every Wednesday and if you've enjoyed this, please leave us a review on whatever your favorite podcasting platform is. We'll see you next time.