Why Storytelling Matters When You’re Building a Product (featuring Melissa Perri)

👀 Turn any prompt into captivating visuals in seconds with our AI-powered design generator ✨ Try Piktochart AI!

Show Notes

01:40 – Inspiration Behind ‘Escaping The Build Trap’
06:02 – Telltale Signs of Being in a Build Trap
08:24 – How Product Teams Can Get Out of a Build Trap
11:57 – Common Mistakes in a Product Roadmap
15:27 – Storytelling is Make-or-Break For Great Product Managers
21:19 – Communicating User and Customer Stories to The Organization
24:06 – Embracing The Shift From Marketing-Led to Product-Led
31:31 – How to Create Successful Onboarding For Users
33:53 – Questions From Audience

Transcript

AC (00:30):

Hi everyone. I am Ching, the CEO of Piktochart, the company that is behind The Business Storyteller Summit. I am honored to be hosting Melissa Perri for this fireside chat. Melissa is the CEO of Produx Labs, a product management consultancy, and the author of ‘Escaping The Build Trap’. I first sent her a note sometime last year and it’s quite rare for me to get in touch with an author of a book that I read, but there were just so many things that I resonated with. She believes that the key to creating great products is growing great product leaders – something that I also totally resonate with. Today, Melissa has had over 3,500 students. So one might think, what does storytelling have to do with product? It appears that it will be quite a lot of good ground for us to cover today and I’m excited to get on this chat together with Melissa. Melissa, thank you again for joining us at The Business Storyteller Summit.

MP (01:26):

Thanks for having me.

AC (01:27):

No problem. Now we would like to hear a little bit more about the story behind the book ‘Escaping The Build Trap’, especially for the audience that has not read the book yet. So what got you to write it?

MP (01:40):

Yeah, so when I started off as a product manager, I was really working in a very waterfall fashion where I was taking all the requirements and that’s how I learned how to do it. Like go get the requirements from the business team, put them into nice spec docs, figure out what we’re going to build, and then ship them off to the engineers. And as I progressed in that career, I started working at more startups. There, I started learning about things like agile and lean startup and testing your ideas, and having hypotheses beforehand. So I started doing a lot of rapid experimentation and really just embodying the whole do we know if this is the right thing to build. Let’s not take it for granted. Let’s actually think about what’s the right thing to build. For me, that made so much sense because I was like how do we know if this is even right if we’re not going to test it, if we’re not going to talk to our customers, if we’re just going to make it up internally? I saw a lot of ideas that I have made fail because of that. So I started working that way and I found a lot of really good success in it.

And once I left the company that I was working at, I went to another company and I realized that’s not common. That way of thinking about testing your ideas before you actually build it, de-risking them, trying to figure out what’s the right thing to build. A lot of companies just don’t operate that way. I ended up leaving my full-time job there and freelancing with a lot of companies and consulting with them through product management. The more and more I got pulled into it, the more I saw that this just wasn’t a common way of thinking.

That’s really what sparked ‘Escaping The Built Trap’ because I start to see this pattern with companies where they would just build, build, build, and then ship. And then never go back and actually see if it was the right thing to build. I start calling that the build trap and as soon as I said those words or described it, people were like that’s us. It started to really resonate. So for the last couple of years, I’ve been really dedicating my consulting and what I do with teams and how I teach to figuring out how to get people out of it. It started with a spark and it’s interesting because it morphed along the years. I’ve been working on this for I want to say it took me about three years to write it, but I came up with the idea about a year before that. And originally I had thought this is just because of the way that we adopt agile and scrum practices. It’s a lot of teams that don’t get product management. A lot of people coming in from the business and learning this job and scrum really just teaches you how to build the things, but they don’t teach you if you’re building the right thing, like how to actually evaluate that.

So I said, “Easy fix, let’s go in and train all the teams, teach them product management.” I started Product Institute because of that, which is an online class for product managers and I was like this is it. We just train the teams and that’s what people wanted me to get in there for. As I got more into that, I found that it’s not just that. It’s the entire structure and the way that we actually think about product management in organizations that build software. Even pure software companies get stuck in this trap. A lot of people go it’s banks, it’s companies that are older that don’t really get software. That’s really not the fact. It’s the way that we build leadership teams. It’s a way that we think about product management in these organizations that it’s both a business and technology function, and it’s not just a technology function. You see a lot of people push it into IT technology and assign it to that role there, and that’s how they get stuck in the build trap.

