How to Think About AI in Your Product.

There is a predictable pattern in early-stage companies right now. Someone sees a competitor announce an AI feature, or has a few useful conversations with ChatGPT, and comes away with a broad conclusion that the product now needs AI. The request then lands with engineering as a vague mandate: add AI, make it smart, make it look modern.

That is understandable. It is also a poor way to make product decisions.

AI is a real and useful set of technologies. It is not magic, and it is not a product strategy by itself. AI systems introduce risks distinct from those of conventional software, and those risks need to be managed deliberately rather than waved away in the excitement phase. AI product decisions should be evaluated through user value, business impact, and implementation reality, not through novelty alone.

For product leaders, the useful question is usually not “how do we add AI?” It is “what problem are we trying to solve, and can AI solve it better?”

That change in framing saves time, money, and credibility.

Start with the product problem

A proposal should survive contact with plain product thinking before it is allowed to become an AI initiative.

The first test is simple: if this idea did not involve AI, would it still sound like a sensible feature? If the answer is no, there is a good chance the team is dressing up a weak product idea in fashionable language. A feature that has no user value without AI usually has no user value with AI either.

A few questions help expose this quickly:

• What user problem does this solve?
• For which user, in which workflow, at which point of friction?
• What changes for the user if this works well?
• How is that change measured: time saved, error reduced, revenue improved, conversion lifted, support volume reduced, retention improved?
• What is the non-AI version of the same feature?

That last question matters. Product features should be discussed in terms of outcomes, not in terms of implementation fashion. Nobody should be proposing “let’s do this with Python” or “let’s do this with Java” as a product idea. Those are engineering choices. “Let’s do this with AI” often belongs in the same category.

The right sequence is:

1. Define the problem.
2. Define the desired user and business outcome.
3. Explore candidate solution approaches.
4. Only then decide whether AI materially improves the result, speed, cost, or feasibility.

Check whether AI is actually needed

Some features are better because of AI. Many are merely adjacent to AI.

That distinction matters because traditional software is still better when the task is deterministic, the rules are stable, the inputs are structured, and correctness needs to be exact. AI tends to earn its place when the task involves ambiguity, messy unstructured inputs, summarization, extraction, classification, ranking, language interaction, or generating first drafts that a human can verify and refine.

A useful test is to place the idea into one of four buckets:

Many proposals become much clearer once they are classified honestly.

If the proposal sits in the first bucket, adding AI may make the result less predictable and more expensive than necessary. If it sits in the fourth, that does not automatically make it invalid. Sometimes a market requires a visible AI story. But in that case the team should say so explicitly, keep ambition modest, and avoid pretending the feature is strategically transformative.

Separate user demand from internal excitement

Internal enthusiasm is not evidence of user demand.

A lot of AI ideas are appealing because they are easy to imagine in a product review meeting. They are much less compelling when placed inside an actual customer workflow. The most useful discipline here is to ask what users are already trying to do, what they complain about, and what they currently spend time or money on.

• Have customers asked for this directly?
• If not directly, have they described the pain that this feature would solve?
• Would users change behavior to use it?
• Would they trust it enough to rely on it repeatedly?
• If the feature disappeared after six months, would anyone be upset?

Features built mainly for demos often fail this test. They attract attention once, then sit unused because they are interesting but not embedded in a recurring job to be done.

That does not mean every AI feature must be deeply utilitarian. Some are legitimately there to signal that the product is current. But the team should distinguish clearly between a retention feature, a revenue feature, a workflow feature, and a marketing feature. Those deserve different budgets, timelines, and standards of ambition.

Ask whether the data exists

A large share of bad AI proposals are really bad data proposals in disguise.

Before discussing models, prompts, or vendors, ask a more basic question: does the system already contain the data and signals needed for the feature to work well?

This usually means checking:

• What exact inputs will the feature rely on?
• Are those inputs already captured, clean, permissioned, and available in the right workflow?
• If not, who will create them?
• Will users be asked to enter more information just to make this feature possible?
• Is the user willing to do that?
• Is the business willing to bear the operational burden of collecting and maintaining that data?

