YISHAN LIN
林乙善
YISHAN LIN
林乙善
The following is an excerpt from an onboarding doc I wrote up for an individual who was joining my product team from an engineering role at HashiCorp. This writeup has been edited for readers who are new or are interested in getting into product. Product careers are overly romanticized by outsiders and the requirements/experience/bar for PM varies drastically from company to company. But if you find the right opportunity where you are empowered and given complete ownership over growing a product - being a PM can be one of the most rewarding and diverse jobs in tech.
My consistent observation is that bad PMs are ones who follow textbooks blindly, live in a world of hypotheticals/ideals, are detached from reality, and make decisions without principles. Bad PMs operate without basis and make decisions that feel to others as spontaneous, confusing, and nonsensical. Good PMs are ones who operate from a central set of principles, make decisions quickly and flexibly, and make decisions that are consistent, predictable (in a good way), and easily understandable. Good PMs trust their principles to guide the decisions they make under pressure or heat of the moment.
Assuming that there are two PMs in this example, the good PM and the bad PM have made the same amount of good decisions and mistakes/bad decisions. The good PM still nets ahead because they will have stronger executive alignment and deeper engineering team support/buy-in/loyalty which ultimately allows them to rally the team down the road, whereas the bad PM loses credibility to the point of no return.
The following list are principles that I personally use a lot and take into context our current team team’s size, revenue, and market share. Many of these principles I have listed did not originate from HashiCorp and became honed/validated/refined over time at different companies and personal startup experiences.
The goal for new PMs is to organically build your own unique set of principles (business, technical, GTM) that you can take anywhere in your career. Listing out my own principles are not ones that you should subscribe categorically to, rather to try and expose a layer of myself to help you understand my personal decision-making approach.
We have no margin for error to build the wrong thing.
We are a small team competing with Google.
Validation is essential to everything we do.
We don’t push new use-cases to practitioners or sales plays without at least 3 logos.
We don’t push vaporware/marketecture. No false promises.
Pragmatism and speed is how we win.
Our advantage over Google is our ability to make decisions, set direction, align, and build quickly.
Imagine the day-to-day bureaucracy at Google needed to get one thing done.
Bad products are more a result of infighting than they are of getting a business wrong.
We compete on technical merit.
We let the product and features we ship do the talking.
Focus on the 80-20.
We will not always make optimal decisions.
But as long as we make those vital 20% decisions right, those good decisions will take us 80% of the way there.
The best data we can get is from directly talking to our practitioners.
When in doubt, talk to users.
We don’t need to predict the future.
A bad PM is the one that has no information.
Build for users, not analysts.
No buzzwords - if we cannot explain “it” in simple language, we do not build it.
PM is about being everything a product needs to succeed.
Headcount is not an excuse.
Assume people are lazy.
Protect customers from themselves.
Ruthlessly focus on adding net positive value.
There are situations every day where a PM doesn’t bring net positive value - the situation would have played out the same with or without a PM involved.
Be prescriptive.
Do things that don’t scale. There is no shortcut to good work.
As PM, we hold ourselves and everyone else to the highest standards. We set the bar.
Products don’t fail from one or two typos on a blog post. But a culture of typos and poor attention to details does lead to failure.
People love underdogs. Tell them a story they can root for.
There are many balls you are juggling at any given time. The skill of PM is about juggling and making that decision which of the balls you drop and which balls you pick up.
PMing is strongest when you are making lots of micro-adjustments/small decisions every day rather than big sweeping decisions a few times per year.
These principles would look different if we were PMing other products. Every team, product, and situation is different. Principles to me are what persists - you generally have a large bucket and choose the ones that are most applicable to the situation or product at hand. Some good parallels to the “principle-based decision making” are in sports (look at NFL or NBA head coaches, what gets them fired, what makes the successful ones continuously successful) or social (what are the differences between a flaky acquaintance and a good friend).
Here are some readings that inspired me through the course of my career. They helped me shape my principles and may be helpful for you.
Startups in 13 sentences: http://www.paulgraham.com/13sentences.html
The Magic Thread: https://blog.geoffralston.com/the-magic-thread
How to Talk to Users: https://startupclass.samaltman.com/courses/lec16/
Startup lessons: http://www.paulgraham.com/startuplessons.html
Zero to One https://www.amazon.com/Zero-One-Notes-Startups-Future/dp/0804139296
The Secret to Career Success - Yishan Wong (first ENG leader at FB, not related to me)
Say it with Charts: https://www.amazon.com/Say-Charts-Executives-Visual-Communication/dp/007136997X
The Efficient Executive: https://www.amazon.com/Effective-Executive-Definitive-Harperbusiness-Essentials/dp/0060833459
PM means different things at every company. At some companies, the PM is a JIRA monkey whereas others are engineering leads. At HashiCorp, the PM is the primary shotcaller for “what to build” (PRD) and “when” (roadmap, rough timelines) and “why” with influence into “how to build” (RFC).
In my experience, there are many different types of PMs - each with their strengths and weaknesses. Depending on how you want to grow your career, you can strategically choose which of these PM types most appeal to you and build/hone those skill sets appropriately. It is possible to encompass multiple skill sets and types (not a black and white field) - but thought I’d share to help frame a starting point for your own personal development.
At the highest-level, there are generalist PMs and specialist PMs. A specialist PM is someone who has deep domain expertise in one area and is deeply technical with a firm ear to the ground on the comings/goings of the field - someone like Andy Monaske in Vault is a perfect example of a masterful Specialist PM. People trust his vision and highly value his thoughts on security. When Andy speaks, the industry listens. Specialist PMs output innovation that move the needle. They go deep into the product and can double as development engineers themselves.
A generalist PM is someone who is a “jack of all trades” type who can wear multiple hats. They won’t have the same level of domain expertise as a Specialist, but can acquire “enough knowledge” as needed to handle the job. Vinod is a great example of a Generalist PM leader. He came in without a deep security background and is leading Vault all the same. When the industry speaks, Vinod listens. A generalist PM outputs stability and consistency - they bring in a measure of business, process, executive alignment, managing customers and just enough technical input to drive the product forward. Generalists PMs know enough about the product and can easily double as Sales reps or high-level engineers themselves.
Both types are invaluable.
PMs have skill trees like in an RPG video game. You organically acquire and can spend a certain amount of points to each “branch” within a skill tree. There are cases where you must invest your points in a certain branch just to get the task in front of you done. There are three starting branches in the PM skill tree in Technical, Business, and Diplomacy. For instance, if you’re tasked with a PRD on a specific area of the product that you aren’t familiar with - then you naturally need to spend some points on the Technical branch. The three branches become even more nuanced as you develop and get more comfortable.
Like any RPG, you can choose to all-in on one branch or spread out your points as you see fit.
This branch of the skill tree represents your technical aptitude with the product and the space. Investing points in the Technical branch involves everything from playing with the product, reading documentation, testing commands, reading code, studying architecture/industry deployment patterns, going through Learn, watching demos/YouTube videos, reading RFCs, and talking with engineers (both on the team and on the customer’s end). You can gain more by attending Sales calls and reading blogs/HN/developments in the space.
A Specialist PM is someone who has put most (or all of) their points into this branch.
This branch represents your familiarity with the product and space from a GTM sense. Investing points in the Business branch means reading up on the competition, studying the market and its past (which companies failed and which didn’t), analyzing why products in the space succeed and don’t succeed. You have an ear close to the ground on the GTM side, knowing deeply the business drivers of why people choose (or don’t) your product and keeping a close eye on why deals aren’t closing.
You are able to see the product from a customer’s lens and understand what they are trying to achieve. You understand what excites buyers and what drives sales - not just the “features that sell”, but also the internal process, serving as a cheerleader/champion/product specialist for Sales. You know enough about the product to sell it yourself and understand how Sales works (both from a process and culture perspective).
This branch represents your ability to secure buy-in and alignment with executives and other leaders/engineering counterparts at your company through relationship building and maintenance. This branch also represents your ability to connect with people across the organization in different functions and rally the Nomad team (engineering, support, etc.). The upper levels of the Diplomacy branch is not something you need off the bat as a new PM at any company- but it is something you can passively pick up and grow through observations of executive/upper management meetings. However, you still need to invest in this branch to be successful.
Getting buy-in and alignment from the direct engineering counterparts you need to collaborate with is crucial to your success. Enable them to understand who you are at a personal level, build your credibility so that they can rally behind you and see you as an asset and equal partner rather than a liability and micromanager.
The following are a set of characteristics that I’ve found to be essential for success as a PM.
A good PM is able to communicate succinctly, effectively, and concisely. Let’s say you are at a company happy hour and at the bar, while you’re waiting for your drink - the founder/CEO/VP of Product suddenly comes up to the counter for a drink, sees you, and ask “How’s your product - what are you working on?” How would you answer without any prep? The other situation would be if you were at the urinal together (this is the more crass version, but is useful to still consider given the time urgency that the latter creates in the space of a bathroom).
Being able to distill the essence of the topic at any time in a concise answer in a way that is useful for the audience you are talking to is a crucial part of PM. Being able to adapt to the audience and convey your point clearly, effectively, and cleanly in a way that they will understand and grasp easily is a must-have. The answer you would give founder is probably different than the answer you would give the CEO. Audiences are at different levels - some are at the 10,000 foot view, others are at 100,000 foot view, and some at sea level (engineers, customers). Being able to communicate your points and distill the essence is critical.
Read your audience. Bad PMs consistently lack awareness of situations, meaning they are prone to say things that come across as tone-deaf or don’t land. For instance, you are in a Sales call with a prospect, an internal enablement session with SEs, or a Zoom with engineering to discuss some points within your PRD/RFC. Read the body language of people as you talk and communicate and convey your point. If they are not listening, not engaged as one example - that can mean there is something amiss in the substance, context, or approach. Having the awareness to detect if something is working or not (the above examples are just communication ones) is the first half of the battle.
Awareness extends to other situations (process, PRD writing) - if engineers are constantly prodding at your PRD, it may mean that they are having a hard time understanding the business value behind it or your phrasing. Maybe the PRD needs more polish or more discovery/validation. If SEs are not excited about the feature you’re talking about, maybe that means they’re tuned out or you haven’t distilled it in an easy-enough-to-understand manner. It could be either one - but having the awareness to detect that and reflect/adjust/iterate without needing that explicit feedback given to you through other channels and other people (“Hey PM, the ENG really don't understand what’s going on in the PRD”) is key.
Awareness isn’t always in real-time. Perhaps you got on a call with a customer and they asked questions that you could not answer as it was an area you were not readily familiar with. After you reflect, you have awareness of your own knowledge gap in a product area or use-case. This is the “I know what I don’t know” (known unknowns) and the “I don’t know what I don’t know” (unknown unknowns). Having the awareness to detect those gaps yourself is critical to continuously self-improve.
PM for lack of a better trope, is a mix of art and science. There is no perfect formula for what we do that can guarantee good decisions. PM is not about just stack ranking the feature requests from customers and picking the top 3 - as that makes a PM nothing but a glorified TAM/Customer Success monkey. There are unquantifiable considerations to the overall product strategy and vision and impact to the open-source practitioners that each decision that you make as a PM - not only what you choose to build, but what you choose to not build and when.
Critical thinking is important because you will face a lot of pressures and challenges. For every “yes”, we have to say “no” to many more things. But we have to be realists rather than perfectionists and ultimately take the heat for the things we say “no” to. Being pragmatic and understanding what you can and can’t do while still evaluating things in the long-term (marathon, not a sprint) are critical.
The other element here is critical thinking. You will get yelled or otherwise pressured by customers, internal folks, executives, people below you, fellow engineers, to do X. The key is to critically think independently and really try to parse the substance from their requests. Is it really as high-pressure and critical as this person says it is? What is the opportunity cost of if we don’t address this right now or today? Who is really impacted? Is this the 80-20 or the 20-80? What are they really trying to accomplish? Is this something the team can handle? What is an acceptable quality for this feature and why? Is this a flavor of the month request from the customer? There are hundreds of technical solutions, workarounds, and implementations one can come up with to accomplish something. But there is only one team and one set of resources and only a few things that they can work on at any given time - how do you ensure that this is the right thing to build at the right time?
You may end up being questioned, second-guessed, or openly criticized by engineers, support, practitioners, customers, and other stakeholders for decisions that you make. You need the grit and mental strength and self-esteem to believe in your decisions. Bad PMs give into the pressure and hide from customers and engineers to avoid confrontation and harsh realities. Good PMs face the pressure and accountability, no matter how painful it is to swallow in the moment.
If a decision or implementation of a feature turns out to be sub-optimal, good PMs go back to the drawing board, reflect on what they could have done better, and apply that to the next opportunity. Having the mental strength (grit, care, patience, humility) to keep driving forward and being that consistent leader for your product is essential. Bad PMs are quiet, hard to find, and disappear when they are most needed - good PMs are visible, make themselves available, and easy to find.
To be leaders, we need to be patient and humble with others. Lastly, care is everything. Caring for the product and its well-being means making decisions that are for the “greater good” that community, practitioners, engineers, and executives may not easily understand. Over time, it may make sense to those stakeholders - but in the moment it may not. That is why grit, care, patience, and humility are important to embody at all times.
https://www.youtube.com/watch?v=J6926uL5hjc
I don’t measure productivity by email/Slack response times or total working hours. If you have a medical appointment or anything personal that takes a chunk of your day, I trust you to handle meeting conflicts and give notice - no need to let me know if you have to step out. I’ve seen people who work 60 hour weeks but their outputs are the same as someone who worked far more efficiently and got it done in half the time. All that matters is the output (in quality and time to delivery).
The standard is not that you work long hours or hard hours - only that you work as much as needed to make the product successful.