The Evolution of Growth Hacking and Product Management in SaaS with Hiten Shah

Hello and welcome to another episode of the Product Thinking Podcast. Today we're going on a wonderful journey back to the origination of the term growth hacker from someone who helped coin the term. We're joined by Heaton Shah who is the co founder and CEO of NERA. Since 2002, Heaton has co founded four SaaS businesses and two were very early in the product analytics space and I actually used them in in my early product management jobs. They were crazy egg and kiss metrics. For those of you who were in product management back then, he and us been at the forefront of many movements in software development and startups and has seen so much happen at the intersection of product marketing and SaaS. I'm excited to dive in to all of those topics with him today. But first it's time for our Dear Melissa segment. So our question for the week. Dear Melissa, we're working hard to convey to the team why software timelines and due dates are impossible to get right and we're more interested in producing quality work than delivery on time. Do you have any advice on how to explain the why behind the we don't have a timeline concept to customers. Are there any examples out there of SaaS companies who do this well?

All right, so one thing that I'm going to say that might be a little controversial here is that if you tell customers, customers that we just have no timelines and we're not going to be able to tell you they're not going to like that. And especially if you're working with B2B customers, individuals might have a higher tolerance for these things, but businesses certainly don't. Now there is a good middle ground where you do not have to promise hard dates, but you can at least tell people things are coming up. And you don't want to over commit to specific dates, but you do want to give them a general idea of when things are being prioritized on the roadmap. A lot of people do now next Slater roadmaps and that works pretty well in SaaS businesses. But there's an expectation that if we're working on it now, it's probably going to be out within the next quarter or two. If we're working on it next, it's probably going to take, I don't know, you could say like by the end of the year and then later we don't have a timeline at all for you. I can't promise you that is coming up with customers you want to really stick to the now and next right things that you know that you're working on that will be released and things that you know will be next up because you prioritize them and you want to communicate to them a general ballpark of when those things will be done. It is totally fine to say something like, hey, we expect to have those things in Q2 or Q2 and Q3, and this is really the level of communication you should be having with your customers. You do not want to just completely ignore them, dismiss them, or be like, I can't tell you one. These things are going to be released because we're working on, you know, quality stuff that comes off really arrogant to customers, especially ones that are paying you. Right. That doesn't sound good. That doesn't actually help make them feel inspired or excited about what you're doing. So instead you want to take a different approach. I would approach this by saying, hey, I know that you're really interested in this feature. It's actually next up to be developed after we finish this. Now, I don't have a certain date that it will be released, but we are generally aiming to have it done hopefully before the end of the year. Although I can't promise that timeline. We do have all these other things that are in development right now, and we expect those to be out by June or whatever timeline you're working on. Right. You want to approach it something like that. You don't want to commit to hard dates, but you also don't want to just be like, now, I can't tell you, it's magic. Right. That does not go over well. So I do agree with you that you don't want to make sure that everything is on time and within scope and fall into a project mindset. But there is a middle ground. And the middle ground is not hand wavy. The middle ground is diplomatic about how we're approaching these things. It's about telling them that we're not making any promises. And I refuse to put this in contracts, but I can give you some insights into the problems that we're solving. I also wouldn't get into it of getting super detailed about what the solutions entail when they're further out. If you're actually building it right now, it's totally fine to show them some early prototypes, some snapshots of what you're actually doing. If it's next on the list, maybe you talk about it a little higher level. You talk about the problems that you're going to solve, what they should be able to do with it, what they can accomplish. Right. You don't have to very be. You don't have to be very specific with the solutions that you're building. So I would just make sure that you are working within these confines. Right. And understanding their approach. Right. And their point of view of hey, I'm paying you a lot of money and for you to not tell me when things are going to be fixed or when these things that I need are going to be done, or just give me like an idea of if it's now or later or next week. Like you're not going to do very well holding onto those customers and fostering trust with them. So put yourself in their shoes for a little bit. Think about what it means. Like think about a product that you've used and you're like, man, I really wish I had this in here. Oh my God, it would make my life so much easier. Do I go switch to somebody else because I need this or do I wait and hold it out like they're going through the same thing so you need to handhold them. And I see that from you writing this in here that you're a co founder of a startup. So this is really important and this is very critical in early days of startups is to sit with them, understand their problems and really foster this customer development. And we're going to talk a little bit about customer development with Heat in a minute. But this is really, really important. In early stages of companies, you really want to make sure that you are understanding your customers needs, you're communicative with them, you're not over promising things, but you are respecting where they're coming from. Right. And you have a lot of empathy for them as well. So I hope that helps and I hope that approach help solve your problem as well. Now let's dive into our podcast with Hiten. Hi Hiten, welcome to the show.

Thanks for having me. Really excited to talk to you today.

I am so excited to finally get to talk to you in person too. I feel like we have been talking on Twitter for probably the last like 13 years. I remember following you on Twitter probably back in 2011. We were using Crazy Egg and KissMetrics, which you founded in the super early days of product analytics. And they were really game changing for me because it helped me measure for the first time what we were doing with our products out there in the world. So thank you so much for building those. I really appreciate that.

