The Build Trap is Product Management

Melissa Perri, Product Consultant, Speaker, and Author of the upcoming book The Build Trap, discusses how to balance getting to market quickly with validating that there’s demand for what you’re building, the importance of focusing on outcomes rather than outputs, and how to squash a poor performing feature.

Here are the highlights:

• What is “The Build Trap”? (1:59)
• How does the build trap manifest differently in startups vs large organizations? (8:30)
• How do you balance getting to market quickly with ensuring that what you’re building is necessary? (11:20)
• What are the benefits of experimentation from an ROI perspective? (22:58)

And here's the transcript:

Mike Fishbein: Hey, I'm your host, Mike Fishbein. This is Product Management, the podcast produced by Alpha. Welcome back. On this episode, I'll be speaking with Melissa Perri, product and UX consultant and author of the upcoming book, "The Build Trap". She's seen firsthand, the challenges that companies face when they continuously shift features customers don't want and how to transition into a leaner, more experiment-driven organization.

Melissa: Hi. I'm Melissa and I'm a Product Management and UX Consultant. My company's name is Produx Labs. I thought I was being clever naming it that, since it sounded like products, but everybody pronounces it Prod UX, but what am I going to do?

So, I've been working in product management for almost 10 years now. I got my start learning product management at a company called Capital IQ in Standard & Poor’s and it was a very traditional way of learning it, and since that time, I've been really focusing on how to incorporate Agile only practices into product management so that we can do it better.

I'm also both a product manager and a UX designer and lately, I found that a lot of people keep separating these things out to be two very unique topics, and I find that I'm a better product manager for being a UX designer and I'm a better UX designer for being a product manager. So it's something that I really like combing and it's a skill set I think that's really important. So I'm very passionate about keeping those things together and using a lot of UX influence in my product management teachings and skills as well.

"The Build Trap" is something that I've been ... a concept I've been working on and trying to teach to people for a while. It really stems from the fact that as product managers and as companies, when we work in product management, we tend to get married to our ideas and we start building a lot of these features, and we keep building and building and building and we're releasing features constantly. But we rarely stop and take time to measure if they're working or not, or say, “Hey is this really a good idea?” Should we really be building this?

Because I think we associate this mentality that as long as we're releasing features or new things, we're working, we're growing, when in reality that may not be the case. Customers might not want those things. They might not be using it. So, "The Build Trap" kind of teaches people what this is, and then I try to teach people and companies how to get out of this method of just building and never checking to see if people really want things.

Mike: I'm intrigued to learn more about "The Build Trap" and why so many product teams get caught in it, but first, let's learn more about Melissa's journey into product management and how she conceived the idea in the first place.

Melissa: I always wanted to go into technology since I was a very little kid. I was probably the only 11 year old running around saying I wanted to be a computer engineer when I grow up, but I had no idea what computer engineering was. I just knew about Bill Gates and my dad was like, "You should be Bill Gates when you grow up." And I said, "Fantastic. That sounds great."

But I also at a young age, around like 13 or 14, I fell in love with Photoshop and I didn't really know what to do. I studied engineering. I studied operations research, engineering at Cornell and when I graduated, you know I was trying to figure out what to do. But during Cornell too, I had the chance to work on some projects here I got to work with Kodak, kind of as a product manager, so we were in this really unique team where we were trying to come up with a new product idea for Kodak, which was really interesting.

And we actually published an article called "Market Driven innovation" and this was back in 2007, and if you back ... I went back and I read it actually two weeks ago when I realized this thing has come full circle and we basically describe the lean startup methodology in there and how do you figure out what do you want from your peers. So we did that with Kodak where we suggested that they take their unique way of ... Well, they take their really awesome cameras and put it into cell phones. Right?

So this was before the iPhone came out, so the iPhone had just released its first model, and we were still using flip phones, and everybody had been taking a lot of photos on their flip phones and we said, "We're all taking photos on our flip phones now.... Kodak, you should put a really awesome camera in a phone, because that's what we have now, so that we can take these photos more, and we also want to be able to edit them very quickly right? Nobody wants to look bad in a photo, so why don't you put some of the little Photoshop techniques in there so we can edit it quickly and release it?"

