5 product managers share their rookie mistakes

Don’t just learn from your product management mistakes. Learn from the blunders of others!

We asked five awesome product managers to share mishaps from early in their careers — and what they learned as a result. From testing blind spots to over-building to obsessions with (not-so-useful) tools, these anecdotes run the gamut of product management gaffes. The good news: they each contain valuable insights for PMs at any stage of professional growth.

Tell us what happened.
When I was on the growth team at Dropbox, we ran this experiment — I’ve actually totally forgotten what it was. But we got the results back and we were like, “Wow, this is really positive!” Particularly in growth, when you’re experimenting, it’s very, very rare to get big wins like that. So we were kind of surprised, but obviously really excited, and we decided to ship it.

So we launch it to everyone, and we’re looking at the results again, and we’re like, “Wait a second. Why are these results not as good as the experiment?” We start digging, and we realize that we made a mistake when we set up the original experiment. We had accidentally removed a step in the signup flow. And any time you remove steps from the signup flow, you get more people going through. That ended up being the reason why the experiment was so positive. It was kind of one of those facepalm moments.

Ack! That sucks. But what did you learn?
It comes down to a pretty unglamorous lesson of “test, test, test.” Really vetting your experiments. Oftentimes testing is the last thing that anyone wants to do, but it’s so crucial to ensure that when you run A/B tests, you really only change one variable at a time. And then the other thing is: any time experiments look like they’re too good to be true, you should probably dig in. Because in growth, particularly, it’s just very rare to find a silver bullet.

So, what’s your mistake?
Early in my career, I was very focused on planning. I was very focused on lining up all the stories and “feeding the machine.” It wasn’t like I wrote one crappy story. It was more a gradual accumulation of story after story without poking my head up and seeing the forest through the trees.

At that point in my career, I assumed the role was about listening to customers very carefully and then somehow codifying them in a spec. The irony of it is that I think the engineers appreciated that someone was feeding the machine. But I wasn’t thinking holistically about the problem, and I wasn’t helping bring the context of the customer to the team. I was being really good at one part of the role — so much so that the team became very reliant on me doing that particular thing. And then I became the blocker. My perspective became the blocker on whether were were solving the problem.

How can others avoid this trap?
You need to schedule a block to reflect on your own work, step back, do your own internal retro. Is this working? Isn’t this working? Give yourself time to think strategically, instead of running between meeting after meeting after meeting. Ask yourself, “Am I doing the best work that I can? Is this effective work or am I just doing busywork?” Even 20 minutes to half an hour of just reflecting. And I would suggest that every product person keep a diary, like how a lot of designers keep sketchbooks.

The mistake that we made, if I was to wrap everything up, is that we built way too much — instead of just trying to be scrappy and validate ideas. We had this whole system built up, how it’s going to scale. But the biggest problem was that we tried to attack the problem indirectly. We tried to build out a big system that would eventually solve a problem, as opposed to realizing that we knew the problem: musicians can’t get paid. Let’s just attack it directly.

What did pivoting teach you?
Two major learnings. One of them is never forget the root problem. And attack it directly. Even if you can’t necessarily think of the product that will scale to solve that problem, by attacking it directly in a scrappy way, you learn about the right system to build on top of it. We should have honestly just been the artists’ agents and started getting them money. We should have started at the crux of the problem, which is “get them paid,” and then built the right product on top of it.

Another one is just a general principle to look for the hack. Don’t build something big and ship it into a vacuum. Find a way to fake things.

What went wrong?
The biggest moment for me was early on, this would have been 2006, 2007. Facebook was just catching on and social networks were the hot thing. I was working on a social network for athletes. And a lot of it was built around the idea of, “How can you create relationships between athletes and their fans?” It was a great idea, but we hadn’t really considered the athletes’ lifestyles and basic stuff like, “Okay, if the athlete has the account, if they are the person with the login, the problem is when they’re running a race, they are not actually generating content. They’re not the ones photographing or taking video.” We didn’t seriously think about the way the user would be able to interact with our platform. And ultimately the whole product flopped.

What did you learn from this experience?
I still find myself needing to teach myself to give enough thought to how the customer will interact with your product. Oftentimes we build products and we expect the customer to change his or her behaviour in the way that we’ve designed the product. But customers generally won’t change their behaviour. They can’t change their behaviour. They don’t want to change their behaviour. They want you to solve a problem that they have. Or they want you to create some kind of enjoyment for them without them having to change. I think it comes down to more testing. I don’t know if there’s anything else that you could do besides testing.

Explain your problem with “the problem.”
I started at HubSpot on the marketing team, so I wasn’t a product manager by training, if there is such a thing. I started out as an associate product manager, which was a pilot program for something that is now pretty established. So I was picking up a lot of product management on the job.

But at the beginning, I ended up being convinced of a specific solution pretty early on. I thought I had the imagination for what the solution would look like, and how it should look. A specific example: we were thinking about how our forms tool should evolve. There were a lot of good ideas, but I was getting married to the solution early on. And I did a bit of design myself, which is not bad — I think a product manager should have knowledge of how design comes together. But sometimes that behaviour affected the developers and the team. They started relying on me for not just the problem and requirements, but also, “What is the solution going to be?”

How did you change your approach?
One of the things that our then-Chief Product Officer mentioned was to stop spending that much time in Trello or whatever product management tool you’re using. I think we were giving way too much detail and obsessing over how something is going to be done, as opposed to talking to customers or analyzing the data. So that led me to think, “Okay, why am I using these tools? Is it appropriate usage?” And then being more careful and selective with that.

And then the other thing was asking more questions. Over time, I’ve realized that product management is basically the art of asking questions. It’s very much like journalism, where you have to ask a lot of open-ended questions and investigate. And oftentimes the deeper you dig, the more you find. So if you’re willing to get on the phone with customers and find out what exactly is happening and educate your team, that can be really successful.

Related posts:

Nestled in the heart of Old Town Fort Collins, The Little Bird Bakeshop brings tasty magic to the air. The shop has been operating since 2010 with a passion for pastries and community. Amy Corliss is…