Thanks for using them in the right way.

You've seen a lot of different topics and a lot of different evolution out there in the product management world. But also in the SaaS world in the early days, one of the things I think is really interesting is you. You actually coined the term growth hacking with Sean Ellis and with Patrick. Am I going to pronounce his last name right?

Blaskovitz. Okay. Patrick Blazkowitz.

I think that's right.

I'm like, I see it written. I have no idea how to pronounce it. Perfect. So back in 2010, can you tell us about that story? Like, how did this, how did growth hacking come about?

Yeah, yeah. Sean had been VP of marketing multiple times at SaaS companies. Um, and he was noodling very seriously in his head about kind of what he does next, how he wants to think about.

Marketing going forward. And he had this thesis that startup marketing is different than scaled marketing, let's just say. And he wanted to sort of.

Kind of put a stake in the ground around it. And so when he, myself and Patrick met down in Southern California, we started talking more deeply about it and kind of, I think, built a core thesis around what to call it and why we would call it that. And so the idea was that you need a growth hacker, not a marketer, early on. And what is the difference? So typically a marketer will come in with a budget. I think that was the biggest difference, to be honest and direct about it. While a growth hacker doesn't care about budget, they're trying to figure out how to produce growth. And that isn't always about a marketing budget or an ability to hire people. It's about basically being scrappier. Like you tend to need to be out of necessity at a startup. And basically Sean came up with the sort of trend and what was going on in the world. And I think all these sort of terms, if they don't hit on something that's going on in the world and there is a ton of tailwind on it, which means, like, you're getting pushed forward whether you like it or not, they don't work. And so. And work meaning they don't become as popular as growth hacking or lean startup have now become. Both of those had a lot of tailwind.

So it was created at a time when we needed to understand how startups should be doing marketing. That's the short sort of tldr. And then Sean Ellis had. Not just that, but he had a very strong thesis about when this person should come into the company too. And that's back to the product market fit surveying that he was. He invented and that we helped popularize at kissmetrics. We built some Tooling that gave it away for free. And then now that's become. Even had a resurgence a few years ago when Rahul Bora at Superhuman decided to create the kind of product market fit engine sort of concept, which at the core was the serving methodology. Pretty much all of it was a surveying methodology that Sean had come up with. But Rahul had operationalized it at Superhuman and kind of blogged about it and talked about it. So it had a little bit of a resurgence. So it's hard for me to talk about growth hacking in the traditional sense that I'm going to call traditional now, because that's what it's turned into. So it's turned into hacks. Well, it was never thought of as hacks. And then I can't talk about this without mentioning Andrew Chen as well, and growth teams. So it started with this kernel of, hey, marketing is not the same at a startup. And then it has evolved into growth hacks, which it was never intended to initially, and also growth teams, which wasn't exactly what it was referring to. And then over the years we've had lots of noise is what I'll call it. And now we have this thing called growth marketing, which I have no clue what it really is, except that we call it growth marketing. And that's fine. Like, I understand how these things evolve. If you look at historical context and forgive me, but I studied organizational behavior in college, so I think about this stuff in very weird ways. Um, but basically a lot of terminology. This is kind of what happens. Like you come up with it and then either it loses steam. So for example, the one that I think should come back again is customer development, but people don't understand it. And that's Steve Blank's. Traditional customer development is extremely valuable. But a lot of these things just get ingrained in our processes and then they lose the terminology. And I don't think that's a negative thing. I think that's good for the world. Um, so initially it was really about startups, kind of a different need, a different type of marketer, what do we call it? And what are they doing? And what they're doing is more equivalent to hacking the system or systems in order to get growth versus traditional budgeting, measurement and sort of spend. Because at that time, ad spend was still like probably the top channel and the top way people thought about marketing.

So for people who are probably not super familiar with like what good growth hacking. Right, in the tr. In the sense that you guys thought about it at startup marketing is compared to what growth Hacking is today. Like how did what happened right? And what are people doing as a practice that maybe doesn't make it as valuable or as maybe it is valuable, but it's just not as intended. Like what do you see as a differences now?

We went really quickly into a world where people wanted to know all the tricks that a growth hacker or the tactics, I should say that a growth hacker was using and those turned into this terminology around growth hacks. And I think part of, part of the issue is the word hack. Just like with lean startup, part of the issue is the word lean. It causes people to have misconceptions about what it really means. Because a hack is like a hack job, something janky, something that is incomplete or was just duct taped together. That was never the intention of what a growth hacker does when the terminology was sort of originated. But what it turned into is everyone wanted to know the trick to get users to convert at a higher rate for just a very basic way to say it. And then it turned into all these things called growth hacks. I'm really happy that there aren't blog posts anymore about the 10 growth hacks to save your SaaS business or to grow your SaaS business or whatever, because I think people learned that that's not learned the hard way that that's not exactly the point. Oddly though, there's folks that work in growth or marketing today that I still see. Like I've given feedback to people that are that have written brilliant pieces of content and if I get to see it before they publish it and it has growth hacking as the title or in there, I tell them, hey, please don't use that. It's not gonna resonate. The reason it's not going to resonate is everyone's tired of that because they the realization we all have now, there is no quick win, there is no silver bullet, there is no real ha that's just going to make it magically work. Part of the reason is something that in marketing I think people tend to know pretty well, which is tactics get less effective over time as more people use them. So of course the growth hack that worked 10 years ago is not going to be as.

