Product Building Guide

A practical audit for founders, PMs, and growth people who are tired of shipping features nobody notices.

Imagine how movies portray falling in love.

You catch eyes with someone in a bookstore.

You have read the book they’re holding and strike up a conversation.

They make you laugh, you make them laugh. Soon the butterflies start to form.

The biggest mistake founders make is they forget that people, are people.

The way we connect, use, and share products will always come down to the fact that we’re human. We want to feel seen, understood, and excited. We want to share things that increase our social status.

You can have a great roadmap, a clean codebase, and a real market, and still watch four hundred people sign up and none of them come back. That isn’t a distribution problem. It’s a product-experience problem, and it hides in places dashboards don’t look.

This guide gives you five checks. Each one is a diagnostic you can run yourself, without a research budget, in an afternoon. They are ordered deliberately: the first two fix what users feel, the middle two fix what they trust, and the last one fixes why they choose you over the identical tool launching next Tuesday.

Here’s an in-depth video of going through Gamma

https://www.youtube.com/watch?v=PZq9qNEwLJY

What you’ll learn

Time to Dopamine. How fast your product delivers its first hit of real value, and how to compress that time.
Study & Emulate. How to borrow solved interaction patterns from the best products in the world instead of reinventing them badly.
Build a World. How to make every touchpoint feel like it came from the same company on the same day.
Cut the Fluff. How to identify what your product should refuse to do, and delete it without flinching.
Be Opinionated. How to turn a point of view into the one thing a competitor can’t ship in a quarter.

HOW TO USE THIS

Run the checks in order. Each has a concept section and an audit section. The audit is where the work happens.

Do them on your own product first, then on the product you most admire. The gap between the two results is your roadmap.

The final checklist collects all fifteen audit questions into one list you can run again every quarter.

Check 1: Time to Dopamine

Time to Dopamine is the elapsed time between a user’s first contact with your product and the first moment they feel something good.

Not activation. Not the aha moment in your funnel deck. The felt moment: the small involuntary “oh, that’s nice” that happens somewhere in the body before it happens in the analytics.

Why it matters

Attention is the only genuinely scarce resource you’re competing for, and it is spent, not saved. Every step between arrival and payoff is a withdrawal from an account the user did not agree to fund. Signup forms, email verification, team-naming screens, product tours, “invite three colleagues to continue”: each one is a tax collected before any value has been delivered.

The cruel part is that this cost is invisible to you. You know where the good part is. You’ve seen it a thousand times. Your user has seen it zero times and is deciding, roughly forty seconds in, whether this was worth opening a tab for.

THE DIAGNOSTIC SIGNAL

If a meaningful number of people sign up and only a small fraction ever complete the core action, you probably do not have a value problem. You have a latency problem.

People who sign up have already told you they want it. Something between the door and the payoff is losing them.

The rule of thumb

Under 60 seconds. Under 5 clicks. That’s the target for a self-serve product. It is aggressive on purpose. Most teams measure theirs for the first time and find it sits somewhere north of four minutes, most of which is administrative setup that could have been deferred, defaulted, or deleted entirely.

You do not need to hit sixty seconds. You need to know your number, and you need it to be going down.

Check 1: The Framework

Four steps. Do them in one sitting, with a stopwatch, in a browser that has never seen your product.

Step 1: Time it honestly

Fresh incognito window. New email address. Start a timer the moment the page loads and stop it at the first moment you would genuinely feel something if you weren’t the person who built this. Write the number down. Do it three times and take the worst one, because that’s closer to a real user than your best run is.

Step 2: Map every step in between

List every screen, field, click, confirmation, and redirect between the start and the payoff. Do not summarize. Write each one on its own line. Most teams discover between twelve and twenty steps where they assumed there were five. The list is the finding.

Step 3: Give every step one of three verdicts

Kill. Remove it entirely. If you can’t defend it in one sentence, it goes.
Defer. Move it after the payoff. Billing, team setup, profile details, integrations: almost none of it needs to happen before the user feels something.
Pre-fill. Supply a sensible default or seed the account with sample data so the user is editing rather than creating from nothing.

Every step gets exactly one verdict. “Keep as is” is not a verdict. If a step survives, it survives because you actively argued for it.

Step 4: Re-time it and set a ceiling

