Inspired — Product Discovery & Team Practice

• · IN1 — Give teams problems, not features. A team's charter is a business outcome or customer problem to solve, not a pre-decided solution to build.
• · IN2 — Validate before you build. Every non-trivial idea passes through discovery (fast, cheap validation) before committing engineering build time.
• · IN3 — Address all four risks explicitly: value, usability, feasibility, business viability. A plan silent on one of these has an unmanaged risk, not a solved one.
• · IN4 — Prototype at the lowest fidelity that answers the question. Don't build production code to learn something a clickable mockup or a spike could answer this week.
• · IN5 — Product, design, and engineering collaborate continuously, not in a handoff relay (spec → build). Engineers contribute feasibility insight during discovery, not after commitments are made.

• · Feature-team smell test: if the team's backlog is a list of pre-specified features with delivery dates and no stated customer problem or success metric, it's a feature team regardless of what it's called.
• · The four-risk audit: for any initiative, can you state in one sentence each how value, usability, feasibility, and viability were checked? Any blank = unmanaged risk.
• · Engineer-in-discovery check: were engineers involved before the solution was decided, or only after, to "estimate" a spec handed to them? The latter forfeits feasibility risk-reduction and morale.
• · Kill-rate check: does discovery ever produce a "don't build this" conclusion, or does everything that enters discovery eventually ship? A 0% kill rate usually means discovery isn't actually happening.

• · Ver anti-patrones específicos del dominio en el pack.

• [ ] Initiative has a written outcome statement (metric + target), not just a feature description. (IE1)
• [ ] All four risks (value, usability, feasibility, viability) addressed in discovery notes, even briefly. (IE2)
• [ ] A prototype or equivalent low-fidelity validation preceded production build on non-trivial initiatives. (IE3)
• [ ] Engineers were involved in discovery before the solution was locked, not only at spec handoff. (IE4)
• [ ] Post-launch outcome measurement is planned/scheduled, not left implicit. (IE5)
• [ ] The team's backlog reflects problems/outcomes, not only a list of pre-decided output features.

• Inspired: How to Create Tech Products Customers Love (2nd Edition)

Este pack cita las siguientes fuentes registradas en el índice bibliográfico:

• bookInspired: How to Create Tech Products Customers Love (2nd Edition)Marty Cagan. Wiley
• webSilicon Valley Product Group (SVPG) articlesMarty Cagan et al