Worthy of even trying today simply because it's either table stakes and you're already doing it, so there's nothing to try, you're already doing it or it's just not as effective. And there's a lot of reasons for that. Usually it has to do with platforms that you're using changing or more people using the tactics. So that Users, customers, people get more, they tune it out and they don't. And the response rates and the conversion rates go down. Those tactics. But that's marketing. I could say that about anything marketing and it would be true.

I feel like a lot of those tactics got borderline shady early on too. I remember you'd sign up for a product and it immediately wanted to connect with all your Gmail contacts or all your LinkedIn contacts and then email them all on your behalf saying you were invited to this product. And a lot of people, I think some growth hackers took that and ran with it thinking, oh, this is fine, this is just how everybody does it. But it started to cross these lines of borderline unethical because people didn't know what they were agreeing to and that some of this stuff was going out there. So I remember the days of, you know, when people were like, oh, growth hackers. Like when it got to be too much for anybody to deal with.

I love that you mentioned that about the sort of, let's just call them spammy tactics, just for lack of a better word. Because what got lost was product syncing in that process. So you ended up having a lot of growth hackers being hired to apply tactics without any logic or awareness of whether those tactics make sense for the actual business and the product the business is creating. And so I think the product mindset kind of got lost because honestly, some of those tactics would just work for a while and then they would get less, they would have less efficacy and efficiency and then. But people still kept doing them because they were told to do them or they got a promotion because they did them, even if they didn't work that well or if they were spammy and people didn't resonate with them anymore. So I'm glad you mentioned that because growth hacking and growth hackers in particular, the intention was to actually be embedded in the company across the board, not just be a siloed marketer, so to speak. So that was, I think, another nuanced piece of it, which is growth has to be sustainable and attached to your product, not some add on.

I think that's really important for people to remember too. And it kind of gets me wondering about product led growth as well and what you were talking about with these growth teams. I get a lot of questions now from people who are setting up product teams at scale and a lot of people are trying to follow these rules of product led growth. 1 I have a question about what's the difference between product led growth and I guess, growth Hacking, and then two, the people who do product led growth. Is that any different than product management? Right. Like, what's, what's product led growth? And how does that kind of relate into this whole world?

Yeah. Without getting philosophical, because I can get philosophical about these categories, but let's keep it really tactical and strategic. Um, I think product led growth is a terminology that helped codify things that great product people were doing to help grow products. Um, you could argue that without the idea of a growth hacker and growth hacks, product led growth would never have any legs at all. Um, you could also say that the folks at PayPal were doing product led growth back in the day when they were saying, hey, we'll give you a free $10 and the person you invite if they sign up for PayPal. Was that product led growth? Was that a growth hack? What was it? I'd say neither, because the terminology didn't exist at the time. It was just really exploring product strategy. So I would argue product led growth is another word for freemium. Product led growth is another word for impressive product strategy or luck in a market, you know, like slack. Like there's a lot of luck that led to slack from a timing and they didn't screw it up early on type of thing. So to me, if you're on a product team or you're thinking about product development and you're thinking about product led growth, then you should go back to basics and think about features, functionality, use cases that lead people to essentially bring other people into a product because of their usage of the product. That would be the way I would describe it. Some product categories have a natural fit with that, such as communications. So every messenger out there, it's not useful unless you have your colleagues, friends or acquaintances, whoever it is, in the product, are they doing product led growth? No, they're building their product. It happens to have this functionality native to the type of product that's being built, where other people need to be invited that might not be at the same company, might not be your family, but there are people that you want to have an experience with or you need to communicate with. So I just take it all back to basics. That way we're not throwing around terminology that people think mean different things. And that's one of the problems with some of the terminology today. If I say product led growth to a product team, it's not going to have the same explanation across the team.

Yeah, that's really true. And I see that, like I was saying a little bit before, manifesting in product management, Teams. And even before product led growth became a thing, I was working with a company in New York City in 2015 that was a meal kit delivery company and I was an interim head of product while the head of product was on maternity leave. And we were looking at these acquisition strategies, right? Like how to, how to get people on. There was, there was an acquisition problem. I was trying to figure out what was going wrong and their CEO was like, oh, we want to hire you full time as like our VP of growth. And I was like, what does that mean though, compared to who you already have as a VP of product? And for me, I could never see like the difference between.

What she was working on and what I was doing. But it felt weird to just kind of take off everything that was basically all the way up until the sign up the homepage to the signup and then carve it out and be like, okay, that's yours, that's growth. And then this stuff was product. Because so much of that feels like it goes hand in hand to me. And yet I see a lot of teams out there who are now what you were talking about in the 2010s, I felt like it was the growth teams, but now we're getting into the product led growth teams, almost like a resurgence of those things are happening again and people are not realizing that it's not just, it's, it's good product management all the way throughout, right. It's, it's about understanding your product strategy and having a way for people to get onboard and have a great time, right. And then tell their friends about it or their co workers about it. And it's not more than trying to figure out what that is when it comes to your product.

