Product Management Cheat Sheet for “0-to-1”
- Framework for evaluating whether the “problem to be solved” is worth solving — is it 1) frequent enough, 2) painful enough and 3) urgent enough?
- An upfront filter he used to evaluate potential startup ideas — building a product that “every human being that’s connected to the Internet would need to use”.
- “Ideas are just solutions to problems”. As most founders start with an idea, it’s important to figure out what’s the underlying customer problem that this idea is trying to solve.
- A great method to evaluate a product idea — as every product idea has an existing alternative out there, try and figure out what users think of current alternatives. Essentially, it’s important to quickly understand the market landscape BUT from a customer’s standpoint.
- a) Every new product is a derivative of something that has already existed. b) It’s very hard to find a brand new problem. Problems remain the same, just that their nature keeps evolving, which in turn, creates opportunities for new products to be built. Ultimately, most software is a replacement for some sort of an excel sheet.
- a) Two ways to build startup products from scratch: 1) COPY-BUILD-ITERATE-GET TO UNIQUE. Copy fast, launch, then discover & find new things to innovate on. 2) RESEARCH-LEARN-BE UNIQUE FROM DAY 0. Learn how to be different first, but without shipping. Make something 10x better. b) If you are good at building teams and executing, go for Option a. If you are good at user research and patiently innovating, go for Option b. Choose the option that aligns most with your strengths.
- User research tips for startup Day 0: a) Usually, about 12 interviews are enough to develop a pattern. b) 2 questions to ask users (i) what’s your #1 pain point in doing X and (ii) walk me through a real story of the last time you experienced this pain point.
- a) Tip to avoid product over-spec’ing/ scope creep: for any feature that needs to be built, first figure out the exact “Step 1” to be built for it, and keep a constraint of “it should be shippable with 1 week/ 40 hours of engineering. effort”. b) This Step 1 should be crude enough that it gets built quickly, but just sufficiently spec’d so that it can drive the user validation exercise. Eg., before building a full sharing capability, just put a dummy sharing button that on clicking, asks the user “what are you looking to do here?”.
- For effective product road-mapping, always ask the question “what part of this product is getting the most usage?”. That’s the area that will drive adoption and where you should be doubling down on.
- Build a highly customer-centric product team. Everything you are doing needs to be solving a problem for the customer. Keep that focus and discipline.
I have learned many of these points first-hand while building Workomo from scratch over the last year or so, so I can attest to how useful these product heuristics are. Would love to hear some of your own learnings as a founder/ early-stage PM, so we can keep adding on to this cheat sheet.