So we told it to them and they were like, "Yup, okay thanks. Bye." And a couple of years later, they went out of business. So that was my first foray into product management. We worked with them on that for two years, really diving in to use the research and talking to our peers about it. And then I learned more the traditional way of doing project management at Capital IQ.

I came in. They taught me how to do all the documentation, how to work with the developers. I was doing the full-scale mock-ups of everything that we were building, so the whole gamut on that. And I really fell in love with it there. I love trying to solve these problems and figure out how do I turn interfaces into something that will solve problems for my users. That whole marriage between the Photo design aspect of my life and the computer engineering aspect of my life really came together in this and I just loved it, and I knew that's what I wanted to do after that.

Mike: Ironically, Melissa's first foray into product management was with Kodak, a company that refused to build anything. So how did she realize the widespread problem of the build trap?

Melissa: So, the build trap ... I realized it a few years into working as a product manager. At the time, I had been working in my third job as a product manager at OpenSky and OpenSky was an eCommerce platform that took celebrities and hosted them on our platform and they could recommend to the public different products that they should buy, so for example, we'd have Martha Stewart on there and she'd be like, "These are the best baking pans. You can buy our baking pans. This is how you do muffins." We had videos that teach people how to use stuff and it was an interesting eCommerce platform to work on.

They raised a lot of money. We raised 40 million dollars while I was there. I started about six months after it started and stayed there for about two years. And when I was at OpenSky, we had been doing things just the way I learned how to do product management, very traditionally. And a lot of times our conversations about how to build features ended up being, "Oh well, you know everybody has social buttons on their platforms. We should have social buttons. Okay, Melissa go build a social button."

"Hey, we really need these tools to go share better on to Facebook" or "Hey, we really need to act like Pinterest and put favoriting tools on here. There should be a Pinterest Board on OpenSky so people can go and just save their favorite products to it." And that's how things got done. We'd look around us and we'd be like, "That's a cool idea. That's a cool idea." And we were just constantly building these things.

And at a certain point, I realized we started integrating more metrics into our platform, and I realized a lot of people weren't using these things or it wasn't making a difference, right? We couldn't feel the difference in the company for implementing these features and everybody started to get a little bit frustrated. We were like, "Why are people not using the things that we're building?" Right? So, I started studying more about lean startup and about Agile and we started implementing experimentations in there, where we really stopped and we said, "Okay, what do people want." Right? "What do they want? How can we test it?" And we started incorporating that into the platform. And it worked really well for the things that we did experiment on.

But I also realized that, while we got some buy-in for it, we also went back to our old ways pretty quickly of, "Oh we're not releasing things fast enough. Oh no, we need to make bigger pushes. We need to make bigger product things." And it was really hard war between that, between this concept of the build trap, right? This mentality that we should be constantly releasing features. And then, this experimentation, to make sure that we're releasing the right features. So, we kind of went back and forth, back and forth and then eventually that kind of build trap mentality won over the company as well, whereas where I believe that I started struggling.

Mike: Most was able to transition in real-time, from a company that built seemingly cool features on a whim, to a company that experimented with and validated features before building them. She experienced the potential promised by the lean start-up movement. How does this sentiment manifest differently amongst startups and large organizations?

Melissa: I think it's actually a huge problem for large companies. I've seen it affect tons of small startups all the time... A lot of the companies I do work with are startups kind of around Series B phase, where this is where they run into the build trap. That's usually where you see it manifest in startups when they already found product-market fit, but then now they're just loaded all up with features. That's always where they run into that problem.

But, with large companies, I think they're more subject to that because they have tons of money, right? So if you look at Google, they've got billions of dollars. If you look at any of these large corporations, Microsoft, LinkedIn, they've got a lot of money right now, which gives them this runway to build things. So, they're not going to run out of money tomorrow and they can afford to just keep building things, but eventually, somebody's going to come in there and disrupt them, right? A startup's going to do it better. It's going to do it simpler. But since they have this security blanket, they fall into this trap more often.

