I’ve seen product specs that were 47 pages long. I’ve seen product specs that were a back-of-napkin sketch. The 47-page spec produced a product that looked nothing like the spec because the team couldn’t keep it all in their heads. The napkin sketch produced a product that worked because everyone understood what they were building.
The right length for an early-stage product spec is one page. Not because you can’t write more, but because you shouldn’t. A one-page spec forces the kind of ruthless prioritization that multi-page specs actively prevent. When you have 47 pages to fill, you fill them with details that don’t matter yet. When you have one page, every sentence has to earn its place.
Here’s the template I use. It’s been refined through dozens of product launches at the accelerator and in my own work. Print it out. Fill it in. Pin it above your workspace. It’s all you need to build V1.
The Template
Product name: [What you call it]
Core outcome: In one sentence, what does the user achieve? Not what the product does — what the user gets. “Know exactly what my team is working on this week” not “project tracking dashboard.”
Target user: In one sentence, who is this for? Be specific. “Freelance translators in Europe with 3+ years of experience” not “people who translate things.”
Problem statement: In 2-3 sentences, what problem does this solve and why do existing solutions fail? Use customer language, not your language.
Core features (maximum 3):
- [Feature that delivers the core outcome]
- [Feature that supports the core outcome]
- [Feature that enables the purchase/conversion]
Explicitly NOT included in V1:
- [Feature you know you’ll add later]
- [Feature customers have asked for but isn’t essential]
- [Feature competitors have but you’re skipping]
Success metric: One number that tells you V1 is working. Usually: X paying customers within Y days of launch.
Ship date: A specific date, 1-2 weeks from today. Not “when it’s ready.” A date.
That’s the entire spec. It fits on one page with room for your coffee stain.
Why Each Section Matters
Core outcome prevents feature creep by anchoring every build decision to a single user result. When someone suggests adding a feature, ask: “Does this directly deliver the core outcome?” If no, it’s a V2 feature. This is the subtraction audit applied before building.
Target user prevents the “everyone” trap. When you’re tempted to add a feature for a different user type, the target user reminds you: this version is for this specific person. Other people get served in future versions. Building for one niche first produces better products faster.
Problem statement in customer language ensures you’re solving a real problem, not an imagined one. If you can’t fill this section with actual words from actual customers, you need more customer conversations before you build.
Core features (maximum 3) is the most controversial constraint. Three features feels absurdly minimal. But think about the products you love most — the ones you actually use daily. How many features do you regularly use? Probably 2-3 core features and occasional access to the rest. V1 should contain only the 2-3 features that deliver the core outcome.
Explicitly NOT included is as important as what’s included. Writing down what you’re NOT building creates a boundary that protects your scope. When scope creep starts, you can point to this list: “We decided not to include this. Here’s why.” It’s a scope management tool built into the spec.
Success metric gives you a binary evaluation criterion. Did V1 work or not? “X customers in Y days” eliminates the ambiguity of “sort of working” or “promising but needs more time.” Either you hit the number or you didn’t.
Ship date creates accountability. Without a date, projects expand to fill available time. With a date, decisions get made because they have to. The velocity principle requires time pressure to function.
Filling In the Template: A Real Example
Let me walk through a real example from a product I helped a founder spec last year.
Product name: ContentPlan
Core outcome: Know exactly what to post on social media this week, with captions and images ready to go.
Target user: Solo marketing managers at B2B SaaS startups with 10-50 employees.
Problem statement: “I spend 5-6 hours every week planning social content from scratch. I run out of ideas by Wednesday and end up posting nothing Thursday and Friday. I’ve tried content calendars but they’re just empty boxes — they don’t tell me what to write.”
Core features:
- Weekly content plan with 5 post ideas, captions, and image suggestions based on the user’s industry and audience
- One-click export to a formatted schedule (PDF or Google Sheet)
- Simple intake form where the user describes their business, audience, and recent content
Explicitly NOT included in V1:
- Direct posting to social platforms (users copy-paste from the plan)
- Analytics or performance tracking
- Team collaboration features
- Multiple social platform optimization (V1 assumes LinkedIn-first)
- Image generation (V1 provides descriptions; user creates in Canva)
Success metric: 15 paying customers within 30 days of launch at €29/month.
Ship date: [14 days from spec date]
This spec took 20 minutes to write. The founder had it printed and taped to their monitor throughout the two-week build. Every decision — “Should I add Instagram format suggestions?” “Should I build a template library?” — was answered by checking it against the spec.
Result: shipped on time, hit 12 customers in 30 days (close to target), and used the feedback to spec V2 (which added Instagram formatting and a basic template library based on customer requests).
The Anti-Spec: What to Avoid
Avoid: Technical architecture in the spec. The spec describes what the user experiences, not how the product is built. Database schemas, API structures, and technology choices belong in a separate technical document — and often don’t need to be decided until you start building.
Avoid: Design mockups at this stage. A spec is not a wireframe. Visual design happens during building, informed by the spec’s constraints. If you attach mockups, the spec becomes a design document, and every spec discussion becomes a design discussion.
Avoid: User stories or personas. These are useful for large products with diverse user bases. For a V1 with one target user, a single sentence in the “target user” field is enough. Adding personas adds pages without adding clarity.
Avoid: Competitive analysis. You’ve already done this as part of validation. It doesn’t belong in the build spec. The spec is about what you’re building, not what others have built. Competitor features in the spec create pressure to match them, which is scope creep in disguise.
Avoid: Revenue projections. The spec has one success metric. Revenue projections belong in your business model, not your build document. Mixing business planning with product planning produces a document that’s too long for either purpose.
One Page, One Focus
The deeper principle behind the one-page spec is focus. When you can describe your product in one page, you understand it well enough to build it. When you need multiple pages, you probably don’t understand it yet — you’re using verbosity as a substitute for clarity.
Focus at the spec stage produces focus at the build stage, which produces focus at the launch stage. Each step inherits the discipline of the previous one. A bloated spec produces a bloated product that launches with a confused message to a confused audience.
Keep it to one page. Build what’s on the page. Ship on the date. Learn from what happens. Then write the next one-page spec for V2.
That’s the cycle. Spec, build, ship, learn, spec again. Iterate fast, learn fast, improve fast. The one-page spec isn’t just a document — it’s a philosophy of building that prioritizes action over analysis, learning over planning, and reality over imagination.
Key Takeaways
- One page is enough. Core outcome, target user, problem statement, three features, explicit exclusions, success metric, and ship date. That’s the entire spec.
- The “explicitly NOT included” section is as important as the features. It prevents scope creep and creates a documented boundary.
- Fill in the template with customer language, not your language. If you can’t fill the problem statement with real customer words, do more research.
- Maximum three features for V1. Everything else is V2 or later. The constraint forces the ruthless prioritization that produces focused products.
- Spec, build, ship, learn, repeat. The one-page spec is a cycle, not a one-time document. Each version gets a fresh spec informed by the previous version’s data.