So it expanded from just let’s do good product management practice processes to how do we build a good product management strategy? How does that really help our business? How do we see that as a core piece of it? And then how do we build operations around that? I was leading a transformation at a company of 5,000 people when we were implementing all these different pieces to get out of the build trap and really testing it and learning myself about what was working. From there, we found that it applied to a lot of other companies. That’s kind of how the book came about how that theory came about. I think it’s all about building the right thing. How do we get out of this whole process of just building and shipping – never really measuring?

AC (05:49):

What would be some like telltale signs basically to a company that’s still ignorant and still in the build track? What would make them kind of realize that they’re actually in the build trap?

MP (06:02):

It’s really asking yourself, what is success? I go into organizations and one of the first questions I do and what I go around the organizations and ask. I go to leaders and I say, “What’s the most important thing you could be doing? How do you know that’s going to be successful when you finish it? What are you measuring?” Sometimes they have very concrete measurements, which is like we’re going to make more money, we’re going to make more of this. So I take that and then I go down the organization all the way to the teams and I ask everybody at each level the same thing to see if the stories line up.

What you typically find is that the teams are telling a different story than the leadership and they’re not really meeting in the middle. There’s no way of how do we get from A to B with this connection. So the teams will be moving nonstop. They are so busy. They are coding, they are shipping, they are doing so many things. Everybody’s panicking because they’re like we have to get this out. And you’re like, “Okay, cool. When you do get it out, how do you know it’s successful? What’s your success metrics?” And there’s usually none. There’s no like, “Hey, once we ship this from the team, it will lead to this. It’ll lead to that. And we’ll go here.” Because those things don’t line up, you can start to see that the teams are busy, but the things that they’re doing, they may not get the same results that the leadership actually wants from it. There’s usually a missing piece of strategy in the middle there. That’s definitely one of it. Just like seeing that stories are why we’re doing the things that we’re doing don’t line up, and then also the success metrics.

If you just ask people, “How do you know those be successful?” They can’t really tell you. They’ll be like when we ship it. And you’re like, “No, not how you will be successful. How do you know this product was successful?” There’s usually no measurements around there. The measurements don’t make sense.

AC (07:42):

And the next question would have been like well then how do teams get out of it? So you seem to concentrate a lot on the product managers all the way up to the chief product officer. I think in your book, you laid out lots and lots of different areas, like alignment around the roadmap and things like that.

Is there something that you could say to kind of summarize what companies need to start thinking about? You mentioned success metrics. You mentioned asking yourself how do you know whether or not you’ll be successful. Would there be something else like that would help companies to start to think about how do I even get out of this?

MP (08:24):

Yeah, I think so. The way that I break down in the book and the way that we’ve done through consulting is thinking about it in three parts. There’s strategy. So you need to understand where you’re going and how far to get there throughout the organization. The way that you fix your strategies by looking at what you want to achieve saying, “Is it really telling a great story where I understand how we’re going to get growth coming from here to there? Does that make sense all the way throughout the organization so that everybody can tell the same story up and down?

As a product manager, I know why I’m building this. I know how it contributes to the business metrics at the top. As a salesperson, the same thing as a marketing person. We’re all speaking the same language. We’re all telling that story from a strategic perspective. We’re not trying to do too many things at once. I think that’s a huge part that really gets us into the build trap is a lack of focus. We start to think that the quantity of the teachers that we build is better than the quality of the teachers. And it’s just like we can do that. We’ll just start building teams to get really big teams. And then we just give them stuff to keep them busy rather than strategically aligning them to what’s going to make a big push.

