- JJ Rorie
Never Assume: Ten Fatal Assumptions Great Product Managers Never Make (Part 1)
Updated: May 11, 2022
Episode 014: John Fontenot, Author, Founder Path2Product
Never Assume is a book dedicated to helping aspiring and current product managers to challenge their own thinking to make better product decisions. It's amazing how many decisions we make every day that are influenced by assumptions. Unfortunately, untested assumptions are the leading cause of startup and product failures.
Â
Episode Transcript
JJ: Hello. Welcome to Product Voices. I'm excited about our conversation today. I've got John Fontenot with me. John is the author of Never Assume: Ten Fatal Assumptions Great Product Managers Never Make. This is a new book. I've read it. It's very good. You need to go get it. And John is here to talk about the book and his insights that he wrote in this book. So I'm really excited.
John Fontenot, thank you for joining me.
JOHN: Hey, JJ, thanks for having me.
JJ: Yeah, I'm excited about this conversation. This is actually going to be a two-part episode. So this is the first part. We'll talk about the first five assumptions in the book, and then you can come back next week for part two, too.
So let's jump in. What got you thinking about this in the first place and ultimately what drove you to write the book?
JOHN: Yeah, that's a great question. I don't know. I feel like my PM superpower is like connecting dots. Right. And so as I thought back around my very early experiences and things that I still experience today, one thing I noticed was that a common pattern of product failures or failed features, which is untested or unchallenged assumptions. Right. Anywhere from things that I thought should be a priority or things that I thought I was aligned on across the organization and on my own podcast, I interviewed a bunch of startup founders and found that it was common amongst startup failures, too, that one of the top two most common reasons for startup failures was there was some level of falsehood to a very key assumption to their business that caused it to stumble and fail. I noticed that there wasn't much content out there on assumptions as it relates to the way that I wanted to frame it in the book. And so I decided to produce it.
JJ: I love it. It's really good. And I agree. I think that it's almost like we all know that we work off of assumptions. We work off hypotheses, and there's like a fleeting content or conversation that, hey, we should do this better, and then we just kind of put our heads down and keep going. So I'm really pleased that you thought it was worthy of a really good piece of content, because it is. We need to talk about this more often.
Let's jump in. I want to talk about each of the assumptions in detail and have you briefly describe each one and talk about why it's important. And so, again, we're going to talk about the first five today on this episode and then come back for part two, and we'll talk about the other five assumptions that great product managers don't make.
So let's jump in. First one never assume you're correct. Tell me about that one.
JOHN: Yeah. It's something that as I read a lot of product content online, I hear from a lot of early stage or aspiring product managers. And I think there's this common misconception. For those trying to get into product that we need to be like the Steve Jobs and come up with this innovative thing that consumers don't know they want, our businesses don't know they want, but we're there to go tell them what they should have or what's going to make their lives to next better. And it's just a fundamentally flawed assumption getting into the career of project management, that we have to be the idea person that comes up with the ten X innovation. And that's just not how the product works in practice. And so I figured I would call out some prior experiences of my own, as well as sharing a story of other very experienced PMs and kind of how they stumbled across those same assumptions and kind of tripped up early in their careers, too, to shed light on that for these early stage PMs who think that they have to be kind of that idea person who comes up with all the great new stuff.
JJ: Yeah, I think that's a really good point. I think so many product managers or aspiring product managers think that it's all an idea job and that you're going to be up on stage, you're going to be the next Elon Musk, if you will. I don't know if anybody wants to be him right now, but maybe they do. I certainly want his money, that's for sure.
But it's interesting because I'm teaching a class now at a University, and the students who are primarily engineering students, early 20s age, little bit of work experience, but mostly just academia. And they all I say that most of them want to be product managers, or at least they think they do. But they don't have a clue what it means. And I'm teaching them about product management, but they're still new and they don't really get it, but they know how cool the job is. They know that it's hot, they read about it all the time. And so many of them have that erroneous opinion that it's going to mean they're going to come up with these brilliant ideas. They're going to end up being this founder, this billionaire someday. And sure, there's one in a million that happens to, but the truth is most of us work on incremental innovation. We take ideas from lots of different parties and bring those together ultimately for the betterment of the customer and the business.
So I love that you talk about that and that, you know, kind of are helping people understand that. It's not it's not only one way in product management. There's a lot of people that come together and a lot of places that ideas come from.
JOHN: The way I like to talk about it is we're almost like a sponge. Right. It's very analogous to that where we have to take in and absorb inputs from all across the business, internally. Externally. Look at the market, look at the customers we serve today. A big part of our job is synthesizing those inputs and then working collaboratively across our product, team with marketing, with sales, and really figure out what's going to make us successful. Going to market. Where are the gaps in the market where our current customers underserved today? How can we strengthen our defensibility? And those aren't things that we can come to on our own. Right. It's almost like raising children takes a village or raising a product takes one too.
JJ: Yeah, absolutely it does. That's a great point. Okay, so the second one I love and I think so many of us fall into this trap.
So the second one is never assume customers are correct. Tell us more about that.
JOHN: I think retail has made this quote famous. Right. That the customer is always right or the customer is always correct. And in product, that's just not the case in a lot of the ways that we choose to handle customer request. Right. It's very common for customers to come to us and say, hey, I want you to build this feature. And it's all too easy to turn around and say, okay, I'll go build that feature.
And I know you talked to Jason Knight recently. I listened to that podcast episode around the differences of B2B and B2C. In some instances, you have very large clients and maybe ten to twelve clients that represent the entirety of your revenue. Right. And it's harder to tell them no for a specific feature than because they represent such a large part of your business. But even in those scenarios, right across product. Disciplines. That's what you want to call them across industries, or whether you're B2C, B2 enterprise, it's more foundational or it's more fundamental to understand the problem driving the request because so at the end of the day, we have to build for market.
If we spend all of our time building for one client, even if they represent 10% of your overall revenue, one the likelihood of you not getting things correct or actually truly solving their problem. There's probably context that you're missing if you just go build the thing they asked you for. And so taking a step back to really go past the surface of saying, okay, the feature that they're asking for might not be the right one, but what I should care about is the problem driving the request so I can truly solve it. Because at the end of the day, whether it's a billion dollar enterprise that you're serving or a million consumers. Right. They don't care what the feature is. They care that you solve their problem. And that's really the big takeaway I wanted to come up from that chapter is that it's not our job to be the order taker. Right.
Like I was a waiter right after College. During College, I waited tables and I took orders. But that's not what we do as product managers. Right. It's a lot more complex. And the whole theory of jobs to be done comes from that is you have to understand the problems that your customers or consumers face and the context in which they face them to truly get to the root needs that's driving behavior.
JJ: Absolutely. I think that's really important. You know, the next one actually ties into that, in my opinion, because I think what some companies do is they try to mirror competitors. They try to better them, but they do what competitors are doing and they try to do it a little bit better. And so we all have done competitive analysis and looked at features and functionality and kind of the big picture of how competitors compare to us as our business and our product portfolio. And then we try to do it better. Well, there's an assumption in there that the competitors have done the right customer needs analysis and the competitors are actually building the right solutions in the first place.
So let's talk about this next one. Never assume competitors are correct.
JOHN: Yeah, this is one of my favorites, and one of my biggest pet peeves as a product manager is inevitably, especially if you're in B2B, which I have been my whole career mostly serving SMBs. So not at the enterprise level, but the sales team will go to the CEO and say, hey, we're losing X number of deals because we don't have this feature. Our competitor has it, this person asked for it and we didn't close the deal. And so they take this corollary analysis, very light corollary analysis and say, well, I didn't close the deal and they asked for this feature. So it must be because we didn't have the feature. So there's fundamental assumption, number one. But then they go to the CEO with the assumption of if we have that feature, we're going to close these deals that we didn't close when there's so many more variables to worry about. But then the CEO comes to the product team and says, hey, go build that feature so we can close those deals. And that leads into the next chapter, which I won't jump ahead.
However, it all kind of ties together where we look at competitors and assume things way too early. And there's a great story in the book about that. But. To your point. Right. It assumes that the competitor didn't do the thing that we just experienced. Who's to say that their executives didn't have pet projects that they forced the product manager to do? And that feature absolutely has has nothing to do with adding value to the customer. Right.
And so now all we're doing is creating more feature Bloat in our products that really doesn't add value to our users whatsoever. And I think the biggest thing that I wanted the reader to take away from that is even if you assume correctly that the competitor is talking to customers, validating their problems, making sure they framed it correctly and they're validating the solutions to those problems. If all you're doing is copying your competitor because you're looking at them to be correct, then you're never putting yourself in a position to differentiate your own product and figure out how you can serve your customers better. And inherently, your solution is going to be subpar your competitors because you don't have the same intimate insight that they did from the actual validation that they did from discovery to delivery.
JJ: Exactly. And you know what's interesting? And again, this ties to the next one, which we'll talk about in just a moment. I want to ask your opinion and your expertise and some of the stuff you put in the book. How do product managers approach that? When we've got a sales team, when we've got executives who are coming to us, and we know that we're all making assumptions or that they're making assumptions that we should not be doing? How do you approach that? What are some tips that you would give product managers to approach those sales teams, those executives who are coming that you know that causality is not there, and how do you kind of rein them back in?
JOHN: Yeah, it's a good question. I'm not going to say that this advice works in every case because there are executives who are very opinionated, some might say borderline arrogant or very top down in their nature. But I'd say that there's a lot more executives these days that are more humble in nature or at least claim to be data driven. And what I like to do, whether it's an executive or mid level manager, whoever it is that's coming to me, a sales rep, and ask for the same thing that I would be asking for if I was thinking of prioritizing something based on the research I did is data. What outside of the anecdotal request you got from ex customer over there, what's actually driving the business value behind this request? And help me make that case? Because I think a lot of times product managers feel like it's all on us.
Somebody comes to us with something and we just have to say no because it's not a priority. But I think if we can start shifting the narrative to where we can start asking our stakeholders, our cross functional partners for the same amount of data that we would be inherently going look for to validate whether or not this is a real opportunity, then it starts to train them to start thinking like product people. They start knowing and understanding that if they come to us with a request, they need to come with this type of data. And so they start looking for it. And so my hope in this and this is something that I'm still trying to prove out in my own practice is that we get less requests because people are helping us filter those requests through the lens of the same data that we're asking for anyway.
And so that's my advice is take the pressure off of yourself, put the ball back in their court. This isn't something that you've seen data on or that you validate yourself. So if it's something that they think is really worth it, then make them go do the work to help prove the point. And it's only going to make your life easier, and it's going to make the business run more effectively. If everyone's thinking like product people and putting that same level of rigor around their thinking.
JJ: I love that. And I agree. I think that would be so beneficial to the organization, to everyone, obviously the product manager, because as you said, those ideas are getting filtered out ahead of you, but it allows those salespeople, those other partners, to understand the process, the decision making process, and why we go through what we go through and why we say no sometimes, and that will be beneficial to everyone again, this fourth one, which we've alluded to here, is never assume executives are correct. Right. So again, sometimes they have a pet project, sometimes they come to us based on just an anecdotal piece of data. I love what you said, though, because the truth is if we if anyone goes to an executive with a recommendation or a request, most of them are going to say, Where's the data? Where's the proof showing impact, even though they don't necessarily do that when they bring us their project.
So tell me a little bit more about this, about this chapter and about this assumption never assume executives are correct.
JOHN: I felt this throughout different parts of my career, but even before Product. But I think there's this inherent feeling that if somebody has a job title that's greater than ours, that we are somehow beholden to do what they are ask us to do, right? Whether it's whether you're an individual contributor at the product level and your director or VP of Product comes to you, a VP of sales comes to you, or your CEO comes to you and says, hey, I want you to do this thing. We don't inherently have to go do it. At least my advice would be that even if they may not like it at first, I firmly believe that they will respect you a lot more if you show them that you think at their level.
Because to your point earlier, JJ, if you try to get investment for some big project, they're going to ask the same questions. And even though that whole debate about being the CEO of the product still rages on on social media, we still have to think that way, right? If we take the level of ownership that we treat this product as if it's ours, and if it was our money that we were tossing around like, how would we invest that money? I believe we should be thinking that way, then I believe that our executives and senior leaders will respect us if we push back a little bit when they don't provide us with data because they may be reacting off of emotion or off of some heated meeting they had with the VP of sales and it may not think to ask for that same stuff they would ask us for.
The advice I give in the book is a little nuanced because it's not so straightforward and easy all the time. And I can go over it lightly, but basically at a high level, asked for data, ask for them to help you make that decision. And then if they're still pushing back, then the next thing I would say is at least come to a common understanding of what success looks like. Because if they know that you are now changing priority to do the thing that they told you to do, because at the end of the day, it's their company or they could fire you depending on who it is. Right. You may have to submit at some level or quit. But if you go ahead and go through with it, then if you have a common definition of what success looks like and it's unsuccessful, then you could bring that back to have a productive conversation to say, hey, look, the thing that we were going to prioritize was supposed to yield X result. This thing missed the Mark here.
Next time, it would probably be a lot better for the business as a whole if we actually went through the exercise and the rigor of doing a proper analysis on this before we just kind of pulled the trigger on a decision. And if they've gotten to that level and can't have that level of candor in a conversation, then it might not be the right culture to do product within. So that's kind of my two cent on that piece.
JJ: Yeah, that's very fair and great advice. Sometimes, no matter how much data we provide or ask for or how much proof we try to get and provide on our side to avoid a pet project, sometimes, as you say, we just have to go forward with it. And I love the advice about establishing success criteria from the beginning because at least we're setting the groundwork for further conversation at the end. And if it succeeds, great. I mean, hey, that's better for all of us. It's not that we're trying to prove ourselves right, but sometimes and most often we do. And as opposed to just saying I told you so, actually having some empirical data there is really great. So that's awesome. Really good advice.
So the final one for today's episode is never assume customer priorities. That's a really good one, too. Tell us more about that.
JOHN: Yeah, this is interesting, right? Because in perfect product practice, if there ever was such a thing, we do discovery. We uncover the opportunity space. We may have read Teresa Torres's book and mapped out our opportunity tree or opportunity solution tree. And I think sometimes we can get a little hasty with saying, okay, here's the opportunity space. Let's just go build the thing that we think will have the most impact. Right. We'll break out our fancy rice framework and say, okay, well, I think that this feature or this solution would have this much reach, and I think based on the conversations, it will have this impact. I'm pretty confident. So let's mark that as whatever number we put on here. And let's go talk to the device about what the effort would be. Right. But there's a level of testing that we can do around Desirability, and there's different tests that you can run to really gauge what actually would make the most impact or what is the most desirable thing. And that's probably not something we have fully time to unpack here.
But the point is, we could make those assumptions around what the priorities of those opportunities are, and then we might be sub optimally, building value for our business. So going and doing that extra level of validation back with our users, whether it's qualitatively, quantitatively running surveys or however we're trying to not only derisk, but also validate the value of what we're trying to build is just going to make you that much more effective and impactful as a product manager. And we know that's big for our career. Right. Because the bigger the impact we can show, the more opportunities we're going to get to get where we want to go in our career.
JJ: Such great advice. So John Fontenot, author of Never Assume - Ten Fatal Assumptions Great Product Managers Never Make. Thank you for joining me for the first part of talking about your book and all of these assumptions that we need to avoid. I've enjoyed the conversation. We're going to be back next week for part two to talk about the remaining assumptions not to make. And those include never assume you're aligned, never assume you're doing a good job, and more.
So, John, thank you for joining me today.
JOHN: Thank you, JJ. It was a pleasure.
JJ: And everyone make sure you come back next week for part two so you can hear the other assumptions that John has written about in his book. You can find out more about how to get the book, how to connect with John on Productvoices.com, and we'll see you next week in part two of the John Fontenot Never Assume episode.
Resources
Connect with John
Ask a Question