If you look, LinkedIn is a pretty good example of it. LinkedIn just keeps putting stuff out there into its interface and now nobody wants to use it. It's super complicated, they keep changing where the messages live, who can message you, all these new features about how you can get spam into your inbox. Nobody wants that. Everybody stopped using it. I think I talk to more people on Twitter now than I do on LinkedIn and most of the people who friend me on LinkedIn aren't even people I know.

So, it's turned into this really bloated platform with tons of useless features on it, instead of something that's actually meaningful…. I think Facebook used to be worse, building features back when it was starting to blow up, I think back in the mid 2000s. You remember they were constantly adding things like events. Different applications were on there and they were just producing a lot of new features and I think they've taken a really good turn from that lately, where they start testing things. Another one you might remember was questions. Facebook put out that questions thing that nobody used back then. But they killed it. They start to kill their things that don't work, which I think is really important for it.

But, whenever I give this talk, the build trap talk, a lot of people from large corporations come up to me from all over and from a lot of standard businesses too like newspapers or media companies and they say, "We do this all the time. We just come up with these product initiatives and we go, okay let's go build them. And we don't actually stop and take the time to experiment and figure out, is this really what we should be building?" But, they're not going to die tomorrow, because they have money.

Mike: Interestingly, Melissa argues that the build trap is the greatest risk for organizations that have the security of deep pockets. But how does falling victim to the build trap compare with building fast and breaking things? How do you balance getting to market quickly with insuring what you're building is necessary?

Melissa: I do think it's really important to balance speed with the experimentation and the results that you get, but a lot of people I think confuse speed and producing things for working, or for building a profitable product. Right? So, you see this a lot in Agile and a lot of people look at Scrum and they say, "Because we're working in Sprints, that means we release things every Sprint, but almost ... I'd say 99% of the companies I see working in Scrum ... They don't actually release those things to customers. They just release it to some staging environment that nobody will ever see. You know? And they don't get the feedback that they need to see if they're on the right path. So, I do believe that people should move fast, but breaking things is bad too.

And that's where we get to the concept of MVPs. So, minimum viable products ... Sometimes I say that to people and they look at me like I just cursed my head off. Right? They're like, "Oh, that's such a dirty word. Why would you say MVP? We don't do that here. We don't make terrible products. You don't understand. Like, this is a good company." And I'm going, "Why would you think that." Right?" That actually happened to me in the company I went to after OpenSky.

So, I was at Conductor as their lead UX designer and I said, "You know, this is a great thing that we really should do an MVP for." And as soon as I said it the whole room went silent. They were like, "No." They looked at me like I just came in and murdered people. I have never gotten that kind of response before to this either. And they said, "No. We don't break things here. Like our customers will be very unhappy if we do that." And I kind of dug into it. I was like, "Why are you being weird about this?"

And I found out somebody had read the Lean Startup the year before and built something they thought was an MVP, but really it was kind of like buttons that lead to nowhere on their site, right? And then the customers start calling up and complaining and they put it up there. They didn't measure anything. Like, they had no results to tell you if it was working and they left it up there for a long time and the customers were upset.

So they just said, "Oh no, we're never doing an MVP again." But in reality he did it wrong. Right. When you, when you do an MVP and when you do an experimentation, it has to have this level of UX on there. That is perfect for the customer, right? They need to not understand that it's an experiment. They need to understand that I'm getting value from it and if you're not delivering any value to your customer, then you're not doing an MVP right.

So there has to be minimum user experience that works, stuff functions. There has to be a feedback loop where if I do click on a button, I get a message. Somebody is telling me what's going on. Like if it doesn't go somewhere, put up a page and say, "Hey, we're still working on this. I know this is not really what you expected, but we'd love for you to be one of our first customers when it launches. Would you mind us contacting you?"

You know, you need to have this feedback loop for the customer to really understand what's going on. You can't just leave them hanging. So I see a lot of people do these MVPs wrong and when you say move fast and break things, that's what they do with MVPs, right? They just put up a bunch of stuff that doesn't work and it's broken and think that's a valid product experiment when in reality it's not.