I think focusing on the strategy and making sure that it tells a story and making sure it’s cohesive. I tell the leaders that I work with in these organizations, these CEOs, they usually want to do a million things and I’m like, “You have to pick three. Pick three ways that you can grow or that you can tackle.” And that’s it. They’re like, “But we have 5,000 people.” I’m like, “Yeah but if you have 5,000 people and you give them 5,000 things at your level, that turns into a hundred thousand things that their levels. What are your three big objectives?” There should be business focuses, there should not be like feature focus. Choose those. Let’s break them down. Because I think that tells a whole organization which way we’re going. Strategy is a huge piece of it. I see strategy really make or break a lot of product teams and their ability to focus and really make a meaningful push.

The other piece of it we say is like your processes and the way that you go about validating your organization. That’s about really making sure that you’re testing your ideas. You are really questioning why you’re building what you’re building. You’re finding out what the right ideas are, and you begin discovering processes into the way that you operate. So that’s a big piece of product managers going out and saying, “I’m going to talk to customers. I’m going to learn what their problems are. I’m going to try little things, little experiments, and prototypes, and really see if it works before we commit to building this massive thing.” That’s another piece that really needs to align. You prove your strategy through experimentation like that. That goes hand in hand right there.

And then the last piece is having good operations so making sure that teams can make decisions. We always want to talk about autonomous teams. We want to talk about letting the product managers and their teams like make decisions. The only way to do that is to have a cohesive strategy, but then also have the data that they need to make decisions. So product operations is all about how do I get the data that I need, or the access to information that I need in order to make concrete decisions on a repeatable basis. That could be aggregating product data or usage data or customer insights, but it’s really about enabling the team to get what they need to be able to make decisions.

AC (11:40):

Totally. Since we talked and touched upon strategy itself, what are some common mistakes that you often see product leaders do that make them fail to kind of get buy-in on whether it’s a strategy itself about things like the product roadmap?

MP (11:57):

I think people misinterpret roadmaps. They think of them as Gantt charts like a way to layout things. I think times are definitely a component of roadmaps. So I’m not saying get rid of time, but the way that you communicate a roadmap. It’s a communication tool at the end of the day. That’s all a roadmap is. You have to have a strategy behind that communication to make it make sense, to tell that story of what’s going to happen. What I see with a lot of product leaders is that instead of focusing on how to tell the big story about how the organization gets from point A to point B and how we manifest that through our software and digital products. Instead, they start to jump into the feature-level discussions with the teams and then try to bring that back to the leadership and start to talk about it. They think of strategy as like, “First we’re going to release this feature then we’ll release that feature, and then we’ll do this” instead of, “As an organization, we want to grow our revenue 10 times in three years. We’re really making this big push. We want to double our revenue first then we want to really grow. We’re trying to get to an IPO.”

Strategy is about figuring out how are you going to do that. Are you going to grow through cross-selling products? Are you growing to grow through more acquisition channels? If you are going to do more acquisition channels, where are you going to target? People are going to do it geographically. Are you going to expand and partner with people to bring in more clients? If you’re not going to expand that way and do acquisition focus, are you going to reduce your costs? If you reduce your costs, are you going to streamline internal tools, or are you going to buy something instead of building it yourself? Or if you’re going to increase your revenue – are you going to like cross sell and upsell? Are you going to make new software products that you can get more revenue from your existing customers with? It starts at that level of conversation. And then it goes what can we do as an organization?

It’s not about building all these features. If that’s our path, then with our current digital products, with our current software strategies and services, if you have those two, how do we combine to make an offering that will move us that way? That’s the missing middle piece that’s usually not there from product leaders. I always call it the missing middle because it’s like you go into these features and it’s like tomorrow we’re gonna allow people to upload a CSV and then we’re gonna grow revenue 10 times. It’s the product leader’s responsibility to connect those dots. So instead of being down here on the release cycle of feature development, you gotta be up here at where is this product vision manifesting and how do I grow my digital products to help move the business forward. That’s really where the product leaders need to come in and focus when it comes to strategy.

AC (14:42):

Do you think storytelling is something that product managers and I’ve noticed this with really great leaders, they’re very good at connecting the dots. Like you said, getting from the high level, like strategy all the way down to something that’s more granular and connecting it like to say, “This is how that uploading CSV will help us make more money.”

Do you see storytelling to be a skill that’s quite necessary? Or would it be more like, just connect the dots, find a way to communicate that over to the different teams, and help them in terms of getting buy-in and understanding the why behind what they’re actually building? Have you seen that storytelling was actually quite crucial from that perspective?

