Find out whether the thing you shipped actually worked — define the success metric, plan the measurement, classify the real evidence, then render a verdict and an iterate / pivot / scale decision.
Shipping feels like the finish line, so the question that actually matters goes unasked: did the product do what it was supposed to? Most teams answer it by vibes — a few loud testimonials, a dashboard nobody reads against a target nobody wrote down. Outcome measurement is a different discipline from the testing and review that got the code out the door: it weighs real user behavior and the business signal against a metric you commit to in advance, and it ends in a decision — iterate, pivot, or scale — not a feeling. Doing that with AI means operationalizing the success signal into a concrete metric, planning what evidence proves or disproves it, categorizing the messy real-world data you collected, and synthesizing it into a verdict you can defend.
Each step uses an existing NewPrompt tool, pre-filled by a matching resource. Open the resource to read it, or jump straight into the tool with the inputs ready.
Define the success metric
Anchor a product-analyst lens and turn the success signal you set at MVP planning into a concrete metric — what success is, how it's measured, the threshold that counts as a win, and the window to measure it over. A goal you can't measure can't be validated.
Plan the measurement
Break the metric into the specific behavioral signals, funnel and cohort cuts, and feedback sources that will prove or disprove it — and fix what counts as hit, partial, or miss before any data is in, so the result can't be rationalized after the fact.
Classify the collected evidence
Take the real usage and feedback you've gathered and categorize it — by theme, sentiment, and segment — into countable signal. This is the step that turns a pile of tickets, reviews, and events into evidence you can weigh. You supply the live data; this structures it.
Synthesize the result and decide
Weigh the categorized evidence against the success metric, render a clear hit / partial / miss verdict, and turn it into the call that matters — iterate, pivot, or scale — with the reasoning and the signals that argue against it. A decision tied to the evidence, not a gut read dressed up in data.
Document the validation report
Consolidate the metric, the evidence, the verdict, and the decision into one shareable Validation Report — verdict and decision up front for stakeholders, the reusable metric and measurement plan carried forward as the seed of the next planning cycle.
A Validation Report that says, on the evidence, whether the shipped product hit its success signal — hit, partial, or miss — and an iterate / pivot / scale recommendation behind it, plus a reusable metric definition and measurement plan that seed the next cycle. The launch stops being a guess and becomes a measured result.
Testing and agent evaluation verify the artifact before or at ship — is the code correct, is the AI output sound. Product validation verifies the outcome after ship: did real users and the business respond the way you needed, weighed against a success metric you committed to in advance. Different object, different timing.
Yes. This workflow designs the measurement and analyzes the evidence you supply — real post-launch usage and feedback. It deliberately does not build instrumentation or collect data for you (that's engineering work); it tells you what to measure and turns what you've collected into a verdict.
A Validation Report: a hit / partial / miss verdict against your success metric and an iterate / pivot / scale recommendation with its reasoning — plus a reusable metric definition and measurement plan you carry into the next planning cycle. It closes the loop that MVP planning opened.
Work the five steps in order: define the success metric, plan what evidence proves or disproves it, classify the real usage and feedback you've gathered, then synthesize a verdict and decision, and document the report. NewPrompt supplies the prompts and step order; you run each prompt in your own AI tool.
Read each classified signal against the hit / partial / miss thresholds you fixed in step 2, before the data came in, so a mixed result renders as a defensible partial rather than a gut call. The AI organizes the evidence and surfaces what argues against it; you own the go/no-go — it does not decide product direction.
Complete build journeys that include this workflow as a stage.
The full path from idea to a shipped SaaS MVP — define and scope the requirements, design the architecture, API, and data model, then build it reviewed, tested, secured, cost-controlled, and deployed.
The full path to a support agent you can put in front of customers — write its instructions, ground it in your docs, route and handle tickets, then evaluate and cost-control it before it goes live.
The full path to an AI research assistant — define its scope, organize the source corpus, ground responses in references, extract key facts, synthesize findings, check groundedness, then validate it for use.
The full path to an AI meeting assistant — define the use case, turn transcripts into structured notes, extract decisions and action items, classify follow-ups, write a shareable summary, evaluate accuracy, then ready it for the team.
The full path to a content operation that runs, not a pile of posts — set the editorial strategy, research the topics, build a reusable template, then produce and QA structured pieces on repeat.
The full path to pages that rank at scale, not penalty bait — map the intents, build the data set, structure it, template the page, then QA before publishing hundreds.
The full path to a support operation, not just a bot — stand up the knowledge base, route the tickets, add the AI agent, integrate your stack, close the feedback loop, evaluate, and deploy.
The full path to a two-sided platform — define the buyer-and-seller requirements, model the data, design the API, build roles and permissions, wire integrations, design the UI, then test, secure, and ship it.
The full path to a store you own end to end — model the catalog and orders, design the storefront and checkout, add customer accounts and payments, then secure it, test it, and ship.
You ask AI "should we keep pursuing this?" and get "it could be valuable — keep testing," so a weak option survives on hope. Here's how to set kill criteria first: the observable evidence, threshold, deadline, and owner that decide, in advance, when to drop it.
Cut a product idea down to the smallest first release that proves the core value — separate the real must-haves from everything that can wait, then define the MVP and its success signal.
Cross the gap between 'tests pass' and 'safe in production' — assess release readiness, plan the deploy and its rollback, and set up the monitoring and launch checks before you ship, not after.
Turn a pile of reviews, surveys, or support comments into themes and priorities — extract the real signal, classify it by theme and sentiment, then summarize what's worth acting on.