With the ship it too, it's the same thing, like you can't just say, "Hey, this is 80% of the way there," and still have like broken stuff all over your site. That really sacrifices, you know, your user experience. What you should be doing is coming up with more minimum feature sets or just enough features on there, just enough of a product experience that delivers value to the user but doesn't break things, doesn't have terrible stuff up there that will confuse them on your experience, because then you're just sacrificing your brand.

So there needs to be this level with experimentation and getting feedback quickly, but you shouldn't be just putting out random stuff in there and just seeing what works. It has to be like a deliberate thing that you plan and test well.

Mike: Melissa has found that common objections to the lean model are due to misconceptions. So what advice does she give to companies that want to do MVPs properly? What does that process look like?

Melissa: I think if a company wants to maintain speed, they should really focus on doing experiments as fast as possible. Right? So, what I try to do to get companies I work within the habit of experimenting is saying we're going to do one-week sprints for the next couple of months, maybe the first month or second month until we find something that hits.

So we plan our sprints out and we have this goal of releasing on Friday, right? So, we're going to do it well. We're going to make sure that we chunk this down and we only put in the stories that we can actually complete, right? We're not going to make this a crazy big feature. We're going to make this a nice, small experiment that answers some of our questions. And that's what you started off with, right? When you're experimenting. A list of questions that we need answered. That's the whole point of experimenting.

So we say, what can we plan? What can we do in one week? Let's ship it, let's get feedback back and you can stretch that to two weeks if you have something a little bit larger, but I try to get them in this habit of learning as fast as possible so it's not about shipping as fast as possible. It's about learning and some of those experiments too don't even have to be shipping software.

They could be just going out and researching things, talking to customers, having the whole team, even the developers, right, on the phones, asking them questions, learning about things, researching what they're saying.

For one of my clients today, I was on Twitter looking up their competitors to see what people were saying about them, because we're trying to get as much user research as we can before we start our experiments next week. And when you go on that, you find really interesting information and it's not something that I would learn just by shipping something. It's something I still have to research.

So experiments can be anything to learn information about your customers that you will need to go into your product experience, to make a good product experience for them. So I think the more you can learn, the faster you can get that feedback, you will be maintaining tons of speed. But I know companies are also a little bit wary of that too, right? Not shipping. And I had this client last year where they really didn't have a product that they did enough user research on at first. They went off on a lot of assumptions building it. So we said we really need to take a reset. And I came in and I tried to help them, you know, reset, test some of their assumptions and learn. And we spent like a good month out there, you know, doing a lot of user experience, testing a lot of things.

And the founder got very agitated. He was like, "We haven't shipped any of the new features that we said we were going to plan this year at all," you know. "The developers aren't coating, they need to be coding." And I said, "What do you want them to code?" What features should they be building?" It'd be like, "This whole list that we came up with at the beginning of the year."

I said, "Well, what will that get you? If you don't know if your customers want them, right?" You've got five developers here. If you put them on to building all these things that have been invalidated, you're wasting time. You're wasting market opportunity. You could be building things that people really do want and the only way we're going to learn if people really want them is to go out and talk to them so it's better to get everybody involved and talking to people as fast as possible, getting all that information and then let's take a hypothesis and say, based on the information we learned, I think that if we build this, we'll get some traction. We'll get some users. This is what people want. Then we'll go and build it. But companies just get very uncomfortable when their developers are not coding.

Mike: Melissa urges product teams to go outside the codebase to learn and get user feedback quickly. They need to resist the itch to continually build new features. Earlier, Melissa mentioned how she transitioned a product team from a traditional development model to a leaner model. What advice does she have for product managers that want to help their teams make the same transition?

Melissa: I would say try to look for a small one. That's what I did. So our CEO came up to me when I was at Open Sky and he said, I want to build this feature that was Twitter. It was pretty much Twitter inside our platform and I couldn't understand why we were doing it, but he said, "We've got all these celebrities out there. They're tweeting all the time on the platform, on Twitter, about their dogs, their cats, what they're eating for breakfast, all this stuff." And he's like, people think they're real. So if we want people to think they're real on our platform and they're actually suggesting these things, we should build Twitter into it so they could just tweet about whatever they want inside Open Sky. And I said, "Okay, I understand that the problem here is that people might not believe that the users are real," that the celebrities that we had on our platform are real, so that's the actual problem, right? But is Twitter in our platform the real solution?

