This is a repost of an article I wrote for the HubSpot Dev Blog.

Starting out as a product manager, you constantly oscillate between feelings of total elation and complete dejection - occasionally, multiple times a day. Over time, you learn to manage the ups and downs of releasing a highly requested feature and being burried under a mountain of bugs, but that feeling never completely goes away. Truthfully, I would never want to lose it completely because I've learned more from it than I could from anything else. The work also teaches you a tremendous amount about humility, agility and persistance.

While a lot of product management has to be learned through experience, there is much I wish I'd known when I started my PM career. With that, I'd like to share a few common mistakes new and aspiring PMs make (all of which I've also made), in the hopes of helping them manage their own ups and downs while wading into the art of product management.

THAT'S NOT OUR USER

Stop me if you've heard this one before: You've just gotten slammed through feedback - a user, colleague or friend tells you they couldn't use your product because of something dealbreaking. A feature is missing that they can't live without. They have an established process now and couldn't justify moving over to use your tool. They don't see the value.

And then someone in the room (maybe you) chimes in, "They're not our user." In other words, you can totally live without solving for their very pressing needs because they are a different persona than those you've created your product for. And so you write their feedback off.

This is dangerous for a variety of reasons. The biggest lesson here is that you cannot be selective with the feedback that you choose to adhere to. Every opportunity you have to talk about your product with someone, use it as an opportunity to get actionable feedback, and to grow your knowledge of how your product is likely to be received when you bring it to market. The truth is, great products almost never solve for a single persona or need. They are nimble, accessible, and agile enough to be broadly applicable. If you're writing someone's feedback off because they don't mesh with your ideal user, you're missing the point entirely. Because in the market, there are a lot more prospective users that don't fit your ideal user than those that do.

WE CAN'T KILL IT

Be brave and humble enough to acknowledge when a feature isn't working. Your user doesn't care that it was an incredible technical challenge implement. Your user doesn't care that it took 4 weeks and 3 full-time engineers to build. And they certainly don't care that you may lose some respect among your team for admitting defeat.

What your user cares about is that their experience using your app is degraded because a feature isn't what they need it to be. Solve for your user. If a feature isn't working and you're talking to users early and often, you'll know when something isn't working. Further, you should be able to measure everything that goes on in your app, so you'll have data to back up your assessment that a feature isn't cutting it. Des Traynor, VP Product at Intercom.io, has a nice post describing exactly how to think about this data when you have it.

You might also think that so long as someone is using a feature, you couldn't possibly kill it. How could you take something away from a loyal user? The truth is that the incremental value of that feature is likely lower than the increased cognitive burden it has on your userbase as a whole. After all, you're not in the business of building everything that everyone wants.

When considering whether or not to push on a feature with low adoption or kill it, a helpful way to think about the problem is to ask yourself, "Am I sure that my hypothesis was right?" If you're sure that the underlying hypothesis that drove you to create the feature was right, push on it. Otherwise kill it. As Traynor says, "If you want a well defined product, you must be comfortable killing features."

THINKING ONLY ABOUT SOLUTIONS

Odds are that if you're a PM or thinking about becoming one, you love to solve problems - it's in your genes. But it is problematic to think only in terms of potential solutions. It closes you off from thinking about the problem itself. There is inherent danger in this because you end up constraining your thinking to a certain subset of solutions. Instead, really think about what the problem you are trying to solve for the user is - make sure you understand not only their pain, but what causes it, to deliver the optimal solution.

This concept, problem space vs. solution space, has been around forever, but it makes an incredible amount of sense for a product manager. A classic example of tackling customer pain from the problem space instead of the solution space is TurboTax. When TurboTax was going to market, their product was informed by the realization that solving for the problem of "prepare my taxes" made for a radically different product than creating a "software for your taxes" solution. The result was a far superior product than their competitors (this example comes from Lean Product Management, anawesome seminar by Dan Olsen. If you're interested in product management, this is a great place to start).

Another important dimension of this problem is that you as a product manager are really the owner of problems more than solutions. Your engineers are the ones who should really propose and own the solutions. If you've gotten attached to a solution too early, you haven't fully leverage your engineering team for all of their many talents.

IT'S NOT READY YET

Early in a feature's lifecycle, your instinct is to polish it. You've thought so much about it, there are so many additional tweaks that could exponentially increase the value of it. It'd be unfair to yourself, the engineers, and the user to release it, right?

Wrong. This is the single biggest mistake you can make as a product manager. None of those additional features can replace the value of getting your feature or product in the hands of real users. Nothing. In many cases, worse is actually better. Be relentlessly aggressive to onboard your first user. Early in a product's lifecycle, that has to be one of your milestones.

This thinking is a lot of what drive's product roadmaps at HubSpot - we get features in front of beta tolerant customers early and let them drive the roadmap. Obviously this doesn't mean a customer tells you they need Clippy in the righthand corner of your app and you build Clippy in the righthand corner of your app, but it sure beats dreaming up features that no one will use. Let the market and your users validate your thinking. The only way to do that is to put your product in front of them and ask them what they think.

A simple heuristic to live by here is: do you know when the next time you're going to ship is? Always be shipping or planning for the next time you will ship.

HUMILITY, AGILITY & PERSISTENCE

There are three commonalities that enable product managers to overcome or alltogether avoid these mistakes - humility, agility and persistence. The great product managers that I've seen all possess these qualities. They enable them to singularly solve for their customer, with a vision and voice that inspires their team along the way to building great products.