The Feature Is Dead. The Job Remains.
What building AI-native products actually changes about how we work.
There is a moment in every AI product conversation where someone says “we should add an AI assistant” and someone else opens Figma and starts drawing a chat panel in the bottom right corner of the screen. And I get it. It ships. It fits the mental model everyone already has.
It is also almost certainly wrong.
Putting a chat panel in the corner of a product you already built is not building an AI product. It is bolting a new communication channel onto an old architecture. The underlying product — its information model, its navigation, its definition of what the user is trying to do — stays exactly the same. The AI lives in its little drawer and answers questions about the thing, but it is not the thing.
I have been working through what it would actually mean to build an AI-native product from the ground up. What I found is that it breaks almost every assumption I had about how product development works. The break is not incremental. It is structural.
The unit of work is no longer a feature. It is a job.
In traditional software product development, the unit of work is a feature. The roadmap is a sequence of features. The design process produces screens and flows that let users access features. The success metric is whether users use the feature.
This frame has a hidden assumption: the software is the actor. The software tracks expenses, or schedules meetings, or generates reports. The user navigates to the place where the software does that thing.
In an AI-native product, the intelligence is the actor. The user states a job they need done. The system does it. The screen — if there is one — is how the output gets rendered. But the screen is not where the value lives.
Jobs, in the sense Clayton Christensen meant, are stable even when the solution changes. “Help me understand what changed in my business this week and what I should do about it” is a job that existed before software, before SaaS, before cloud. What changes is the mechanism by which you hire something to do that job. For thirty years, you hired a dashboard. Now you can hire an intelligence layer.
The artifact that encodes a job for an AI-native product — I’ll call it a job brief — is made of three layers. The first is the job specification: the user’s intent, the expected output, and the expertise required to ask the right question in the first place. This is where it overlaps with good prompt engineering, and that overlap is real. A skilled prompt engineer already knows to be specific about intent, rich about context, and precise about output format. The job brief borrows all of that.
What makes it something different is the second and third layers. The second is proprietary context — the data the software company manages and injects at runtime. Customer history, live signals, structured records, accumulated domain knowledge. This is what makes the same brief produce a different answer for one organization than another. A brief without proprietary data is a good question. A brief with it is intelligence. And it is what a competitor with a better model still cannot replicate, because they don’t have your data.
The third layer is user context — who is asking, from what surface, in what role, at what moment. What they were just looking at. What their history suggests about what they actually need. This is what makes the output feel like it was made for this person right now, not for the category of people who might ask this question.
Most prompt engineering focuses on the first layer. Most data platform thinking focuses on the second. A job brief holds all three together as a single designed artifact — and treating it that way is what separates a product from a wrapper around someone else’s AI.
The job brief catalog is a new kind of product — and it creates new problems.
A library of job briefs is not a feature list. Each brief encodes something reusable: the next time any user needs that job done, the same expertise fires — combined with that user’s context and that organization’s data. The library accumulates. The proprietary context deepens. Over time, it becomes the organization’s institutional knowledge made invokable, and the gap between what your briefs can produce and what a generic AI can produce widens with every passing month.
But unlike features, job briefs are never really finished. They improve as you learn what produces better outputs. They get retired when a better formulation exists. The underlying model improves and changes what’s possible. This creates problems the product industry hasn’t had to solve before.
How do you version a job brief? An improved brief may produce materially different output — which is a breaking change to any workflow built around the old one. But it is a breaking change in an artifact most users cannot see.
How do you communicate improvement? When a feature improves, you show before and after. When a job brief improves, the improvement is in the quality of the reasoning. You cannot screenshot better thinking.
How do you measure whether a brief is working? The right metric is not invocation rate. It is what happens after — did the user act on the output, make a decision, take a next step? A brief that gets used and then ignored is not doing its job. That ratio of invocation to purposeful action is your iteration signal, and almost nobody is tracking it yet.
This makes user research a strategic concern, not just a design one.
If the job brief is the primary product artifact, and job briefs must encode real expertise about real jobs, then understanding those jobs becomes the most important input to the entire product. Not the most important design input. The most important product input.
This is where user research changes character — and why it matters more than it ever did in traditional SaaS, not less.
Behavioral research — watching people use software — tells you where they struggle with the interface. That still matters for the rendering layer. But it cannot tell you what jobs people actually need done, because the job often exists in the gap between what the software does and what the user is trying to accomplish. The evidence is in the workarounds: the spreadsheet they maintain alongside the platform, the Slack message to a colleague, the manual step they’ve never questioned.
Finding those gaps requires something closer to ethnography than usability testing. Sitting with a practitioner and asking not “how do you use the platform” but “walk me through the last time you had to answer a question you didn’t have good data for.” The workaround is the job. The job inventory — a catalog of what people need done, ranked by frequency and pain — is the strategic document that drives everything else.
This is adjacent to Task Analysis — the structured HCI method for decomposing workflows into goals, subtasks, and decision points before automating them. Dan Saffer has written well about its application to agent design, and for structured, repeatable workflows it remains exactly the right tool. Where job discovery differs is at the open-ended end of the spectrum: the jobs that don’t decompose into a finite task tree, where the value comes not from mapping what humans already do but from encoding what an expert knows to ask that a less experienced person doesn’t. Task Analysis maps the workflow. Job discovery finds the expertise gap inside it. Both matter. They’re sequential, not competing.
Domain expertise becomes a product contribution, not background input.
Most AI products are only as good as the questions they are asked. And most users don’t know how to ask the right questions — not because they’re unsophisticated, but because the right question in a complex domain requires expertise they haven’t accumulated yet.
A junior financial analyst doesn’t know to ask “how does this margin compression compare to the last three times this company faced input cost inflation, and what did management do about it?” A senior analyst does. A newly qualified physician doesn’t know to ask “given this presentation, what are the three diagnoses most commonly missed at this stage, and what would rule each one out?” An experienced clinician does.
Those questions — and the dozens like them that experts ask intuitively — are domain expertise. They have historically lived in people’s heads, transferred through apprenticeship and scar tissue. Job briefs are how you codify that expertise at scale and make it available to every user, every time.
The implication: domain experts are now direct co-authors of the product, not interviewees. A legal tech company needs practicing attorneys writing job briefs alongside PMs. A healthcare product needs clinicians whose diagnostic logic gets captured as jobs. This is a new kind of role — somewhere between senior practitioner and product manager — that most organizations haven’t thought to create.
Design becomes a grammar problem.
When an AI-native product runs across multiple surfaces — a native app, a browser, an IDE, a third-party AI tool — you cannot design a fixed interface. You have to design a grammar: rules for what output components exist, how they compose, and how they degrade as the rendering environment becomes more constrained.
Think about what responsive web design demanded a decade ago. Not “make the layout smaller” — a fundamental rethink of the relationship between content and container. What is essential at this size? What can be deferred? Designers had to stop thinking in pages and start thinking in systems.
Rendering job brief outputs is the same problem, one level of abstraction higher. A “Weekly Performance Briefing” output in a native app can be a rich structured card with expandable sections and a reasoning disclosure panel. The same output in a general-purpose AI tool is a well-structured document. In a developer’s IDE it is three bullet points and a recommended action. Same job. Same intelligence. Three completely different surface expressions.
The design question is not how to design three interfaces. It is how to define the grammar that determines how output adapts — what the invariant is, what the enhanced layer adds, what requires a native surface to exist at all. The designers who will thrive are the ones who learn to think in output grammars, not screen compositions. We’ve been here before. It just looked like CSS breakpoints last time.
What this adds up to.
Most AI products are still features in the corner of someone else’s architecture. The ones that will actually change how people work will be built from jobs up. The brief library will be the product. The rendering layer will be the UI. The moat will be the combination of encoded expertise, proprietary data, and user context that makes every output more relevant than anything a generic tool could produce with the same question.
What does not change in any of this: the user still has a job to do. The job still has a trigger, a desired outcome, and a definition of done. The user’s trust is still earned through reliability and relevance, not novelty. Understanding people deeply — their context, their expertise, their frustration — still matters as much as it ever did. It just produces a different artifact.
The discipline is the same. The artifact is different. That turns out to be everything.
If this resonated, I’d be interested in what you’re building and what you’re running into. The practice is still forming and collective sensemaking is how it gets better.
Greg Petroff is a fractional Chief Design Officer who works with companies building AI-native products from the ground up. He has led design at scale inside large technology organizations and is currently helping a software company rethink what a product is when intelligence is the primary interface. This piece comes out of that work.
I love the idea of a Job Brief! I've seen similar ideas, but none spoke to me as your piece did.
As soon as I learned about JTBD, I stopped believing in roadmaps centered on features or new tech. It's really incredible how quickly we can forget about the humans using products when new tech comes into the picture.