Couldn't agree more with the way that things have shaped up. I just wanted to mention one thing, which is it seems like a lot of this terminology comes about when things feel stale and static and a change should happen in focus or a thesis that organize that is kind of more relevant to the world. So as we got more people on the Internet, growth hacking and growth became more of a top of mind thing. So I think product led growth doesn't mean anything. Product management does. Great product strategy does. And the folks at Openview saw a pattern and gave it a label. And I happened to catch up with them early on and told them some simple things about repetition and examples in case studies. And they have been very successful since then at applying those things because those are all things that I wish would have been done differently with both Lean Startup and growth hacking or growth hackers. Because if it was codified even more and structured the way product led growth has kind of become, at least was for a little bit. I think it's more confusing that ever now. The, the, the room for misconceptions would be reduced. And that's kind of where we've landed now again, where I think there's a lot of misconceptions about it because it's so popular and people use it as a blanket term to mean a lot of other different things. And that's kind of what happens to most of this terminology unless it's deeply codified properly. And I wouldn't say this one has. That's happened and not. It's not a criticism of anyone, anybody. It's just the way the world kind of works. People run with great ideas. It was a great idea to codify that.

And I can't say there's anything wrong there. But now we're in. We have a message and I think we're going to have new terminology. Someone tried to say customer development should be called customer led growth recently.

I don't like that. I don't want to invent new terms for things that we already do.

Yeah, that's crazy to me that people want to actually change that to customer led growth. It's like customer development is a core principle that has been taught at universities, is taught in many different fields. I don't feel like we need to reinvent that. I think people just need to do it. And like a lot of people don't do good customer development at all these days. And that's usually where they're falling short. It's got nothing to do with the terminology.

Oh yeah, like, oh, so yes, like people are not doing customer development. I, I've done polls on this and people don't even know what it means anymore.

What do you. So when you think about good customer development, like back to the Steve Blank days, what, what did he teach that you're not seeing happening out there in companies today? And like, what are people doing instead?

His original book was extremely tactical and it walked you step by step. So you could pick up the book, apply the principles and it would just happen. Like it would happen. Meaning, like you'd learn really fast. Um, now I think information is just spread and diluted and that's the bigger problem. And there was also, I think the thing to. Thing that's important to remember is that it's like when they're. It's like a pressure cooker. If there's no pressure. There's no incentive to do these things correctly or codify them or anything when there's a lot of pressure. That's when Lean Startup came about. That's when customer development came about. Product led growth's a little different because it was created by a VC firm. Nothing wrong with VC firms, but they have different incentives than a founder or an educator like Steve Blank or a, you know, operator turned educator like Steve Blank or an operator turned evangelist. Not that he's just this, but like Eric Rees or like Sean Ellis, they evangelize the concept. And I think that Open View has done a great job of evangelizing this concept of product like growth. Um, but what's missing today is the tactical operational side of that and it's almost too late once, once the terminology gets way ahead of some of that stuff. And so I think today we're just missing a lot of instruction, to be frank. And I think that's across the board about any of these categories. We want to talk about jobs to be done, customer development, growth, whatever, Product led growth, lean startup. Like yes, the information's all out there, but nobody know, nobody new knows where to find it. In fact, I'm educating people that I help out in one way or another or that I talk to and sending them stuff. And also there's new frameworks I'm into that I really buy into. And the reason they work to your question, circling back again to that same answer, they educate people. You need to educate and you need to give frameworks and ways of thinking about it. And Steve Blank did an incredible job of that because he's an educator, he's an instructor, he's a professor, he's a teacher now. Right. And so that was his job. And I, and same with Eric Reese and to a great extent not as structured. Same with Sean Ellis because he gave you the hey, don't go hire someone to do growth if you don't have product market fit. By the way, here's a survey you can send out to understand if you have product market fit or not. So it's kind of like providing more of the solutioning in a cookie cutter wave but proper way and then educating people about the solutioning. Like so many things about Lean Startup are still extremely relevant even if you don't believe in the thesis, which again, hard to argue with the thesis if you really understand it because it's not about spending less money. That's the problem with some of this stuff. Right? So yeah, I think it's, it's just More, more of an instructional mindset and more of a professor teacher sort of education oriented approach would help these things not turn into, or take longer to turn into something messy where there's misinformation everywhere.

