Define the smallest useful product, not the smallest list of features.

Write down who experiences the problem, what they do today, why the current alternative is insufficient and what observable improvement the product should create.

Avoid defining the product only through a technology, interface or feature category. A useful MVP has a reason to exist before it has a backlog.

• Who is the first user?
• What recurring problem are they trying to solve?
• What do they use instead?
• What result would make the first release useful?
• What evidence supports the problem?

A feature list can grow without proving that the product solves anything. Define the end-to-end outcome the user must be able to achieve, then identify the minimum capabilities required for that outcome.

Separate essential workflow from convenience, polish and future expansion.

Record what is included, what is deliberately excluded and which decisions are deferred. Exclusions are not a failure; they protect the learning objective and prevent the MVP from becoming an undefined first version of the entire vision.

Scope should also state supported users, environments, devices, data types and operational assumptions where they materially affect delivery.

Create a staged roadmap from the first useful outcome to later capability. For the first stage, write acceptance criteria that describe observable behaviour rather than vague quality claims.

A criterion should be specific enough for a reviewer to determine whether it passed, failed or remains unverified.

The Project Model preserves the accepted intent, evidence, decisions, scope and roadmap. A Build Specification translates the next approved stage into a bounded implementation contract with exclusions, dependencies, ownership and acceptance criteria.

Airchor’s Control Plane direction keeps those objects connected to the work and later verification.