Run the stopwatch again. Then make the number a tracked metric with a ceiling you refuse to cross, the same way you’d treat page load time. Anything that would push Time to Dopamine past the ceiling needs an explicit argument to ship.

Worked example: Figma

Figma is the cleanest example of this discipline in modern software. You open a file and you are already drawing. There is no project to create, no workspace to name, no five-slide tour explaining what a frame is. The canvas is the onboarding.

Notice what Figma defers. Teams, permissions, shared libraries, billing, plugins: all of it exists, all of it is important, and none of it stands between you and the first shape you draw. The administrative layer is real but it waits its turn.

Notice also what it adds. Other people’s cursors appear on the canvas within seconds. That is social proof and delight delivered simultaneously, before you have done a single thing to earn it.

THE TRANSFERABLE MOVE

Figma didn’t make setup faster. It made setup optional until after the user was already invested.

Ask of your own product: what am I forcing people to configure before I’ve given them a reason to care?

Check 2: Study & Emulate

Originality at the interaction level is almost always a liability.

Your users arrive with muscle memory built by the best-funded product teams on earth. They know what a settings gear does. They know where the search bar lives, what a toast notification means, how a date picker should behave, what happens when they drag something onto something else. That knowledge cost you nothing and it is sitting there, free, waiting to be used.

When you invent a novel pattern for a solved problem, you are asking the user to pay tuition. Occasionally that’s worth it. Usually you’ve just made your date picker worse than everyone else’s and called it a design decision.

Emulate patterns, not aesthetics

This is the distinction that separates smart borrowing from being derivative. Copying how a product looks makes you a knockoff. Copying how a product solved an interaction makes you competent.

Copy the fact that Linear’s command palette lets you do anything from the keyboard. Don’t copy Linear’s gradient.
Copy the fact that Stripe’s docs show a working request and a real response side by side. Don’t copy Stripe’s purple.
Copy the fact that Duolingo makes the streak visible before it makes the lesson visible. Don’t copy the owl.

Build a swipe file

Pick ten products you genuinely admire. At least three should be outside your category: a game, a banking app, a piece of hardware. Category-adjacent inspiration produces category-average products.

Every time you hit a moment in one of them that feels good, screenshot it and write one sentence about what specifically produced the feeling. Not “nice onboarding.” Something like: “they asked for my name after showing me the dashboard, not before.” The sentence is the asset. The screenshot is just the reminder.

WHY THIS MATTERS STRATEGICALLY

You have a limited budget of originality, meaning the number of things you can ask a user to learn before they give up.

Spend it on your point of view (Check 5), not on your dropdown menus. Be conventional everywhere it doesn’t matter so you can be strange where it does.

Check 2: What to Look For

For each product in your swipe file, run these five. The point isn’t to admire them. It’s to name the specific mechanism so you can rebuild it in your own context.

Area	What to look for	Audit question
1. Onboarding	What they ask for, when they ask, and how much they defer until after value is delivered.	What did they NOT ask me up front that I would have asked for?
2. Micro-interactions	Hover states, loading behavior, transitions, the small confirmations that tell you something worked.	Where did the interface respond to me faster than I expected?
3. Empty states	What sits in the box before the user has done anything: sample data, a prompt, a template, a demo.	Did the empty screen teach me what to do, or just tell me there was nothing here?
4. Error handling	How they say no. Whether the message explains the fix or just reports the failure. Whether it blames me.	Did the error make me feel stupid, or did it make me feel helped?
5. Celebration	What happens the moment something succeeds, and whether the size of the reaction matches the size of the win.	Was I acknowledged when I did the thing the product wanted me to do?

RUN IT ON YOURSELF

Now answer all five for your own product, in writing, in the same words you used for the products you admire.

The comparison is uncomfortable, and that discomfort is the entire value of the exercise. The gaps that make you wince are the ones to fix first.

Check 3: Build a World

A product is not a set of screens. It’s a place, and people can tell instantly whether the place is coherent.

Your user doesn’t experience your product in the order you built it. They hit the landing page, then a signup screen, then a confirmation email, then the app, then an error message, then a help doc, then, six weeks later, an invoice. If those seven things feel like they came from seven different companies, the user learns something you didn’t intend to teach them: that nobody is really in charge here.