MP (15:27):

It’s one I will say storytelling is one of the make-or-break things for great product managers. I think it’s the thing that will differentiate a great product leader from an okay product leader. It’s also the thing that I see hold people back from getting those positions that they want as chief product officers. A lot of times they’ve done the work, they know what they’re doing, but they can’t tell their story. I think every level of product management, it’s so important for storytelling. I came into an organization a couple of years ago when I led the transformation and the CTO, I asked him, “Tell me about the product managers. What are you feeling? What’s wrong? What are you seeing them not do that you’d like them to do?

And he’s like, “They are not forward-thinking. They are not like really planning out in advance. They are stuck in a reactive mode that’s going what are we doing right now?” And then he goes to the product managers and you talked to them and they’re overwhelmed with the work they’re doing, but they also don’t know how to tell that story. They’re like, “I do have a plan. I think we should be building those things.” I’m like, “Okay, this is what you should be presenting in your roadmap meetings, right? This is what you should be presenting to your leadership.” So how do we start to craft a narrative about what are the problems you’re solving, how it’s going to help achieve the goals? This is the right thing to build what we actually did so that you can go and present to leadership and they’ll feel confident in your direction.”

And I think that’s a big issue with a lot of organizations. The product managers always tell me our leadership does not trust me. They don’t trust me. They don’t give me the room to do the things I need to do. They don’t trust me. They just tell me what to do. I go to the leaders and the leaders are like, “I want them to come to me and tell me what my options are, but they’re not doing it. If they are not going to come to me and tell me what my options are, what they think we should be doing, I think they don’t know. So I’m going to tell them what to do.” That’s the whole gap in storytelling. You see this everywhere. You see this at larger organizations too with boards and executives and stuff like that.

But it starts from the product management perspective. I think it’s about telling what your strategy is, communicating it, and getting ahead of your leaders because then they can evaluate it and give you feedback rather than just dictating what to do. And then as you get up into the leadership level, it’s a similar deal. You learn those skills as a product manager and then great product managers usually make it to the leadership level because they are getting ahead. They are presenting the ideas. They are seen as more forward-thinking. They are seen as pulling that story together. I think at every level of the organization, it makes a lot of sense and it’s a critical skill for product managers.

I also think that it’s about really tailoring that story to the right audience. I see a lot of people get in front of the CEO and they’re like, “Great, I’m in front of the CEO. Fantastic. I start to talk to these people. Great.” And then they tell a story about these super nitty-gritty technical implementation details of what they’re building. And the CEO is just like snooze, right? Cause they’re like, “I don’t care about that. I care about what this means for our business. How is this going to move us forward?” And they are not connecting the dots from a story perspective on like how that CSV is going to help them increase revenues.

So that’s like tailoring your story to the right audience. I think is a huge part of being a successful product manager. I also think that it’s a skill that a lot of people would just take for granted. They’re like as long as I can do the work and work with the engineers, tell my story to the engineers, it’ll be okay. But it’s not just that. It’s about telling it to sales and marketing and CEO and customers, and like being able to tailor your story for every single person that’s out there and think about what do they care about and how can I relate my story to what they care about so that they get excited about it.

AC (19:17):

Yeah. I love, love, love that point. What you just said, that’s a critical skill set. It’s underappreciated. I think a lot of people think just the ability to crunch numbers, maybe know some parts of like how to focus on the discovery process and talk to developers and they’re done. Also in the book, I quite remember seeing the roadmaps and they are quite simple and visual. But then the idea is how do you then prop the narrative so that it’s tailored to each and every audience. I think that’s definitely the part that a lot of product managers don’t quite get, but it’s so fascinating to hear it from you.

MP (19:57):

With the roadmaps too, right? That’s a whole thing where we’re like, “Okay, let’s go build a roadmap and everybody thinks you take a chunk of time, you write a name in it. And you’re like, there it is.” But there’s so much context behind it in such a story that you have to tell. So when we build roadmaps at organizations, almost every item that’s on a roadmap has like a two-pager associated with it that explains what we’re actually doing and what’s the strategy behind it and why we’re doing it. I think connecting those things from here’s the item on a visual to here’s why we’re doing it is super important. Sometimes we just think about the act of getting it into a grid or a timeline, rather than what’s the context behind those items on the timeline.

