Alex Roe’s Product Management Principles

Last updated: February 2023

Background

These are the principles / lessons / mental models I have taken away after three years as a PM at Google (Search, Photos, Lens) and ~5 years as the first PM (and many other roles) at an enterprise startup (Cresta). This is largely inspired by Ray Dalio’s book and I plan to keep this a living doc and continue to update as I learn more. If you have any questions or have found this useful - I’d love to hear! Please email me at alex.roe48@gmail.com.

2023 update log: added 12 (operating remotely) + 13 (on managing) + 14 (on hiring) + 15 (on culture)

1. General

1. Be nice to people; assume everyone is trying their best given the information they have
2. A PM does not need to have all of the answers. This is a classic new PM logical fallacy.
3. Appreciate your team, after all, they’re the ones producing the output
4. It’s never as good or as bad as it seems
5. Know thyself: Seek out feedback, know your strengths and weaknesses, what excites you, what bores you

1. A simple and effective way to do this is to send an email to folks you closely work with and ask (1) what should I keep doing (2) what should I stop doing (3) what should I start doing

1.  Making decisions

1. Seek to get to the best answer regardless of who it comes from (ux, eng, uer, prod, etc.)

1. *Note* not everyone communicates the same way or is comfortable speaking up in a group; go out of your way to make sure your team is included when decisions are made and that their voices are heard

2. Always refer back to the user need and/or goal you’re trying to solve
3. Get the data (UER, experiment) when in doubt; this speaks louder than words
4. However don’t be paralyzed by acting without data if it is difficult or time consuming to get; “let’s wait til we get the data” is often a scapegoat and leads to punting the decision
5. Figure out if the decision is a type 1 vs type 2 - critical for velocity
6. When a decision is made, document what it is and send to stakeholders; this prevents later finger-pointing and confusion
7. If you cannot resolve a decision amongst parties, escalate to the decision maker asap with clear reasoning from both sides; don’t make it personal - refer to 2.1
8. Familiarize yourself with cognitive biases and start developing a filter for detecting when these are in play

2.  Prioritization

1. Have a clear definition (metric) of what success is for your product / project; evaluate all new projects against this metric; focus on the ones that move the needle the most
2. 80/20 rule - find ways to do 20% of the work and get 80% of the benefit; too easy to get caught up trying to do 80% for 20%
3. Any feature to be prioritized must have at a minimum (1) an estimate of user/business impact and (2) an estimate of engineering cost. A simple S-XL grade for these two criteria is sufficient and makes deciding whether to prioritize something or not much easier.

1. Note: you should be in the habit of reflecting after doing this to make sure your estimate for (1) matches reality. Your engineering stakeholders should be responsible for (2) and likewise should make sure matches reality over time

3.  Presentations

1. Slides are a tool, not your presentation; don’t have essays; be a minimalist w/ content; images + speaking over them > words
2. Tell them what you’re going to tell them, tell them, tell them what you told them
3. Be a storyteller - villain, victim, hero framework
4. Tailor your presentation to your audience; make ‘em laugh
5. Demos/prototypes speak louder than slides

4.  Delegation

1. You will not scale as a PM unless you delegate and trust your team
2. Define clear requirements and expectations (document these), then get out of their way and let people do their job
3. When giving feedback, refer back to the requirements and expectations you defined
4. Don’t be critical of how someone does the task if it meets the requirements but might be different than how you would’ve done it; this leads to resentment. It is fine to give feedback and make suggestions but should frame it as “consider…” vs directive
5. Give feedback along the way vs at formal performance review points

5.  Productivity

1. OKRs are an effective tool for planning what you want to get done at a high level for a long period of time; when new tasks come in or you think about your week, refer to these to make sure what you are working on aligns with your goals
2. Don’t let others define what you do, you control what you do. You let others control what you do by being reactive to email and not asking “how soon do you need this by?” and “if I do this I drop X, is that ok?” if reactive asks come in
3. Email is async, minimize checking this; aim for only 3x / day; don’t set a precedent of having to reply immediately - especially outside of work hours; for even more productivity, don’t start your day by checking email, do an hour or two of work before opening up email.
4. Inbox zero. Inbox zero. Inbox zero.
5. Use your calendar to block off time to get work done
6. Maximize time spent on important, not urgent tasks. Minimize time spent on urgent, important. Delegate urgent non-important. Spend no time on non-urgent, non-important.

