The Function Your Product Team Is Missing

Three articles described the work an AI-enabled feature demands before anyone can write its requirements. This one names who should do it, and what to call it: not a hire, not a title, but a function most product organizations have not built yet.

The last article ended on an uncomfortable note. The technical work that makes AI-enabled features buildable happens before requirements can be solidified, within product development processes not designed to accommodate it, and sits within neither traditional product nor engineering. That leaves the open question: Who does it? Answering it means first seeing the work whole, since each of our three prior articles described a different piece of it. Here they are in brief.

1. Feasibility became a research question. With AI, “can we build it” stopped being a scheduling question, and someone has to tell routine work from an open research problem before anyone commits to a date.
2. Setting the quality bar and proving it are different jobs. The implementation certainty software always gave us is gone, so proving the bar has been cleared takes a ground truth dataset, and most product teams have nobody to build one.
3. The process has to change, not only the staffing. Because the feature can only do what the model can do, you experiment first and specify second, and the requirements come out of that loop as a proof of capability.

Set side by side, those are not three separate gaps. They all happen before the requirements; they concern the same subject, how the product behaves; and they call for the same handful of skills: defining the problem, judging what current models can do, proving it, designing for how the model fails, and turning all of it into requirements. On most teams that work gets done piecemeal, and the parts that sit in nobody’s job description don’t get done at all. It is one body of work, and on most org charts it has no owner. So who should own it? Most organizations reach for one of a few answers first.

The answers most teams reach for first

Each of them is reasonable, and each one covers part of the work.

Each of these is a real piece of the answer, and none of them is the whole of it.

What a function actually is

What covers it is a function, a word worth being precise about. In ordinary organizational usage a function is defined by the work and the reason for it, the what with a why behind it, rather than by who does it. A role is the who, the seat someone fills, and a title is only the name on that seat. That is exactly what the table above shows: each normal answer is a role or a title carrying a piece of this work, and nothing on the org chart carries the whole of it.

Finance makes the distinction easy to see. Every company does some accounting; somebody pays the bills and somebody sends the invoices. A company without a finance function still has all of that activity. What it doesn’t have is anyone who owns the books. That is the situation on most product teams building AI-enabled features: the effort is there, in pieces, and what is missing is the function, the work recognized as one thing with a purpose someone is accountable for. A function is the work and its purpose; roles are how you staff it, and a process is how it gets done.

A function is the work and its purpose; roles are how you staff it, and a process is how it gets done.

The function this series has been circling needs a name as plain as finance, so I’ll call it AI Product Strategy: deciding where AI belongs in your products, proving it works, and defining it so engineering can build it.

Here are the two, drawn the same way.

The finance function

• How: a monthly close, an annual budget cycle, and an audit calendar everyone works to.
• Why: so the company’s money is accurate, planned, and compliant.
• Value: books leadership can trust, a budget to run against, forecasts to plan with, and clean audits.

The AI Product Strategy function

• How: the problem first, then experiment before you specify, with evaluations that keep running after launch.
• Why: so AI-enabled features solve real problems, work as promised, and keep working.
• Value: AI spend that goes only where it can work, features customers keep trusting, dates that hold, and a brand protected from bad guesses.

Who does the work

The function has five roles, not necessarily five full-time people; in a smaller organization one person may cover two. Research and design usually exist somewhere in the organization already. The three in the middle are the ones most teams have to add, and they are commonly fractional rather than headcount.

Note: The product manager isn’t a row, on purpose: the PM is the anchor on each feature and makes the calls, and the function is who the PM works with to make those informed decisions well.

The designer’s row is the only one of the five the first three articles didn’t build toward, so it is worth a moment. At a ninety-five percent bar of LLM robustness at a particular task, the other five percent isn’t an edge case; it is a scheduled part of the feature, so it gets designed rather than patched. The work is keeping the user’s trust calibrated, so people neither rubber-stamp every answer nor give up on the feature, while the system behind the screen is sometimes wrong, sometimes unsure, and sometimes different from last week. Google’s People + AI Guidebook gives this a chapter of its own.

