AI product thinking

Meera’s list was on a single sheet of paper, and it was long. Fourteen ideas, collected from store managers, two investors and her nephew. An AI cake designer. A WhatsApp bot that takes orders end to end. AI replies to Google reviews. AI demand forecasting for each store. An allergy checker. AI-written Instagram captions. Predicting late deliveries. And seven more.

“I have budget for one engineer-quarter,” she said. “That’s you, Arjun, for three months. Which ones?”

Arjun knew which one he wanted. The cake designer. A customer describes a dream cake, the app generates a picture, the bakers make it. It used image generation, which he had never shipped. It would demo beautifully.

Priya noticed the look on his face. “Build a prototype this weekend, if you like,” she said. “Then let’s talk about it on Monday. Bring numbers.”

The weekend the cake designer won the demo and lost the argument

Arjun’s prototype worked. On Monday, he typed “a two-tier mango cake shaped like a peacock, for a fifth birthday” and a gorgeous image appeared. Meera clapped.

Then Raju, the head baker from the central kitchen, looked at the screen for a long time.

“Who is holding up the tail?” he asked.

The peacock’s tail was a fan of fondant feathers sticking out sideways, half a metre wide, with nothing underneath. It could not be baked. Arjun tried twenty more prompts that afternoon and showed every image to Raju. Raju said twelve of the twenty were impossible or would take a full day of a decorator’s time. Customers who saw a perfect picture would expect exactly that cake, and complain when they got a real one.

Then Priya asked for the numbers. Each image cost about ₹4 to generate, and people regenerated about eight times before they were happy: ₹32 per customer, most of whom never ordered. Custom cakes were 3% of Crumb’s revenue. Even if the designer doubled custom orders, the gain would barely pay for the engineering time.

“It’s a lovely demo,” Priya said. “Is it a good product?”

Arjun had made the most common mistake in AI engineering, and it has a name worth remembering: starting from the technology instead of the problem. “What can this model do?” is an exciting question. “What does Crumb need, and is a model the best way to get it?” is the useful one.

Hiring a brilliant intern who is sometimes confidently wrong

Priya drew a stick figure on the whiteboard. “Imagine Crumb hires an intern. She is astonishingly fast. She reads anything, writes anything, in English, Hindi and Marathi. She costs almost nothing. She never gets tired. But a few times in every hundred tasks, she gets something wrong, and she sounds exactly as confident when she’s wrong as when she’s right.”

“That’s a large language model,” Arjun said.

“Which jobs from Meera’s list would you give her?”

He thought it through aloud. “Writing first drafts of replies to Google reviews. If a draft is a bit off, the manager fixes it before posting. Instagram captions, same thing. Summarising a week of support emails into themes for Meera.”

“And which would you never give her alone?”

“The allergy checker. If a customer asks ‘is this cake nut-free?’ and she’s wrong once, someone could end up in hospital. And the customer has no way to check her answer.”

“So what’s the pattern?”

“Two questions,” Arjun said slowly. “How bad is it if she’s wrong? And how easy is it for someone to notice before it matters?”

That is the most useful tool in AI product thinking. Draw it as a grid:

	Easy to check before it matters	Hard to check
Mistake is cheap	Green. Automate, or near enough. Instagram captions, review reply drafts, internal summaries.	Yellow. Fine, but monitor samples. Tagging support emails by topic.
Mistake is costly	Yellow. Use AI for drafts with a human approving. Refund decisions, supplier emails.	Red. Don’t let the model decide. Allergy guarantees, medical or legal advice.

The intern analogy breaks in one useful place. A human intern learns from each mistake and stops making it. A model does not, unless you change its prompt, its data or the model itself. Your system has to do the learning: evals, logs, and someone who reads them.

Show the answer

Not necessarily. The red square means the model must not be the source of truth. You can still build it: store allergens for each product in a database maintained by the kitchen, have the bot look up the product and quote that record word for word (always with the “made in a kitchen that handles nuts” warning), and hand anything not in the database to a human. The model becomes the friendly interface; the database makes the claim. Changing where the answer comes from can move a feature from red to yellow.

Is it even an AI problem?

Before the grid, there is an earlier filter. Some of Meera’s ideas do not need a language model at all.

Predicting late deliveries sounds like AI. But when Arjun looked at the order database, 80% of late deliveries came from two things: orders placed after 6 p.m. for the same evening, and one particular delivery zone in Wagholi. A simple rule (“warn customers ordering after 6 p.m. to Wagholi”) would catch most of it, cost nothing per prediction, and never hallucinate. If they wanted more later, classic machine learning (a model trained on Crumb’s own order history, as in the MLOps lifecycle) would beat an LLM at predicting numbers from tables.

Demand forecasting is the same: a numbers-in, numbers-out problem with years of sales data. LLMs are language tools. Use them where the input or output is language: emails, reviews, documents, conversations, code.

A quick test: if you could write the solution as a SQL query, a rule or a spreadsheet formula, do that first. Reach for an LLM when the task needs reading or writing language at a scale humans cannot.

Following one idea all the way through: review replies

