Example Prompts in AI Products: What Works

Example prompts in an AI product work when each one is a finished task the product can run right now, with real content already attached and a clear picture of what comes back. A grey chip that says Summarise is not an example. It is a topic, and it leaves the new user to supply the document, the exact request and the format, which are the three hard parts.

This matters more than it looks for an AI founder, because the first request is where a prompt-first product either proves itself or gets written off. If your product only impresses people when you are the one typing, the examples on the first screen are the cheapest place to move what you know out of your head and into the product.

Three grey chips that paste one word

Picture an AI contract review tool for startup operators who do not have a lawyer on staff. You sign up and land on a page with a dashed upload area that reads Drop a contract here, and under it a text box with the placeholder What do you want to know? Below the box sit three grey pills: Summarise, Find risks, Compare.

You are a head of ops on a free trial, and you do not have a contract open. You click Find risks. The box now contains the words Find risks and nothing else. You press Enter. The reply says: Please upload the contract you would like me to review. You do not have one handy, and you are not going to upload a real customer agreement to a tool you met two minutes ago. You leave the tab open, and you never come back to it.

Now picture the same screen with three cards instead of three chips. Each card has a small file tag at the top: Sample, Mutual NDA, Northwind and Acme, 6 pages. The first card reads Find the clauses a seed-stage startup should push back on in this NDA, and underneath, in small grey text, Returns a risk table: clause, why it matters, suggested edit. The second reads Summarise this NDA in one paragraph your CEO can read before the call. The third reads Compare this NDA with a standard mutual NDA and flag anything unusual, with page numbers. Each card has one button, Run example. The answer arrives on the sample file, and right under it sits a single line: Now try it on one of yours, with an upload button.

Same model, same prompts behind the scenes, same team. The first version asks a stranger to bring everything. The second brings everything for them and lets the product show what it does by doing it.

A chip names a feature. An example finishes the job.

Most advice on suggested prompts treats them as a cure for blank page anxiety. Add a few, the advice goes, so people know what to ask. That framing is the mistake. The new user is not stuck for ideas. They are stuck for inputs. They do not have your sample data, they do not know the wording your model responds to, and they do not know whether the answer will be a paragraph, a table or a redlined file.

A chip fixes none of that. It names a feature the user could already guess from your landing page, then hands the work back. A runnable example does the work and lets the user watch. It shows the length a good request runs to, the kind of content the product expects, and the shape of the answer, all before the user has typed a word.

So here is the rule this post argues for. If clicking the suggestion does not produce a finished, useful answer without any further input, it is not an example prompt. It is navigation dressed as help, and you would be better off with nothing.

Why his demo never uses the chips

Watch the founder of the contract tool on a sales call. He shares his screen and drags in a file from a desktop folder called demo contracts. It is always the same one, a software agreement with an auto renewal clause hidden on page 11. He types a long request: act as a startup lawyer, flag anything that renews or extends without notice, and put it in a table with the clause, the risk and a suggested edit. The table comes back, the renewal clause sits in row two, and the buyer on the call leans toward the camera.

He never clicks Summarise, Find risks or Compare. He does not need them, because the real example lives in that folder and in his typing. Most of his demos close. Self-serve trials rarely get past the first request. When a teammate suggests the first screen needs help, his answer is a fourth chip, Negotiate, which ships the following sprint. The folder on his desktop is the onboarding. It just never made it into the product.

This is the quiet version of a familiar pattern. The product works when he drives it and stalls when a stranger does, so growth runs at the speed of his calendar. We wrote about the empty box version of this in why an Ask anything prompt box fails. The fix there and here is the same idea: put the founder's input on the screen.

What a click that returns nothing costs

In a prompt-first product, the first request that returns something useful is close to the whole activation event. If you have not pinned that down yet, start with how to define activation for an AI product, because example prompts are the shortest path to it.