So I said instead of us building this, I had the developers estimate it too and they said it was going to be like four months to build it and I had a team of like, six people. I said "Instead of that, why don't you give me two weeks to see if this is a good thing to build, right? We'll do some tests, they'll be contained, we'll measure to see if we get an increase in sales on them and we'll just test it." So we did that and me and two the developers, we built a little CMS block right where I could just type in HTML code and we pretended to be the celebrities on our feed, on our home page, on Open Sky.

And we started tweeting inside Open Sky funny messages about different things, in their voice. And we tried things, you know, random tweets. We also tried tweets about the actual products we were selling too, to see if maybe the user voice would have a thing with that. And we compared it to sales and at the end of the two weeks, we found out that it made no difference whatsoever. There was no more clicks on them than any other product. There were no more buys on the products than on any of the regular ones. We A/B tested this whole thing, so there was no difference whatsoever.

So I was able to take that back to our CEO and he said, "Oh, okay." I said, "Also, because we did this instead," you know, building it over four months, you know, "We saved almost $100,000 grand."

Right? We saved a lot of money doing this. And he went, "Oh, that's awesome. Do it again." Right? Like, find us something else that we can do and that was the quickest way I've found to get buy-in. And it's really important when it comes from the top too. If you have buy-in from management, you usually have a much easier time trying to do the product experiments, but when you're a product manager too, you have to put yourself into the shoes of your CEO, right? Or you're VP of product or anybody else who might be a stakeholder and say, you know, what are their measures of success? Right? The CEO's measure of success is having a successful company, but if you are going up against the head of marketing and saying you want to experiment on these things, and he's like, "No, I just want you to build these features."

Remember what he's getting measured on too, right? Marketing people get measured on how many people they bring in into the platform. So if your experiments are going up against that, that's why they're going to be, you know, very reluctant to try that. So it's really important to just put yourself in the other people's shoes who are on your team and realize where they're coming from and then try to get buy-in in a way that allows them to achieve their goals, too. Try to help other people. That's probably the fastest way I've found myself being able to experiment in other companies.

Mike: Put yourself in their shoes and align experimentation with their objectives. That sounds like something I can get behind. I asked Melissa to elaborate on the benefits from an ROI perspective.

Melissa: I think the money speaks, right? Money always speaks to people because when you say that, and that's the whole point of doing product experimentation too, right? It's about saving money, but it's also about the opportunity costs. So you're like, "While we were spending $100,000 on something that nobody wanted, we could have been spending that money on something somebody actually wanted."

And that's a hard thing to remember when you're in the moment, when you're stuck in that build trap, when you're trying to release all these features that you know, if we're not doing this now, if we're not spending our money on this, somebody else is going to spend their money on that. And that's when your competitors start to win.

Mike: Bringing this full circle, what are the KPIs or metrics product managers should follow when running experiments and evaluating the impact of new features on the underlying performance of the product? How do they determine why they should build the what?

Melissa: I think this is a huge problem. A lot of the teams are tasked with building the what and they don't look at the why at all. The one company I'm working with right now, I think they really understood that and it was probably one of the best engagements I came into as well because when I got there they said, "All right, we're going to reorganize our product teams and they're around goals, so we're not exactly sure what they're going to build next quarter, but everybody has a goal. One team is working on acquisition, the other one's working on retention just for the quarter one." And I said, "That's fantastic because this is what I try to tell people and a lot of companies don't get it." Like, your product teams shouldn't be organized around necessarily the what they're building. It should be about what they're going to achieve for the company.

So I think tasking product teams with a KPI or goal each quarter or each year, however you want to divide that time, is really important because then you put the power in their hand to come up with the best thing to get you to that goal and that's the whole point of building a company is achieving your goals, making great things for your users.

I usually advise people to follow something like the ARR metrics, the pirate metrics from Dave McClure and focus in on one of those each quarter. So maybe you say this quarter our team is going to work on retention and we want to try to improve it by 20%. Okay, team. Go find out how we can improve this by 20%.