Arjun picked the most promising green-square idea and pushed it through every question that matters, with real numbers. Crumb gets about 600 Google reviews a month across six stores. Store managers are supposed to reply to every one. In practice, only 22% get a reply within 48 hours, because writing a thoughtful reply takes about three minutes and managers are busy running bakeries.

Here is one real review, from the Aundh store:

“Ordered a Black Forest for my son’s birthday. It arrived 40 minutes late and the cream had melted a bit. Taste was great though. 3 stars.”

Is it AI-shaped? Language in, language out. High volume (600 a month). A mistake (an awkward reply) is cheap, and easy to catch, because a manager reads it before posting. Green square.

What could go wrong, and what does the user see? Three failure cases, each with a design answer:

• The draft promises something Crumb cannot give (“we’ll refund you in full”). Design: the prompt forbids offers; code checks drafts for words like “refund”, “free” and “compensation” and marks them for careful review.
• The review mentions illness or allergies. Design: no draft at all; it goes straight to Meera with a red tag. Some situations need a human from the first word.
• The draft is bland and generic. Design: the prompt includes the store name, the manager’s first name and two examples of great replies the managers wrote themselves.

How fast does it need to be? This is where Arjun’s thinking changed most. He had assumed AI features must respond instantly. But nobody is waiting for these replies. Drafts can be generated overnight in a batch, so they are ready when the manager logs in at 8 a.m. Perceived latency (how slow something feels to the user) is zero, even if each draft took ten seconds to write. Not every AI feature needs to be real-time.

What does one task cost? A draft needs about 900 input tokens (a 600-token system prompt with examples, a 150-token review, 150 tokens of store details) and about 120 output tokens. Assuming $4permillioninputtokensand$20 per million output tokens (check current prices; they change often), and ₹88 to the dollar:

• Input: 900 × $4/1,000,000=$0.0036
• Output: 120 × $20/1,000,000=$0.0024
• Total: $0.0060, about ₹0.53 per draft

Managers ask for a regenerated draft about 30% of the time, so the real figure is about ₹0.69 per review. That is the cost per task: not the price per token, but the price of getting one useful thing done, including retries. For 600 reviews a month: about ₹414.

What is it worth? Writing a reply by hand takes about 180 seconds. Reviewing and lightly editing a draft takes about 20. That is 160 seconds saved per review, or about 27 hours a month across the stores. At roughly ₹300 an hour of a store manager’s time, that is around ₹8,000 a month of time handed back, for ₹414 of model cost.

How will we know it worked? Before building, Arjun wrote down the success metric: the share of reviews with a reply within 48 hours, currently 22%, target 80%. And a guardrail metric (a number that must not get worse while you chase the main one): zero posted replies that promise refunds or discounts without Meera’s approval. Plus two signals of quality: how often managers accept a draft with few edits, and how many reviews get escalated.

How do we test it safely? A pilot: the Aundh and Baner stores use it for a month; the other four do not. Comparing them shows whether the change came from the tool or from, say, a quieter month.

Show the answer

Almost everything except the model bill. His own time to build it (a week or two), the eval set and the time to run it, monitoring, fixing it when a model update changes its tone, and the managers’ 20 seconds per review. The model bill is often the smallest line in an AI feature’s real cost. It is still worth computing, because it tells you whether the feature can scale, but present the whole picture.

Opening the hood: four questions every AI feature must answer

The review-reply walk-through followed four questions you can ask of any AI feature. Here they are with the precise ideas behind them.

1. Where does it sit on the mistake grid, and what happens when it is wrong? Every AI feature will eventually produce a wrong answer, a hallucination (fluent, confident output that is not true) or simply a bad one. Design the wrong-answer experience as carefully as the right one. Good patterns from earlier in this course: show sources so people can check (Chat with any document); let people edit a draft rather than accept or reject a final answer; abstain with a clear “I don’t know” (RAGAS metrics and the “I don’t know” rate); put a human in the loop (a person who approves before anything irreversible happens) for costly actions; and make undo easy.

2. How fast does it feel? Latency is the real time something takes; perceived latency is how long it feels. They are not the same. A long-standing rule of thumb from interface research: about 0.1 seconds feels instant, about 1 second keeps your train of thought, and past about 10 seconds people lose focus. LLMs often take 2 to 15 seconds. The tools you have learned change how that feels:

• Streaming the answer word by word, so the first words appear in about a second (Streaming with Server-Sent Events).
• Showing progress (“Searching 3 sources… Reading…”), as Sift did, which makes a 12-second wait feel purposeful.
• Moving work out of the user’s way entirely: overnight batches, as with review replies.
• Making it truly faster: smaller models for easy questions, and prompt caching (Prompt caching).

3. What does one task cost, including retries? Cost per task = (input tokens × input price + output tokens × output price) × (1 + retry rate), plus tool and search calls. Then divide by the success rate to get cost per successful task. If 70% of drafts are accepted, a ₹0.69 draft really costs ₹0.99 per accepted reply. Compare that with what the task is worth, not with zero.

4. How will you measure value? Choose one success metric that a non-engineer cares about (replies within 48 hours, emails closed per shift, minutes saved), measure the baseline before building, and pair it with a guardrail metric. Avoid vanity metrics like “AI messages sent”: they go up whether or not anyone is helped.

