✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
This is the clearest statement of the exact idea in our answer: a spec describes how the product works entirely from the user's point of view, and says nothing about how it is built. Spolsky, who shipped Excel and later founded Trello and Stack Overflow, spells out that your job is screens, flows, and what happens when the user clicks, not databases or architecture. Read it and you will stop apologizing for not knowing the stack.
From
Joel on Software
by Joel Spolsky
10 min read
- A spec talks about features, screens, and user actions, never implementation
- Nailing the user experience comes first, the how comes later
- Writing it forces the hard decisions out of your head before code starts
Open
joelonsoftware.com →
✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
Part 2 tells you what a spec is, this one covers who writes it and how they build agreement without authority, walking through Spolsky's own experience owning the spec for a real feature. It shows that a good spec is a tool for consensus, not a command, which is exactly the register a non technical founder can write in. You will see the spec as a conversation you lead, not a document you dictate.
From
Joel on Software
by Joel Spolsky
12 min read
- A spec owner drives design by building consensus, not by giving orders
- Writing the spec is a distinct skill from writing the code
- A spec is a starting point for conversation, not a legal contract
Open
joelonsoftware.com →
✍️ Essay
✓ Link checked
Free
Beginner
Why we picked it
The healthy counterweight to over documenting. 37signals argues that a thick spec creates false agreement (everyone reads the same words differently) and locks you in before you have learned anything. Their fix maps onto our answer perfectly: write a short one page story in plain language, then move to rough sketches and real screens. It frees you from thinking a good spec has to be long.
From
Getting Real (37signals)
by 37signals
6 min read
- A one page plain language story beats a thirty page document
- Long specs create the illusion of agreement, not the real thing
- Move from the story straight to sketches, do not polish the doc
Open
basecamp.com →
✍️ Essay
✓ Link checked
Free
Beginner
Why we picked it
This backs up the sketch the flows part of our answer. Design the screens before anyone writes code, because a paper sketch is cheap to change and code is the most expensive thing to change. For a non technical founder that is empowering: the interface is the part you can actually own and communicate, and it gives the developer a concrete target instead of abstract requirements.
From
Getting Real (37signals)
by 37signals
5 min read
- Sketch the screens before code, changes on paper are nearly free
- The interface is the product the user actually experiences
- A designed screen gives a developer a real target to build toward
Open
basecamp.com →
📖 Book
✓ Link checked
Free
Intermediate
Why we picked it
Basecamp's battle-tested, opinionated system for shipping meaningful work in fixed cycles without endless backlogs, a primary source, free in full. The antidote to over-planning your roadmap.
From
Basecamp / 37signals
by Ryan Singer
free online book
- Work in short cycles with a cool-down between them.
- Fix time, vary scope, use 'appetites,' not estimates.
- Make bets, not plans; no runaway backlog.
Open
basecamp.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
Amazon's trick is to write the customer facing press release and FAQ before building anything, which forces you to describe the experience in the customer's words first. That is the same discipline our answer asks for: start from what the user does and gets, not the machinery. The FAQ section is a natural place to list what you are deliberately not doing in version one.
From
Working Backwards (Colin Bryar and Bill Carr)
by Colin Bryar and Bill Carr
12 min read
- Describe the finished experience from the customer's side first
- Iterating on a document is far cheaper than iterating on code
- The FAQ forces you to answer the hard scope questions up front
Open
workingbackwards.com →
✍️ Essay
✓ Link checked
Free
Advanced
Why we picked it
Cagan, the most cited voice in product management, makes the case that a clickable prototype communicates intent better than a long written spec. For a founder that is a useful reframe: your goal is a shared picture of the experience, and a rough prototype (even in a wireframe tool) can carry more meaning than paragraphs. It also warns you that a fifty page document few people read is a waste of your energy.
From
Silicon Valley Product Group
by Marty Cagan
8 min read
- A prototype often communicates intent better than written requirements
- Long paper specs rarely get read and are hard to validate
- Aim for a shared picture of the experience, not exhaustive prose
Open
svpg.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
A simple, powerful sentence template for describing what a user is trying to do: when [situation], I want to [motivation], so I can [outcome]. It keeps you focused on the user's intent and the moment they hit it, which is precisely the plain language your developer needs. Intercom fits its whole feature brief on one printable page built around these, a format you can steal directly.
From
Intercom Blog
by Paul Adams
8 min read
- Frame each need as when I want to so I can
- Anchor features to the situation that triggers them
- One page of job stories can brief an entire feature
Open
intercom.com →
✍️ Essay
✓ Link checked
Free
Intermediate
Why we picked it
Story mapping is the technique for laying out the user's journey left to right and slicing off the smallest first version, which is exactly the must have actions for version one problem our answer names. Patton's own writeup teaches you to tell the whole story of what the user does, then draw a line under the handful of steps that make version one. It is the antidote to a flat wishlist of features.
From
Jeff Patton & Associates
by Jeff Patton
20 min read
- Lay out the user's journey as a left to right sequence of steps
- Slice horizontally to find the smallest usable first release
- The goal is shared understanding, not a longer feature list
Open
jpattonassociates.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
A plain, practical guide to the as a user, I want, so that format that lets you describe features without a shred of technical knowledge. It gives you a repeatable sentence for each action a user takes, which is a natural way to list the must have actions for version one. Good, unglamorous reference material to keep open while you draft.
From
Atlassian Agile Coach
by Atlassian
10 min read
- Write features as as a [user] I want [goal] so that [reason]
- Keep each story small and centered on one user action
- Stories describe intent, the developer decides the implementation
Open
atlassian.com →
📄 Article
✓ Link checked
Free
Beginner
Why we picked it
Once you have described a feature, acceptance criteria is how you say what done means so you and the developer agree before work starts. The Given, When, Then format lets you spell out behavior in plain language a non technical founder can write and a developer can build against. This is how you avoid the it does not work the way I imagined conversation after delivery.
From
Atlassian
by Atlassian
9 min read
- State what done looks like for each feature before work begins
- Given When Then describes behavior in plain, testable language
- Clear criteria prevent misread expectations after delivery
Open
atlassian.com →
📄 Article
✓ Link checked
Free
Intermediate
Why we picked it
This one is written for engineers, and reading it tells you what your developer will want that a pure product spec does not cover, so you can hand off cleanly and let them fill the technical half. It also reinforces our answer's core point: a good developer examines the problem and asks questions before writing code. Knowing the shape of their document helps you write yours to meet it.
From
Stack Overflow Blog
by Zara Cooper
12 min read
- See what a developer's technical spec covers versus your product spec
- A spec makes the builder examine the problem before coding
- Your clarity of intent is what lets them fill in the how
Open
stackoverflow.blog →