AC (20:36):

Yeah, totally. Communicating actually in this case and with roadmaps and whatnot, there’s also the other part, which is like communicating that same with the users and the whole discovery process. I know when possible, teams should try to jump on to be on those calls, but it’s not always very easy to take all of the insights that have come out of those calls and then communicating them back towards the teams to get alignment.

How do you usually recommend getting these user stories or customer stories back to the teams?

MP (21:19):

I think it’s important to start to show people why people are doing that. What we’ve done is a technique of a combination of recording some of the interviews, cutting out the snippets that are really important so that people can see it firsthand and start to understand there. And synthesizing the insights into a narrative about here’s our customers, here’s what they experienced, here’s how we talk about it. One of the things that we would do with our user researcher, her name is Michelle at Produx Labs. For our clients, we would do deep insight sprints for them a lot. Sometimes they just don’t have enough people who know how to interview their customers. They don’t know how to take the insights and turn them into something actionable.

So if we were doing any roadmaps for our customers, Michelle would do a deep insight sprint and she lined up something like 30 customers and two weeks or three weeks depending on how many interviews done and take the snippets of the interviews that were most important to illustrate the big problem points that they would have, synthesize that into a document that was like, “Here’s your users, here’s their persona. Here’s what they care about. Here are their needs.” Now let’s drill into each need and start to talk about where people feel that was the context around it, what’s not working for them right now. She would take little tiny pieces of video, a minute or two minutes, and put them in there so you could just drill into what’s happening there. That was really powerful. Cause you’d show that to CEOs and they’d be like, “I hear it firsthand”. You showed that to developers and they’re like, “I’m watching them use something and they’re not getting. That’s why this is not working.”

I think having that firsthand story from them makes a big difference when you can see customers do it, but then also putting the context around it. So it’s not just like I had to sit through 10 hours of interviews to get this but it’s getting right to the point, showing somebody experiencing pain. I think that really resonates very well.

AC (23:11):

That’s a great tip and something that we’ve begun trying as well. When a product manager or a user researcher is in charge of integrating that data and then passing it on like you said, a lot of the context. Because they don’t hear it directly from the users. That’s a really good tip.

Now, we’re also curious about how many product managers for example struggled to convince their CEOs or the executive team to shift the focus from sales or marketing-led organization to something that’s more product-led. That’s obviously quite a big discussion. It’s like around how the design of a company almost like an organization and its strategy, but how would one best approach such a shift and they clearly see the need to start thinking from a more product-led direction?

MP (24:06):

There’s a double-edged sword to this. I’ll tell you what I advise teams to do first, and then let’s talk about should you actually do it? I get this question all the time where product managers are like, “My CEO doesn’t get it. My leadership team does get it. My sales don’t get it.” The first thing I think you can do, it’s hard to change an entire culture of an organization. Let’s just say start there. One person is not going to be able to do it as a team member. It’s going to take a big movement. It’s going to take a lot of people wanting to do it and embracing it.

One thing that I’ve seen work really, really well for people who want to start approaching this is to ask before you ship anything to your leaders to everybody, what do we think will happen when we ship this? What are we going to achieve? What business metrics will we hit? What product metrics will we hit? Like if we ship this thing, I’m not saying we won’t, we’re going to ship it. We know it’s on the roadmap. It’s halfway done. We’re going to do it. What do we think will happen? Just writing that down, getting to concrete metrics, making sure their outcomes are associated, and then ship it and see if it actually measures up. And then you have a conversation about are we building the right things?

That’s my biggest advice for anybody on a team who’s like, “This feels overwhelming. Where do we start?” Because that’s something you can’t control and then you will start a dialogue because if you don’t hit those metrics, people start to go why are we doing that? What about these other ones? Are those not going to hit the metrics too like what’s happening here? And it starts people questioning. I think that’s the best place to start. Start questioning why you’re doing the things that you’re doing, but not in an obnoxious way. Nobody can argue with just putting a metric down saying we think this will happen and write it down, walk away, and then measure it at the end of the day.

