9 resources from Silicon Valley Product Group we point founders to, and the questions each answers.
📖 Book
✓ Link checkedPaidIntermediate
Why we picked it
The definitive text on how strong product teams discover and deliver products customers love, from the most cited voice in modern product management. The reference for shipping and iterating with intent.
Why we picked it
Cagan draws a sharp line that saves founders real pain: the thing you use to test a hypothesis is an experiment, not a product you ship to everyone. He argues for calling it an MVP test so you do not confuse a throwaway prototype with something customers must be able to rely on. This keeps you from over-building a 'real' product when a rough test is all you need.
Why we picked it
Cagan, the most cited voice in product management, makes the case that a clickable prototype communicates intent better than a long written spec. For a founder that is a useful reframe: your goal is a shared picture of the experience, and a rough prototype (even in a wireframe tool) can carry more meaning than paragraphs. It also warns you that a fifty page document few people read is a waste of your energy.
Why we picked it
A tight essay separating the work of figuring out what to build (discovery) from building it well (delivery), and arguing you must do both in parallel. It reframes what to build next as an evidence question you answer with cheap tests, not a bet you make once. Short and clarifying if you tend to jump straight to shipping.
Why we picked it
Cagan makes the sharpest version of the argument: replace a list of features with a small set of outcomes you are trying to move, then let the team find the features. It is the strongest case for a roadmap as direction rather than a shipping contract. Read it when your roadmap has quietly become a promise list to stakeholders.
Why we picked it
A free, focused summary of how empowered teams operate: given problems, held to outcomes, and coordinated by a light cadence rather than top down task lists. It is a fast way to grasp the operating model before committing to the full book. Good for aligning co-founders on how much autonomy and how much rhythm your teams should have.
Why we picked it
Cagan draws the exact line at the heart of your question: output is what you shipped, outcome is the result it produced, and teams confuse the two constantly. He is honest that measuring outcomes is harder than counting features, which is why most teams quietly avoid it. Read it to commit to the harder, truer scoreboard.
Why we picked it
Cagan draws the line between discovery (figuring out what is worth building) and delivery (building it), and argues most waste comes from skipping the first. Reading this gives you a vocabulary for pausing before you build and testing whether the feature is valuable and usable at all. It is the disciplined version of your rule to write down who asked and what happens if you skip it.
Why we picked it
Marty Cagan draws the line cleanly: if you are going to fall in love, fall in love with the problem, not the solution, and get feedback before you get attached. A short, senior take on keeping the problem central all the way through discovery. From one of the most respected voices in product.
