Article Series

The Missing Function

A four-part series on the product-side work AI features actually require, and the function most product organizations have not yet built.

For product managers, product leaders, CTOs, and engineering leads inside software companies who have AI features on the roadmap.

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

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

An analog precision gauge with a red line marked GOOD ENOUGH on its dial, the needle blurred in motion as it sweeps back and forth across the line without settling

Part 2 of 4 8 min read

Owning the AI Quality Bar vs. Owning the Proof

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.

Read Part 2

A realistic autonomous mobile robot on a lab bench, bristling with recognizable external sensors: a spinning LIDAR unit, stereo cameras, a radar module, an ultrasonic array, and a microphone array, each awaiting characterization, with no datasheets in sight

Part 3 of 4 9 min read

Specifying an AI Feature Takes a Process You Don’t Have

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 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.

Read Part 3

The same characterization bench from the series cover, now in service: the task lamp lit, a steady trace on the oscilloscope, the graph-paper data table filled in and its curve completed, calipers and a dial gauge measuring a machined part, with the product and engineering zones active on either side

Part 4 of 4 12 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.

Read Part 4

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.