How to Start a Software Project: Spec Document or Product Discovery?

The most common project start in mid-sized companies looks like this: someone writes a requirements document for months, collects three quotes, awards to the cheapest — and realizes half a year later that the document described the wrong problem precisely.

A spec document feels safe because it is thick. But size is not safety. The real question at project start is not "did we write everything down" but "do we know what is actually risky".

Why the big spec document fails

An 80-page spec assumes you know the most at the beginning — exactly when you know the least. It freezes assumptions before any of them has been tested. Every later insight becomes a "change request" instead of normal improvement.

DORA's 2024 Accelerate State of DevOps Report shows the pattern: large, rare, late-tested commitments are less stable and slower than small, frequent, early-tested ones. That holds for code — and for requirements just the same.

Product discovery is not the opposite of planning

Discovery is often misunderstood as "we don't plan, we just mess around". The opposite is true: discovery is disciplined planning that attacks the riskiest assumption first instead of the most convenient one.

An assumption is risky if the project fails when it is wrong — and if nobody knows for sure whether it holds. That is exactly where a good project starts, not at the login form.

Four questions that start a project right

1. What is the riskiest assumption?

Not "what do we build first" but "what has to be true for the whole thing to make sense at all". Test that assumption first — before budget is committed.

2. What is the smallest useful first cut?

Not the whole system, but the one process that delivers real value early and tests the risky assumption. Everything else is deliberately deferred — in writing.

3. How do we recognize success — upfront?

A project without a predefined, measurable target is an expensive gut feeling. "Should get better" is not a target. "Cycle time from 5 days to under 1 day" is one.

4. What is deliberately not in the first cut?

The most valuable sentence at project start is "we deliberately don't do that yet". Whoever doesn't write it down implicitly builds everything — and delivers nothing early.

A spec document is not dead — it is just not the start

There are contexts where a formal specification makes sense: regulated procurement, tenders, fixed price on sharply bounded scope. But even then: discovery first, specification second. A spec that emerges after a short discovery describes the right problem. One before it describes a guess.

Read estimates honestly

A serious estimate at project start is a range with named uncertainties, not a point. Whoever puts an exact number on a vague spec has either hidden buffer or not understood the risk (see What does custom software cost?). And whether a project needs custom development at all belongs before any project start (see Custom or Standard?).

Checklist for the project start

• Do we know the riskiest assumption — and do we test it first?
• Is there a smallest useful cut instead of "the whole system"?
• Is the target metric defined upfront and measurable?
• Is it written down what is deliberately not in the first cut?
• Does any specification emerge after, not before discovery?
• Is the estimate a range with uncertainties, not a point?
• Is it clarified whether custom development is needed at all?

Frequently asked questions

Don't we need a spec document anymore? Often we do — but as the result of a short discovery, not as its replacement. Understand the risk first, then specify cleanly.

Isn't discovery just a delayed project start? No. A discovery takes days to a few weeks and prevents months of wrong development. It is the project start.

What if the client demands a finished spec? Then the first deliverable is to jointly test it against the riskiest assumption. A good partner doesn't blindly deliver what the document says.

How big is a sensible discovery? Small. Goal, riskiest assumption, first cut, success criterion — on a few pages, in days, not quarters.

Conclusion

A software project does not start with the thickest document but with the most honest question: what has to be true for this to work — and do we already know that? Whoever tests the riskiest assumption first, cuts small and defines success upfront starts safely. Whoever starts with 80 pages often describes the wrong problem perfectly.

Further reading

• Custom Software vs Standard Software for SMEs — the question before any project start.
• AI & Automation for SMEs: the 90-day pilot — testing risk first, in practice.

Next step

You want to start a software project without investing months in the wrong document? Start with a short assessment of your requirements. We name the riskiest assumption and cut a first, testable step.

Sources

• DORA, Accelerate State of DevOps Report 2024 — dora.dev
• Atlassian, Agile Project Management — atlassian.com
• Thoughtworks, Technology Radar — thoughtworks.com