6.  Communication

1. Never ping someone just “hey”. Ping someone the entire question that they can respond to when they can; if they don’t respond, send an email
2. Keep your emails and docs short; no one has time to read them; if needed give a tl;dr and link out to a doc instead of writing an essay in email
3. Bold action items in emails to make them explicitly clear
4. Over-communication is rarely a bad thing - especially with your managers / stakeholders; avoid the “hey what’s up with X project” emails
5. It’s fine to admit you don’t know something; admit so vs trying to sound smart
6. Overpromise and try your effing hardest to deliver (h/t Jeff Grimes)

1. Common saying is underpromise and overdeliver, but great products get built aiming for something difficult (make sure it’s possible tho)
2. Contrarian point: if you don’t have credibility within the org yet, it’s wise to underpromise and overdeliver and then leverage that organizational capital into bigger projects down the road (h/t Michael Hopkins)

7. if you can’t do something immediately, let the stakeholder know and give an ETA up front

7.  Meetings

1. Be allergic to meetings; treat meetings as if you are paying for everyone’s time. Is it still worth it? Can it be handled over chat/email?
2. If you have to schedule a meeting, find a time where people already have blocks of meetings and cluster there as to not fragment their time too much (especially with engineers!)
3. Status meetings are time sucks; get team to update status of tasks ahead of time and use meeting for resolving open questions / discussion
4. Have a clear agenda and desired outcome defined ahead of time; cancel meeting if there is no set agenda / outcome needed; meetings for the sake of meetings suck
5. Keep meeting notes and send them out to everyone afterwards
6. Keep meeting moving, be quick to take things offline or follow-up separately
7. Be present - laptops and phones down

8.  Enterprise / B2B product management

1. There are three different classes stakeholders that have different needs: the person/group writing the check; the manager/group who will help implement/operationalize the software; and finally the end user of the product.
2. Sales is as/more important than the product. Get to a min-viable-sales product that you can close a deal then grow that product to a set of customers; leverage that set as distribution for additional product offerings + feature prioritization; there is danger in overfitting to early customers.
3. The buyer of your product is often different from the end-user of the product. This means that although you could have an incredible end-user experience, unless the product meets the needs of the buyer, then it doesn’t matter, so you need to deeply understand what your buyer wants.
4. What do buyers of enterprise software want? A promotion! In my experience at Cresta our buyers are using Cresta for a specific need: increase sales revenue, and ultimately want a good ROI on their purchase; I think this can be generalized to most enterprise product buyers (e.g. if you spend $1 on technology, you should be expecting to get $5 back measured in some way)
5. To the point above, you should have a really good way to demonstrate clear ROI for your product

9.  Working with customers

1. Visit them in person. Talk to them, understand who they are as people, develop relationships with them. Cultivate a win-win mentality. Spend time with them outside of the office.
2. Be front-line support. Make sure your customers have a direct line to you and you are responsive. Stuff will go wrong, it’s how you respond that matters.
3. Every day observe your customers. If you’re not with them, observe using a tool like Fullstory. Replicate their setup at your office if not the same (e.g. they use windows but you’re on a mac). So crucial to never lose sight of how your users are using the product especially if you’re not the target user yourself
4. Let your customers write your roadmap. Refer to 9.1 above, think about the roadmap from the perspective of all three of them and solicit their feedback and listen, listen, listen. After listening (seriously, listen), compile into prioritized list; go back to them with prioritized list and get their agreement. That’s how you get buy-in.

10.  Startup product management (especially when you’re the first PM)

