- JJ Rorie
Never Assume: Ten Fatal Assumptions Great Product Managers Never Make (Part 2)
Episode 015: 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 and welcome to Product Voices. Today is part two of my conversation with John Fontenot, author of Never Assume: Ten Fatal Assumptions Great Product Managers Never Make.
Last week in part one, we discussed his first five assumptions that product managers should not make. Those included:
· never assume you're correct
· never assume customers are correct
· never assume competitors are correct
· never assume your executives are correct, and
· never assume your customers priorities
So again, if you missed that episode, go back to ProductVoices.com or any of your favorite podcast platforms and find that episode. And today we're going to be continuing the conversation and talking about the final five assumptions.
So, John, thank you for joining me again.
JOHN: Yeah, thanks for having me back.
JJ: Ok. So. The 6th assumption that you write about in your book is never assume UX complexity. Let's talk a little bit about that.
JOHN: Absolutely. So I talked to my UX friends all the time and see so many people still referring to UX is UX UI and getting them confused. Right. Where too many people who have the title of product leader or even outside of product think that UX is just making things pretty. And it drives me nuts because UX adds so much more value than just making things pretty. And UX is incredibly complex. Right. And I always say that in hyper competitive spaces, one of the only ways you might be able to differentiate yourself is user experience.
I'm reading a book right now, The Cold Start Problem by Andrew Shannon, and he talks about that with how Zoom came into a hyper competitive space with teams and Webex and you have Skype and they came in and dominated the market. Why? Because it was super simple and the UX was like ten X, better than everything else. Didn't have all the features, but it was just a better product. And so I'm a huge advocate and proponent for UX as a discipline.
Like, I call it Full stack UX because it's not just visual design. And I wanted to stress that point in the book that you can't just make something pretty and expect people to adopt it and use it and love it. It's a lot more complex than that.
JJ: Yeah, absolutely. And I agree totally in that there are so many examples. There are so many times where companies, most companies exist in a very competitive market. And there are few ways that can differentiate more impactfully than having a better customer experience. And if you can really do that, if you can really embrace that, then I think you're going to be set up for success quite well. So that's a really important one. And something that again, I think in product you mentioned UX UI and just some confusion on what it actually is. So I think it's really important that you've started that conversation and making sure that everyone understands that, yes, it's complex, but that we need to have the conversations around it so that we can actually win.
I mean, think about that. Think about what you just said. Skype, Teams, all of these huge companies. Right. That got beat, at least, you know, in some cases, in some circles. So I mean, I think that's a really important point. Yeah, absolutely.
So the next one never assume you're aligned.
I think this happens so often. I know I've made this mistake a lot. Right. We as product managers, talk with our teammates, we talk with our stakeholders, we share information. We think we're connecting with them. We think we're all on the same page, and then something happens, and we know that we are certainly not on the same page.
So tell me a little bit more about this assumption.
JOHN: Yes. This is the bane of my existence as a product manager. And it's funny because people get consultants or OKR coaches to come into an organization and pitching how this framework or what have you is going to be the silver bullet for alignment. And my current employer has been going through this for the last four months of trying to adopt OKRs and assuming some of the same things, that this is the magic bullet to align you. And by far, chapter seven is the biggest chapter in the book because it's to me, one of the most complex things to get right as an organization and especially as an individual contributor and product or even a product leader trying to align across the organization.
One, I think it's incredibly complex. And two, I think there's some frameworks that you can use to start drawing common language and common understanding around the business to create that alignment. And one of the things that I call out, which I'll be doing a talk on in a couple of months at the Product Led Summit, is that OKRs are not a standalone tool, that there are some missing pieces. And so we could jump into that if you want.
JJ: Let's jump into that. Let's talk a little bit there, because I think OKR is like so many things, they get some traction in product management, and it's not always easy to implement within organizations. And reorganization is a little bit different. So let's talk specifically about that. Tell me a little bit more about how you address that.
JOHN: So, OKRs, for the listener that may not be familiar with the concept, it stands for objectives and key results. And really what it is. It's an execution framework of trying to say, okay, what is the thing we're trying to accomplish? Qualitatively. And then the key results are the quantitative measure that determine whether or not you're making progress towards that objective in the way that I've always learned it is the objective is kind of like a twelve to 18 month thing. And the KRS are measured quarterly as kind of indicators, quarterly of progress towards that objective.
And so in my conversation with a lot of leaders, whether it's in my current organization or in prior organizations, is that OKRs as an execution framework get mistake for strategy in the thought process. And the language I hear is that, oh, yeah, the objective is what we're trying to reach, and the chaos is how we're going to do it. And I always ask, so putting numbers behind these are the numbers we have to hit to get closer to our objective defines how we're going to hit our objective, but how are we going to make those numbers move?
And so there's something missing in between. And I found a really nice synergy between the OKR framework and Richard Rumelt in Good Strategy, Bad Strategy. He has a strategy kernel where you first identify what is the key challenge in our way, and then what is a guiding policy to frame the actions that we take and then guided through the lens of that guiding policy, what are the coherent actions that we need to take?
And so I found out that if you sandwich that kernel in between, OKRs, then you could say, okay, here's our objective. All right, what's the key challenge in the way of reaching that objective? And then what is the guiding policy, or what is typically known as strategy of defining how are we going to tackle the challenge? And that to me, has been what's been successful in creating alignment around the overall approach.
Because what happens is if you don't have strategy or an overall understanding of what the approach is to overcoming your challenge, then you have multiple departments running in different directions trying to reach the same outcomes or the same key results, and the organization is just not coherent or not aligned in those actions. And so your results end up becoming sub optimal because people are people have different opinions of how to actually get there. And there's nothing constraining how you make decisions throughout the organization.
JJ: Yeah, that's great advice. And it is ironic, isn't it, that devices or methods like OKRs that are designed to align us all often make for more confusion than what they should. Really good advice there and how to kind of tie things together.
So let's take it to the next assumption. And that is never assume development effort. What does that mean to you?
JOHN: Yeah. So one of the common things that you'll hear and that you probably already here if the listener has been in product for a while, is as a product manager, I'll go to the developers and I used to say all the time, is this possible? And the response was always, well, anything is possible. And what they mean by that is given enough time and resources, we can pretty much do anything. But we know that time and resources and money is finite. And so it's not about whether or not it's possible. It's about whether or not it's feasible. And determining feasibility has nothing to do with whether or not it's possible.
So in the chapter, what I try to emphasize is, like, just as we talk about UX complexity, development is complex, too. And just because something may seem straightforward or someone may think, oh, that seems like a simple change. You have no idea what's going on behind the scenes. That could make something that seems like it would be a day or a week's worth of effort, could be six months worth of effort. And there's actually a story in the book that explains that very concept in practice at Microsoft.
So it doesn't matter what we think should be easy or we think might even be complex. We have to have those conversations with our development team to really understand what's going on behind the scenes and what constraints or technical debt might be in our way to getting to where we want to go. Because the method that I hear all the time of like, oh, well, product managers shouldn't be involved in solutioning because we just have to make sure that we prioritize the right things. Well, if we're prioritizing the right things, but they take an extraordinarily amount of time to actually go and develop, then are they really the right things? And are we really doing our job to make sure that we're prioritizing the right outcomes with the constraints we have on timelines? That's the thought process that I really wanted to challenge in that chapter and make sure that we're actually having productive conversations versus throwing like, a requirements document over the wall.
JJ: That is such an important point and it just drives home the importance of real collaboration within product management and not just handoffs. I see that a lot where we collaborate during a hand off, right, during a work stream, hand off if you will, but not truly collaborate across the entire problem to solution space. And I think that's a really important point you make that the more we can involve all of our partners development, UX design, et cetera, from the beginning or at least from an earlier stage and have them understand what's going on with the customer, they can not only design better solutions, but conversely, we need to be involved in some way to make sure that we are not creating tech debt or that it's not a solution that is going to add a new burden.
So I think that's a really important point and just kind of illuminates the importance of real relationships and real collaboration across our groups because you can't really do great product management the way that at least when I started product management it was done and it didn't mean that we weren't successful in some cases, but we really did kind of have a throw it over the wall, right, kind of here's your product requirements document and come back to me when you're done kind of mentality and it wasn't intentional, it was just we thought that's how it's supposed to be done and we've grown so much since then, but we still have this problem of really collaborating well and taking advantage of everybody's strength.
JOHN: Totally. And I think there's a lot of very prescriptive methods of how to do discovery collaboratively as a team. And like everything else in product, it depends. Right. What works best for your given context, to make sure that to the point of context that everyone has it. Right. Because when everyone has the right context, like you said earlier, from the problem space and kind of that generative discovery down to, okay, this has been prioritized because early on we've had those conversations around constraints, and we're not waiting for Dev planning for the next sprint to uncover what those constraints are and have to pump the brakes on everything because we're flushing out those conversations earlier. We're actually increasing velocity by having a couple more meetings a month maybe to make sure that we avoid some of those. Gotchas.
JJ: Yeah, absolutely. So speaking of teams and all of the teamwork that goes along with product management, the next one is never assume your team feels appreciated. Talk to me about that one.
JOHN: Yeah, we're all people. Right. And I think at the end of the day, whether we're introverts or extroverts, we all like to feel like we're doing a good job and we all like to be recognized. I do break down some nuance from some great advice that I have from some of the wonderful women that I interviewed for that chapter around how different people have different styles of how they prefer being recognized. And we have to be cognizant of that. But we all want to be recognized in some way for the work that we're doing. Right. We're not robots. We're not cogs in a wheel. We are human beings who have thoughts and feelings, and we have to recognize that at work. Right. And so taking the time to really step back and understand that, yes, to some level, this is our job. But, man, they're kicking butt at this job and they're really invested, and I'm going to let other people know about that. It goes a long way for team morale, for company morale. And it's surprising how when people have done that to me, how much of a lift that gives me.
But also it's contagious throughout the organization when people appreciate one another, like from Bottoms Up, you start shifting that culture from like, oh, I'm just going to punch the clock today, even though, like, salary work, it's not really punching the clock. But you get that same kind of like manufacturing mentality whenever you don't feel that appreciation at work. But whenever you start showing it to others, it catches on and other people start doing it as well, because I don't know, there's something about that that just becomes very sticky and contagious with people.
That may be one of my favorite chapters of your book. I don't know that it's the most important maybe there's no real ranking importance of these assumptions, but it to me feels like the kind of bedrock of successful product management. Right. I write in my book some line and I should know it since I wrote it. But it's something like I've yet to see a really successful team exist in a toxic or in a less than optimal environment. Right. At least for the long term. People who feel appreciated, people who are happy, people who feel respected and who enjoy what they do. That is such an important part of successful careers, but also successful teams, successful products. Right. I just think it's such an important part.
So I love that chapter of your book and the fact that you bring that out because, yes, there's a lot of processes and models and judgment and all of these things that we have to do as product management, but as product managers. But we're humans. And I love that you say it that way, that we're humans, we're people, we all want to do a great job. We all want to feel appreciated. And if we can approach our job and our situation in a way where we don't take things for granted and don't assume that they feel appreciated, I told them a year ago that we would want to be treated that way. And so if we can do the same for our teammates, I love that. I think that's a really important point. And one of my favorite parts of your book.
So just to finish off the last one. On its surface, when I saw it, I was like, oh, goodness, brings us down a peg for what we were just talking about. But then I think it's really makes a great point. So talk to me about this next one. Never assume you're doing a good job.
JOHN: Yeah, it does seem like kind of a mood kill towards the end, doesn't it? Well, I think it's important. Right, because as product managers, we should thrive on feedback. And in the same way that we're giving a form of feedback to our peers or our cross functional partners, making sure our teams feel appreciated, we can't assume that our own work is appreciated. And there's a lot of great people who do a lot of great work that are heads down and just getting stuff done. And sometimes it goes unrecognized and we're sitting there scratching our heads thinking, well, do I need to self promote more?
Or, like, how do I get recognized for my work? And so kind of going back to the previous chapter, like, putting it back on ourselves is like we want recognition. Right. And I think there's some really healthy ways to go about making sure that we're going down the right path, because every company culture is different. The expectation from one leader to another might be different. And so we can't assume that the same expectations from one company or one position we had are the same now that we're in a different company or a different position. And so in that chapter, I just walk through some advice of right, when you're starting out, try to understand what are the expectations of the organization like, what is the culture of the organization from performance to communication?
Because all those things make a difference. It's not just about what you produce with your team, but it's also about those interpersonal relationships, how well you work across departments. And in the same way that that constant feedback loop from our customers or our users helps us improve our product, that same constant feedback loop from our boss or our peers or our cross functional partners that helps us get better at our craft and get better at working throughout our organization. And so that's the real thing that I wanted the reader to take away from that chapter is don't reduce feedback loops to your product alone. Treat your career like a product and put those same feedback loops in place to improve upon yourself. Because we all have blind spots. And so the more we get feedback from others around our blind spots, the more that we grow professionally and as a person.
JJ: Yeah, great advice. I love this conversation. Tell the listeners where they can get the book.
JOHN: It's available on Amazon, it's available on Kindle or a paperback, and an audiobook will be coming soon. So stay tuned if you like listening.
JJ: Awesome. Great. And we'll link to that on Productvoices.com. John Fontenot, author of Never Assume: Ten Fatal Assumptions Great Product Managers Never Make. Thank you for joining me.
JOHN: Yeah. Thank you for having me.
JJ: And thank you for joining us on Product Voices. Hope to see you on the next episode.
Resources
Connect with John
Ask a Question