“Okay. I believe you. The brief is the gap. So what does the brief actually look like?”

Fair question. I had spent a whole essay arguing that taste is a brief, and I never showed a single one.

A frame without an artifact is just a nice sentence.

So this one is different. No new argument. Just the document, built in front of you, with a template you can copy before you close the tab.

Most teams already write a brief

That is not the problem. The problem is what the brief contains.

Open ten AI feature briefs and nine of them read like a feature list wearing a costume. “Add an assistant that helps users finish onboarding.” “Summarize the document.” “Suggest the next action.” Each one names a capability. None of them names a behavior.

A capability is what the model can do. A behavior is what the user feels at 9am on a Tuesday, when they are tired and the screen is asking them for one more thing.

The brief that produces a generic feature answers one question: what can the AI do here.

The brief that produces a feature with taste answers three. What is the human actually trying to do. What should the AI refuse to do. What happens when it gets it wrong.

Most briefs answer the first and skip the other two. Then everyone blames the model.

The sections you leave out are the ones that decide taste

A feature list tells the engineer what to build. It says nothing about restraint, and restraint is the whole game.

The chatbot in the corner that nobody uses was fully specified. Someone wrote a brief for it. The brief just never asked what the feature should not do.

When you do not decide what to leave out, the model fills the space for you. It explains too much. It interrupts. It offers help nobody needed, because no one told it when to stay quiet.

On Lenny’s Podcast in June, Tony Fadell, the builder behind the iPod and iPhone, named the biggest risk for people building with AI. Cognitive surrender. “We can use the machines,” he said, “but don’t cognitively surrender because it’s so easy to build.” The architecture is still yours to supply. It is not a vibe you bring to the demo. It is a set of decisions you make before the build. The brief is where you make them.

What good looks like

The clearest version of this I have seen was not a product feature. It was a content engine I built for a newsletter creator.

She was spending 25 hours a week on research, writing, and repurposing. Burnout was close. Her real fear was not the hours. It was that AI would flatten her voice into the same beige paste everyone else was publishing.

A generic brief would have said: build a writing assistant that drafts in her style.

We wrote a different one. The load bearing section was not what the system should produce. It was what it should reject. The system learned her voice by watching what she cut from drafts, not what she shipped. Her deleted sentences taught it more than her published ones.

That one decision, voice is defined by rejections, was a single line in the brief. It changed everything downstream.

She went from 25 hours a week to 7. Her output tripled. Her readers could not tell where the AI helped.

Same models everyone else had. Different brief.

The template

Four sections. The order is the argument.

1. The human flow. Map the flow as if AI did not exist. Every step the person takes, in sequence. AI does not enter until this is done. If you cannot draw the flow without AI, you do not understand the flow yet.

2. The right less. Name what the AI will deliberately not do. This is the section most teams skip, and it is the one that creates taste. Write the refusals down as plainly as the features.

3. The failure manners. Decide how the feature behaves when it is wrong, unsure, or about to interrupt. A feature with taste is mostly defined by how it acts on its worst day, not its best.

4. The calm defaults. Decide the no input state. The blank screen, the untouched field, the moment before anyone asks for anything. Most users live here longer than they ever live in the demo.

That is the whole template. Four headers. You can fill it on a single page.

The reason it works is not the headers. Three of the four force a decision about restraint, and restraint is the thing a model cannot supply for you.

What this means on Monday

Take the AI feature you are building right now and try to fill these four sections from memory.

If you can name the human flow without mentioning AI, good.

If you can name three things the feature will refuse to do, better.

If you already know how it behaves when it is wrong, you are ahead of almost everyone.

If you got stuck on any of them, that is not a gap in the model. That is the brief telling you it is not finished yet.

Do not open the model playground until all four sections are written. The temptation is to prototype first and decide later. Decide first. The prototype is cheaper that way, and the taste is already in it.

The AI Taste Gap essay told you the brief was the gap.

This one handed you the brief.

What you write in those four sections is the part the model was never going to do for you.

The next essay starts where this one ends.

You have the brief. Now the question is how to build from it.

This is where it gets technical. How a taste aware brief becomes a real system across different domains, starting where it should, with the human flow and the UX, before any of the model work.

Mansukh Kaur
Founder, SketchSprint
sketchsprint.dev | linkedin.com/in/mansukh-kaur

In the first 30 seconds of using it, I knew almost nobody would stick with it.
Not because it was broken. It just felt like a form that had grown teeth.