This is where many apparently clever ideas collapse. A team imagines an AI system that gives smart recommendations, scores risk, writes better CRM notes, suggests next actions, or drafts highly contextual responses. Then engineering discovers the product does not actually store the context required to do that reliably. Or the context exists, but in incomplete free text, scattered across systems, with no stable identifiers, poor permissions, and no clear data ownership.

When that happens, the real project is not an AI feature. The real project is instrumentation, workflow change, data quality improvement, and governance. If the company is not willing to fund that work, it should not fund the AI feature either.

Understand the economics

AI features are not just build-cost decisions. They are ongoing unit-economics decisions.

This is one of the biggest differences between conventional software and modern generative AI. Traditional features are often expensive to build and comparatively cheap to run. Many AI features are expensive in both phases. Risk management has to extend through deployment and use, not stop at launch.

Product and business leaders should therefore ask:

• What does it cost to build the first usable version?
• What does it cost to run per user, per workflow, per month?
• How sensitive are costs to usage growth?
• What happens if the feature becomes popular?
• Can the business charge for it, bundle it, limit it, or reserve it for certain tiers?
• Is a slower, cheaper model good enough?
• Can the workflow be redesigned so AI is used only where it creates meaningful leverage?

A feature that looks compelling in a demo can become unattractive once usage scales. This is especially true when the feature makes multiple model calls, processes long contexts, triggers background jobs, or encourages exploratory user behavior where one action becomes ten follow-up requests.

The right way to think about AI economics is not “can the model do it?” It is “can the business sustain this behavior if customers actually use it?”

Be explicit about quality and failure modes

AI outputs are probabilistic. That is not a philosophical point; it is a product design constraint.

The same prompt can produce different outputs. A result can sound confident and still be wrong. These are not the failure modes of ordinary software, and they cannot be managed with ordinary software practices. Any proposal that assumes “the model will just know” is not ready for prioritization.

For each feature, define the acceptable quality bar in practical terms:

• What does a good output look like?
• What kinds of mistakes are tolerable?
• What kinds are unacceptable?
• Does the user have the knowledge needed to detect errors?
• Can the output be grounded in company data or explicit rules?
• Is a human review step required?
• Is the feature assistive, or is it taking an action on behalf of the user?

This last distinction is important. Assistive systems help a user think, draft, search, summarize, or decide. Autonomous systems take or recommend actions with limited human review. Assistive and autonomous approaches require different evaluation and success criteria. That distinction matters for product strategy too.

If the downside of a bad answer is mild inconvenience, the system can be more permissive. If the downside is financial loss, legal exposure, reputational harm, unsafe advice, privacy leakage, or customer mistrust, the design must be narrower, more observable, and more heavily controlled.

Treat security, privacy, and governance as part of the feature

AI risk is not a legal appendix. It is part of product definition.

A practical governance checklist for generative AI asks teams to document:

• The use case and models involved
• Input and output data types
• Evaluation methods and monitoring
• Infrastructure controls and LLM-specific security risks
• User onboarding and human oversight

That is a useful discipline even in startups, because the most expensive AI mistakes often come from weak boundaries rather than weak prompts.

At minimum, product and engineering should review:

• Whether sensitive data is entering prompts, logs, vector stores, training pipelines, or third-party tools.
• Whether the system is vulnerable to prompt injection, jailbreaks, or malicious content in retrieved documents.
• Whether outputs could leak confidential information across tenants or user accounts.
• Whether users understand what the feature can and cannot be trusted to do.
• Whether the team can monitor failures, audit usage, and shut the feature down safely if needed.

This is not bureaucracy for its own sake. In many cases, the cheapest AI prototype is cheap only because it quietly ignores privacy, security, and operational control. Those omissions come back later as incidents, rework, sales friction, and delayed enterprise adoption.

Use a staged decision process

Most teams do better with a standard filter than with repeated open-ended debates. The following stages are a thinking tool — a sequence for the proposer to pressure-test their own idea before bringing it to others.

A simple decision process might look like this:

Stage 1: Problem fit

• Is the user problem real, frequent, and important?
• Is the proposed outcome clear?
• Does the feature still make sense when described without the phrase “using AI”?

If no, stop.

Stage 2: Solution fit

• Is AI materially better than conventional software for this job?
• Is the problem probabilistic, language-heavy, or dependent on unstructured data?
• Can a non-AI fallback or constrained version exist?