And you probably have some ideas already floating around and how you can do it and that's the time to look at those customer problems and those ideas and validate them and see if you can get to that 20% by building the best solution for those problems. So, I think teams that really hone in on the KPIs and look more at the goals and the outcomes rather than the outputs, are way more successful.

Mike: Look at outcomes rather than outputs. That nicely summarizes Melissa's insights from this episode. To wrap up the interview, I asked Melissa what product teams should do if they already have a poor-performing feature. Should they squash it? How so?

Melissa: So squashing bad ideas is a really hard thing to do and it's because we're subject to so much bias. So as product managers, it's really important for us to get out of our own heads and it's important to get other people out of their own heads, too, since a lot of times at bigger companies, the product mangers might be coming up with the ideas. At a lot of startups I work with, it's the founders coming up with the ideas and dictating it to the product managers. But either way, wherever these ideas come from, they're usually heavily biased. And there are a lot of common biases I see come up time and time again when we're building features.

One of them is called causality. As humans, we overestimate why things are successful and we attribute it to the wrong things. I see causality all the time. I call it the copycat bias because we look at other people and we go, "Well that company has a mobile app and they're very successful. So we should build a mobile app, too." And we use that as a justification of why our customers will want things. When in reality, you don't know if it was the mobile app or the things on the mobile app making it successful.

B2B companies do this all the time. They copy all their competitors' features. And they go, "Well that competitor has it so we need to have it so we can check off a box." But you don't know if it's working for that competitor or not. They might seem successful, but you don't know what their customers want. You don't know if their customers are the same as yours, if they're slightly nuanced, if they're slightly different. So causality always drives us in trouble there.

Another bias is the curse of knowledge. As product managers, we are the experts and when we work at companies, we are the experts, right? We're building this all day, every day for other people. We know how to use it. And I see this happen in UX quite a bit where you will be making these features and you'll go, "Oh. I know how to use this so everybody else will, too." And if you're not testing it with users, you don't know.

I ran into that so much at the beginning of my career. I was making the back-end software for the e-commerce platform and the first couple ones I did that at ... I was like, "Ah, there's some workarounds in here, but it'll be fine. They'll understand how to use it." I had a line of people at my desk every day asking me, "How do I use this? I just want to publish this thing." And that's when I went, "Oh. Yeah, I need to stop doing this. I need to go over to my people, test it, make sure that they want it."

So the curse of knowledge really gets us into this hole of not understanding how to be in the user's shoes. And I think one of the biggest things I've seen recently at companies, too, is called anchoring. It's another bias. Anchoring is when we fixate on a piece of data and we use it to explain everything. We use it to justify everything. And a lot of times, that data is insignificant or it has nothing to do with anything.

So, at one company I was at, we justified building every product feature with the data that 99% of our users log in every day. We were saying, "We need to give them more things to do every day in our platform, more stuff to go into." And when I actually went out and talked to the users, I found out that they were logging in, but they were putting it at the back of their screen and only checking it once a week. So they would log in, leave it there. Maybe they would log in every morning, but they only checked it on Mondays because that's the only day we refreshed our data.

So, when we get stuck on data and we don't actually find out the why behind it, we can't build the correct things. We make the wrong decisions.

And I think one of the last biases that I think comes up in product management all the time is the sunk cost fallacy and loss aversion. And that's the bias that, "Well, we already built it. So we might as well keep it. Nobody's using it, but we just spent four months doing this so I guess we'll just keep it there. And one day, one they'll learn how to use this. One day they'll want it." And that's how you end up with these crazy, super huge, very fat products that are too complicated to use.

My favorite real-life example of that is the copy machine. I don't know how to use anybody's copy machine anymore. It's like a copier, a printer, a scanner, a faxer, a magician. I never know how to use it. You walk up to it. It's got 17,000 buttons on it. All I want to do is copy a piece of paper and it usually takes me about 25 minutes to do that. So I've given up. That's why everybody's like, "I'll just send you a PDF. I'm not going to make you a copy."

