Skip to content

Should This Feature Use AI? A PM Decision Framework

Not every product needs machine learning. Here is a clear way for product managers to decide when AI helps and when a simple rule wins.

The Question Behind the Question

Every PM team faces it now. A leader asks for AI, often without saying why. The pressure feels real because the market funds AI features. But many teams ship AI when a simple rule would do the same job.

This is the heart of a strong PM interview answer. Top PM thinkers warn against tech for tech's sake. As Marty Cagan writes, the goal is solving customer problems, not stuffing models into a roadmap (Cagan 47). Teresa Torres pushes the same point with her opportunity solution tree model. Start with the problem before you pick the tool (Torres 23).

A Two-Question Filter

Before you build any AI feature, ask two simple questions.

One: Is the rule too complex to write down? Some problems break clean rules. Spam looks like a thousand things. Image content shifts every minute. A user's next click depends on hundreds of small signals. These cases need a model. Other problems fit clean rules. Tax code, return windows, password rules. These do not need ML. They need clear logic.

Two: Is the cost of being wrong low or recoverable? AI gets things wrong. A model can hit 95% accuracy and still hurt users 5% of the time. For low-stakes content like ad ranking, that error is fine. For high-stakes work like medical alerts or trade orders, it is not. A simple rule may help build trust.

If the answer is yes to both, AI may fit. If the answer is no to either, look at rules first.

The Hidden Cost Curve

PMs often forget the long tail of cost. Lenny Rachitsky talks about this in his writing on shipping AI features (Rachitsky). A model needs labeled data, retraining cycles, drift checks, and on-call support. Each adds load to the team. Rules need none of that.

So the question is not, "Could AI work here?" The question is, "Will AI pay back its cost over time?" If the use case is small or short-lived, the cost may sink the project.

When AI Wins

AI shines in three patterns.

Personalization at scale. Think Spotify radio, Amazon home page, or a learning app's lesson order. Each user wants a different output. No rule set can keep up.

Pattern detection in messy data. Think fraud, churn risk, or image search. Humans can spot the pattern in one case. They cannot label every case fast enough.

Ranking and recommendations. Think search, feed sort, or product match. The best answer depends on user signals that change every day.

In each pattern, the cost of a wrong call is small. The user moves on. The system learns. The next call gets better.

When Rules Win

Rules win when the input space is small, the rules are stable, and the cost of error is high.

Compliance flows. A rule says, "block transfer over $10,000 to a new account." That is the law. AI here would just add risk.

Onboarding states. A rule says, "if email is verified and profile is filled, mark active." Clear inputs, clear outputs.

Safety alerts. A rule says, "alert if temperature is over 100 for 10 minutes." Doctors trust that. They do not trust a model they cannot read.

Jeff Gothelf makes this point in his work on lean PM thinking. The simplest tool that meets the user's need is the right tool (Gothelf 89). Adding a model when a rule will do is waste.

A Framework for the Whiteboard

In an interview, lay out four steps.

  1. Define the user problem. State it in one line.
  2. List the inputs. Are they small and stable, or wide and shifting?
  3. List the cost of error. Is the cost low and recoverable, or high and lasting?
  4. Pick the tool. Use a rule when inputs are stable and cost is high. Use AI when inputs shift and cost is low.

Then add one more step: the build cost check. AI brings ongoing cost in data, ops, and trust. Rules cost less. Choose the cheaper tool when both can do the work.

Common Traps

Watch out for four common errors in PM interviews.

Trap one: AI as a default. Saying, "we'll use AI" without a reason loses points. Say why the problem needs it.

Trap two: Skipping the rule baseline. Always plan a rule-based v1. It sets a floor and helps the model prove its value later.

Trap three: Ignoring failure modes. Plan for the wrong call. Show how the system catches it, undoes it, or asks the user.

Trap four: No success metric. Better is not a metric. Pick one number, like click rate, time saved, or false positive rate.

A Sample Interview Answer

If asked, "When would you use AI in a checkout flow?" a strong answer goes:

"Most of checkout is rule-based. Tax math, shipping zones, and stock checks all have clear logic. AI fits when the problem has wide inputs and low cost of error. So I would use AI for fraud risk scoring, since the inputs are messy and the user can re-try if blocked. I would not use AI for the final charge step, since the cost of a wrong charge is high and the rule is clear."

That answer hits user value, scope, and risk in three short beats.

The Bottom Line

AI is a tool. It is not a product. Strong PMs choose the tool that fits the problem and not the trend. Cagan, Torres, Gothelf, and Rachitsky all push the same point in their work. Start with the user, then pick the tool that costs the least to ship and run (Cagan 47; Torres 23; Gothelf 89; Rachitsky).

Use the framework. Ask the two filter questions. Lay out the four steps on the board. Show the build cost check. The interviewer wants a thinker who picks the right tool, not the loudest tool.

Works Cited

Cagan, Marty. Inspired: How to Create Tech Products Customers Love. 2nd ed., Wiley, 2017.

Gothelf, Jeff. Lean UX: Designing Great Products with Agile Teams. 3rd ed., O'Reilly Media, 2021.

Rachitsky, Lenny. "How AI Will Change Product Management." Lenny's Newsletter, 2024, www.lennysnewsletter.com.

Torres, Teresa. Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC, 2021.

Back to Live Blog