A capability is not a reason to exist

\u201cWe are building with AI\u201d can describe a technical choice. It cannot, by itself, describe a product strategy.

The distinction matters because the capability is so broad. AI can draft, classify, summarize, search, recommend, and automate. Those are ways of doing work. They do not tell us whose work is painful, what is currently broken, or why someone would change their behaviour to use a new product.

Start with the problem that has a cost. Then decide whether AI makes the outcome meaningfully better.

Find the recurring moment of friction

Good product opportunities usually show up in a repeated moment: a team loses decisions after meetings, a founder cannot keep customer context current, or an operator spends hours turning scattered information into a usable next step.

The useful question is not \u201cwhere can we add AI?\u201d It is:

What happens often enough, hurts enough, and is important enough that people are already trying to solve it somehow?

Existing workarounds are valuable evidence. A shared spreadsheet, a personal reminder system, a weekly manual report, or a long chain of copied messages can reveal what people care about. They also reveal the constraints a product must respect.

The Nielsen Norman Group\u2019s guide to user interviews makes a related point: useful discovery is grounded in concrete past behaviour, not abstract opinions about an imagined solution. Ask people about the last time the problem happened. Listen for what they did next.

Decide whether AI changes the outcome

Once the job is clear, AI earns its place only if it improves an outcome that matters. That might mean:

  • reducing the time required to turn a conversation into a usable plan;
  • making relevant context available before a decision;
  • helping a person handle varied, unstructured information;
  • lowering the effort needed to keep a record accurate.

If a deterministic rule or a simpler workflow solves the problem, use that. A product becomes harder to explain when it uses AI only because the technology is available.

The better test is counterfactual: if the AI layer disappeared, would the product still solve a problem? If the answer is no, the team may be relying on novelty rather than customer value. If the answer is yes, then AI should be judged by whether it makes the existing solution faster, more useful, or more accessible.

Make the wedge specific

Broad categories rarely create momentum. \u201cAn AI workspace for everyone\u201d is difficult to evaluate and even harder to position. \u201cA tool that turns client calls into reviewed follow-ups for small sales teams\u201d gives a real person a reason to pay attention.

A narrow wedge lets a team:

  • talk to a defined group of users;
  • understand the current workflow;
  • make a clear first promise;
  • know whether the product was useful;
  • learn what adjacent job to solve next.

It is not a permanent limitation. It is a way to earn the right to expand from a clear use case instead of an undefined category.

Strategy includes the trade-offs

AI changes the shape of a product, but it also introduces trade-offs: privacy, permission boundaries, review, variable output, cost, and user trust. A real strategy decides how the product will handle those trade-offs.

For an AI workspace, that could mean deciding that the assistant drafts but does not send customer messages; that people choose which sources to include; or that every important change is reviewable and reversible. Those choices are part of the product\u2019s value, not implementation detail.

The strongest AI products do not lead with \u201cwe use AI.\u201d They lead with a job people need done, then show a better way to do it. That is the order that keeps the technology useful instead of becoming the entire story.