But we do that in our products all the time, too. And that's how you end up with things like Salesforce. Salesforce is great, it's highly usable, but you have to hire consultants to set up your Salesforce, right? People can rarely do it on their own because there's just so many things in there. It's very complicated. And it works for them because they are very useful, but for a company that maybe wouldn't have such a strong problem to solve, it could be very dangerous to get into that habit.

Mike: Melissa argues that the build trap is what happens when you focus on shipping over learning and the what over the why. Next up is the benchmark. Let's see how Melissa reflects on the next series of questions we ask all interviewees to ask themselves.

Melissa: How do I eat my own dog food? I do this a lot in my consulting business now. When I first started off teaching workshops and teaching product management, I didn't really know what people wanted to learn. So, the first workshop I ever taught was in Intro to UX Bootcamp and I put it up on Eventbrite. I didn't spend a ton of time developing the content yet. I knew what I would generally put in there. I communicated what the value proposition was, what you would learn in the class, and I put a nice little clause on it that just said, "If we don't get at least 10 people to sign up for this, I'll cancel the class a week before and I'll give you all your money back."

So I put that up there and I found out that people did want it. A lot of people signed up. I got 30 something in that class. But I do that any time I teach a new workshop. I'll always put out the proposition, try to see if there's any interest in it and if there's not, then I say, "Okay. Maybe that's not it. I'll go back. I'll refine it. I'll try to teach a little differently. I'll try to target a different market, do another iteration on it, and put it back out there." That's been my little consulting experimentations.

How do I use customer feedback to inform my business? I spend a lot of time going to conferences, too. And I love speaking. I love giving presentations and sharing my knowledge, but I spend a ton of time just talking to people there about the challenges they're going through, what they're trying to learn, how they're trying to help. And I go to about over 10 conferences a year. So a lot of them. And to me, those are the most exciting times, though, because I learn a ton from the other speakers, but I also learn so much from the people in the audience, the people who are actually have the problems.

So, I spend a huge chunk of my time doing that. I go to meetups and just listen to other peoples' stories. I talk to a lot of people at meetups there, too. And I use all that in trying to figure out what are the strongest problems people are tackling in product management. And then I might go home and think about how I solved them and write a blog post on that, put it out here, get some feedback on it, and if it's good, I'll turn it into a talk.

What am I reading right now? I'm almost done with Zero to One by Peter Thiel. I really like this. It's been interesting. I usually have a hard time reading business books, to tell you the truth. I just find it ... I get really sleepy when I read them. I usually read books to fall asleep, but this one has been really good.

It's been a little bit eye-opening, too, to see the big leaps and it makes so much sense. In the book, he always talks about you have to make something radically different, right? If you're just marginally improving on something that already exists, you can get somewhere, but if you disrupt it and do something very different, that's how you build a unicorn. Which has been really interesting. I usually talk a lot about incremental product improvements, which works really well inside a company, but if you're doing that to start a startup, I can see where a lot of people have failed because they've only marginally improved over something somebody's been used to using and that's where I think startups do run into trouble.

What's a recurring product management nightmare? Oh man, I have this a lot with consulting and it has happened to me before where I'll come in and I'll spend quite a few months with a company and with their founders, with the CEO, or with their heads of this divisions and we'll be going through how to do product management well, how to set up their teams around KPIs, how to do product experimentation. And they'll start doing it for a while and then just one day, they walk in and they go, "Nope. We're not going to do that anymore." And it's happened twice to me.

I've also had people not do that, which is great, but oh that's my biggest fear. That we're doing it and it's working really well, but people get very scared and then they just stop it. Or they just go, "Nope, we're not going to keep trying. We're going to just put a kibosh on this and go back to our old ways."

So, my product management nightmare is always when people start off experimenting, and then because we're not coding all the time, they decide to stop experimenting. They say, "We just got to build big features and release them."

Mike: Listeners can find out more about Melissa at melissaperri.com or at Mind the Product in San Francisco in May. Her book, The Build Trap, comes out later this year. That's our show. Thanks for tuning in. Until next time, this is Mike Fishbein from Alpha UX.