A four-part test for whether a product idea is worth pursuing: is it valuable (customers will choose it), usable (customers can figure out how to use it), feasible (engineering can build it within constraints), and viable (it works for the business — legal, financial, marketing, etc.)? Used as the validation bar for backlog and feature-candidate items before they earn a place on an outcome-based roadmap: before committing effort, ask what evidence exists across all four dimensions, not just technical feasibility. Originates from Marty Cagan / SVPG discovery practice (see SVPG Service Model, Discovery (Product Discovery Process)).
In Product Model (vs. Roadmap Model) companies, the product manager is accountable for viability (marketable, sellable, fundable, legal) and shares accountability for value with the whole Product Team (Five-Trait Definition). Feature teams (the Roadmap (Feature/Project List)-driven model) only sign up for usability and feasibility — value and viability are assumed to have already been decided upstream. Product teams add value and viability on top, which is what makes the job substantially harder than being a feature-team PM.
Cagan sets the bar for value bluntly: whatever you build, your customers must believe it's sufficiently better than everything else out there that they will buy it or choose to use it.
Cagan assigns explicit single-owner accountability per risk during Discovery (Product Discovery Process): PM accountable for viability, designer for usability, engineer for feasibility. Evaluate every candidate solution against all four risks explicitly — not just the two (feasibility, usability) teams default to checking.
A product can be loved by users and still fail commercially if it lacks a viable business model to match its value proposition — being well-designed and wanted (valuable, usable, feasible) is not sufficient without viability. Two illustrating cases: the Xerox 914 copier only became a commercial success once Xerox switched from a straight sale to a lease-plus-per-copy pricing model that matched how customers actually wanted to consume the value; the iPod's value proposition only became viable once Apple negotiated a business-model deal with record labels that made legal music distribution economically workable. In both cases the underlying value proposition didn't change — the business model wrapped around it did, and that's what made the difference between failure and success. See Business Model Canvas for the tool used to map and test business model options, and Explore/Exploit Dual Portfolio Management for why viability should be evidence-tested like any other assumption rather than assumed.
Julia Barham calls this same double-diamond-derived framework the "illities": feasibility, viability, usability, and desirability. It's applied once the problem is already understood, to stress-test a candidate solution before committing to it. She treats strong desirability combined with strong viability as a rough measure of product-market fit itself — see Product Market Fit Pyramid — not merely a check on solution quality.
Из тем: The Product Operating Model