Product design for founders who are also the first user

Product design for startups starts with a founder who is already the first user. That daily use is real evidence. It shows which steps hurt, which words you reach for, and which screens you skip because you already know the answer. It does not replace a specification for the next person.

The next person lacks your memory. They will not forgive a control because you remember the argument that put it there. Keep what your own use proved. Set aside the habits that only make sense inside your head. That split is the whole job of the early design.

What your own use can prove

You have done the job, sometimes hundreds of times. That repetition is worth more than a hypothetical persona sketched in a workshop. If you hesitate every time you export a report, the export is probably in the wrong place. If you keep a notebook beside the product to remember a sequence, the sequence is too long. If you have trained yourself to ignore a banner, the banner is noise.

Write those moments down while they are still fresh. A useful note is concrete. "I filter to this week before I do anything else." "I never open settings." "I copy the client's name into another tool because the record here does not hold it." These are observations from the job. They belong in the brief.

On a Hanabi project, this is the material worth bringing to the first working session. The studio designs and builds product interfaces, and the founder's daily use is the fastest way to see the real workflow. Got Next is a public example of a focused product interface: a place to discover and track what matters, rather than a home for every idea the team had along the way. Your notes should be that specific. A mood board is a later problem.

What your own use cannot prove

You are a biased instrument. You know the vocabulary. You know which error is harmless. You will wait for a slow screen because you care whether the feature ships. Nielsen Norman Group's research on time spent on web pages found that people often leave within 10 to 20 seconds, unless the value is obvious. You will stay. The next user may already be gone.

That gap shows up in small ways. You tap an icon with no label because you drew it. You accept a three-step setup because you wrote the steps. You keep a dense table because you like seeing everything at once. None of those habits prove that a stranger can finish the job.

Personal taste sits in a separate pile. You may prefer a quieter screen, a particular blue, or less decoration. Taste can guide the brand. When a preference and a job disagree, the job wins. Clarity over complexity is the studio's working standard for that disagreement: the plainer path that a new person can follow outranks the arrangement you have grown used to.

Write the next person's job in one sentence

Before you add a screen, write one sentence with a person, a verb, and an outcome. "A sales lead marks which prospects to call today." "A trader checks whether a position needs a decision before the open." "An operator sees that an order failed and what to do next."

If the sentence will not come, the screen is often a place to store anxiety. Founders add dashboards for numbers they might want later. The next person needs the number that changes an action today. Leadly, a public lead-management interface, is shaped around that kind of sentence: track a prospect, nurture them, and move them forward. The screens exist to serve the verb.

Read the sentence to someone who has not used the product. If they ask what the verb means, the sentence is still insider language. "Triage the pipeline" is a habit phrase. "Choose who to call today" is a job. Use the second one as the heading of the flow. The product can keep a more specific proper name. The heading has to be legible to a newcomer.

Pin the sentence somewhere the team will see it: the top of the brief, the first frame in the file, the first line of the ticket. When a new idea arrives, ask whether it helps that sentence. Ideas that help a different sentence go on a later list. This is how a small team avoids designing three products at once.

Separate habit from the job

Take three tasks you do every week. For each one, write two short lines.

• What you actually do, including the skips and the workarounds.
• What a new person would need to see to do that task without you in the room.

The first line is evidence. The second line is the design. The distance between them is the project.

A common distance looks like this. You open the product, ignore the welcome state, jump to a saved view, and act. A new person opens the product, sees an empty table, and does not know what the first record should contain. Your habit skipped the empty state. Their job begins there. The empty state belongs in the specification even if you have not seen it in months.

Vocabulary creates another distance. You say "account" and mean the company. The interface says "workspace" and means the login. You translate without noticing. The next person cannot. Pick one word for the object and use it in the navigation, the button, and the error.

Frequency creates a third. You live in one advanced screen. Most new users need a simpler path for the first month. Keep the advanced screen. Open the common path first. Designing only the screen you live in is designing for today's habit.

Write the two lines in the founder's own words before anyone cleans them up. Polished language hides the workaround. "I check Slack because the notification inside the product is late" is more useful than "we should improve alerts." The workaround names the real job: know, in time, that something needs you.

How to test the split in a week

You do not need a research department. You need one person who is not you, doing one job, while you stay quiet.

1. Pick the single job sentence.
2. Hand them the product, or a clickable sketch, and the sentence. Skip the tour.
3. Watch where they stop. Write down the stop, not your theory about it.
4. Ask what they thought the screen was for. Their words are the next draft of the copy.
5. Change the one thing that blocked the job. Repeat once.

If you only have yourself, role-play the new person with a constraint. Hide the feature you always use. Complete the job with the navigation a stranger sees. The places you get stuck are the places your habit was covering a hole.

This will feel slow. It is cheaper than building the screen you already know how to operate. One afternoon of watching beats a month of adding controls for cases only you understand.

Take the notes in the order things happened. A tidy summary will drift back toward your habit. "They paused on the second screen, read the label twice, then clicked the wrong tab" is a design fact. "The information architecture needs work" is a way of not deciding.

What to hand a studio

When the split is clear, the design work has a boundary. Hand over the job sentence, the three real tasks, the words you refuse to keep, and the stops from the test. Leave the forty-screen map of everything the product might become for a later conversation.

If you want that translation done with a team that designs and builds, see Hanabi's services. Bring the job sentence and the places you currently cheat. That is enough to start a serious conversation about the interface.

Once the job is named, the next decision is how narrow the first version should be, and which edges deserve polish. How an MVP can feel finished without covering every idea is the piece to read next.