Where I see people struggle with making big pushes and changing working culture is when they start getting super demanding and not meeting people where they are. I used to be that person like I would walk into organizations and as a full-time employee and be like, “You don’t get it. You’re just not doing it right.” No CEO and no leader wants to hear that they are not doing it right. They are going to dismiss you like what do you know? So I think there’s a lot of attitude around that. I see a lot of people try to approach it that way and get very dismissive.

You have to meet people where they are. A lot of people learn how to do their job in a certain way. With a product-led organization or a product-led culture, that’s probably very different than the way that they learn to do their job so it’s uncomfortable. If you want to bring people into a place where they feel comfortable, you take small steps to start changing minds and changing attitudes and you meet them where they are. If it’s a CEO, you start talking to them about how do they know they’re going to get that much revenue. How’s the strategy really working and relating the choices that you make back to that. So helping them see that the thing you’re building might not help them get the outcomes that they want and then they’ll start listening. They will be like, “Interesting. How do we fix that?” And not come with the answers rather than a bunch of problems that you want them to fix.

I see a lot of people argue instead and say they should just fix it, but that’s not the case. If you want to lead a revolution in your organization to get people to move to this, you got to start with small little questions that make people just start to think rather than saying we’re going to blow it all up and go this way. If we’re talking about changing organizations, I always tell people there are two paths. I took the path of being a change agent and helping people to transformation. That’s a full-time job. And there’s the other path of being a product manager. So ask them, “Do you want to go and be an amazing product manager? Or do you want to be a change agent and help transform somewhere?” Because it’s hard to do both unless you’re in a leadership position. If you’re a chief product officer, that’s where you should be. That helps you do it. But if you’re a team member on a scrum team or on a development team, you can start by chipping away and asking those questions to see if you make the shift.

But when you start hitting your head against the wall and feel like you can’t do great work, I tell them maybe you should start looking for an organization that gets it a little bit more because you’re not going to be able to practice your craft of product management well in these organizations that don’t get it. And I do think there’s going to come a time in the next couple of years where there will be organizations who really get it and there’s going to be organizations who don’t. And there are today, but there’s going to be a lot more that do get it. I see a lot of leaders making the strides to really build those organizations today. There’s going to be fewer who don’t and there’s gonna be a lot more opportunities for people at the places that do. So I think about it as that path too and that’s my recommendation.

Do you really want to take on changing an organization and is the organization ready to change? Because even I can’t help organizations that aren’t ready to change. I won’t take those jobs. I say no because I’m just going to beat my head against the wall and get mad at you. It’s not worth it. But if you are ready to change and there’s reception there and you feel like you’re making progress, that’s a great place to stay because you can watch it change. But if it’s not, you’re beating your head against the wall, there are other places out there that do get it.

AC (29:24):

I love how honest and pragmatic you’re being. Because I think like some of the other advice that people might have given would be just doing your best to be that change agent. But I also think you’re totally right. Like you said, it’s a full-time job. Maybe you’re taking on organizational design or HR on a side while also running a job as a product manager, you’re not going to be good at doing both, but that’s very refreshing to hear.

MP (29:56):

It’s a wake-up call for leaders, right? If you are not listening to how people want to work, if you’re not seeing the value in this, you will lose people. I tell people that frequently when I help organizations through a transformation or coaching leaders – like you have to change if you want your people to change. I have been brought into so many organizations where the leaders are like just go fix my teams. I’m like, “No, because if they don’t see you responding and being receptive and enforcing it, backing them up, they will learn these new skills and I guarantee you they’ll go find a new job with their new skills.” It doesn’t work that way. You have to be invested as well. You have to be a part of the solution. I think that that’s a big part of it too.

AC (30:39):

I love it that you don’t just blindly say go be the change agent, be patient while waiting for the transformation, but you’re totally right. Often times I think with building a product with the philosophy or the values that are behind it, a lot of it has to do with the leadership of the company so good one.

The other question that we had was actually around onboarding because that’s a great first opportunity that the company gets to present itself like a story apart from the podcast, the website, marketing materials, etc – to tell the product story and build an emotional connection. So I wanted to hear what are some more of the most important aspects of a good onboarding, especially for a tech product or something that’s in SaaS?