Over the last year I’ve audited around 40 AI features. Some at funded startups, others inside enterprise tools with millions of users. The pattern is almost always the same:

That’s the taste gap. And right now, it’s the single biggest reason AI features ship but don’t land.

You’ve felt this before

The “AI summarize” button that spits out the same four bullet structure whether you gave it a meeting transcript, a legal contract, or a love letter.

The AI assistant that opens every reply with “Great question!” even when the question was “what is two plus two”?

The writing tool that offers three variations of the same sentence, each one a little more corporate, gently sanding your voice down until you sound like middle management.

The sales coach that scores your call and tells you to “build rapport”. Something you already knew.

None of these are technically broken. They demo well. They look good in pitch decks.
But they are also why most people try an AI feature once and never come back.

What’s actually wrong

It is tempting to blame the model. Or the prompt. Or the context window.

But after building enough of these myself, I can tell you the model is almost never the real bottleneck. The bottleneck is upstream. In the brief.

Most teams ask: “What can AI do here?”
The better question is: What is this human actually trying to do, and where can AI quietly help?

A generic brief produces a generic feature, no matter how good your tech is.
A taste aware brief creates something that feels thoughtful. Even with a simpler model.

This is the part most teams skip. They spend weeks debating models and RAG architecture, but rarely spend a full afternoon watching real users, mapping their actual flow, and understanding where they get stuck.

The features that feel premium almost always come from teams who did that work first.

What good looks like

One SaaS founder I worked with had an onboarding flow bleeding users.
40 percent drop off in the first session.
They had added an AI chatbot in the corner. It worked. Nobody used it.

We rebuilt it with the same model and same data, but a very different brief.

The new version did not announce itself. It quietly watched. When the user typed something that conflicted with a previous answer, it gently surfaced the conflict inline. When someone paused for more than 12 seconds on a field, a small, specific hint appeared. Written for that exact moment.

No “Hi, I’m your AI assistant.” Just a form that felt unusually patient and smart.

Onboarding completion jumped from 60% to 85%.

Another time, I worked with a newsletter creator burning out at 25 hours a week on research and writing. Instead of building a generic writing assistant, we created a system that watched what she read, saved, and eventually published. It learned her taste by noticing what she rejected in drafts.

Her new drafts started showing up with her thinking, not a model’s approximation. She dropped to 7 hours a week. Output tripled. Readers couldn’t even tell where the AI helped.

In both cases, the AI did less. But the right less.

Human flow first, AI second

This is the principle I keep coming back to.

Map the work as if AI didn’t exist. Sit with the actual human doing the job. Watch where they pause, where they abandon, where they get frustrated or embarrassed. Only then ask where AI can help.

When teams reverse this order, the feature feels robotic. Like AI was the answer looking for a question.

When they honor it, the feature feels designed. Like it was built by someone who truly respected the work before bringing in the technology.

The order matters more than the model.

What this means in practice

If you’re about to ship an AI feature, ask these three questions before you write a single prompt:

1. What does this person actually do today, without AI?

2. Where in that flow do they pause, abandon, or do something they’re not proud of?

3. What’s the smallest, quietest thing AI could do to remove that friction? Without announcing itself?

Answer the first two deeply, and your feature has a real chance of being used. Skip them, and no model will save you.

This is the bet I’m making with everything I build now.

The AI features that win the next decade won’t be the ones with the biggest models or the loudest demos. They’ll be the ones that feel like they were built by someone who cared enough to do the unsexy work first.

Taste isn’t a vibe. It’s a brief.

I’m pouring everything I’ve learned from the last 8 months into SketchSprint, my one-person studio where I consult, architect, and ship production AI systems end-to-end for founders and teams who want their AI to actually move business metrics.

If you’re thinking about an AI feature and want a second pair of eyes on the brief before you build, my DMs are open.

If this resonated, the next essay drops soon: a real “taste-aware brief” template you can steal. Subscribe so you don’t miss it.


Mansukh Kaur
Founder, SketchSprint
sketchsprint.dev | linkedin.com/in/mansukh-kaur

About the author

Mansukh Kaur is the founder of SketchSprint, a one person studio building production AI systems for founders and teams who want their AI features to actually move a business metric.

She ships something working every week in public. Read more at sketchsprint.dev or DM her on LinkedIn at linkedin.com/in/mansukh-kaur.