Notes on Startup PMing

• Engineers solve problems. PMs decide what problem to solve.
• When to hire. 1:10 PM:eng ratio is great. <1:8 is questionable. Hiring engineers with good product sense > hiring PMs.
• Hire your first PM once you find yourself re-inventing the PM role from first principles.
• "Wow we need to seriously sit down and do some thinking about ‘who exactly are we building for’ but we’re all so busy coding; it would be great if there was someone whos fulltime job was to do that...”
• Velocity is the most important determinant of product success.
• Moving fast >> making good product decisions. If you’re wrong, you can just change it quickly.
• Moving fast >> shipping features without bugs. Counterintuitively, a fast-moving eng team ships a more bug-free product than a careful team since the fast-moving team can fix bugs so quickly.
• A “good PM” is usually just a PM on a team that moves fast.
• Engineers feel good and move fast when they know they’re building something valuable. Burnout is caused by feeling like you’re building something useless (eg “let’s add AI to Strava”).
• Be an expert on the user and the product. That’s your main value add. Engineers will respect you if you can authoritatively say things about the userbase. (e.g. “Our users are primarily using our product to make CRMs”).
• Come with receipts (e.g. “here’s a survey I did”).
• You should be a “power user” of your product.
• Product decisions. Most product decisions should be made by an engineer without any PM involvement.
• Eg: “should users be able to see this when they’re logged out?” “idk, use your brain”
• If you discover you made the wrong decision, just fix it.
• One-way / high-risk decisions: PM should be involved for high-risk / one-way decisions (Eg: Should this be a paid feature? Should we depreciate this feature? Should we make this breaking change to our API?)
• Write down decisions. For each project, keep a doc listing all the decisions you can for the project, even small ones, + your reasoning. That way, no time is wasted re-making decisions.
• Eg: free users will be rate-limited at 5 uses/week. Reasoning: this caps our spend at $5/user/week, which keeps us within budget.
• Aligning a team on the specs for a project. Hold a one-hour meeting with all team members. Come with a goal and a list of “open questions” that can only be answered with input from team members (e.g. how do we give users a preview of their app before generating).
• By the end of the meeting, the team will “mind-meld” on what the feature should accomplish.
• Talking to customers. Read the mom test. Talk to >= 1 user/wk. When necessary, do “research sprints” where you talk to a bunch of users in a week. Decide what type of user you want feedback from. Email power users and they’ll be happy to chat for free. Pay new users $25/30 min call (you can go up to $50 if nobody’s interested). Source non-users from network.
• Metrics. For an early startup, metrics are usually misleading. User convos are more valuable than metrics. Most metrics just say “higher users are higher intent” (e.g. users that used this feature are more likely to convert -> this does not necessarily mean the feature is good). Some comments on specific metrics:
• NRR. Very important metric for a growing startup. “Do users grow on my platform”. >100% is good. If <100%, you should investigate.
• Activation. Important for consumer products. Users are activated when they have an “aha” moment and realize how great your product is. >35% is good. Decreases when marketing spend increases—brings in lower-intent users.
• NPS. Not important; mostly a vanity metric.
• User Growth. This is often a marketing metric.
• Break feature development into phases.
  • Common failure mode: product team has a vision for a feature, they spend 4 months grinding on it without showing it to anyone, when they launch, it disappoints users.
  • How to fix this: break up feature development into ~month-long phases and get user feedback after each phase. “Look over a user’s shoulder” while they use the incomplete product (this is called usability testing). Launch an Alpha / AB test asap—it should be incomplete + have bugs.
  • Running an Alpha: Recruit ~20 users. Start a slack channel and let them drop feedback on the feature in the channel.
• Meetings. Meetings can be a very useful tool (contrary to what some engs may think!) Recurring meetings are usually unproductive. One-off meetings are good. The best meetings are typically 15-min “can we meet real quick after standup?” type things.
• Leading the team.
  • Your engineers should describe you as the “fearless leader” of the team.
  • Have short biweekly 1:1s with all team members. Ask them how things are going, let them vent, tell them about customer calls you’ve recently had.
  • At standup, tell the team about what’s happening on other teams (e.g. “marketing is investing more in paid acquisition for freelancers”).
  • Share “proof points” for why your idea is great in public slack channels to get the engineers (and the rest of the company) hyped about what they’re building. (e.g. “this guy on twitter tried our product and said its saving him $2k/month)
  • Do bitchwork to unblock the team so they can move faster. Eg: Sales needs us to fill out some security checklists -> do this yourself.
  • Praise engineers publicly on slack and in team meetings.
• Generating buy-in for an idea. Bring up the idea to each person on the team in a 1:1 as “something you’re playing around with” and ask for their thoughts. Then, once you’ve met with everyone, announce it to the team.
• Communicating w/ other teams. Share weekly async status updates in email form. Flag high-risk decisions.
• Crafting a product strategy. Read this and copy the examples (section starting w/ Tesla). Many good strategies are very simple / 3-step (e.g. “Become the best way to build web app MVPs” -> “Become the best way to build enterprise apps” -> “Become the best way to write all software”)
• Most important PM skill: Make shit happen. There’s always some bs that comes up right before you launch—that’s on you to deal with.