1. No ego. Engineers are used to making product decisions themselves before you were there. CEO was used to driving product direction before you were there. Don’t rush to “be a PM” and make product decisions. Listen, understand, and make sure you understand deeply the customer, tech stack and the business. Take on grunt work, fix some bugs, ask lots of questions.
2. At times you’ll have to do everything. Write code, build dashboards, make mocks, visit customers, help with marketing, etc.. Don’t forget to block out time for product thinking every week.
3. You’ll have fewer resources, less time, and more things to do than at a larger company. Prioritization becomes even more important. Even though everything feels critical and you want to move fast because “startup”, take a breath. Say no more often, think about what’s important in the grand scheme of things, make sure you maintain some work life/balance (at least one day / week with no work) to prevent burnout.
4. Block out days to help with focus. At one point I was responsible for product work, marketing work, customer success work and a plethora of other random things. I struggled with prioritization and getting stuff done until I broke my week into chunks of time: 2 blocks (morning, afternoon) each day; then ahead of time, I defined what those blocks were for e.g. meetings, marketing work, product work, etc. Then, whenever I had a task, I would categorize it into what kind of work it was and batch it until I had a block for that type of work. This helped keep me sane and helped me get stuff done
5. Coach others to be product thinkers: the whole company benefits from not just “product managers” being able to be product thinkers; help your teammates out, overcommunicate context for decisions being made, lead others to water and decisions instead of making them yourself especially when they are type 2 type decisions that are correctable. This way of operating gives the company and yourself massive leverage.

1. Caveat: as PM your job is to ensure that the product is going towards the correct direction; if you give up all decision making and don’t keep a pulse, then the product risks losing cohesion and devolving to show your organizational seams. This is a tricky balance to get right.

11.  Operating effectively remotely

From Cresta where I worked remotely for ~3 years, somewhat hybrid in office but mostly remote 

6. Multi-stakeholder decisions: one of the best ways to do this I’ve found is to write up a short (1-pager) written document with context + the proposed decision + the relevant stakeholders tagged in the doc; then send out a short email with the proposed decision, link back to context doc, and then ask for input by X date; depending on urgency and importance of decision, setting up a (small) meeting ahead of the decision date is a good forcing function (can cancel if it gets resolved ahead of time)
7. Written communication vs email/slack black holes: re-direct communication to written *capturable* form (aka docs, not email/slack): too much gets lost in the ether on slack or email with giant threads; when this happens, find what is best to pull the existing context into a doc and then re-direct email/slack threads to reference the doc; end output is a referenceable and indexable artifact for context across a team
8. Relationship building: carve out “non-transactional” interaction settings with colleagues: by default, most every meeting is transactional remote; while you can operate this way, do find this can weaken working relationships and is worth investing in; ways to do this could include some cadence of 1:1, non-”work” occasional meetings (e.g. a virtual lunch/game thing), and even better - some occasional in-person meetup/travel
9. Routine + Boundaries: Have routine and some boundaries (esp. If you are working from home): ideally having a separate working space that you use just for work, having a time to at least walk away from desk and take a walk, dinner, etc, lunches away from your desk, etc.
10. In-person policies + cadence: more macro from a company perspective - some formal in-person policy is needed else the default is fuzzy and results in low(er) office capacity; at a minimum, if it is a remote company would highly highly highly recommend having some regular cadence of in-person meeting for the whole company (or larger functions) - at minimum once a year, ideally more often; one experiment would be to enable sub functions (e.g. a product/eng unit/team) the autonomy to organize in-person working weeks 1x a quarter

12.  On managing

From managing a team of 20+ at the peak and had 10+ direct reports across a variety of functions; this is somewhat surface level, entire books are written just on this (if you read one, read this one) so not expecting to capture everything re: management in a few principles