The benchmarks most founders quote were measured on SaaS and product-led companies, so say that when you use them. Activation there runs 20 to 40 percent for most products, and 40 to 60 for the best. A ten point gain in activation typically drives a 15 to 25 percent increase in free-to-paid conversion. Opt-in trials convert at around 18 percent. Every one of those trial users was paid for before they clicked a chip, and the cost lands whether or not the chip did anything.

AI products carry an extra cost. Measured on AI companies, product builders average around 52 percent gross margin, against 70 to 80 for traditional software, because inference sits in cost of goods. A runnable example that produces a great answer is a session worth paying for. A chip that leads to three vague follow-up attempts is three model calls spent teaching the user that the product is ordinary.

Four things every runnable example carries

A good example card is small, but it has to carry four pieces of information. Leave any one out and it slides back toward being a chip.

• Real content, already attached. A sample file, a sample dataset or a pasted paragraph, named the way your user would name it. Mutual NDA, Northwind and Acme is believable. Example_Document.pdf tells the user nobody tried this.

• A finished request, written in full. The card text is the actual prompt that runs, at the length your best users write. Find the clauses a seed-stage startup should push back on is a request. Find risks is a label.

• The output shape, stated before the click. Returns a risk table, or one paragraph, or a list of flagged clauses with page numbers. People choose an example by what they will get, and the shape also tells them what the product is for.

• A bridge to their own content. Right after the answer, one line and one button that offers to run the same request on their file. The example is a rehearsal. The second request is the real activation.

Sample content also solves a problem most teams miss. Many evaluators will not hand real data to a product they met minutes ago, especially contracts, finance files or customer lists. A good sample lets them judge the output before they have to decide whether to trust you with anything real.

Pick the three examples from your demo folder, not your feature list

The usual way chips get chosen is from the nav: one per feature, so every feature gets a mention. That produces Summarise, Find risks, Compare, and it teaches nothing. Choose examples the other way round, from the requests that have already worked.

• Collect the 20 requests that land best in demos and in your heaviest users' history. The founder's own typing counts. It is usually the best source you have.

• Group them by job, not by feature. Checking a contract before signing is a job. Briefing the CEO is a job. Find risks is a feature.

• Pick three jobs that a new user is most likely to have this week, and one request for each.

• Run each request against its sample file many times and read every answer. An example must succeed every single time, because users treat it as the product's best foot forward. If one run in five is weak, cut it or fix it.

• Write the card in the user's words, with the output shape underneath, and keep the full request visible so people can copy the pattern.

If you ask one question at signup, such as what kind of contracts you review most, use the answer to swap the three cards. Sales agreements, NDAs and vendor contracts each deserve their own sample file. This is not personalisation for its own sake. It is the difference between an example that looks like someone else's work and one that looks like the user's Tuesday.

When to retire an example

Examples go stale, and a stale one is worse than an empty slot because it trains people on the wrong job. Track two events: example run, and first request on the user's own content. The second one is the one that matters.

Retire an example when people run it but rarely follow it with their own content. That card is entertaining, not teaching. Rewrite one when it is almost never clicked, because the job on the card is not a job your new users have. And rerun every example after a model or provider change. A card that quietly returns a worse answer after a model update is the first thing a new user sees, and nobody on the team will have looked at it in weeks.

If you have screens that start empty for other reasons, the same thinking applies to empty state design more broadly: the first screen should show the product working, not describe it.

The examples he cannot see are missing

The contract tool's founder looks at Summarise, Find risks, Compare and sees a complete first screen. To him each chip is shorthand for a request he has typed a hundred times. A new user sees three words with nothing behind them. The examples are obvious to the one person who has never needed them, which is why they rarely get fixed from the inside.

Studio Maydit designs the first run of AI products, the screens where a stranger decides whether the product is real. We start from what the founder types in demos and turn it into examples, sample content and defaults a new user can run alone. Dualite reached 100,000+ users in seven months after design work that supported a repositioned ICP, and our fixed-scope projects of three to four weeks end with a diagnosis of where the product is still leaking. If your product lands on calls and stalls on signup, book a 30-minute call with Studio Maydit.