Problem vs Solution · Product Fluency

Problem vs Solution · 4 min

Situation

“We need search.”

A sales lead wants a search box in your document product. Three customers have asked for it. Engineering is ready to estimate.

Before discussing filters or indexing, ask what people were trying to do. One customer says: “I spent ten minutes finding the contract we used last quarter.” That describes a problem you can investigate. A search box is one possible response.

Mental model

Describe the struggle without naming a feature.

A useful problem statement names a user, a situation, and an obstacle to an outcome.

“Account managers cannot find older approved documents quickly when preparing a renewal” leaves room for search, better organization, recent documents, or links from the customer record. “We lack search” quietly chooses an implementation before establishing the need.

Investigate

Follow the last real attempt.

Ask the account manager to show you the last renewal. Where did they look first? What did they remember about the document? How did they finally find it? How often does this happen?

If they remember the customer but not the filename, a basic filename search may add a feature without removing the struggle. Watching the workaround tells you what retrieval actually requires.

Compare

Two causes, different bets.

If documents are easy to identify but buried in folders, search or a customer-specific view could help. If nobody knows which version is approved, faster retrieval may make the wrong document easier to use.

In the second case, ownership and version status may matter more than search quality. The same feature request can point to different underlying causes.

PM decision

Agree on the outcome before estimating the solution.

Define a small task test: find the correct approved document for a renewal. Measure success and time with the current product, then compare a few approaches.

A prototype that improves speed while increasing wrong-version selections is not a clear win. Keep correctness alongside speed. Ask engineering which options fit the existing data and permission model before committing to scope.

Before scrolling

Rewrite the request.

A stakeholder says: “Add a dashboard so managers can monitor the team.” Write a problem statement that does not contain the word dashboard.

Name what managers cannot decide today, what information they lack, and when that decision occurs. Notice which parts you would need to verify rather than assume.

A strong answer

Make the unknowns visible.

“During weekly workload planning, managers cannot tell which customer cases are likely to miss their response deadline.” This is a plausible hypothesis, not an established fact.

Investigate whether managers lack visibility, authority to reassign work, or available people. A dashboard addresses only some of those causes.

Remember this

A request starts the investigation.

Preserve the user's intended outcome while keeping the solution open. A precise problem statement helps design and engineering propose better options; it does not dictate their answer.