11. First off - managing a team can be one of if not the most rewarding activities in a business; it is amazing to see a well functioning team crush it and see individuals grow, learn, and succeed in projects and areas that are larger than a whole. That being said, it’s hard, really freakin’ hard and you need to be intentional. One of the hardest parts (I found) is a tension between a “family” and a “sports team”. Naturally, you will (and should!) care deeply about the people on your team - you want to support, root for them, and help them succeed. However, there is a balance between “we are a family member” -> unconditional love and “we are a sports team” -> even Steph Curry at some point will have his minutes reduced, come in from bench, etc. - would just keep that in mind and don’t let personal relationships get in the way of making decisions around performance management, coaching, etc; try to separate X as a person from X’s execution in a role.
12. Second off - there are different management styles. For me personally and in managers throughout my career so far, there are a variety of styles that can be successful - you can read a lot of books and see others, my advice for first time managers would be to think back on the best managers that you’ve had, write down what you liked about their styles, what made them great, and take pieces from that; in time you will find your own style and make sure to get feedback from your reports on where/how you can be better
13. Third - I found managing a team in a way like building a product. There is still some end output or goal you are trying to achieve, instead of features, there are processes, people, and direction; you can still measure, you can define what a north-star looks like, can examine what is and is not working, in general I used this mindset to help me manage and define the organization I built.
14. General framework: when managing can think of activities as direction (defining where the org/team is going), inspection (understanding what is happening), decision making (unblocking + moving stuff forward) and coaching (how are) ; depending on size of team and situation, etc. - you may be spending time on individual contributor type of activities still and/or as well as recruiting, hiring, etc. type of activities (recruiting/hiring covered in section 14)
15. Direction: Why does your team/org exist? What are the goals? What is the rallying cry that everyone is rowing towards together? These are really critical questions that should have clear answers and are incredibly empowering to a team - when I was running our CS org and we were growing quickly with a million things to do, one of the highest impact things I did (in retrospect) was defining a very clear goal for the quarter(s) with a theme that everyone was bought into (e.g. WIN-ter for a winter quarter where we were trying to win a high % of new business); having these clear goals and motivations is really inspiring for a team - make sure they are measurable in some way and celebrated at the end when (hopefully!) accomplished; everyone in the team having a clear sense of direction and a WHY behind the org, goals, and direction is a bit like maslow’s hierarchy of team’s needs - it’s core and it is your responsibility for making sure this is clear. Spend time on it and revisit when appropriate (ideally there is a yearly theme and quarterly/monthly goals)
16. Inspection: now that there is direction, how can you measure how things are going, both at a macro org/function/team level and on an individual level; depending on function, this could be quantitative metrics (e.g. # of tickets, resolution time, customer health score, etc.) or qualitative (attending non-1:1 sessions to get signal); it’s a bad position for both manager and report to be in a situation where a manger does not have enough signal or context on what is going on for the report which makes the dynamic incredibly ineffective; as a manger, if you feel that you do not have context on a report (doesn’t mean day-to-day necessarily, might be metrics or top problems, goals, etc.) that is a red flag and you need to either change your inspection cadence/approach or your span of control might be out of whack and you need to refactor your team.
17. Coaching + performance management: another book could be written on this, would say that this is something that is important but can be uncomfortable, aim for some constructive feedback in every 1:1 and avoid surprises, nothing sucks more than a “performance review” and a bunch of feedback waits until then or is misaligned; situationally relevant + ongoing feedback >> one-off once a year.

13.  On hiring

I directly sourced, recruited, interviewed, hired, a decent chunk of the org from above; book-wise would read this one on hiring and again, entire books written here so not expecting to capture everything

18. First off: hiring is one of (if not the) highest leverage activities that you can do as a manager. It takes time to do right and in a high growth org, you should effectively always be spending some % time on hiring. I remember reading some book where Steve Jobs at Apple was spending 20% of his time just on recruiting activities / week. You can’t half-ass hiring if you want to build a great team.
19. Second off: it is paramount that every external interaction with a candidate (from cold outbound, to interview process, to offer process, to rejection process) is treated with respect. A reputation from having a bad interview process or disrespecting candidates will travel, also if a candidate goes thru a process and it is not a fit at the moment, it may be later (we hired multiple people who initially were not a fit for later roles who were A+); plus in general, it’s the right thing to do, too much BS happens in bad interview process and companies, please don’t contribute to that.
20. Start by defining the who/why and an objective rubric: the most critical part, always start with an internal very specific description of what output and responsibilities that you expect this hire or function to achieve; from there, come up with a rubric that is objective and scorable of distinct signals that you (and the interview team) can reliably get from the interview process; once this is done and well defined, then come up with an external job description; part of this step is also defining the interview process
21. Sourcing: based on 14.1, would come up with some ideal prototype candidates (usually via LinkedIn) and define why - referencing back to the rubric prior; the goal with this is to come up with a basic set of criteria; if you have a well defined prototype candidates, links and some definition, sourcing can (if needed) be outsourced or delegated more effectively
22. Candidate pipeline channels: best channel is a referral from someone (internal or that you know/worked with closely) and ideally there is a two-way intro and some selling that can happen already before even the first conversation; seriously, try to get these even if it is, everything else is high high variance; if you cannot get referrals, do cold outreach; I’ve found using LinkedIn and a tool like this to setup drip campaigns is decently effective; do try to personalize things and be intentional, we all hate getting blasted generic emails - I try to take some info from LinkedIn or their website, etc. and personalize it (e.g. if they played golf, I might send a note with “I’m looking for help fixing my swing (and a A+ CSM)”); you should also have a basic inbound setup (via your career site or whatnot) but there is more often noise than signal here, worth having up and spending some time / week flagging interesting candidates

1. Side note: good managers are always sourcing and building pipeline for A+ candidates; even when not in full blown recruiting or hiring mode

23. Interview process - first two calls: if a cold outbound candidate, you need to be in understand mode in the first call; why should the candidate spend their time going thru the interview process? Should be very specific on the opportunity, the company, and then shut up and listen! If the candidate is A+, likely they’re happy where they are at.. What are their goals? What excites them? What would it take to get them to even consider something else? The goal of this first call is not to get candidate into the interview process, your goal is just to interest them enough to get them to a next call (with you still) where you then you earn the right to sell and get them excited - again thru a lens of understanding their initial motivations, wants, goals, etc. - this allows you to better tailor the process
24. Interview process - rest of process: once a candidates is in the formal interview process, it should be systematic and NOT different per candidate. This is really important as you need to have a repeatable process to get reliable signals. Don’t stray from your process. Let it run for multiple iterations and only then look to change parts of it, but be very intentional. The whole goal of the process is to emit trustworthy signals for the rubric defined in 14.1 - so this gives some flexibility but signs of a bad interview process are when it is done and you (and other interviewers) cannot strongly answer rubric scores; won’t be as specific in terms of actual interview stages, etc. but have found that some project (ideally with you compensating candidate for time spent OR the project is live together) is best signal. Also note if you are growing a function, having a repeatable process here is great because it allows you to turn on/off the hiring spigot in the future and immediately have a calibrated process to run against and use for signal.
25. Move with speed, not haste: Once you’re hiring for a role, run really fast at it; it’s bad to get one candidate thru the pipeline and not being confident in giving an offer because you haven’t seen enough other candidates yet; it’s also bad to have a long drawn out process, this is exhausting for internal teams interviewing, exhausting for candidates, bad for everyone! Would run (as fast as you can) at the process - starting with pipeline gen and in general have urgency. Time-wise it depends, from defining rubric -> interview process -> offer I’m not sure of averages but from experience it is ~3 months-ish on average (and then there is time for the candidate to start, etc.) so in general would be hiring 6 months ahead of when you need it.
26. References + backchannels: do them, seriously. Obviously be respectful and is candidate dependent on their situation (don’t interview anyone at their present company); ideally you can find a mutual connection (or mutual of a mutual connection) for a backchannel to get more honest feedback; these are a critical step and should not be skipped.
27. Offer negotiation: again another book on this topic, most important I found was a) knowing way early in process (in the first call ideally) what the salary/comp expectations are - it sucks going thru a whole process only to be way off and could have avoided wasted time b) use some comp tool to get a fair/accurate-ish comparison for equity/total comp c) VERY IMPORTANT when you give the offer, understand from the candidate besides the comp would there be anything preventing them from wanting to move forward and work together? From there, work with them and make sure that you understand the negotiation levers you have (e.g. more equity vs less salary, bonus), etc.; you shouldn’t feel like “we’re getting a deal!” with a candidate; you want to make sure the candidate feels valued, excited, and compensation is not something they need to worry about post negotiation; it sucks to lose someone at this stage (esp. Given time invested) so doing upfront work here re: understanding expectations, etc. is critical

