Listen:
Check out all episodes on the My Favorite Mistake main page.
My guest for Episode #96 of the My Favorite Mistake podcast is Melissa Perri.
She is the author of the book Escaping the Build Trap: How Effective Product Management Creates Real Value.
Melissa does many things, including hosting the podcast Product Thinking with Melissa Perri. She is Founder & CEO of Produx Labs. Melissa created the online school Product Institute, where she has shared her scientific approach to Product Management with over 3500 students. She also started a program called the CPO Accelerator.
In 2019, Melissa was appointed to the faculty of Harvard Business School to teach Product Management in the MBA program.
Melissa is a highly sought-after keynote speaker, having addressed audiences in over 35 countries. She has a B.S. in Operations Research and Information Engineering from Cornell University.
In today's episode, Melissa shares her “favorite mistake” story related to working for a software company, where they produced a big requirements document and then built software that, basically, nobody wanted to use. People SAY they’ll use it, but really??
Questions and Topics:
- How do we know if it’s a great startup idea?
- The Highest Paid Person's Opinion?
- Risk of creating smaller batches but not being open to experiments not working out
- *MVP – minimum viable product
- Delegating the things you’re really good at
- Didn’t listen to gut over advice, warring with herself for years
- “Experiment theatre”
- What is “The Build Trap”?
- As a consultant, have to be careful not naming names when presenting on stage or doing podcasts… everyone’s on a journey
- Product management mistakes?
- Is the problem the product managers or the company?
Find Melissa on:
Watch the Full Episode:
Quotes:
Subscribe, Follow, Support, Rate, and Review!
Please follow, rate, and review via Apple Podcasts or Podchaser or your favorite app — that helps others find this content and you'll be sure to get future episodes as they are released weekly. You can also become a financial supporter of the show through Anchor.fm.
You can now sign up to get new episodes via email, to make sure you don't miss an episode.
This podcast is part of the Lean Communicators network.
Other Ways to Subscribe or Follow — Apps & Email
Software Product Manager Melissa Perri Got Stuck In The “Build Trap”
This is episode 96 with Melissa Perri, author of the book, Escaping the Build Trap: How Effective Product Management Creates Real Value.
—
In this episode, our guest is Melissa Perri. She's the Founder and CEO of Produx Labs. She's a Senior Lecturer at the Harvard Business School where she teaches Product Management. She's also the Founder and Lead Instructor of Product Institute. Before I tell you a little bit more about Melissa, we’ll welcome her. Melissa, thanks for being here.
Thanks for having me.
I'm going to tell you more about Melissa. She has a book called Escaping the Build Trap: How Effective Product Management Creates Real Value. That's something we're going to be able to dig into in this episode. She has a podcast called Product Thinking with Melissa Perri.
That's all accurate. Those are all the things I do. There's one more thing to add on there. I run a program called CPO Accelerator for VPs of products to learn how to take the leap into the executive suite. That's the last thing on my very long list of things that I do but that's fairly new. We've run three sessions so far. I'm excited because one of our participants from our January 2021 cohort was a VPO product at our company. It went through a giant merger with a huge growth-stage company in London. She was named Chief Product Officer. I'm very excited that it's working.
I'm sure it's going to continue working. I hope people will check that out. Melissa is a highly sought-after keynote speaker. She has addressed audiences in over 35 countries. I first learned about who you were at Lean Startup Week Conference where I saw you speak.
It was one of the Lean Startup Conferences. That's where we were the last time. Also, in the Lean Toyota Kata type of stuff and the Lean Kanban world, we were floating around there too. I've been following you on Twitter for quite a while.
Likewise. I'm on the periphery of some of those worlds that are more of your core professional home base.
The Toyota Lean stuff, I float in and out but it's cool to see it applied to so many different industries.
We do have a little bit of overlap educationally. Melissa has a Bachelor's in Operations Research and Information Engineering from Cornell University, which is close enough to my field of Industrial Engineering. There's a lot of overlap there as well.
They changed the name of it from Industrial to Information Engineering while I was at Cornell. I was like, “What does that mean?” They were like, “We don't know but we're going to change the name.”
It does sound more modern. Industrial does have a dusty perception.
I don't know anything. It didn't concentrate on the Industrial Engineering part. If you asked me about that, I don't think I would be able to answer any questions.
Even the professional association changed its name from the Institute of Industrial Engineers to the Institute of Industrial and Systems Engineers, which might be as vague but more modern. Before we talk about your book and other work, the diving as we normally do here, looking back at your work and the different things you've done, what is your favorite mistake?
My favorite mistake set me on the path that I'm on. When I was a Product Manager at OpenSky, which was the first startup that I joined, I was employee number 35. We were an eCommerce startup in New York City. I came in there as a product manager and I had been doing product management at very large companies before like banks and financial companies that all operate in what we call Waterfall Way. Back then, I was taught, “This is the way you do your job.” I was like, “Cool.”
[bctt tweet=”I think my favorite mistake set me on the path that I am on now.” via=”no”]
The CTO I had previously worked for a couple of years prior was the one who brought me in. He had left a big company, went for the startup and then said, “I need you to come in and do what you were doing for me there here. We need some rigor and process. I need you to write specification documents. Dive in and get going.” I did. I walked in and was like, “I can do this. Let's start spec-ing everything out.” We write these long specification documents. We shipped them off to the engineers and waited to see what would happen if they would build them.
I remember the first time I did and a few weeks later, they were like, “It's ready for you to QA.” I went in there, started looking at the product and it was nothing that I specified at all. I was like, “Where did you get this from? Did you make it up?” That's when I realized what I was doing was not going to work here. The engineers were like, “I'm not going to read a 30-page document. I'm used to making open-source products and doing fun engineering stuff. Why am l going to read this?”
That's when I first got introduced to Agile. One of the guys on the team, after me and the whole team been butting heads for a good three months of me trying to force them to read things. They were like, “No.” He was like, “Let's try this thing called Agile. I'm an Agile coach.” He was a software engineer for us. It wasn't like he was hired to be an Agile coach. He happened to be certified in it and we're like, “We'll try whatever because we all hate each other. Let's fix this.”
We ended up learning some basic scrum. We started talking about what we were doing instead of me going off in a corner, writing a big specification document and coming back. We found that lightweight process in the meetings that we spent together and it helped so much. We got it down to where I'd write a one-pager and then spec everything out in user stories. We started cruising as a team after that. A few years later, we were so effective and operating crazily well. I was pretty excited about that.
The biggest mistake I had been making came through a realization when we started to measure the success of our product. I loved my team and hanging out with the guys. We all got along so well and we were effective in building lots of stuff. We kept getting harder projects thrown at us. We had scaled the company. I came in at employee 35. We had 150 people. We were nearing 200 people in 2021. There are tons of traffic coming to the site. We're raising a lot of money and scaling pretty fast.
We had this one project that the CEO gave us where he said, “To keep scaling, we can't hire millions of people to service our customers.” We had these curators on our site who would pick out the products that we would sell. He's like, “We have no way except calling them on the phone to work with them. We need to start automating this and build these dashboards and stuff for them.”
We got handed the task of figuring out how to do that. How do we build a system where these curators can pick out the products, manage their businesses and see everything? You can think of it as people had stores like Etsy but we did all of the sourcing of it and the selling. We needed somebody to pick out those products.
I went out and mocked everything up. We made it nice and then we broke it down into our Agile sprints. We spent a long time. We had gone out and asked the curators, “What do you want to see?” I started taking a list of requirements. We started using our Agile process to break it down, put it out there and build it. A few months later, we were ready to do a big splashy launch. We emailed everybody and it was the first time that we ever used analytics on anything. It wasn't a thing back then. This is several years ago.
We put Google Analytics on the product and told all the curators about it. They were like, “That's so cool. It sounds great. Fantastic.” I started monitoring Google Analytics and I found that on the first day, we got a bunch of people logged in. On the second day, a couple of people logged in. On the third day, nobody logged in. A week later, nobody logged in. A month later, there are crickets. I'm like, “What's going on? Why are people not using our product? What's happening here?”
I started contacting them, especially the ones I took the requirements from. I said, “You told me you wanted us to build this stuff. What's going on?” They were like, “Yes. In hindsight, none of that's necessary. It's what I thought I wanted but it's not what I needed. I told you I wanted to see all these complicated financials of all the products we sell but I don't care. All I care about is profit. I can't find profit because you buried it on the page somewhere.” It's that type of stuff.
It made me go, “We spent all this time building this stuff and never stopped to think if was it the right thing to build. Is it going to satisfy their problems?” That got me onto this journey of figuring out how we do that better. I ended up going to a Lean Startup Machine workshop over the weekend. My boss was like, “If you want to give up your weekend and go to this workshop, go for it.” Two of the developers had gone a few months before in New York and they were like, “It's fantastic, Melissa. You're going to love it.” I was like, “That's cool. I'll try anything. I want to go see what it's like.”
At the Lean Start Machine workshop, we started learning about experimentation and treating building products like a scientific formula. Coming from an engineering background, I was like, “This is my jam. This is how my brain thinks.” I was very excited about that. I was eating this up. We were building startup ideas. I've never been to have any great startup ideas but I looked at it and I was like, “I could use this process to prove out our products and features that we're building at OpenSky.”
I went back and was like, “Can I start doing this?” My boss was like, “Go for it. Run some experimentation.” We had a great CEO who was super visionary and he had a million ideas. I was like, “I can test the ideas. Can I go out?” Everybody was super supportive about it. They were like, “Do it.” I started doing it and getting the data. I was able to start proving, “This is what we should be doing versus what we should not be doing.”
I remember the first idea I pseudo-killed came from the CEO. We tested it, ran experiments and found that it did not get the money or the revenue that we thought it would. I didn't know this at the time. My old VP of product told me this a few years ago and it blew my mind. He is leaving the company and he was like, “I was cleaning out my inbox and I found the results of those experiments you ran back in the day. Look at the chain discussion that this started. It ended up being the catalyst that pivoted our entire company into what it is.”
I was like, “I didn't realize how much meaning those things had at the time for that company in particular,” but I saw how powerful it was to have that concept of all our product ideas should be tested. An idea is just an idea. It doesn't matter unless it's going to get you some value at the end of the day. During that big three-month-long project and putting it out there was my big mistake that started the catalyst of what I do.
Once I ran those experiments, the same boss was like, “You need to show other people how you do this. I don't know any product managers who run these types of experiments or do these types of stuff. You should teach this stuff.” He was the one who pushed me to go teach it. I started on Skillshare and did workshops on it. I then ended up building Product Institute and started helping all these companies but it was the path that started all the stuff that I do.
Going back to the first part of the story about having the big specification documents, I was involved in a startup software company in 2001 and 2002 timeframe. You're right. There were these big documents. We had a product manager taking input from sales, customers and everybody and writing these huge documents. To be fair to you, it's not like that was uniquely your mistake. That was an industry mistake. That was the norm at the time.
I still think that it is the norm in a lot of places. We get very attached to our ideas. This is why I'm still in business. There are tons of companies that are still figuring this out. As humans, we're subject to so much bias that we're attached to our ideas. We come up with something cool and we're like, “We have to build it.” We're fighting against that. Product management is a nascent discipline. There have been product managers out there for a very long time. Some people have been in this business for many years, especially if they're coming out of Silicon Valley.
As a whole, what's happening is we're having a lot more companies starting to adopt software and thus, starting to get product management for the first time. It's becoming a more prevalent role but we don't have enough people out there who have been doing it for so long that they're very well-versed in these different techniques. It still is a maturing industry. Companies are still trying to understand how it works. It's still out there but back in the day, that's how we were all taught to do it.
At least you recognize, “This is too risky to do this big huge batch and not communicate back and forth. There's the risk of misunderstanding and miscommunications in going off and doing our thing.” It seems like there are two pieces here that lead to this more experimental Lean Startup-type approach. One is the idea of smaller batches, tighter collaboration and shorter cycles. The second thing is being open to the idea of like, “We might be wrong.” It seems people could adopt the first small batches but then stubbornly keep moving forward, even if the data and analytics say, “That wasn't a good idea.”
I see that all the time. I've worked with tons of large companies who are trying to transform into an Agile company and the second thing that they do is, “We want to be a Lean product-focused company.” That's usually where I came in in the past. We still do a lot of training around that. I don't get super deep on the consulting pieces with large companies anymore but I used to go in and coach these teams.
I worked with a lot of teams trying to adopt these Lean Startup-type principles and the small batches, which are more Lean. I would train the teams and teach them how to do it and how to do MVPs. They would prove it was a bad idea or there was no strategy that aligned everything at the top of the company. They were experimenting to experiment. We'd bring that to management and they would say, “I don't care. Build it.” It's interesting because there's only so much process you can teach people if the culture doesn't change as well. It is that willingness to be wrong and say, “This might change the way that we work or the things that we produce.”
For those who don't know, the term MVP is Minimum Viable Product. It comes from the Lean Startup space. Let’s say we're doing process improvement in hospitals. When you do small batches or changes, those are incredibly helpful. Test a process on a small scale because you might be wrong. Instead of saying, “I have this idea. I know it's right.” We're going to roll it out through the whole hospital and spend a ton of money. It's the same risk as the big batch specification document.
When it's a larger test of change, it becomes scarier, more embarrassing and humbling for someone to say, “We took this big swing and it was wrong,” as opposed to the small test of change. You were talking about an example there of a CEO having an idea. The acronym HiPPO, the Highest Paid Person's Opinion can't be wrong. That's politically risky when the analytics are pointing out that the CEO's pet project or idea isn't panning out. Any thoughts on how to address that conundrum?
I had this conversation right before I jumped on with you. She's the first product manager in a startup. It's founder-led. The founder was the CEO and the first product person. She's taking that over. That's an issue I hear from a lot of people. It's like, “How do I work with this person? They have a million ideas but I can't keep up with them all.” I explained to people, “No matter where the ideas come from, your job as a product manager is to help provide structure around it and talk about the pros and cons of doing those ideas. Your job is not to dismiss every idea that comes your way.”
Every idea is a good idea but that's it. That's where it ends. It's a good idea but is it good in execution? That's what we have to figure out. I tell people, especially when you have a CEO coming to you with an idea, your response should be, “That sounds fantastic. Cool. What a great idea. I'm going to go do my job, which is to run some numbers on that and then I'm going to come back to you with a plan.” Before you run off, you say, “It's a great idea. What do you expect to happen when we build this? Will it increase revenue? Will it stop churn? Will it get us new market share or anything like that?”
You take that and experiment around it. You then come back and tell them, “We ran some of the experiments around it and found that this is as much as we could get from that. Is that good for you?” You put the ball back in their court. “Is that something that you're willing to go after?” If they say yes, you'd be like, “This is how it changes our current roadmap. Are you willing to sacrifice X, Y and Z on our current roadmap to go after those things or would you prefer us to finish what we're working on?” It's all about presenting trade-offs and risks and helping people make decisions. It's not necessarily about making all the decisions yourself.
That's risky when data butts up against HiPPO. You've touched on this and I've run across this. There are what people say they want to do with software and there are what people say they're going to buy but one thing that tests powerful about the Lean Startup methodology and we can relate this to other areas is trust but verify. People say they want to do that but how do you go test that for real? They say they're going to buy it versus they punch in their credit card numbers. That's two very different things. I've seen two different times for several years where people in healthcare organizations say they want to collaborate and share improvement ideas, not just within their organization but across organizational boundaries but then they don't do it.
It's a matter of not figuring out the execution or am I going to stop believing people when they say, “We want a website so I can share ideas and people outside my organization can access.” There are so many reasons like legal and embarrassment. Sharing process improvement ideas in a way is highlighting something that wasn't ideal. When it comes down to it, they're like, “I don't want to type that into some system. That's going to make me look bad.” It breaks down in practice. That's one of my experiences with something like that.
I see that a lot too in the product. A lot of it comes down to the culture as well of an organization. On my podcast, I talk to Gib Biddle about how they do learning at Netflix. A lot of what Netflix does is so characterized by tons of experimentation. When we were talking, he said, “We had to all be willing to look at those numbers and say we shouldn't do that. It's because we all had the best interest of the company at heart. Even our CEO, it wasn't about him. It was about building the company. We were willing to make the hard decisions if they weren't the right decisions, even if they bruised people's egos.”
That's the culture you need in any organization to be able to introduce experimentation. You have to have the ability to look at everything. When I talked about the product managers showing the CEO stuff and letting them make the choice, it's great to do with a difficult CEO. When it's touchy or you're worried about hurting somebody's feelings, that's what you do. In a good organization, hopefully, the product manager could come back and say, “We shouldn't do this,” and be respected for that opinion. The CEO might say, “I have reasons why we need to.” That's fine.
I feel like in some organizations, it's not safe to kill the ideas or say that's a bad decision, especially when it's with management, even if you have all the data in the world to prove it. Those organizations will struggle with anything like this. They're going to struggle to build great products because you can't talk about building great products there. You can't have the conversations that you need to have to say, “Are we all moving towards our goals?” You're worried about stepping on people's toes.
There's this catch-22 where engineers or entrepreneurs might want to be data-driven but then we're also trying to be optimistic or why else would you start a company or launch a product? When you get to day three and that story you were describing the big launch, maybe people logged in once and never came back. Maybe that's what was happening and then it trailed down to day three, nobody logging in.
How many days of nobody logging in do you have to go through before you say, “Maybe we should pull the plug on this,” versus the optimist who says, “We haven't figured it out yet. We need more time. We need to promote it better,” and all the defensive/optimistic responses start coming in. There's an art to evaluating an experiment of when do you say, “Pull the plug on this. We need to pivot,” versus refinement of it.
It's huge art and hard to do. In another team that I was working with, we were experimenting because that's what the leadership wanted them to do. When I'm coaching this team, they're like, “Run experiments.” It was around the conversion rate. We were changing a million different things on the site and nothing was changing. Everybody was like, “It's because we don't have the right idea yet so try this promotion or that.” Nobody wanted to stop and say, “It's because we don't know what the problem is. We don't know why people aren't signing up or buying.”
Stop throwing solutions out there. That's good Lean problem-solving to say, “What's the problem?”
It's getting to the root of it. I got caught up in it too. It's like, “We could test all these ideas.” You can test a million ideas. You can run experimentation. I call it experimentation theater because that's not the only company I've seen that does that. “As long as we're running experiments, we'll be fine,” but they're not doing the first thing, which is to get to the root of the problem and then run experiments around the different solutions. They experiment to check a box like, “We have an experimentation in our team.” I don't think experimentation is easy to do well.
[bctt tweet=”I call it “experimentation theater” because they’re not actually doing the first thing, which is getting to the root of the problem, and then running experiments around the different solutions.” via=”no”]
One of the things that I do is teach people the Product Kata, which is Toyota Kata but how do you apply an experiment around products? One of the things that I do see junior product managers do, which I didn't expect was try to fill up as many rows as possible in the different experimentations. I'll pop it into a Google sheet for them and let them go through the process of running through the Kata defining, “What's the problem we're solving? What do we need to learn next? How are we going to learn it? What's the experiment we're going to run to do that? What did we learn,” and then reflecting on it. Each one of those will be a row.
I've walked into some teams where they'll have 250 rows for the last 3 weeks. I was like, “How many experiments did you run?” The question is also like, “Why did you run 250 experiments? What were you trying to learn here?” The big issue is they don't stop and get to that problem that we were talking about. The other issue too is that we judge people for success based on these outputs rather than the outcomes.
The overall company's success or the project's success eventually will get judged by an outcome. If you launch a product that doesn't do anything for 5 years, eventually that product will get shut down, revamped or something but 5 years is too long to wait to analyze that. We're not getting that feedback loops faster but that's because we're focusing on measuring the success of our teams by how much they do put out.
I have seen teams get rewarded for running 50 experiments. I had 1 team that had a goal of running 50 experiments a quarter and I was like, “Why should they run 50 experiments? What are you experimenting around?” It's not a good goal because it's not getting to those outcomes but it's so much easier to measure outputs, those velocity metrics we talk about like how many experiments did you run or anything like that than it is to measure the outcomes because that requires a lot more analysis and a lot more digging and we get comfortable with that.
I see a lot of that in different settings what you're describing as experiment theater. I see or hear about some organizations that say, “In the Lean framework, we're doing A3 problem-solving.” They're being measured on how many A3s like how many of the templates they fill out, which can be problematic. That's activity or output versus outcomes or impact.
Even worse is when they're going through the motions of the A3 should be framed as an experiment. Make sure we understand the problem, the current state and root causes, then start talking about potential countermeasures that we test experimentally. The A3 theater would be when someone says, “I know what the solution is so I'm going to go through the motions and fill out the form in a way that works backward to my pre-ordained solution.”
What's the point? Do we expect that that's going to lead to better outcomes than a more rigorous authentic use of the methodology? It goes to show that you can have some tools but without the mindset or the culture, it might not work the same as it would at Toyota or some great software development house.
That gets back to what you're talking about. All of this comes down to culture. Do we understand as a company what our goals are? Are we all bought into reaching those goals instead of personal pet projects? Are we all willing to sit here and emit that we are wrong at certain points? We made our favorite mistake. That culture needs to be in place before any of this could work.
[bctt tweet=”Instead of personal pet projects, are we all willing to sit here and admit that we are wrong at certain points?” via=”no”]
My passion for trying to develop that culture is one of my reasons for doing this show, normalizing and exploring the idea of there are a lot of good hypotheses or plausible hypotheses that don't work out in practice. That's a long way of saying mistake. That's one type of mistake. Maybe not the worst mistake. I want to touch on a couple of other things before we have to wrap up here. One is to tell us a little bit about the book, the Build Trap. You've alluded to some of what is behind that title but what do you mean by the Build Trap? What's the nutshell summary of that?
It is what we were doing before I started measuring our success. I see a lot of other companies get into it like we had talked about. It is how we learned how to do waterfall product management and how companies typically operate. You keep building but never stop to think, “Is that the right thing to build? How does this relate to our goals? How do we make sure we're on the right path,” before you commit to going down those paths. That's why I wrote the book.
I saw it in a ton of companies after OpenSky. I saw a lot of people struggling to get out of it. I get tons of questions about how to set up good product management to get out of it every single day. That was the impetus for writing the book. It's about how you set up a whole product management organization that will get you out of the build trap that creates and test the strategy, figures out what's the right thing to build and operates on that process. It then sets up an infrastructure to scale that decision-making across the organization.
It's a trap because it sounds good but it's not. A good trap draws people in for some reason.
It's comfortable. It is hard to get out of this trap. A lot of companies that I talk to are like, “Tell me all these super successful transformation stories of companies who've gotten out of this.” I've asked all my friends as well. There are a couple of good transformation stories out there but I don't know if any company is doing it 100% perfectly all the time.
There are companies that generally do it most of the time. They have a culture of learning. They have executives and teams that question their ideas and create strategies. They're following this path most of the time but I do think maybe, every once in a while, they do admit like, “We do get stuck in that and then we have to pull ourselves back out.” It's a slippery slope.
Toyota people admit they're not perfect when it comes to different principles or standards that we would look to Toyota for. We shouldn't put any organization on so much of a pedestal. They didn't uphold that principle 100% of the time. They're human and a company is made of humans. Well-managed companies with a strong culture maybe help avoid some of these pitfalls but every company backslides.
I've heard stories that way about Toyota when you think of discipline around process and standard work. There have been at least a couple of times I've heard stories from Toyota people and they've talked about this publicly like, “We lost some of our discipline. We needed to go back in and take a closer look at our standard work.” In a way, maybe that's reassuring to people so it doesn't set the bar so high. You can struggle and make some mistakes but learning from it, getting past it and getting better is maybe a more realistic thing to do.
It's about the exception versus the rule. If you are generally doing the things that you should be doing, great. If you have a couple of instances where you decided not to follow them or something happened, you're human so it's natural. A lot of companies end up in that situation but you're right, it's about learning it.
I have people who read my book and sometimes be like, “Do I have to do this all the time? Am I not a product-led company if I don't check every single box in this book?” I'm like, “No. Do you produce great products that your customers love? If the answer is yes, you made a scalable business, the business is thriving and people love your product, congratulations. I don't care if you don't do the product ops exactly how I describe it in the book. I don't care if you don't have a product strategy that matches the framework that I decided to teach you. You did well. Good job.”
Eric Ries to his credit is not certifying companies as, “I'm a certified Lean Startup.” He would scoff at that whole idea. To his credit, there would be money to be made in certifying startups. For somebody reading this, please don't do that. Eric trademarked the phrase The Lean Startup maybe to head off that exact thing there. I may have fallen into this trap myself. I've mentioned Toyota and I'm passing along things that I've heard from former Toyota people. I'm not trying to throw them under the bus but we have to be careful, whether we're giving speeches on stage or podcasting like, “Something's recorded and out there forever.” I'm not throwing Melissa under the bus here. She knew I was good to bring this up but this conversation here is version 2.0. Can I ask you to describe what happened?
It was super fresh in my mind, an experience I went through. I was telling a story about a mistake that I made that I was trying to learn from. I've been reflecting on it a lot. It was good to process it and talk about it but I did name some names and reflected on it after listening and said, “I don't feel good about that because the way I portrayed it came off negative.” I don't think it was a negative experience but the way I talked about it and I named some names made it sound like a negative experience.
I was like, “I don't want to represent it that way.” I learned this much earlier on. I was doing a conference once and this was a long time ago. I didn't name-drop a client but I described a client in there and they saw themselves in the description and they ended up watching it as hopefully, your clients watch your stuff. They said, “We don't feel good about how you portrayed us in it. We know that you didn't name our name but I'm worried that people at our company will watch it and feel disheartened because you described our journey and we are struggling but I want people to try.”
That made me reflect on that and say, “Everybody's going through a change. Especially in our line of work, a lot of people are going through these transformations.” It's fantastic when you could tell a story about how we made a crazy mistake and we learned from it and had a beautiful shining silver lining afterwards. You got to give those mistakes a chance to be learned from before you can go bashing them. It's easy to get into a habit of being like, “Look at all this negative stuff that people do,” and make fun of it a little bit. It provides some fun commentary but at the same time, you have to allow people to process that, change and get better from it.
Most of the companies that I have worked with have so I reflect on that a lot. I did end up going back and having that edited out of the talk and everything because I realized I don't want to portray that company like that. This is the beginning of their journey. They're going to learn and they have learned. I keep in touch with them and they're doing fantastic. They're doing great. They got out of some bad habits but everybody deserves some change process. That's why we took a step back and redid this story.
I'm glad you reached out and brought that up. I was happy to redo a second episode. I'm empathetic to the situation because the younger me loved to write blog posts that would go on a rant about some organizations highlighted in the Wall Street Journal and to them Lean office means putting tape around the staplers on everybody's desk, banning family photos and saying, “You're not allowed to put a sweater on the back of your chair.” That's all nonsense and it's ridiculous. I could write a rant blog post about it but at some point, I stepped back and reflected a little bit on it.
Getting it off my chest and allowing some readers who are in the know to also feel superior by reading and looking down on this other company. I'd like to think I'd do a lot less of that. I wrote a book with a bunch of other authors called Practicing Lean, which was from the spirit of everyone's journey. When I was early in my journey, I did things that the older me might have written a rant blog post about. It's having other people share their stories about the mistakes they've made early in their careers.
Also, as a continual reminder to myself to try to be a little bit kinder. When people are trying, they're well-intended and hopefully, they're learning things like when their employees start pushing back and saying, “That's BS that I can't have a family photo on the desk.” That's my view on that. That's why I appreciate that we could at least have some of that discussion about being careful about naming names and sharing examples with what's the spirit or the context. This has been beating myself up for mistakes but no, that's not the name of the show. I'm glad we could explore that a little bit, Melissa. We talked about it before we started, “Do we pretend that never happened or could we talk about it?” I'm glad we can talk about that.
Me too.
If it was a mistake, I could have edited it out but I don't think it is.
No, we're good this time.
Our guest again has been Melissa Perri. You can learn about all the different things she does on her website, MelissaPerri.com. Her book is Escaping the Build Trap: How Effective Product Management Creates Real Value and her podcast is Product Thinking with Melissa Perri. Melissa, thank you for being a guest and for suffering through my mistakes while you reflect and share some of your favorite mistakes.
Thanks for having me.
—
Thank you again to Melissa Perri for being a great guest. To learn more about her, her book, her work and more, go to MarkGraban.com/Mistake96. As always, I want to thank you for reading. I hope this show inspires you to reflect on your mistakes and how you can learn from them or turn them into a positive. I've had readers tell me they started being more open and honest about mistakes in their work. They're trying to create a workplace culture where it's safe to speak up about problems because that leads to more improvement and better business results. If you have feedback or a story to share, you can email me at MyFavoriteMistakePodcast@Gmail.com and our website is MyFavoriteMistakePodcast.com.
Important Links
- Escaping the Build Trap: How Effective Product Management Creates Real Value.
- Produx Labs
- Product Institute
- Product Thinking with Melissa Perri – Apple Podcasts
- CPO Accelerator
- Gib Biddle – Past Episode of Product Thinking with Melissa Perri
- Practicing Lean
- MelissaPerri.com
- MyFavoriteMistakePodcast@Gmail.com
- Twitter – Melissa Perri
- LinkedIn – Melissa Perri
- https://Anchor.fm/Favorite-Mistake/Support