Yeah, I totally agree with that. I feel like every time you turn around these days, somebody's got a new canvas or a new framework that they're teaching, or here's a list of tactics that you can go do, but it's never really tied back to, okay, so this is when you would do it. Here's the context, here's where it doesn't work, this is how you could do it. Wrong. Here's when you would use it, here's when you wouldn't use it. All of those things are so highly nuanced around a lot of these topics. And I find what's happening too. And I saw this with Lean Startup as well. So, like, I got started, I did, I was doing product management, but I used to apply a lot of Lean Startup principles back to my job as a product manager. And I had a lot of people come in and ask me to teach them that, how do you do the experimentation? How do you do that? So I'd come to these larger companies and I would try to educate them about minimum viable products and experimentation and things like that. And they were getting such a bad rap early on, probably around like 20, 2013, 2014, 15. Like, people were just so against Lean Startup. And it was because they were basically applying some of those tactics that you see with the MVPs, like putting a button to nowhere there and seeing if anybody clicks it without understanding why, like those things would not work in those contexts. Right? And how, like some of these experiments don't apply to B2B SaaS companies. Like, I had one company that was.

A B2B platform for major institutions and they did, they literally put like a button to nowhere somewhere on their page to see if people would click on it. And their customers who are already in their product are clicking on this thing and there's no feedback loop, right? Like, they just think it's broken. So they're like, oh, your product's buggy, like there's something wrong with it. And then they go, oh, no, that was an experiment. Like customers never want to hear that you're running experiments on them. Like, that's, that's not, that's not a good way to do that. Um, but then because people were doing this so poorly, Lean Startup became not a thing anymore, right? Like, nobody wanted to do Lean Startup. People thought it was gross. Like, they were like, that's going to kill our business. Um, and it was just basically a bunch of people who were applying things blindly without any context behind why they were doing things.

Yeah, I mean, it's to the point where I work with people that, like me, learn directly from Sean or Eric and folks like that, and I still work with them at my companies. And we've come up with something new. Some of it might be a little controversial, but we don't use the term minimum viable product in our company. And part of the reason is I can't even explain to someone what it is because of all the misconceptions they already have, but what they think it is. And that's especially true for engineers who tend to have to build these things. Um, and so the way we think about it now, in order to help people understand, it's not just a button, It's a button with intention. And is this idea that we've come up with, and it's a framework that we call step one. And the way we think about it now is that it's not about any of the way you think about building product from an MVP standpoint or even a prioritization standpoint. Because I don't really believe in prioritization in the traditional sense. I really think about it as sequencing. So what we're trying to do when we do either a new product or a feature or some initiative that's, like, important enough to do this with, which is just about everything we do at this point, or a lot of what we do, I'd say 80, 90%. Because, you know, small improvements, they don't require MVP thinking as much because you're just literally like, you heard that from the customer, you better go freaking fix it. You know, kind of thing. So the content we went after is what is the thing that we need to build that's going to earn us the right to be able to build all the other things we think we might need to build. And we pro. And the reason prioritization is annoying to me is because it doesn't account for sequencing. It might account for things like dependencies, like, I need to. We need to technically build this before we can do this. Fine, that's totally cool. But that's more of an engineering, technical side of it. I think the product side of it for me is like, we're always shipping product to earn the right to do more for the customer. So if we think about step one. So let's say we have, and I have a brilliant example of this that I just, I just love sharing because it sort of dispels a lot of the myths and a lot of the objections to it. So let me share that, if you'll bear with me for a second. But basically, I think this was back in 2016, Instagram wanted to compete with Pinterest is what it seemed like. Pinterest is a pretty, was a pretty, like, evolved product by then. They had boards and sharing of them and all of these things. And then you thought about Instagram, you're like, yeah, it's obvious Instagram probably wants that because it's an image visual platform. But you don't think about Instagram in the same way you think about Pinterest. Right. So instead of doing that, what they did, this is the journey. What I would say that they did was what I would call step one thinking. Instead of building out every single feature they possibly could, they literally built one button that was added to every post that you saw. That was a little bookmark button. I'm sure everyone's used it by now because what ended up happening is they just shipped that. You hit it, it said save to your bookmarks. It didn't even tell you where they were. They happened to be hidden in your profile. And then here's where it got really interesting. About six months later, they announced that they're adding save to collection. So, so, and I think it was collection at the time. So then what you could do is you hit the bookmark and you could, it'll get saved, but then you could save it to a specific collection, you name it. Still, really slick experience. Not Pinterest, but very Instagrammy. But here's when they launched that add on, you could tell they earned the right to build it. Here's why they said that 47% of Instagrammers had used that bookmark, that bookmark button at least once. That was in their announcement post for the save to collection feature. That's a brilliant example, because by that time, Instagram was already at scale. You could assume they could have thrown 20 engineers at building a Pinterest competitor, but they didn't. Why? They wanted to earn the right to build it, not assume that everyone's going to use it in the same way they use Pinterest. And even today, you don't have much evolution of that feature. Why? Whatever Instagram's goals were internally on metrics, it has already essentially solved the problems they were looking to solve when they launched it. But they also earned the right from a simple button and a hidden Saving, like reviewing of it. Because honestly, when people save, they don't usually go check it out again. That's the irony and that's the funny thing. So my assumption is people who saved had higher retention and then saving the collection was just a little bit more, but they didn't need to do much more in order to service the need that they had of being in that game, so to speak. I don't even think collection pages exist on Instagram right now in terms of the web, because I don't think Instagram cares to get distribution that way. But whatever they do, they could easily add that when, you know, the lifecycle of their product makes sense to add that with or their strategy aligns with it. So the, what I like to say is if Facebook, meta, Instagram, whatever you want to call the entity today, can do it at massive scale and think in step one and not blow it out and add all the fancy features right away. Why can't you?