1. If needed, also leverage other people helping sell at this point in time - whether someone else in the org (CEO, head of X, etc.) or external (an investor)

28. Onboarding: whole other topic, but once you hire, the job isn’t done! The very first “onboarding” experience actually is as soon as the candidate takes the offer - other folks who interacted closely with them thru the process should reach out - excitement! And ahead of them starting, you need to be very intentional and setup an onboarding process, ideally a buddy, and clear 30/60/90 day goals. Don’t skimp on this.

14.  On culture

From being at Cresta from < 10 people -> 200+; note What You Do is Who You Are is a good read on this

29. Culture is one of those “things” that is quite mystical in definition but perceived as one of the most important parts of a company (e.g. airbnb’s don’t f$%k up the culture); reflecting back on my career, I can identify what could be described as a culture in different teams - Google Search vs Google Photos, Cresta at 10 people vs Cresta at 200 people; there is definitely *something* here and think a working definition of culture from Ben’s book above is “culture is how decisions are made” in company; for me personally, I identify culture as “culture is the invisible set of rules, habits, and procedures that affects how individuals at a company operate which in turns affects how the company as a whole operates”
30. Culture truth: even if you don’t define a culture, culture is being formed, enacted, and happening with every single action and person that is part of a company; early on, the cultural impact of each new person is outsized in impact - in a company of two adding a third person, that third person has more of a cultural impact than if you are at 1000 and one person joins (caveat being that person is a new CEO, etc. etc.)  
31. Defining culture: when is too early to define culture? By default, when starting a company the founders set the tone for culture and the first few hires continue to the set the tone; per 15.2, even without pithy principles or culture “rules” written down, invisible rules and operating habits are forming and affecting others; Why both to define and actually write these down? And when is too early? Having written cultural principles feels “big company”, but do think this is an important activity to do when you start to hire a non-initial-founding team and as a founder, you should be thinking about this when hiring (and even finding a co-founder, etc.); once there is some critical-ish mass (5-10 people?) and stuff is “working”, there is hiring and growth on horizon, etc. - that might be a good time to more formally define and write down
32. Programming culture: once a culture is defined, how do you program it? How do you instill those principles in an existing team, how do you maintain it as you grow, and how do you help form this when new employees join? Repetition and examples are key. At Cresta we had both a peer nominated motion (someone could “thank” someone else for doing something and tie that back to a value) and more of a top-down founders award type of motion as well (founders would give a specific award tied back to a cultural principle to someone who exhibited a motion); these both worked well, the key is having something consistent and clear - it’s hard to remember “the 10 cultural commandments” but depending on the company situation, you can be very specific e.g. “this quarter we are focusing on decreasing our time to value so we want to instill + reward speed” and then orient company and achievements around a specific cultural value
33. Measuring culture: how do you measure culture? Is culture getting better? Worse? By default, would have some company survey cadence (quarterly / 2x year) where individuals and teams can provide feedback re: likert scales, etc. of various culture values; also besides trying to quantify culture, just ask! What if you asked everyone at the company (or micro - your team) - what is the culture? How would you define it here? What is the best team culture you ever worked at? Why?
34. Ultimately these are all fuzzy questions and principles around culture, but once your company becomes more sizable such that the initial founding team is not doing everything, there are a practically infinite number of situations that individuals will encounter and how they handle will be a direct result of culture (some %, of course a large % is still individual traits, etc.) so as a company does scale, how it operates is a direct result of those invisible cultural rules; even if you are not the founder, on the leadership team, or even managing - as an individual you can still play a huge part in team culture so that is another principle worth remembering; ignoring all these meta questions, what kind of company do you want to work at and be a part of? How do you want to treat customers? Your colleagues? Do it.