Start with the decision you need
An MVP is not “half a product.” It is the smallest build that produces a business decision: pay, renew, refer, or walk away.
If the workshop cannot name that decision, you will ship features that feel productive and teach you nothing.
Workshop agenda (90 minutes)
- User and job — who suffers, and what job are they hiring the product for?
- Success metric — one primary number for the first 30–60 days
- Must-have journeys — three paths maximum
- Out of scope — write it down or it will sneak back in
- Risks — data, integrations, compliance, unknown tech
- Release shape — weeks, demo cadence, and launch checklist
Capture outcomes on a single page. Long decks become negotiation surfaces, not decisions.
Prioritization rule
If a feature does not change the success metric or unblock learning, it waits. “Nice for sales demos” is not the same as “required for the first cohort.”
Engineering constraints to surface early
- Auth and roles
- Payments and billing edge cases
- Admin tooling for support
- Analytics events for the success metric
- Hosting, environments, and secrets
These are not “phase two surprises.” They are MVP infrastructure. Leaving them implicit creates silent scope growth.
After the workshop
You should leave with a written scope, a timeline band (often 4–12 weeks), named owners, and a list of open risks. That is the input to a fixed-scope proposal or a dedicated squad plan.
Explore startup MVP development and custom software if you want XYRONEXT to facilitate and build.