This Ex-Google PM shares his Product Management Principles

Alex Roe’s Product Management Principles

Last updated: November 2018


These are the principles / lessons / mental models I have taken away after three years as a PM at Google and six months as the first PM 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. Thoughts? Disagreements?

  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


  • 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


  • 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%
  • 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
  • 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. Give feedback along the way vs at formal performance review points
  • Productivity
    1. 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
    2. Inbox zero. Inbox zero. Inbox zero.
    3. Define what things you want to accomplish in that week ahead of time, every day keep track of what new incoming tasks and compare it to your stack; adjust if need be
    4. Use your calendar to block off time to get work done
    5. 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.
  • 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
  • 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

[added 11/2018 after 6 months at Cresta]

  • 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.
  • 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.
  • 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 else you will fail to do your actual job.
    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.

via Read

Leave a Reply

Your email address will not be published. Required fields are marked *

You May Also Like