Small Team Project Kickoff: Don't Write Requirements Yet, List Assumptions First

Start with One Question: Why Do You Think This Project Will Work?

Many small teams jump straight into writing requirements, drawing wireframes, and planning sprints. But if you ask, "Why do you believe users will use your product in this scenario?" the team often can't answer, or gives a vague "I think it should work."

That "I think" is an assumption. And when assumptions are wrong, all the effort that follows may be wasted.

I've seen too many projects launch only to find that users don't care about the core feature, the technical approach doesn't work, or the market window has passed. These aren't execution problems — they're assumption problems.

Categorizing Assumptions: More Than Technical

Assumptions aren't just about technical feasibility. For a project, they fall into four categories:

1. User Assumptions: Do users actually need this feature? Are they willing to pay? Does the usage scenario exist?
2. Technical Assumptions: Will the libraries, APIs, or algorithms work as expected? What are the performance bottlenecks?
3. Business Assumptions: Is the cost structure reasonable? Can the pricing be accepted? Can channels reach the target users?
4. Resource Assumptions: Will key people be available on time? Will external dependencies (e.g., third-party services) deliver on schedule?

Each type has different risk profiles. User assumptions are the cheapest to validate — an interview or a prototype — but are often ignored. Technical assumptions may be expensive to validate (need a demo or POC). Business assumptions should be validated early, but many teams wait until launch.

A Decision Framework: Assumption Priority Matrix

We can't validate all assumptions, only the most critical ones. How to choose? Two dimensions: Uncertainty and Impact.

• Uncertainty: How likely is this assumption to be false? Below 50% counts as high uncertainty.
• Impact: If this assumption is wrong, will the project fail or require major rework?

Plot assumptions on a 2x2 matrix:

• High Uncertainty x High Impact: Fatal assumptions — must be validated first.
• High Uncertainty x Low Impact: Can be quickly validated or deferred.
• Low Uncertainty x High Impact: If wrong, the impact is large but probability is low — prepare a backup plan, but don't invest heavily in validation.
• Low Uncertainty x Low Impact: Ignore.

In practice, small teams usually need to identify 3-5 fatal assumptions and spend 1-2 weeks validating them. If validation fails, the project should pause or pivot, not continue.

How to Validate Assumptions? Minimal Validation Design

Validation is not writing a paper; it's running an experiment. Each assumption maps to a "validation question" and a "pass criterion."

Example: Assumption that users will open the app three times a day

• Validation question: Do users really have a need to check multiple times daily?
• Validation method: Create a simple landing page describing the core feature and observe sign-up or pre-order rates. Or conduct face-to-face interviews where users describe their usage scenarios.
• Pass criterion: 80% of interviewees say "I would use it daily," or landing page conversion rate > 5%.

Note: Match the validation method to the uncertainty level. For high-uncertainty assumptions, use the lightest method (interviews, surveys, prototypes). For low-risk assumptions, skip validation and go straight to development.

An Assumption Log Template

At project kickoff, the team can hold a 30-minute assumption identification meeting. Everyone writes down what they believe are assumptions, then categorizes and prioritizes them. The final output is an assumption log like:

This log should be part of the project and updated regularly.

Risks of Assumption Validation

But assumption validation itself has risks.

1. Over-validation: If every assumption requires a precise experiment, the project never starts. Only validate fatal assumptions.
2. Confirmation bias: Teams may only look for positive evidence and ignore negative signals. Solution: before validation, write down "what would make us consider this assumption invalid" and stick to the criteria.
3. Stale assumptions: External conditions or user needs may change during the project. Revisit the assumption log regularly (e.g., every two weeks or at milestones).

When to Pull the Plug?

If a fatal assumption fails validation, the team should suspend or pivot. But in reality, small teams often continue due to sunk cost. A simple rule: if two or more fatal assumptions fail, the project should be reassessed, not continued.

Summary

At project kickoff, listing assumptions is not a formality — it's exposing risks early so the team can ask, "Why do we think this will work?" before investing. Small teams have limited resources; the worst thing is to sprint in the wrong direction. The assumption log is that "pause and think" checkpoint.

PaxLee