Where it sits, and what it hands over

On a given feature, the function defines the problem, screens it, proves it, designs for the misses, and defines the requirements (in that order). What matters more is where it sits. It sits beside each product team’s product manager, as part of how that team defines features, rather than as a separate group you send requests to. And it sits in front of the AI team, or engineering generally, which receives exactly what it asked for back in the second article: requirements it can build against, along with the ground truth and the evaluation suite. That is the moment the standoff becomes a hand-off. After launch, the function keeps those evaluations running and owns what happens when they trip.

What AI Product Strategy is worth

Some of a finance function’s value is what it prevents: the fine, the restatement, the fraud nobody caught. The same holds here. When a feature leans on the model’s own training to draw conclusions about a person, it will sometimes draw ones that person finds insulting. Picture a banking app whose model notices a large withdrawal and helpfully offers a short-term loan for people in financial difficulty to a customer who has just bought a house. They aren’t grateful; they’re offended, and they say so. Without the feature, that customer would have lost nothing; with it, the bank has told them what it thinks of them. An AI-enabled feature that guesses wrong about a customer may exact more damage than having no feature at all.

An AI-enabled feature that guesses wrong about a customer may exact more damage than having no feature at all.

In a product sold to other businesses, that complaint goes to the company that bought the software, and it is the vendor’s brand that pays. So sometimes the most valuable thing the function does is conclude that a feature shouldn’t ship, a choice you only get if the proof runs first. And four of the five root causes in RAND’s study of why AI efforts fail are gaps this function exists to close.

And if you have more than one product, it compounds. A suite of related products runs into the same kind of work again and again, so one function brings one way of building ground truth and running evaluations, one standard for what counts as proof, and one current read on which models are worth using, instead of each product working it out alone. More valuable still, the AI strategist, looking across every roadmap, can see that a capability one product needs next quarter is one three others will need next year, and build the foundation early, even though no single product will use all of it at first. Most product teams can’t do that well when they are heads-down on their own roadmaps. A function looking across every product can build the foundation once, ahead of the roadmaps that will need it.

Standing it up is your call

If you run product, this lands on your desk. Your product managers already own the quality bar and the behavior of each feature, which is where the second and third articles left them. Whether a function exists to back them, for every product that includes AI, is a decision only you can make, whoever ends up supplying the people.

There are two workable ways to do it. The roles in that table above rarely live in one person, and by staffing firms’ own figures hiring for them takes two to four months a role; the designer who knows how models fail barely exists as a hiring category yet. People are also only half of it: building the function means building the process it runs, and for teams that are agile in the middle and waterfall at both ends, that is the harder change. So you can build a small team and the process around it, kept beside product. Or you can source the function, which arrives with the process already running and, if your AI team is new or doesn’t exist, with the AI engineering knowledge too, working inside your product teams now, while an internal team forms or instead of one. The third option, not deciding, is the one most organizations are on by default: whoever is nearest does the work, and “no time for a POC” becomes the plan.

No one would run a company without a finance function and trust the books to sort themselves out, yet most product organizations are building AI-enabled features exactly that way. So before the next one reaches your roadmap, go down the roles in that table and write a name next to each. Wherever you write a blank, or “the AI team, I suppose,” you have found the function your product team is missing.

---

I would be remiss if I didn’t say that Planorama is organized as an AI Product Strategy function, process included: experimenting first and specifying second is how we already define features, and the roles in that table are the people we bring, working as one team inside your product teams and alongside your AI team if you have one. If you have read this series and recognized your own roadmap in it, I would be glad to spend an hour on the phone working out what your team needs, and you will get plain advice either way.

This is the last of four articles on the work an AI-enabled feature demands before anyone can write its requirements. The series began with telling routine features from research problems, moved through proving quality and the process that proof requires, and ends here, with the function that holds it together.