Coherence is a trust signal

People read consistency as competence. It’s not fair and it’s not rational, but it is reliable. A product whose transactional emails are warm and human, and whose error messages are cold system output, is telling you it has a marketing team and an engineering team who don’t talk. Users don’t articulate this. They just trust the product less and can’t say why.

A world is not a brand guideline

A brand guideline is a PDF that specifies hex codes. A world is a felt consistency in three layers, and only one of them is visual:

Voice. The same personality is talking in the app, the emails, the docs, and the 404 page. Same vocabulary, same level of formality, same sense of humor or lack of one.
Visual system. Type, spacing, color, motion, density. Not just matching, but recognizably systematic, so that a screen you’ve never seen still feels like it belongs.
Point of view. The same values show up in every decision. If the product is opinionated about focus, the emails should be rare. If it’s opinionated about speed, the docs should be short.

THE STRIP-THE-LOGO TEST

Take a screenshot of your app, your marketing site, and your most recent product email. Remove the logo from all three.

Hand them to someone who knows your category. Can they tell these are the same company?

If they can’t, you have a collection of assets, not a world.

Check 3: The Coherence Map

Six touchpoints. Score each one pass or fail. Be strict, because a generous audit produces a generous product.

Touchpoint	What to check	It passes when…
1. Landing page	Does it promise the thing the product actually does, in the voice the product actually uses?	The headline could be pasted into the app and not feel out of place.
2. Signup & onboarding	Does the tone shift the moment money or data is involved?	The forms sound like the same person who wrote the marketing copy.
3. Core product UI	Is the visual system consistent across screens built at different times by different people?	A new screen feels familiar before you’ve read a word of it.
4. Transactional email	Receipts, resets, notifications: the messages nobody was assigned to write.	They read like the product wrote them, not like the mail service did.
5. Support & error copy	The words that appear when something has gone wrong.	They explain the fix, take responsibility, and stay in voice under pressure.
6. Off-platform	Social presence, documentation, invoices, contracts, the changelog.	Someone who found you through any one of these would recognize the others.

Scoring: Six out of six is rare. Four is respectable. Anything at or below three means your product feels assembled rather than designed, and the fastest fix is almost always copy. Rewriting emails and error messages in one voice costs a day and moves the perception more than a redesign does.

Check 4: Cut the Fluff

In-N-Out sells four things. The line is still out the door.

They have had seventy-plus years and enormous demand to add breakfast, salads, chicken, a loyalty app, seasonal promotions. They haven’t. The menu is famous precisely because of what it refuses to include, and every item on it is better than it would be if the kitchen were also making nine other things.

That’s the whole philosophy. Constraint isn’t a limitation you apologize for. It’s the mechanism that lets the few things you do be excellent.

Every feature has a carrying cost

Teams evaluate features on whether someone will use them. That’s the wrong question, because the answer is almost always yes and it ignores what the feature costs to keep alive:

Cognitive load. Every option makes every other option harder to find.
Maintenance. Code, docs, support articles, edge cases, and the meeting where someone explains why it works that way.
Surface area. More surface means more bugs, and bugs in a neglected feature erode trust in the whole product.
Positioning. A product that does eleven things is harder to describe, harder to recommend, and harder to remember than one that does three.

A feature that 4% of users touch once a quarter is not free. It is charging rent to the other 96%.

The Ruthless Test

Three questions. A feature has to survive all three.

Would I build it today? If this didn’t exist, and it came up in planning tomorrow, would we build it, knowing what we now know?
Who complains if it disappears? Name the specific people. If you can’t name them, or you can and they aren’t who you’re building for, you have your answer.
Does it serve the core promise? Does it make the main thing better, or does it just sit next to the main thing taking up space?

THE HONEST VERSION

Most features that fail this test aren’t bad ideas. They were good ideas for a version of the company that no longer exists, built for a customer you chased once, or a deal that didn’t close.

Killing them isn’t an admission of failure. It’s the maintenance work that keeps a product legible.

Check 4: The Feature Audit

List every feature in your product: every menu item, every toggle, every page. Then assign each one to exactly one bucket. No hedging, no “sort of core.”