MP (31:31):

Onboarding to me is such a fascinating topic and I really love products that do amazing onboarding because I’ve also worked in places that have not. And the amount of money that you spend on training people and when it’s all like a user experience, the problem is wild. So if you fix that, you’ll have a decent product and you’ll introduce people to your product. My tips for onboarding are always to meet the user where they are and help them understand what they’re trying to achieve. I honestly hate tutorials. I hate when I get into a product and they’re like this tool is over here, this tool is over there – but I don’t care about the tools. I want to accomplish a certain thing.

So how do you help your user tell their story? So they come in, what do they want to accomplish? What’s the first thing they can do? I think moving your onboarding around, helping them do that is key. I’ve worked with healthcare companies that have put people through training for weeks to get them to use their software products when a lot of times they know how to use basic tools like that. It’s just more about teaching them how to get what they need into their system. A lot of it is just user experience problems.

So here’s the thing about all of onboarding. If you need a wild training system or you have onboarding problems, it’s almost always the UX problem. It’s almost always that you are not designing your UX flows. You’re not designing the journey for the user to get into that platform in a way that they can appreciate. It’s usually too complicated to use. People don’t know how to get started and they can’t accomplish the things that they want to do. That’s almost always a design and user experience problem. Those are all fixable things. You don’t need 7,000 videos on YouTube about how to use these things. It’s about making sure that people can get in, get what they need to get done, and understand it in a human language that’s not complicated to figure out where everything is.

AC (33:53):

That’s a really helpful one to reduce as much friction as possible from a user experience perspective. Like you said, helping them to taste the success of what they came on to the platform or the app to accomplish.

I have two last bonus questions. One is from attendees and this person is a sales manager. So how can you keep clients engaged when you’re not sure whether what they want can actually be achieved by the product team?

MP (34:30):

I’d say one big thing is get the product team involved in that early. If you’re not sure the product team can do it, bring them in. What we should all be doing with sales and product in that moment is trying to figure out what is the problem that the customer has. Do we have the ability to solve it now? If not, if we build something to solve, does that align with our strategy? So if you can’t build what the customer wants and it doesn’t align with your strategy, that’s not a good customer for you. It’s not about closing every single deal. It’s about closing the deals that are right for you.

One of the biggest issues I see with SaaS companies today is that they turn almost into a software shop, where they’re building stuff with the big signs that will never apply to the other clients. That’s the biggest thing that’s going to stifle your growth. So you have to look, we call it sales debt when we start to look into the data and pull things out and you can quantify it. What’s the cost of you building almost custom software for clients that don’t align to your future strategy? Sometimes you see that those costs rack up like crazy.

I think first we have to say, is this client actually in our wheelhouse – do we want to solve the problems for them? And then if we do solve the problems for them, can they be applied to everybody else? If the answer is yes, I think we get sales and product together to start thinking through how we might do that. But you can use those potential customers as well for beta users, for alpha users, you can start to co-create with them and you can get them on board with it. I wouldn’t say like we’re gonna build this especially for you, but you want them to be a part of that and that will usually engage people.

We’ve worked with a lot of potential clients that wanted something that we had on our roadmap. Sometimes they’ll even pay to get it further up the road map. And you’re like, we’re going to do this anyway as long as it applies to other users and then you co-create with them and they are beta testers. They use it first, they give you the things and then you can expand it to everybody else. I think the hard part to get out of and this is another build trap symptom is we don’t want to sell clients and we don’t want to close clients on a software that will not apply to everybody else. That’s how you get into being a custom dev shop. Now, you’re no longer a product but a service company. That’s where all your margins get screwed up and it’s not healthy to do that. You will staple your growth.

I think it’s really stepping back and first saying is this the right problem to solve? How do we get everybody involved in that? We actually want to solve it and if not, cut the client and say, “We’re not going that direction right now. Thank you very much. We’ll reach out to you if we do in the future.”

AC (37:08):

