Seven Lessons from a Year in Product Management
Disclaimer: These thoughts are my own and do not represent my current employer or any of my former employers. Though informed by my own experiences, the content below is generic and learned both in my current role and through first-hand conversations with other product managers outside my company.
Starting in early 2020, I was afforded an opportunity to transition from a customer success role to product management. I believe I’ve learned more this year than I would have learned in ten years in a different role. I thought it would be worthwhile to document the lessons I’ve learned and share my insights with anyone interested in product management.
I believe these insights can only be learned through experience. PM is a trial by fire and not a skill set that can be learned or taught in school without direct, first-hand experience. It’s a bit of a catch-22 for aspiring PMs (like I was) to get your first shot. I am hopeful that sharing these ideas will help anyone interested in or getting started in PM to know a bit more about the role and what it takes to succeed. I know I have a long way to go in my own journey as a PM, so I hope to keep track of the steps I’ve taken while it’s fresh in my mind.
Here are seven lessons I’ve learned in my first year in PM.
1. Be warned: in a technology company, PM is a highly visible, high stakes role.
I had many conversations with friends and peers in PM across different companies when I was looking to get into the role, and every single one emphatically told me this, with some going so far as to call PM the most political role in any company. Yet I cannot overstate just how true it is. I believe this is a ubiquitous reality that cuts across industries, but is particularly true in technology companies whose bottoms lines are usually driven by a handful of products.
As a PM at a product-driven company, you have immense influence over the organizational direction. This makes you a target for the insights, ideas, opinions, criticisms, and strategic needs of everyone across the company. There will be no end to people trying to influence you to take the product in the direction that they want it to go. You must have conviction, resilience, and a discerning mind in the face of the many competing needs coming your way. The ability to handle this pressure is a muscle you can develop over time, but it’s truly jarring out of the gate — which leads directly to insight number two:
2. You will always be disappointing someone.
Your job as a PM is to discern, document, and decide on tradeoffs for your product direction. There are always at least ten areas of interest that a customer, prospect, or new market is clamoring for. You quite literally cannot pursue them all. Irrespective of whether you are the world’s most “lean”, “agile”, picked-up-your-dribble pivoting company or the Niagara Falls of waterfall design companies, your product will always have, at any given time, at least ten areas where major investment is needed to keep the whole thing afloat.
A truly hard part of being a PM is taking in the mass of ideas and opinions on what the next highest priority should be, and saying no to the vast majority of them. Your job is to make hard decisions about what to prioritize and say no to the rest. Inevitably, this means you will disappoint and aggravate the majority of people most of the time. Depending on how functional, forgiving, and profitable your company is, this might lead to a lot of people expressing their displeasure with you on a regular basis. This is just part of the job.
Some PMs handle this by digging in and fighting back, highlighting their successes and rejecting all failures; others by flat-out ignoring criticism and carrying on as if there is nothing to be learned. For me, it was immensely difficult at the beginning not to break down in frustration regularly at the thought of how many people I was disappointing.
I think the right place to be is solidly in the middle — ready to admit the mistakes you’ve made in your product investments, championing the team’s successes that you helped facilitate, and taking time to hear out the people who need you to hear what they believe is critically important. It’s not easy, but a little bit of empathy and a whole lot of humility can make the difference between getting more people on your side and leading the organization forward vs. turning everyone off to you and losing the trust of the team that you need to have behind you to execute on your product vision.
3. If you came from within the organization, you are not going to solve everything the moment you start.
PMs tend to get their start by transitioning from a different role within an organization, likely where they had first-hand experience with the product and/or customers. I’ve found anecdotally that a very common experience for a first-time PM coming from within the company is to believe that you can now, finally, solve all the problems with the product that you observed in your previous role. This is just flat-out not possible — mostly due to the political pressure and disagreements held across the organization that make the role hard to begin with.
This can be extremely disappointing to passionate first-time PMs (like me) who, when gearing up for the opportunity, are planning to hit the ground with a zeal to fix up the product that they likely love and mold it into the vision they’ve developed in their experience using and implementing it. There is likely a reason the holes in the product exist; perhaps it’s an ideological stance, or a piece of technical debt that requires massive heart surgery to fix that the company can’t afford. Maybe it’s simply “we haven’t gotten to that yet,” and probably won’t anytime soon given the size of the backlog. It’s easy sitting outside PM to believe that the backlog needs to be reordered to fill the product’s holes, but when you get in and see the big picture, the reality is likely more complicated than it first appears.
If you can ride out this initial wave of disappointment, you may realize that some things you perceived as important are not as important as they once seemed. But what’s truly important will be easy to prioritize even amongst the company’s most strategic, forward-looking initiatives.
4. Break your big ideas into bite sized components
Another common first-time PM temptation is to dump your grandest of grand visions into a long requirements doc as soon as you get the resources to make your vision a reality. After all, having ideas and a vision for making your ideas a reality is a key PM skill, and if you’ve been vetted for the role, you probably have this skill set. However, don’t be surprised if, when your first big idea lands, the team balks and asks questions like, “Is all this really necessary?”, or “Can we cut down the scope to something more manageable?”.
This happens in part because large initiatives are always a risk, and a key element of executive decision making is mitigating and managing risk. Even if the idea is a great one, and your execution plan is well-formed and thought out, there will still be execution risk. As a new PM, you don’t have experience or credibility working with engineering management to actually bring your product ideas to completion as real features, so nobody will trust that what you are proposing is realistic — and probably for good reason.
I believe the way to mitigate this response and actually move toward your grand vision without causing this “whiplash” reaction is to:
1. Break down your big idea into a series of bite-sized components that can be easily managed and delivered. This reduces the risk in the mind of the engineering manager of delivering the feature. They will be much more likely to get behind you when they see a path to executing on your vision.
2. Limit the audience for your grand master plan. A good audience might be your PM leadership, CTO, and the engineering manager, to help them manage toward the end goal. Writing up your big picture idea helps ensure that the ultimately-delivered feature MVP doesn’t stifle your grand plans; limiting the audience keeps the execution team from worrying about how big of a scope you’ve got in mind for the end goal.
After all, it’s your job to worry about the grand master plan; the more other people worry about it, the more the whole team will become distracted with worrying about the many different directions it could go.
On this last point — I’m not saying that you should hide the plan from everyone, keep “secrets”, or try to make something happen that the leadership won’t buy into. It’s all about communicating your ideas in a way that can be accepted and understood. The more you broadcast a large, grand plan, the more mental energy you ask of your peers to process your ideas — and they probably don’t have the bandwidth to fully digest and understand what you are proposing. This can only serve to derail the team responsible for execution from the end goal of delivering an MVP that can help move your vision toward an initial iteration that actually comes close to matching your imagination.
5. You win arguments with data.
One thing that a new PM quickly learns is that everyone has an opinion — and most people have no hesitation sharing theirs with you. You, in turn, have strong opinions about strategic directions that the company should go in, and often the people you have to convince are executive management, who themselves often have the most solidified and dogmatic opinions of all. This is frequently seen at technology startups, where the technical founder usually started the company with a specific, dogmatic point of view about the core philosophy of the product. It was their idea, after all, that won over the initial investors and secured the money that gave you a job.
However, the dogma held by everyone (including yourself) can become the molasses that sinks the most important changes you wish to make to the product. Even at small companies (in fact, especially at small companies), it can be excruciatingly hard to make difficult choices about the product direction. Usually, this means that any initiative ends in one particular sticking point — the unending argument, or as it is affectionately known, the “holy war.”
There is one, and only one, way to cut through the holy war: data. Data of any kind, really. And the best data you can find is direct conversations with existing and potential users as well as those who explicitly chose not to use your product. But whenever obtaining this kind of data is impractical (hopefully, this should be super rare), don’t let that stop you from finding some data to back up your claims. Even making a slide deck, searching online for whoever you can find with relevant knowledge, and asking for their time to validate your ideas is better than forming a product hypothesis with absolutely no data.
Even better, rarely make claims without first going through the scientific process of forming a hypothesis and then setting out to confirm or reject that hypothesis. Get in the habit of asking others and yourselves what the hypothesis is behind a statement of what’s important before you begin trying to have an argument. Cut off the argument before it even starts by asking, “What is it we want to demonstrate?” Then set out to validate the hypothesis. Any other route will lead to arguments, and arguments cannot be won by sharing your opinion; whoever disagrees with you will likely continue to disagree with you. You can only win arguments with data.
6. Always validate your ideas — especially your best ones.
Always take your ideas on what to invest in and get them in front of anyone you can find, including your peers, the engineers, the sales team, and your customers and prospects. This puts more up-front cost into planning and designing your solution, but it can save your company literal years in engineering investment toward the wrong thing. Before you make an investment of your company’s precious time and resources into a new initiative, it’s critical that you have at least some confidence that the hypotheses behind your feature are accurate. In the best case, this will help you uncover things you hadn’t thought about that will make your product better; in the worst case, it will help cover your behind when things don’t go according to plan.
Take extra time to validate your best ideas that you are most excited about. Your best idea can be called your “best” probably because it is innovative, unique, and exciting. It is probably also the most complex and requires the most investment out of all the things you want to prioritize. You probably feel strongly that it has the potential to drastically increase revenue for your company, “if only…”
It might also be based on a set of assumptions that are demonstrably false. Customers might not care at all about the feature, have no interest in using it in the way you envisioned, or have the problem you assumed they do. Even if they have the problem, they may already have something that’s “good enough,”, and the fantastic new tool you want to give them won’t be worth the trouble to them of dealing with a buggy new product.
Take the time up front to ensure that the thing you want to give them is valuable, and don’t just settle for, “yeah that sounds nice.” What you really want to hear is an emphatic response such as, “Yes please, I need that right now, can I have it yesterday?” Anything less runs the risk of not landing how you had hoped, nor generating the usage and revenue uptick to justify the investment. This is certainly a high bar, but it’s the job of a PM to come up with ideas that yield this response. You have to be up to the challenge to succeed in the role.
7. PM is really hard; don’t get discouraged.
The bottom line is that the PM role is difficult. It can lead to some of the best and worst experiences working at a technology company. That’s not to say that PM is more difficult than any other role, but the mental overhead of juggling so many competing concerns is truly challenging. It’s important not to get discouraged and keep your head up.
This is where a good mentor can really help. I’ve been fortunate to have a few good mentors and friends over the years, and I think it might actually be very necessary to have a mentor to succeed in PM. But the key is to understand that the hard days will pass, you will get better at handling the challenging moments, and the thrill of shipping features and delighting users will always be worth it in the end.