If no, use conventional software.

Stage 3: Demand fit

• Will users discover it, trust it, and return to it?
• Is it embedded in an important workflow?
• Is success measurable within a reasonable pilot period?

If no, the team does not yet have a feature worth building.

Stage 4: Data fit

• Do the required inputs already exist?
• Are they accessible, clean enough, and legally usable?
• Will users provide missing inputs without friction that kills adoption?

If no, either fund the data work explicitly or stop.

Stage 5: Economic fit

• Are build cost and run cost acceptable?
• Do the unit economics still work if usage grows?
• Is the feature monetizable, limitable, or strategically necessary?

If no, redesign scope or stop.

Stage 6: Risk fit

• What is the worst plausible failure?
• Can the user detect it?
• Can the system be monitored, reviewed, and controlled?
• Are privacy, security, and compliance concerns addressed?

If no, narrow the use case or add controls before proceeding.

Stage 7: Priority fit

• Is this the best use of the team’s capacity right now?
• What does the team not build if it builds this?
• Is there a reason this must happen now rather than next quarter?

If no, queue it — do not let excitement override sequencing.

A practical scorecard

For portfolio discussions, it helps to force proposals into a common format.

Score each area from 1 to 5:

Not every feature needs a perfect score. But low scores in data readiness, cost viability, or risk control should trigger real caution, even when the demo value is high.

Where “checkbox AI” fits

There are situations where a company does need a visible AI feature because customers, investors, prospects, or partners expect one. Pretending otherwise is not always realistic.

The mistake is not shipping a checkbox feature. The mistake is allowing a checkbox feature to sprawl into a major engineering program without a clear ceiling. If the real goal is market signaling, then define it as such and design accordingly:

• Keep scope narrow.
• Prefer assistive over autonomous behavior.
• Avoid deep coupling into critical workflows.
• Limit data exposure.
• Cap usage and operating cost.
• Be honest internally that this is a commercial response, not a foundational product bet.

Handled this way, a market-driven AI feature can be useful without becoming an endless sink for engineering time and leadership attention.

What good proposals should include

The staged process above is internal. Once a proposal survives it, the proposer should be able to present clear answers to the following. This is what engineering and leadership need to see before estimating work:

1. What exact user problem is being solved?
2. Does this feature still make sense when described without the phrase “using AI”?
3. Why is AI the right approach rather than conventional software?
4. What is the non-AI fallback, and can the feature degrade gracefully without it?
5. What inputs will the system need, and do they already exist?
6. What does success look like for the user and for the business?
7. What are the likely failure modes?
8. What human oversight is required?
9. What are the privacy, security, and governance implications?
10. What will it cost to build?
11. What will it cost to run?
12. What happens to cost if usage grows significantly?
13. Why is this worth doing now instead of something else?
14. How will users discover, trust, and repeatedly use this feature?

If a proposal cannot clear these questions, it is not ready for roadmap discussion.

A simple decision flow

Once the problem is real and AI is the right approach, this is the technical feasibility funnel:

The engineering posture that helps

The best engineering response to AI enthusiasm is neither cynicism nor blind excitement.

A dismissive posture alienates commercial teams and misses real opportunities. An uncritical posture leads to expensive features that do not help users, stress the stack, and create avoidable operational risk. The useful middle ground is disciplined curiosity: assume some ideas will be valuable, require them to pass through product, data, economics, and risk filters, and then execute cleanly.

AI deserves to be treated as an important technology option. It does not deserve exemption from ordinary product judgment.

That is the standard worth defending.

Further reading

• NIST AI Risk Management Framework (AI RMF) — The formal framework for AI trustworthiness, risk-based design, and governance referenced throughout this post.
• NIST AI RMF: Generative AI Profile (PDF) — Covers risks specific to generative AI systems: hallucination, data leakage, misuse, and the need for explicit monitoring.
• A Strategic Framework for AI Product Development and Evaluation in Enterprise Software — Google Research paper on evaluating AI features through user value, business impact, and implementation reality.
• AI Product Strategy — Reinforces standard product-thinking patterns: problem-first framing, measurable outcomes, and user value over marketing.