I think it takes quite some courage for a sane person to walk away from a deal. For the product manager, I can imagine the conversation going pretty well, but for the salesperson who was like I have to say no to this deal. I think understanding what the product strategy would be could be quite helpful.

MP (37:34):

Yeah. I think a lot of companies don’t set up sales for success. It’s funny because sometimes we’ll get into a war between product and sales where it’s like product people are like I hate salespeople. Salespeople are like I hate the product. It’s like no, we’re all in the same team. Instead of rewarding people on closing every deal they possibly can, we should be rewarding people and closing the right deals that contribute more to our company and get us further along. Sometimes companies don’t incentivize that way. So I totally understand if a salesperson being scared of saying no to a customer because that’s their livelihood. That’s how they make money.

AC (38:13):

That’s a great point because the entire compensation system right now as we know it is usually based on how many deals you can get in. So it’s very understandable that they’re apprehensive about turning off the deal itself.

The other one which I know you talk about it quite extensively in the book itself. But when hiring product teams, what are some of the skillsets that you look for or that you recommend for your clients to be looking out for?

MP (38:46):

I think beyond just the roles of what can you do on a day-to-day basis as a product manager, I look for a couple of traits. I look for people who are systems thinkers, which means that you’re considering the whole. Like if I build this, how does it affect sales? If I build this, how does it affect our existing customers? How does it go into our strategy? How does it affect development? Will I have to do something with technology? You’re thinking through all the implications of your product and the impact it will have on your teams and your customers and your company. So I was looking for that skill. Can you really think through all the things that this will affect?

I also look for people who were really focusing on problems. Like they just don’t jump into solutions immediately, but also I want somebody who’s decisive as well. When somebody has enough information, even if it’s not perfect, they’re going to say we should go that way. Because I think a lot of times we can get into a trap of reviewing data and reviewing data and trying to get to a hundred percent. And you will never get to a hundred percent confidence with a lot of these things. So you need somebody who’s like focusing on the problem, not necessarily on the solution, but also can just make a decision once they have enough information to go somewhere, but being humble enough to say if it’s the wrong decision and let’s go back and change it.

I just roll a bunch of stuff into one of them. But definitely problem thinkers – people who think through problems and empathize with problems, they look for optionality and how they can actually solve those problems. So it’s not just like this is the only solution we can do. They’re like we could do this or we can do that. And then they have a way to evaluate those solutions in their heads. It doesn’t even have to be software-related. A lot of these questions I ask people who’ve never done product management before, just about the decisions they make in their own life or around certain choices. They have some kind of set way to evaluate it and then they can make a decision based on imperfect data to help move people forward if it comes down to that. I think those traits really make a big difference.

I also look for people who tell a story hands down. One of the big things that we do in our interviews is getting people to put together like if they do a take home assignment on what’s this product or how you would improve it or anything like that, it’s about how they tell the story of how they got into that decision. These are the things that I evaluated. This is who I think the customer is like. How do they put all those points down and tell something cohesive? Because to me, now I know if I give them anything in the organization, they’re going to be able to present that and tell that story to their teams and to their customers and to the leadership. That’s a big skill that I think product managers need, but maybe don’t have.

So all of these things are not necessarily about grooming a backlog and working with developers and doing product. I think if you take some of those critical thinking skillsets that we just talked about and those traits and you teach people good product management techniques of just how to go through it, a lot of them succeed. But where I see people struggle is if they don’t want to be a decisive decision-maker, they don’t want to tell the story if they’re not good at it, if that’s not what really makes them excited. If they don’t really consider optionality and think through problems, like the toolset that we have in product management, it’s very teachable. But I think that way of thinking is the part that really makes or breaks people’s success.

AC (42:06)

That’s a great point. As a visual communication company for us, apart from a couple of the things that you mentioned – being decisive. We don’t call it a systems thinker, but the ability to connect the dots and basically draw sound conclusions. Like you said, problem-focused and not totally jumping into solutions all the time and storytelling is definitely one of the things that we look out for, because I personally have seen what it does and how it changes the entire organization as well when a person is more able to help to connect the dots.

These are all great stuff, Melissa! It has been a real pleasure having you and learning so much as well from this particular session. I know and I trust that the audience also likewise would do the same. Thank you again for joining us.