The One Page Product Spec

Startups don’t die from starvation. They die from indigestion. They try to do too much at once. The symptom is a team that works hard but doesn’t seem to make progress. The cause is often a lack of clarity about what to build.

You have an idea for a feature. You talk about it with your cofounder. You mention it to an engineer. Everyone seems to be on the same page. Then two weeks later you see the result and it’s not what you imagined at all. Sound familiar?

The problem is that a conversation is not a plan. Vague ideas lead to wasted work. You need a document. But not the kind you’re thinking of. Not a 30 page product requirements document that no one will read. You need something small simple and powerful. You need a one page spec.

The Goal is Clarity Not Exhaustiveness

A spec for a two person startup is different from a spec for Microsoft. Its purpose is not to be a legal contract for an outsourced team. Its purpose is to create a shared understanding for a small group of people sitting in the same room real or virtual.

A good spec is a tool for thinking. Writing it down forces you to clarify your own ideas. It exposes gaps in your logic before you've written any code. It should be short enough for everyone to read in five minutes. It should be clear enough to prevent major misunderstandings.

It must answer three big questions. What problem are we solving? Who are we solving it for? And how will we know if we succeeded? Everything else is detail.

The One Page Template

Here is a simple template. Copy it. Use it for the next thing you build. It should fit on a single page. If it gets longer you are probably adding too much detail or your scope is too big.

1. The Problem

Describe the user’s problem in one or two sentences. Use their words not yours. What is causing them pain or frustration?

Example: “When I invite a new teammate I have to manually set their permissions for every single project. It takes forever and I often make mistakes.”

2. The Target User

Who are you building this for? Be specific. “All users” is not an answer. Is it for new users during onboarding? Is it for advanced users of a specific feature?

Example: “This is for Admins on our Team and Business plans who manage more than five people.”

3. Success Metric

How will you know if you've solved the problem? You need a number. A metric you can measure. This turns a vague goal into a concrete target.

Example: “Reduce the average time to set up a new user’s permissions from 10 minutes to under 1 minute. We will measure this with product analytics.”

4. The Core User Story

Describe the new feature from the user’s perspective. A simple format works best. “As a [user type] I want to [take an action] so that I can [achieve a benefit].” This keeps the focus on the user’s goal.

Example: “As an Admin I want to create a 'Marketing Team' role with preset permissions so that I can assign new marketing hires to it with one click.”

5. The Scope

This is the most critical section. It’s where you prevent scope creep. You must be ruthless about what is in and what is out for this first version. It is better to ship a small thing that is complete than a big thing that is half done.

What’s In:

• A new “Roles” page in the Admin settings.
• Ability to create a role and define its permissions.
• Ability to assign a user to a role from the “Invite User” screen.

What’s Out (For Now):

• Editing a role after it has been created.
• Deleting a role.
• Assigning roles to existing users.
• Default roles like “Editor” or “Viewer”.
• Any API support for roles.

How to Use The Spec

The process is as important as the document itself.

First one person writes the spec. This is usually the CEO or a product manager. It is a mistake to write a spec by committee. The goal is a coherent vision not a collection of everyone’s ideas.

Next you share the draft with your team. This is not for approval. It is for feedback. The engineer will see technical constraints you missed. The designer will see user experience issues. The purpose of this discussion is to poke holes in the plan and make it stronger. Update the spec based on this feedback.

Once the team agrees the spec becomes the source of truth for the project. When work begins you refer back to it. Every day someone will have a great new idea. “What if we also added notifications?” The spec gives you an answer. You look at the “What’s Out” list. If it’s not there you don’t build it. You can add it to a list for a future version.

This isn’t about shutting down ideas. It’s about maintaining focus. The goal is to ship the first version quickly to see if you solved the original problem. The other ideas can wait.

A simple document like this does more than just define a feature. It builds discipline. It forces clarity. It aligns your team and lets you build faster with less wasted effort.

— Rishi Banerjee
September 2025