Write the problem statement section for an AI meeting-summary feature.

How to answer this, stage by stage

Seven moves. The problem statement itself is the artifact here, so treat it the way you'd treat any design decision: name it, defend it, show what it survives.

Let's learn

The artifact is four sentences at the top of a document, and almost nobody reads past them if they're wrong.

Picture the problem statement section of a PRD. It's supposed to come before the feature, before the mockups, before anyone has written a single line of code. Its whole job is to say, in plain words, what's actually broken, so that everyone reading the rest of the document is building toward the same thing.

Before a strict rule exists for that section, most teams write it fast. Something like: "Employees spend too much time writing up notes after meetings. We should build an AI tool that listens in and produces a summary." That took about four minutes to write. Nobody in the doc review pushed back, because who's going to argue that meeting notes are annoying.

Now watch what that paragraph actually does once engineering reads it. It never said which meeting. So the safest reading, the one that covers the most ground, is: all of them. Every calendar event with two or more people gets auto-joined, transcribed, and summarized. That's not a guess about what engineers would do. That's what the words on the page permitted.

Here's the part that's easy to miss.

The problem was never "meetings, in general." At a company running dozens of small team syncs and one 90-minute, 40-person leadership review a month, only one of those rooms was actually losing something real: decisions made out loud in the big review, with no record of who owned what, so roughly a third of them got re-argued the following month. The small syncs were fine. Six people who were already in the room remembered what got said.

What the room actually loses, before anyone builds anything

Here's where it goes wrong at its worst. Three sprint weeks into the build, someone notices the tool is already auto-joining a claims huddle, a meeting where two adjusters discuss an individual policyholder's file out loud. Nobody had decided that was in scope. Nobody had decided it was out of scope either. The problem statement never said, so the build defaulted to everything, and now there's a compliance review to open before anyone can ship the one meeting that actually needed help.

A vague problem statement isn't neutral. It's a decision, made by accident, to build for the widest possible reading of a sentence nobody checked.

The choice I would take back. The PRD template at most companies doesn't forbid the word "AI" in the problem statement, and it doesn't require naming a specific meeting either, it just never asks. I would make both mandatory: no solution words in this section, and it has to end in one meeting, one number.

What I would leave alone. The weekly team syncs. Nothing about this feature needs to touch them. Forcing a summary onto a room that already remembers what happened adds a compliance question nobody needed to ask, for a benefit nobody was missing.

The lesson. If a problem statement survives being read out loud without anyone asking "wait, which meeting do you mean," it hasn't said anything yet. It's a mission statement wearing a problem statement's clothes, and nobody will notice until three sprint weeks have gone into the wrong room.

Now here is the same thing as a story

You don't need this part to answer the question. Read it when you want to feel why the short version is true.

For four years, Linh Tran's PRDs were the ones engineering actually trusted, because nobody on her team had ever had to guess what she meant. She was a product manager on the internal tools team at Corrigan Mutual, a regional insurance company with about 850 employees, and her documents were known for one thing: you could hand one to an engineer who'd never met her and they'd build the right thing on the first pass.

Then her director asked for a problem statement, fast, for "an AI thing for meetings," in time to demo something at the next leadership review.

She wrote it in about four minutes, between two other things. "Employees spend too much time writing up notes after meetings. We should build an AI tool that listens in and produces a summary automatically." Nobody in the doc review flagged it. Everyone already agreed meetings were a problem, so the usual scrutiny, the kind Linh's docs normally got, just didn't happen this time. It went to engineering that afternoon.

For the first two sprints, that felt fine. The build moved fast. Calendar integration, auto-join, a transcription pipeline, a summarization step at the end. Nobody asked which meetings, because the document never said which meetings, and the safest reading of a sentence that says "meetings" is "meetings."

The same team, building from two different paragraphs

Nothing dramatic caused what came next. Nobody was careless. In sprint three, an engineer named Tobias Kwan asked a plain question in the build review: "Wait, are we transcribing the claims huddles too?"

Linh didn't know. She checked. The answer was yes. The tool had been auto-joining every weekly team sync it could see on the shared calendar, including a meeting where two adjusters go over an individual policyholder's open claim out loud, by name. Nobody had decided that should happen. Nobody had decided it shouldn't, either. The paragraph she'd written in four minutes had never said.

Compliance opened a review that afternoon. It added two weeks to the timeline before anyone could ship anything. And when the feature finally reached the one meeting it was actually meant to help, the monthly leadership review, the summary it produced was one long paragraph: "The team discussed Q3 budget and the onboarding timeline." No owner. No decision line. The thing that was actually broken, decisions getting made out loud and then forgotten, was still exactly as broken as before any of this started.

Tobias's question wasn't an accusation. He was right to ask it, and Linh was right to have written fast under a deadline, the way anyone would. The problem was never a person being careless. It was a paragraph that let "meetings" stand in for one specific room, and let a solution get named before the room did.

So here's what she rewrote, the same afternoon compliance called.

The rule the second draft had to pass

"At the monthly, 90-minute, 40-person leadership review, decisions get made verbally with no written record of who owns what. Four of the last eleven decisions from this meeting were re-discussed the following month because nobody could show what had actually been agreed. Weekly team syncs are not part of this problem: the same small group is in the room every time, and they remember." No mention of AI. No mention of a solution at all.

Engineering scoped the second build to exactly one recurring calendar event. Not transcription of everything, extraction of three things from one room: what was decided, who owns it, and by when. The build took one sprint instead of three. Compliance never opened a second review, because the tool never touched a claims huddle in the first place.

Now walk the same kind of Tuesday forward with that version live. Of the next six decisions made at the leadership review, zero got re-argued the following month. Not because anyone got more disciplined about remembering things. Because the summary that landed in everyone's inbox the next morning had a line that read "Decision: move onboarding redesign to Q3. Owner: Claims Ops. Due: end of quarter," and nobody had to trust their memory against anyone else's.

A vague problem statement didn't just risk building the wrong feature. It built a correct one, aimed at the wrong room, and left the real damage sitting exactly where it had always been.

SPARK, aimed at the paragraph instead of the feature

This is a design question dressed up as a writing task, so the framework is still SPARK, just pointed at the document instead of the interface. A question that asked "how would you measure this" would reach for LEAD instead. Different question shapes need different tools, even when the deliverable is a paragraph and not a screen.

SPARK, applied to Linh's second draft

And if you want to be sure it really works, try it somewhere else

A regional HVAC company writes problem statements the same rushed way. Same framework, a very different room, and a different reason the vague version costs someone real time.

Same framework, a different way to pick the wrong scope

S. Bettina Osei, product lead on Redcliff Mechanical's small internal tools team. Technicians write repair quotes by hand from the truck, after the job, referencing notes scribbled on a clipboard during the visit.
P. The habit worth building: whoever reads the problem statement checks which job type is actually slow to quote, instead of assuming every visit needs the same help.
A. Name one job type, "multi-part repair quotes," state how often it happens, and end on a real number: technicians spend 35 minutes per multi-part quote versus 6 minutes on a routine filter swap, because the parts and pricing change every time.
R. A vague version, "technicians spend too much time on quotes," gets read as every job type, so an AI drafting tool gets built for filter swaps too, a job that already has a fixed price and takes six minutes. Customers get a stilted, auto-written quote for something that used to be a one-line answer.
K. Don't build voice capture for warranty calls on day one. That's a different workflow, with a different approval chain, and folding it in "for completeness" is exactly how a six-week build becomes a four-month one.

Flashcards (click a card to flip it)

Check yourself Score: 0 / 0