It's a really good point. And also like, I like this, this example as well, because it's showing. They didn't just go and copy Pinterest, right? Which is what so many companies do. They just go, oh, our competitors have this, like, let's add this. Even the company that I was at, like, when Pinterest was really big, we copied it and put boards. It was an E commerce shop. It wasn't like a, it wasn't an image search thing and people didn't really use the boards that much. But that was, oh, Pinterest is doing this, so we have to do it too, right? But I love the way that Instagram actually tested it and said, is this going to be relevant for our people before they went to, to build it? And just with that small test, it's such a great example of, let's just make sure that this is going to work. Let's get some proof and then let's commit to rolling out those feature sets. Such a great example of that. And with the prioritization stuff that you're talking about too, I completely think about it that way. And it's been so hard for me, I think, to wrap my head around certain things. I feel like I learned something and then I apply it myself. And then I go back and I, I try to teach some of these concepts or something that somebody codified and then I go, oh, that's not really how I do it. So why does this feel weird? Why does this feel weird to talk about it that way or to teach it that way? And for me One of the biggest things that I came across that helped me really explain my sequence thinking and how to build these things up was Kata, which is from Toyota Lean Kata, and that I always loved because it really starts from, like, you know, understand. Understanding what you're trying to achieve and, like, where you're trying to go in the vision or what you're trying to prove, and then breaking it down into one small step to try it. And in, like, product management, that could be what, you know, what Instagram did. Let's just put a button there. And then if that works, we're going to roll out this, and if that works, then we're going to roll out that, and then we're going to work our way to our vision as we prove that that's actually the right vision. And if it's not, then we're going to pivot along the way because we' thing we're building a little bit and then we're always having feedback loops. And what I love about Kata as well is that it really promotes learning, which is what, to me, like, Lean Startup was really all about. Right. And what MVPs was all about. It's about how do we learn if this is the right thing before we go full force. And in a lot of ways, I found that people were doing it or interpreting it or understanding what an MVP was inside a company. It turned into like, oh, no, we just do that thing and then we move on. We're not actually learning, we're not actually incorporating those things. So, like, for me, that. That became like a huge pivot point in the way that I was thinking about stuff and teaching it, too.

Yeah, it's. It's incredible how the concepts are fairly simple, but the application, because there's all this terminology and different people think about it differently for whatever reason, where alignment ends up being the first problem to solve, which is like, why are we doing this? What is it we're doing what is like. And you end up getting this in companies because people have ideas and they have lots of ideas, but it's not about actual ideas. It's more about what's right for the business and what's right for the customers. And how do we start experimenting with it and testing it. I even am scared to use those two words for this because, yes, it's an experiment to test, but people have all kinds of implications that they have about what tests and experiments are right? So to me, it's more like, okay, how are people doing this stuff today and how can we help them understand how to do it differently or better by using examples and using some kind of terminology that's shared, that doesn't get completely lost or isn't something that has misconceptions already. So we're really careful about that. If I see mvp, even in companies I talk to or any of that, and they're using that a lot, I'm like, wait, let's step back and make sure everyone knows the definition of that. Once we usually do that, if we need to, I tend to then say, okay, now let's replace MVP with what we really think we're doing here and call it. Call it the right thing and don't use words that not everyone understands. Because I can guarantee you today, if you ask 10 people what an MVP is, unless those 10 people were there back then when I was around and we were learning it together, they wouldn't be able to give you a good answer. And I know you can because you care and you were around, but a lot of people weren't around and they don't care as much about the nuances because they haven't seen the pitfalls of not caring, you know, so, yeah, I couldn't agree more.

And also, like, there's this whole factor that happened as well where Agile had a different definition of mvp, which was very much literally the first version of something, whereas in lean startup it was more about learning and experimentation. And then those worlds kind of clash. And like, for me, I don't talk about MVPs anymore either. I teach it from the perspective of, for companies that are new to it, I teach it from the perspective of this is what I know and this is. I'm going to try to display some misconceptions here so we could just move forward and try to have a common terminology on what we mean by that. But really, if I'm working with somebody and we get down to it, I'm not going to talk about that. I'm going to just talk about what are we shipping first, to figure out what we're doing next. What are we going to do to learn and see if we can actually solve a problem. One thing that I run into, though, a lot from product managers, and I'm curious what your thoughts are on this, because you got into it a little bit, is there are people out there, I think, who understand this, who are working as product managers in teams, and they find that their leaders or the people around them are kind of grasping onto these terms and misconstruing them. And are the ones who are like, no, you Gotta do it this way or this is what it means. And they want to be able to go back to them and try to. To educate them. Right. And try to bring them along on this journey and frankly, just do their jobs. Like, a lot of these people are just like, I just want to do my job. Right. Like, I want to be a good product manager. I want to go do my job. I don't want to get into this political, you know, nonsense about terms and stuff. What's your suggestion for people who are, like, battling this terminology war?

