Answer whether and for whom before you answer how

Before designing an AI system, decide who has the problem, how much solving it is worth and whether a model is needed. Work a delivery-delay example, compare it with a rules baseline and state what would make you stop.

LESSON 1 OF 22 · 14 MIN ESTIMATED STUDY

On this page 8 sections

TL;DR: When given a product prompt, answer in this order: who has the problem and how often, what solving it is worth, whether a model is needed at all, what good enough means, and only then how to build it. Your technical depth is an asset when it sharpens those answers, and a liability when it replaces them.

Where you are. In Change the question. It sets the habit the rest of the course builds on: the decision comes before the design.

Case note. Kitewire is fictional; its figures and dialogue are teaching assumptions.

The switch in one example

Kitewire's head of product asks: "Should we use AI to predict late deliveries?"

An engineer's first answer can sound like this: "We have three years of scan events. I'd train a gradient-boosted model on route, carrier, weather and depot load, serve predictions from the event stream, and alert when the probability of lateness passes a threshold."

Every part of that is reasonable, and none of it answers the question. The question was should we. A product answer starts somewhere else:

"Retailers on Kitewire get about 40,000 late deliveries a month. Each late delivery generates, on average, 0.6 support contacts for the retailer, at roughly 4 USD each, and some share of customers do not reorder. If we could warn customers early and reduce contacts by a third, that is around 32,000 USD a month for our retailers in support cost alone. That is worth testing. Before building a model, I would check whether simple rules (carrier delays, depot backlogs) already catch most late deliveries, because rules are cheaper to run and explain."

The second answer still uses technical knowledge. It uses it to size the problem and to question whether a model is needed.

A decision sequence to practise

Follow the flow, one stage at a time.

Illustrated sequence; animation speed does not represent processing time.

Read diagram description

Identify the user, measure how often the problem occurs, estimate value, compare a rules baseline, set a quality bar, choose a small scope, test it, and stop if the model does not justify its extra cost. Kitewire figures are illustrative.

Who and how often. Name the user precisely. For Kitewire there are two: the retailer's support team, who field the complaints, and the retailer's customer, who is waiting for a parcel. They want different things.

Worth. Put a number on it, even a rough one, built from things you could measure: volumes, time, cost per contact. A number with visible assumptions invites correction; "big opportunity" invites nothing.

Model or not. Engineers are well placed to answer this honestly, because you know what rules and simple statistics can do. Say it: "A rule on carrier delay events might catch 60% of late deliveries. A model needs to beat that by enough to justify its cost and opacity."

Good enough. Define the bar in user terms. A late-delivery warning that is wrong half the time trains customers to ignore it. Perhaps the bar is: of deliveries we warn about, at least 70% are actually late, and we catch at least half of all late deliveries.

How. Now the architecture, briefly, shaped by the bar above.

Stop. Say what result would end the work: "If a model cannot beat the rule baseline by 15 points of recall at the same precision, we ship the rules and stop."

What to keep from engineering

Your engineering experience can strengthen a product decision. Bring it into the answer where it changes the proposed scope, evidence or cost:

Your sense of what is feasible. Use it to prune ideas early, out loud.
Your instinct for failure modes. Engineers ask "what breaks?" naturally. Turn each failure mode into a user consequence and a cost.
Comfort with numbers. Use it for sizing and thresholds, and make every number carry its denominator.

Hold back on architecture detail unless asked. One sentence of design is enough at first; offer to go deeper. If the interviewer wants the system, they will ask, and you will be ready.

Common traps for engineers

Trap	What it sounds like	Product version
Solution first	"I'd fine-tune a model on..."	"The users are... the problem costs..."
Precision about the wrong thing	Exact feature lists, no user	One clear user and one number
Hiding behind feasibility	"It's technically hard, so no"	"It costs X to build; worth it only if Y"
No stopping rule	Iterate until it works	"If it cannot beat the baseline by date Z, we stop"

Know which product responsibility you are taking on

The title “AI PM” does not tell you who owns the service. At Kitewire, an application PM decides which delivery problem to address. A platform PM may own the prediction API used by several teams. A PM using an assistant to draft research notes still owns the accuracy of the notes; that alone does not make the notes an AI product.

Before accepting a project, write the decisions you own and the partners whose judgment you need:

Decision	PM contribution	Partner evidence needed
Which deliveries to support	User value and initial scope	Operations' workflow and failure history
What data to use	Purpose and required coverage	Data owner's provenance and permitted-use record
What quality earns a pilot	Consequences and acceptance bar	Research's evaluation and uncertainty
Who carries the service after launch	Named ownership and support budget	Engineering's monitoring and recovery plan

The PM cannot approve a data use outside their authority or promise a capability because a demo worked. They can insist that those unresolved decisions have owners before a customer commitment is made.

Do this before moving on

Take this prompt: "Should Kitewire add an AI assistant that answers retailers' questions about their delivery data?" Write the six parts in order, one or two sentences each: who and how often, worth, model or not, good enough, how, stop. Use made-up but plausible numbers, labelled as assumptions.

Expected reasoning: the strongest answers name a specific user (a retailer's operations analyst, say), estimate how many questions they ask and what each costs them today, ask whether saved reports or a dashboard filter would solve most of it, and set a stopping rule tied to a measurable result such as questions answered correctly on a test set.

Add a responsibility check: Kitewire's carrier-data lead leaves before the pilot. Who accepts responsibility for stale or missing scans? Reference reasoning: name a successor and a freshness/fallback contract before depending on the feed. The application PM owns the scope decision, while a qualified service owner must operate the dependency.

Go deeper

The AI fit test gives a scored checklist for the "model or not" step in this lesson.
Sizing an AI opportunity works the "what is it worth" step bottom-up with every discount shown.
Capability versus reliability explains why a working demo is not yet a product, which is the gap good-enough thresholds close.
Why are you moving into AI product management? shows how to tell the switch as a story in a behavioural round.
The AI product lifecycle connects these responsibilities to the evidence needed at each investment decision.

Key takeaways

Answer who, worth, model-or-not and good-enough before how.
Use technical depth to size the problem and prune ideas; the decision still comes first.
Every number carries an assumption you could check.
End with the result that would make you stop.

Check yourself

Answer out loud first, then reveal. Retrieving it yourself is what makes it stick; reading ours and agreeing does very little.

1An interviewer asks whether to add AI-predicted delivery times. What should your first sentence contain?
2Why state a rules baseline before proposing a model?
3Does an application using a model API always need its own model-training phase?