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.
Show Notes
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.
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 the culture.
How to pivot to transform an organization must be tailored to the position the company is in.
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.
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.
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.
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.
John talks about some of the core strategies of product leadership.
Before teams decide to move on to strategy, they should do a simple linear regression and analyze 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.
Not everyone in the product world is fortunate to have job mobility, so organizations need to create an environment that gets outcomes going.
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.
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.
Resources John Cutler | LinkedIn | Twitter | Articles
Amplitude John Cutler’s Product Org Expertise
Episode 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: 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?
Melissa: Yeah. I love that. And I think that's a great place to end it. So thank you so much, John, for joining us on the product thinking podcast. It was a pleasure to have you.
John: Yeah. Thank you so much, Melissa. It was a pleasure.
Melissa: And thank you all for listening to the product thinking podcast. We'll see you next time.
John: Please leave us a review on whatever your favorite podcasting platform is. We'll see you next time.