Yeah, this is an oddball answer, but the answer I would say is I learned a lot. I've learned a lot about this from sales. So a piece of this is objection handling. So if you ever need help, go read up on sales and how sales folks deal with objections. They're very effective at it. There's also a framework called the challenger sale, where you're challenging people's assumptions. So that one's interesting, too. And you're challenging them because you have something unique to sell. But the tactical advice I would give on this level, if someone came to me with this situation, would be if you can have a conversation with that person who is saying that we need to do it this way, and this is the terminology that I would just have a conversation where I'm looking to understand even more what they're thinking and why. And that can go one of two ways. I think it's totally fine on the product person side to have that convo. So I don't think that that's the issue. And I can. We can talk about, if it makes sense, more about that convo. But that convo will tell you how much room you have to get that person's mind to change. Because if you don't have enough room to get that person's mind to change, if you don't have the room, you might not want to continue being at the company if you have resistance to the way that they're thinking about it. And that's what you're really trying to determine here. And I like being blunt about it. One.

I'm a founder. I'm a CEO. This is how I'd want to be treated. But, like, I'd want someone to understand what I'm thinking and how I'm thinking about it. And then I need them to make a decision on whether they can either change my mind or not, which is fine, or they can't, and it doesn't work for them. And I know that's, like, super hard, like, to swallow so to speak. Because you're just like, oh, like, that means I might not be here, but. But, yeah, but, like, do you want to waste your time? And so to me, it's just a legit conversation. Not about, like, that leader or whoever's saying it to know that you're doing this, but more like, hey, I really want to understand what you mean on a deeper level without the terminology. So when you say MVP and you say we need to test buttons and stuff, what do you really mean? What do you want to accomplish? What is your goal with that? What is the outcome you want? Because I want to make sure I can align with the outcome you're looking for. And then you figure out if you have room, if you could get aligned on the outcome, to. To go after that outcome in a different way than that leader is saying. Because as a leader, you probably have an outcome in mind and you want it done, but you usually don't care as much about how it needs to be done unless you think your team doesn't know how to do it. And that's what you're trying to figure out is how much room do you have there for maneuvering the way you'd like to? And if you don't have enough room, there's an unfortunate truth.

There's. Yeah, that has definitely become some of my advice for people, too, is just like, if you. If you feel like you're not making headway, just go. You got to find another place to go. And I think it's hard and it's challenging for some people to be able to just pick up and move. I get that. But at the same time, if you really care about that and you feel like you can't live at this company anymore, that's. That's the. I think what you have to deal with, with the frustration and decide, am I going to be frustrated and just, like, suck it up and do what I need to do, or do I want to find a place where I can really thrive? But I really like that you brought this back to sales, because I've never heard anybody actually explain it from that perspective. So I think those are great resources, and I'll link to them in the notes. I'll put them in there so people can look it up. But I like the way that you're thinking about it with leadership, too, where it's like, let's align on the outcome, and then I'll tell you how to get there and see if there's room for people to actually choose the tactics. I find a Lot of product managers and a lot of team level people in general are really afraid to have those conversations with their leaders. And I think it's so important that they're not afraid. Right. Like that they kind of get over that and start to have hard conversations. Because I've had a lot of conversations with people lately too about how do I, how do I move up the ladder, how do I go from like a team level product manager to a director or product manager? I want to be a VP one day. And if you're not willing to have those conversations where it's like, let's get back to the outcomes, you're never going to be able to lead a team, you're never going to be able to work with executives. That's the conversations that we have all day, every day in a C suite meeting or a board meeting. People will be throwing terminology all over the place, but we'll just be like, whoa, whoa, whoa, let's back up, let's just talk about what we want to do here. How are we going to get there? Here's the plan. This is what we're going after. And I feel like most leaders are not objected to that. They're like, oh, unless they think you can't do it like you brought up. But if they think that the team can't do it, that's interesting to dig into as well and say, why is your leader not confident in your capabilities and what are you doing as a product manager or as a team to make them not feel confident. A lot of that to me comes back to communication too. Not clearly expressing your plans or what you intend to do, keeping it vague, keeping it to low level, very tactical, and not really showing that you've got ownership of this and that you're going to steer it forward. And I see a lot of, of people make that mistake and not communicate up. And that's a really good way for leaders to just lose faith in you too. What else have you seen, like kind of steer those conversations where you feel like you're not going to get any room.

