The MVP assumptions worth writing down before design starts

Every early product has unknowns. The risk is not having assumptions; it is allowing them to become invisible facts in a backlog, prototype, or scope document.

Use four clear categories

Question

Something the team needs to learn about a user, context, or outcome.

Assumption

A provisional answer, labelled with where it came from and how risky it is.

Research

The method that could test the assumption, such as an interview, observation, prototype test, or data review.

Fact

A conclusion supported by documented evidence, with its scope and date.

Prioritize the assumptions that could break the release

Ask what would make the proposed workflow irrelevant, unusable, unsafe, or commercially impossible. Test those first. A lower-risk visual preference does not deserve the same research effort as an assumption about the core user, problem, or willingness to change behavior.

Keep the record useful

For each item, note the owner, source, date, next research step, and decision it affects. Revisit it when new evidence arrives. This prevents a product plan from appearing more certain than it is.

Kiwi can help teams map critical assumptions and align a focused MVP scope around what has been learned.