The Missing Function

Every product team I talk to is being handed AI features by executives who assume the team can build them the way it has built everything else. It cannot, and this series is my honest attempt to explain why, without either apocalypse or hype. Four articles: one on why feasibility became a research question, one on why product’s quality bar now needs evidence product does not usually have, one on why the specification cannot come first, and one on the function that has to exist to hold all of that together. It is written for the people who have to build them.

Matt GenoveseFounder & Product Strategy Lead, Planorama Design

A finished sedan hovering above the floor of an automotive assembly line, wheels folded up, while the cars around it rest on their tires

01

Part 1 of 4 5 min read

Four of Those Are Standard. One of Them Hovers.

If AI is on your roadmap, someone on your team has to be able to tell a routine feature from a research problem before anyone commits to a date. Most teams cannot, and the misjudgment runs in both directions more often than anyone admits. Read this if you have looked at an AI feature request and not been sure whether it’s a week of work or a year of it. Leave with a two-question check you can run in the meeting where it comes up.

Read Part 1

02

Part 2 of 4 Coming soon 8 min read

Product Owns AI Quality, Not the Proof Behind It

Product decides whether a feature is good enough to ship. With AI, answering that question suddenly needs evidence most product teams have no way to produce. Read this if you have been asked for a “ground truth dataset” and had no idea what to do with the request. Leave with the one question that tells you whether you are being handed an afternoon of annotation or a data science project.

03

Part 3 of 4 Coming soon 9 min read

You Can’t Have an Opinion About a Model You Haven’t Used

The rule that says product owns what and engineering owns how has held for the whole history of software, and AI is the first thing to genuinely break it. Read this if you are trying to write requirements for an AI feature and the words won’t stay still. Leave with a specific artifact you now need to produce before the spec, a distinction hardware always carried and software mostly did not, and a cost asymmetry that makes skipping the upfront work more expensive than doing it.

04

Part 4 of 4 Coming soon 11 min read

The Function Your Product Team Is Missing

After three articles diagnosing why AI features are hard for standard product teams, this one names the work that has to happen and shows why no role on your org chart currently owns it. Read this if you have caught yourself writing a job posting for a role that reads as one person doing three people’s worth of work, and suspected that person did not exist. Leave with a way to name the missing capability, an example of a real team doing this well under harder constraints than yours, and a decision framework for filling the gap without hiring the mythical unicorn.

About Planorama

We leave your team better than we found them.

We position ourselves upstream of your engineering sprints and produce the artifacts your developers need before they write a line of code. Everything we produce becomes permanent institutional knowledge inside your organization. Senior practitioners from day one, and your team carries forward the practices long after the engagement ends.

The artifacts stay.

The way of working stays.

The dependency on us doesn’t.

Get in Touch

Let's talk about your project.

Tell us what you're working on. We'll find where Planorama can have the most impact — and be honest if we're not the right fit.

30-minute discovery call — free, focused, no obligation

Senior practitioners on every engagement, not junior staff

Deliverables your engineers can act on from sprint one

Honest fit assessment — we'll say so if it's not right

We reply within one business day. Usually sooner.