Bucket	Definition	How to spot it	Action
Core Value	The reason people pay. Remove it and the product stops being the product.	Used by most active users, most weeks. Named unprompted when customers describe you.	Invest. Make it faster, deeper, more obvious.
Nice-to-Have	Genuinely useful, genuinely secondary. Improves the core rather than competing with it.	Real usage, but nobody switched to you because of it.	Keep, but demote. Move it out of the primary path.
Legacy Bloat	Built for a reason that has expired: an old ICP, a lost deal, a strategy you abandoned.	Low usage, high support burden, and you hesitate before explaining why it’s there.	Sunset it. Announce, migrate, delete.

Reading your results

Now look at the proportions, not by feature count, but by how much of the interface each bucket occupies.

Core value takes up most of the surface: you have a focused product. Protect it.
Core value is under a third of the surface: you have a Swiss Army knife. It does many things adequately and nothing memorably, and it will lose to a competitor who does one of them properly.
You classified nothing as Legacy Bloat: you’re not auditing, you’re rationalizing. Do it again with someone who didn’t build it.

BEFORE YOU DELETE ANYTHING

Check usage data rather than trusting your instinct about who uses what. The surprises usually run in both directions.

Give real notice, offer a migration path, and say plainly why it’s going. Users forgive removals that are explained. They don’t forgive things quietly disappearing.

Check 5: Be Opinionated

Feature parity is a race you cannot win, because anything you ship can be copied in a quarter. A point of view can’t.

If your answer to “why you instead of them” is a longer list, you are one funded competitor away from irrelevance. If your answer is a belief about how the work should be done, you’re competing on something that takes years to replicate and can’t be reverse-engineered from a screenshot.

Opinionated products decide on the user’s behalf

The defining trait of an opinionated product is that it removes a choice the category assumes is sacred, and it does so on purpose.

Superhuman decided email should be keyboard-first and priced itself out of casual use. That excluded most of the market deliberately.
Basecamp decided your team should be interrupted less, and built a product that is actively worse at real-time chat than the alternatives.
Craft, iA Writer, and their kin decided that fewer formatting options produce better writing, and shipped fewer buttons than any competitor.

In each case the opinion repels people. That’s not a side effect. It’s the mechanism.

Why repelling people is the moat

A product that tries to be acceptable to everyone is chosen enthusiastically by no one. A product with a sharp opinion attracts the segment that already shares it, and those users arrive pre-sold, churn less, and explain you to their friends for free, because your opinion has become part of how they describe themselves.

The people your opinion drives away were, in almost every case, the ones who would have churned in month three while filing support tickets asking you to become a different product.

ONE IMPORTANT WARNING

An opinion you can’t defend is just a limitation with better marketing.

The test: can you explain the tradeoff out loud, name what the user gives up, and say why it’s worth it? If the honest answer is “we haven’t built that yet,” it isn’t a point of view. Ship the thing or own the gap, but don’t rebrand it.

Check 5: Finding Your Takes

You almost certainly already have opinions. They tend to be buried in decisions you made without writing down the reasoning. These five questions dig them out.

1. What does everyone in your category do that you think is wrong? Not “does badly.” Does wrongly. The convention everyone copies from everyone else without asking whether it ever worked. Your discomfort with it is the raw material.

2. What do you refuse to build, and why? Look at the requests you keep declining. If you’ve said no to the same thing four times, you have a principle you haven’t written down yet. Write the sentence.

3. Who is your product actively not for? If you can’t name a specific type of user you’d cheerfully turn away, your positioning is decoration. The answer should feel slightly uncomfortable to say in a sales call. That’s how you know it’s real.

4. What belief predates the product? Most durable opinions come from something you learned before you started building: in a previous job, a previous industry, a decade of watching the same thing go wrong. Those are the ones you can defend under pressure, because you didn’t adopt them for positioning.

5. What do your best customers say that nobody says about your competitors? Go to your own testimonials, support threads, and renewal calls. Look for the sentence that keeps recurring in different words. Users often articulate your point of view more clearly than you do, because they experienced it rather than intended it.

WHAT TO DO WITH THE ANSWERS

Pick the two strongest. Write each as a single declarative sentence a competitor would be uncomfortable copying.

Then put them somewhere public: the landing page, the pricing page, the onboarding. An opinion you only hold internally does no work.

