1.2.1 - Can You Explain This in 30 Seconds Without Mentioning the Tech?

The earlier files (user.md, problem.md, promise.md) are written for the builder and the AI tools they prompt: who the user is, what pain we are solving, what the product promises. positioning.md is written for everyone else. It is the answer to "what is it?" when someone asks at a meetup, lands on the homepage or pastes a competitor's URL into AI chat. The three lines borrow from the earlier files because they pull from the same source of truth, but they are written to be said out loud, not read.

30-second explanation

Can you explain this in 30 seconds before users ask?

The call

If the explanation takes longer than 30 seconds, the idea is still too loose. AI can rewrite it quickly, but only you can decide whether the boundaries are right.

Sharpen the 30-second explanation with AI

This is a Shape idea, so the AI move is to Sharpen the 30-second explanation: run your draft through the prompt below until two people would make the same decision from it. Build and Launch ideas have their own AI moves, building and running the code.

New here? Let your AI do this with you. Paste your problem into Guide me and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt.

Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see how to use vibe2value.

Or copy this prompt into AI chat, replace the bracketed lines with your real 30-second explanation and keep the instruction exactly as visible here. It helps you put your positioning.md together by refining your three lines until two people would make the same product decision from them.

There are six ways to work with AI across a build. This idea's AI moves are noted above. See Working with AI for all six and where each fits.

The same idea on a recipe card

Imagine telling a friend what is for dinner in one breath. "It is a creamy chicken pasta, on the table in twenty minutes" lands straight away. If you need three minutes, a list of equipment and a diagram of your kitchen before they understand what they are eating, the dish is still muddled in your own head.

Your 30-second explanation is that one-breath answer. Say what it is, who it is for and what they get, with no kitchen jargon. If it does not land in a breath the idea is still too loose, the same way a dish you cannot describe simply is one you have not really pinned down.

The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See the recipe card.

What it really means

A short explanation is not about compression alone. It is a test of whether you actually understand the user, the problem and the outcome. If the explanation needs a follow-up paragraph to land, the idea is still too loose. AI can help rewrite the message, but it cannot create clarity that is not there.

Make the 30-second explanation concrete

Compare the broad version with a version you can actually test.

• Too vague: This is an AI search tool that helps people find better answers.
• Concrete enough to test: This helps a content creator find gaps in what they have already published so they can decide what to write next, using AI search shaped by their saved context.

The second version lets two people describe the same product from it.

Check the 30-second explanation

• Pass: You can explain who it is for, what problem it fixes and what useful result appears without adding a second paragraph.
• Fail: If the explanation depends on follow-up clarification to make sense, it is still too vague.

Do not move into messaging, review or build work until this passes.

What you'll walk away with

You put this into practice with the prompt above. You'll come out with a 30-second explanation clear enough that every later decision flows from it. Landing-page copy, how you describe it in conversation, the README and the prompts you write to AI all inherit that clarity.

You write the positioning before you start describing the product publicly, so you have one source of truth when the question comes up in person, on a landing page or inside an AI prompt. The file is called positioning.md because that is what it is: how this product positions itself in plain language. The post calls it a 30-second explanation because that is how the positioning shows up in practice, in the moment someone asks "what is it?"

Write it down

Your positioning.md is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again.

knowledge-base/shape-build-launch/shape/positioning.md is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI.

The .md ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code.

Writing it down is how you keep good context for your AI. See Keep the signal, not the noise for why this matters across a whole build.

Risk and mitigation

• Risk: Using a long explanation that sounds complete but means different things to different people, which causes decision drift and rework.
• Mitigation: Agree on one 30-second explanation and check every new request against it before adding scope.

Key takeaway

Do not move forward until you can explain who it is for, what problem it fixes and what useful result appears without adding a second paragraph.

How to document your 30-second explanation

Write your 30-second explanation up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this.

# 30-second explanation

## Answer
User: [who it is for]
Problem: [what problem it fixes]
Useful result: [what useful result appears]

## Evidence
Why you believe this. Conversations, examples, tickets, your own experience.

## Decision
What you are optimising for and what you are saying no to.

## Risk
Where you might be wrong and what would tell you.

## AI instruction
The standing note your AI reads on this project.

Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier.

## Answer
User: A hungry friend
Problem: They do not know what is for dinner
Useful result: A creamy chicken pasta on the table in twenty minutes

## Evidence
When I described it as a creamy chicken pasta on the table in twenty minutes, my friend knew straight away whether they wanted it.

## Decision
Optimising for a plain plate they can picture. Saying no to naming the pan, the technique or the brand of pasta.

## Risk
Creamy chicken pasta might still be vague if they picture something different. Check they imagine the same plate I do.

## AI instruction
Explain the dish in one plain sentence a hungry friend gets in thirty seconds. No equipment or technique, just who it is for, the problem and the plate they end up with.

What now?

Apply it. Guide me turns what you are building into a prompt that walks you through this idea.

Get all 27. The guide is a free coffee-length read with the whole method. Join free and it is yours to download.

Get a hand. Work with me and we will work out together what is worth doing. The first conversation is free.