Where product thinking goes wrong

Arjun’s cake designer failed at all four questions at once: mistakes were costly (an unbakeable promise) and only an expert could catch them; generating images was slow; the cost per ordered cake was high; and nobody had defined what success meant. A brilliant demo can hide all of that, which is exactly why demos are dangerous.

Three more traps experienced engineers watch for:

• The 80% demo, the 99% product. Getting a feature to work on the ten examples you tried takes a weekend. Getting it to work on the thousandth real customer, with typos, Hinglish and anger, takes months. Estimate the second number, not the first.
• Automation as the goal. Users often prefer a great draft over full automation, because it keeps them in control and keeps their name on the work. The review-reply managers said so directly.
• Ignoring the people around the feature. Raju, the head baker, killed the cake designer in one question. Talk to the people whose work changes before you build, not after.

Two beginner misconceptions are worth naming plainly. “If AI can do it, we should use AI for it.” Many problems are better solved with a rule, a form or a database query. And “accuracy is the metric.” Accuracy is a means. The metric is value: time saved, money made, customers helped, without new harm.

Try it yourself

Pick one idea, either from your own work or from Meera’s list (try “AI-written Instagram captions” or “a WhatsApp bot that takes orders end to end”). Write a one-page AI product brief:

1. Problem and user. Who has the problem, and how do they handle it today? Give a baseline number.
2. Mistake grid. How costly is a mistake? How easy is it to catch? Which square?
3. The wrong-answer experience. What does the user see when the model is wrong? Who catches it?
4. Latency budget. Must it be real-time? If so, what is the first-word target?
5. Cost per task. Estimate tokens in and out, retries, and the cost in rupees or dollars.
6. Success and guardrail metrics. One of each, with a target.
7. Verdict. Build, build with a human in the loop, solve without AI, or don’t build.

Expected result: a page you could hand to Meera, with real numbers in at least four of the seven sections.

Show the answer for the WhatsApp ordering bot

Problem: about 150 WhatsApp orders a day; staff type each into the order system, about 4 minutes each. Grid: a wrong order (wrong date, wrong cake, wrong address) is costly; the customer can catch it only if shown a clear summary. Yellow, if the bot always confirms. Wrong answer: the bot never places an order itself; it fills a structured order (as in Typed outputs with Pydantic), shows the customer a summary to confirm, and staff approve anything unusual. Latency: conversational, so first reply in under 3 seconds. Cost: about 5 turns of 2,000 input and 150 output tokens: roughly 10,000 × $4/M+750\times$20/M = $0.055, about ₹5 per order. Metrics: success, staff minutes per WhatsApp order (baseline 4); guardrail, wrong-order rate must not rise above today’s. Verdict: build with a human in the loop for the first two months, starting with one store.

Common mistakes

• Starting from the model. “What can GPT do?” leads to demos. “What hurts at Crumb?” leads to products. Start with the problem and a baseline number.
• Designing only the happy path. Every AI feature fails sometimes. Decide in advance what the user sees and who catches it.
• Computing cost per token instead of per task. Include retries, tool calls and the success rate. Then compare with the value of the task.
• Assuming everything must be instant. Ask whether anyone is actually waiting. Background work has zero perceived latency.
• Measuring activity instead of value. “10,000 AI replies sent” says nothing. “Replies within 48 hours went from 22% to 81%, with no unapproved offers” says everything.

Recap

• Start from a problem with a baseline number, not from what the model can do. Check whether a rule or query solves it first.
• Place each idea on the mistake grid: how costly is a mistake, and how easy is it to catch? Red ideas need a different source of truth, not just a better prompt.
• Design the wrong-answer experience: sources, drafts, abstention, human approval, undo.
• Perceived latency is what users feel. Stream, show progress, or move the work out of their way.
• Cost per task includes retries and success rate, and the model bill is usually the smallest part of the real cost.
• Pick one success metric and one guardrail metric before you build, then pilot and compare.

On Friday, Arjun handed Meera a single page. “Review replies first: about ₹400 a month in model costs, around 27 hours of manager time back, a pilot in two stores. Then the WhatsApp order helper, with staff approving every order. The allergy questions get answered from a database the kitchen owns, never from the model’s memory. The cake designer waits.” He hesitated. “And the late-delivery warning doesn’t need AI at all. It’s one rule. I can ship it on Monday.”

Meera read the page twice. “This is the first AI plan I’ve seen that tells me what we’re not doing,” she said. “Keep the cake designer, though. Raju liked the peacock.” Then she tapped the desk. “Now, something else. We’re making your title official, Crumb’s first AI engineer, and we’re hiring someone to join you. I want you to help pick them. You know what this job really is now.”

Go deeper

• Building effective agents, Anthropic’s practical guide, which argues for the simplest design that works.
• Response times: the 3 important limits, the classic article on how waits feel to users.
• Cost management and prompt compression for cutting cost per task once a feature is worth it.
• Governance, readiness and RAG vs fine-tuning for deciding how to build once you have decided what.