If both sentences could appear on a competitor’s site without anyone noticing, they aren’t opinions yet. Sharpen them until someone would object.

The Complete Checklist

Run this quarterly. Every box needs an honest yes, backed by something you could show someone. “Probably” counts as no.

Check 1: Time to Dopamine

I have timed my product’s Time to Dopamine in the last 90 days, from a fresh account.
I have mapped every step between entry and payoff, and given each one a verdict: kill, defer, or pre-fill.
Time to Dopamine is a tracked metric with a ceiling we won’t cross without an explicit argument.

Check 2: Study & Emulate

I keep a swipe file of at least ten products, three of them outside my category.
I have audited onboarding, micro-interactions, empty states, error handling, and celebration in products I admire, and named the specific mechanism, not the vibe.
I have run those same five questions on my own product and written down the gaps.

Check 3: Build a World

My app, marketing site, and product emails pass the strip-the-logo test with someone outside the team.
All six touchpoints on the Coherence Map score a pass, including transactional email and error copy.
One person owns voice across product, marketing, and support, and can be named.

Check 4: Cut the Fluff

Every feature in the product has been assigned to core value, nice-to-have, or legacy bloat.
Every core feature survives all three questions of the Ruthless Test.
Something has been sunset in the last two quarters, with notice and an explanation.

Check 5: Be Opinionated

I can state, in one sentence, what my category does that I think is wrong.
I can name the type of customer this product is deliberately not for.
At least one opinion is visible publicly, on the site, in onboarding, or in the product itself, and I can defend its tradeoff out loud.

SCORING

13 to 15: You have a product with a spine. Re-run this next quarter before drift sets in.

8 to 12: Solid fundamentals, real leaks. Fix Check 1 and Check 3 first. They’re the cheapest and move perception fastest.

Under 8: Don’t start with the roadmap. Start with the stopwatch.

The Tools

No affiliate links and no stack flex. This is what I have open while I run the five checks, and which check each one earns its place on.

Tool	What I use it for	Serves
Mobbin	A searchable library of real app screens and full user flows, filterable by pattern. This is my swipe file. When I want to see how twelve products handle an empty state, it takes four minutes instead of twelve signups.	Check 2
Figma	Prototyping the onboarding flow before anyone builds it, and holding the visual system that keeps unfamiliar screens recognizable.	Checks 1 and 3
Claude Code	The main build agent. Also does the unglamorous half of Check 4: finding dead code, orphaned routes, and features nothing links to anymore.	Checks 1 and 4
Codex	A second agent, usually working the same repo on a different task. Two agents disagreeing about an approach is the cheapest code review available.	Check 4
cmux	A terminal built for running several coding agents at once, with per-pane notifications so you can tell which one is actually waiting on you. It’s what makes Claude and Codex in parallel a workflow instead of a tab-cycling mess.	Workflow
GitHub	Source of truth, and the paper trail for deletions. Sunsetting a feature is easier to defend when you can point at the PR that removed it.	Check 4
Vercel	Front-end hosting and preview deploys. Every Time to Dopamine change gets its own URL, so I can stopwatch the old flow and the new flow back to back instead of arguing about them.	Check 1
Railway	Backend and database hosting for the parts that don’t belong on the edge. Cheap enough that spinning up a throwaway environment to test a flow isn’t a decision anyone has to approve.	Check 1

THE POINT OF LISTING THESE

Every tool here does one of two things: it shortens the loop between noticing a problem and shipping the fix, or it lets me see what good looks like before I build.

None of them will run the checks for you. If you swapped all eight for different tools tomorrow, the five checks would work exactly the same.

What’s Next: go run Check 1

Don’t read this twice. Open an incognito window, start a stopwatch, and find out what your number actually is. It takes eleven minutes and it will tell you more than your last three planning meetings did.

Then pick the single worst result from the checklist and fix that one thing this week. Five checks is a lot to hold at once. One is not.

Want more of this?

adamhayes.xyz for frameworks, teardowns, and growth experiments, written up in full, including the ones that didn’t work.
@adam_ha_yes for short-form breakdowns and live audits of real products.

If you run these five checks on your product and want a second pair of eyes on the results, get in touch through the site. I do this for a living and I’m fairly direct about what I find.