There's really the way I would think about it is I don't think you're trying to have a conversation where you're trying to steer it. Anyway. What I believe and what has been most effective in every scenario I've seen of essentially managing up is essentially what you're talking about. It's like a conversation you're having with someone who has responsibility for your job, right? They can fire you, they probably hired you if they didn't hire you, they're still responsible for you one way or another. So I get, I get the sort of perceived weight of the conversation, but the conversation shouldn't be that weighted. I think you can do it not necessarily casually because these are important conversations. So the words I use and what I have seen, even managing up to investors work really well is the word alignment. So I would say, hey, I want to make sure we're in alignment of what? Goals, outcomes and even the process that we're going to take to get to them before we start. Or a more brute force way to say it if you're in the middle of something is, hey, I think there's some misalignment and I just want to make sure we're aligned. So I'd love a 20 minute conversation to talk about 1, 2 and 3 so we can get aligned. And if they say, I don't want to have the meeting or something, be like, okay, can we, can we do it asynchronously so I can at least lay out my impression of 1, 2 and 3 and then understand and make sure that it's aligned with what you're thinking. And so to me, these are alignment conversations. And that's a, that that has been a hundred percent effective every time I've done it. The reason is leadership knows they need alignment because when they manage up, they're always looking to get alignment because the best leaders are always looking to be aligned in their execution with whoever is their boss, which is another leader usually that's, you know, got a lot of responsibilities and a lot of people they're managing. And so the best way to think about it is just, are you in alignment? Are you not? And how can you use that word to help everyone get in alignment? And it's that simple. And that I have to tell you, it's effective 100% of the time.

I think that's really good advice for all those product managers out there listening to us. Hinton, we talked about product led growth as one of the hot topics and terminology that people should be watching out for right now. Is there anything else that you've seen floating around that people should keep a heads up for on these new growth terms or things that are coming out that you're like, make sure that doesn't spiral out of control.

Yeah, you know, I'm gonna give two examples. One that's old and one that's just in my mind. And I think it's still relevant for product teams in a big way, especially B2B. But let's start with the one low hanging fruit. I am over the moon about a specific part of Jobs To Be Done. I'm not the biggest fan of calling things jobs. I think it's ineffective and it's very confusing. It's worse than MVP or any of the other terminology. The reason is when we think about a job, we don't think about a job that the customer is hiring our product to do. That's just not a natural way to think about the world, unfortunately. Much respect to everybody who worked on the framework because of what I'm about to say. There is a interviewing methodology called the Switch Method. It is highly effective and it's part of Jobs to Be Done. And it helps you understand why people are switching to your product from other products or alternatives or whatever they were doing previously. And it also helps you understand why people are switching off of your product to other products or alternatives. If you haven't ever done that kind of interviewing, I would highly recommend you dig into it. It's called the Switch Method Interview and it's from.

Jobs To Be Done and it is indispensable. Like it is highly effective at helping you understand the events that go on in a potential customer or a customer's journey that lead them to switching products. That's one. Number two is the sales methodology called Winning by Design. That's another one. I'm over the moon by or for. And if a think of it this way, every single other sales framework that a product person would look at, they're either gonna look at it and be like, oh, that's not relevant to me. Or look at it and be like, oh, that's a little cringey, just to be honest about it. Or oh, sales. Oh man, not another one of these. This one though is essentially perfect for product people because it's really full. It's. It's almost like the customer development version. It's almost like customer development for sales is how I'd say it. And it's called Winning by Design. And there's tons of videos that the team over there has put out. To my point, about frameworks and educating, I have never seen anyone, even Eric Reese, who educated a lot, a lot more than any other person prior to this. But Jocko and his team at Winning by Design have educated the masses, so to speak, on this. And it's essentially a SaaS B2B sales framework that really focuses on get this diagnosing pain before prescribing solutions. Sounds very producty to me. And so a lot of this stuff in their Whole framework and everything they do is just very impressive as to how they've taken kind of sales and turned it into a system. And very systematic, very similar to customer development.

Wow, those are really good resources. I have not heard of winning by design, but when you just described it, I was like, I think that's exactly what I. What I would do in sales when I was consulting, and it worked very well. So I would encourage a lot of people to go look at this, because I felt like I was in these calls for, like, 30 minutes, you know, and it was supposed to be a sales call, but I just listened to people complain about their product management. And I'd be like, what's wrong? Like, tell me what's broken, what's going on? And then they would go, you know, down a whole list of things that wasn't working. And I'm like, okay, well, I don't think you need this thing that you thought you needed, but I do think you need these things over here. And that always worked. And I never had almost closed pretty much almost all the sales I've ever done in a meeting like that. But I think that's so valuable for product managers to get their mindset around that when they think about interviewing and helping customers and even just like, talking to people within an organization as well, trying to solve problems internally. So thank you so much for bringing those up. Hinton. It's been such a pleasure to have you on the podcast, and I'm so excited that you could be here. If people want to learn more about you and follow any of your writing or, you know, look you up on Twitter or LinkedIn. Where can they go?

Yeah, just follow me on LinkedIn or find me on Twitter. I'm HN S H A H on Twitter. It's actually a cool story is that was the. My middle name is N. It's my father's name, Nitin, and he put H.N. shaw on his first car in the US as a license plate. So that's why it's my Twitter handle. So. And my handle in a bunch of places. And then LinkedIn, it's just heat and Shaw, and you can find me pretty easily there as well. But that's where I share kind of most of my stuff, whether it's blog posts or other people's stuff or some of your stuff, too.

Well, thank you so much. And for those of you listening to the Product Thinking podcast, thank you for being here. If you enjoyed this episode, please like and subscribe. You can go to productthinkingpodcast.com to get all of the notes from Heaton's episode and all these links that he shared as well. And we will see you next Wednesday for another episode.