How to Set Up Product and Engineering in an AI-Enabled Organization

The old product-and-engineering assembly line is breaking. When AI can plan a change, write the code, run the checks, and prepare something reviewable, the scarce job is no longer translating a customer need into a ticket and then translating the ticket into React. The scarce job is owning the outcome.

My answer is to organize around a product expert: one person who understands the customer problem, why it matters, what good should feel like, and how to tell whether the experience actually works. That person stays with the work from customer conversation through an AI-built preview, a limited release, customer feedback, and the decision to ship, revise, or delete it.

Engineers and designers do not disappear in this model. Their leverage moves up a level. They make the environment, architecture, components, tests, observability, design system, and operating rules better so every product expert—and every AI agent—produces better work the next time.

The handoff is the problem

The old model separated customer truth from implementation

The familiar sequence looked sensible because implementation was expensive. A customer talked to product. A product manager interpreted the need and wrote tickets. An engineer accepted the tickets and wrote the code. QA checked the result. The customer saw it after several handoffs.

The best people always resisted those boundaries. Great product managers understood the customer deeply enough to recognize when the requested feature would not solve the real problem. Great engineers understood the product deeply enough to question the ticket, test the experience, and notice where the system would fail. Great designers cared about the behavior, language, accessibility, and edge cases—not only the pixels.

The weakest version of each job was much narrower: product management as backlog administration, engineering as framework syntax, and design as screen production. AI is compressing those narrow task bundles first.

This does not mean every product manager should become a full-time software engineer. It means the coordination boundary has moved. OpenAI describes Codex as able to write features, run tests and linters, and prepare pull requests from an isolated environment. Its early examples even included product managers contributing lightweight code changes with engineering review. The implementation step is becoming available to more people; judgment about what should exist remains the hard part.

The new core role is a product expert

“Product expert” is not necessarily a new title. It could be a former product manager, engineer, designer, founder, customer-success lead, or domain specialist. The background matters less than the combination of context and responsibility.

A product expert can answer five questions:

1. What is the customer trying to accomplish? Not what did they request, but what changes in their work if we solve it?
2. Why should we build this now? What evidence makes it more important than the alternatives?
3. What should the experience feel like? What is obvious, fast, safe, and complete from the customer's point of view?
4. How will we test it? Which happy path, edge cases, system checks, and customer behaviors distinguish working from merely implemented?
5. What did we learn? Did the customer use it, trust it, and get the intended result—or should we change or delete it?

The person does not throw a specification over the wall. They direct the AI, inspect the implementation, use the deploy preview, try to break it, put it in front of the customer, and update the work while the context is still fresh.

A one-week outcome loop

For a bounded feature, the cycle can be surprisingly short. At Polyform we can sometimes fit two customer-learning loops inside a week. That is not because every change is easy. It is because the same owner carries the context across the entire loop and the first implementation is no longer treated as precious.

Anthropic's analysis of Claude Code interactions found exactly this combination: much more task automation than in ordinary chat, but also a strong feedback-loop pattern in which people validate the work and feed the environment's response back to the agent. That is the important organizational clue. The work is not “AI acts alone.” It is a much tighter loop between intent, implementation, evidence, and human judgment.

Cheaper code should also make teams less emotionally attached to code. If a feature does not solve the problem, remove it. If the architecture of the first attempt is wrong, rebuild it. The sunk cost of typing thousands of lines should no longer determine the product roadmap.

Engineers become stewards of the system

If AI is producing much more code, somebody has to make sure that volume compounds into a better product instead of a more chaotic codebase. This is where strong engineers become more valuable.

The engineer's unit of leverage becomes the system that produces changes:

• architecture and clear boundaries between parts of the product;
• the development environment, deploy previews, and reliable test harnesses;
• shared components, libraries, and preferred implementation patterns;
• caching, performance, data access, security, and failure handling;
• observability that makes bad behavior visible quickly;
• instructions and examples that teach agents how this product works; and
• continuous cleanup that removes duplication and turns recurring mistakes into system rules.

This is not engineering as janitorial cleanup after careless AI. It is engineering as platform design. When the same mistake appears twice, do not only fix two pull requests. Improve the abstraction, test, library, instruction, or review gate so the class of mistake becomes less likely.

The 2025 DORA research makes the same point at organizational scale: AI amplifies the system around it. More change can improve throughput, but weak testing, slow feedback, tightly coupled architecture, and poor internal platforms can turn that extra volume into instability. The answer is not to slow AI back down. It is to make the system worthy of the speed.

Designers steward the experience system

Design changes in the same direction. If AI can produce a plausible interface quickly, pushing every pixel is no longer the highest-leverage job.

The designer defines the visual language, interaction patterns, accessibility standard, content rules, reference experiences, and acceptance criteria that make many generated screens feel like one product. They review the moments where taste, hierarchy, or human behavior cannot be reduced to a component. They watch customers and update the system when the system teaches the wrong behavior.

A strong design system becomes executable judgment. It gives product experts and AI a constrained language for building, and it lets designers spend more time on the hard question: is this experience actually understandable and good?

Three roles, one result

The modern team does not need a clean boundary between “product” and “engineering.” It needs clear ownership across three kinds of work.

Some companies will combine these responsibilities in one person. Others will have product experts supported by senior engineers and designers across several outcome areas. The org chart matters less than the loop. The person closest to the goal must be able to carry the work far enough to test reality, and the experts closest to the system must be able to improve the conditions under which every future change is made.

Data is going through the same transition

The old data workflow looks a lot like the old product workflow. A business person has a question. They check a dashboard. If the answer is not there, they ask the data team. The request enters a backlog. An analyst writes SQL, builds a chart, and returns an artifact. The business person then discovers the next question and starts again.

Making that queue faster is not the transformation.

The transformation is letting the person who owns the business goal use AI to carry the data work much further: investigate the question, inspect the records, build the analysis, create the dashboard or dataset, turn the result into a workflow, and review what happened. The data expert shifts toward maintaining the system that makes those results dependable: sources, transformations, metrics, dimensions, definitions, permissions, examples, tests, production state, and the recovery path when the AI should not guess.

This is exactly what we are building at Polyform. Poly and its agents can work across the data path instead of stopping at a chat answer. The system gives them the reports, models, lineage, runs, tasks, workflows, and tools needed to inspect, build, test, and continue. Business context is maintained as shared operating material, not recreated in every prompt. And our dedicated expert remains accountable for the definitions, quality, and decisions that software should not invent.

The point is not that data engineers or analysts become unnecessary. The point is that a senior expert should not spend the day translating every question into one more query. Their leverage comes from creating a system in which many people—and many agents—can produce trustworthy outcomes without rebuilding the foundation each time.

How to start changing the organization

Do not reorganize the whole company around a prediction. Pick one bounded customer problem and change the operating loop around it.

1. Name one outcome owner. Give one product expert responsibility from customer need through the adoption decision.
2. Give the AI a real environment. Include the repository, setup instructions, preview path, tests, component library, and safe permissions it needs to do reviewable work.
3. Write acceptance conditions before implementation. Define the customer behavior, edge cases, system checks, and evidence that distinguish a result from a demo.
4. Release narrowly. Use previews, internal users, feature flags, or a small customer cohort appropriate to the risk.
5. Keep a system-stewardship backlog. Track recurring mistakes, duplicated patterns, weak tests, missing components, unclear guidance, and slow feedback as product infrastructure work.
6. Measure the loop. Track time to customer evidence, accepted outcomes, reversals, incidents, and repeated rework—not lines of code or tickets closed.

I wrote previously about why a fast conversational AI and a deep execution agent should not be the same system. The organizational version of that lesson is similar. Do not ask one role to hold every responsibility, and do not confuse implementation capacity with judgment.

Put the goal with the person who understands the customer. Put implementation capacity close enough that they can test reality themselves. Put senior technical and design judgment into the system so quality compounds. Then make the whole loop accountable for what changed for the customer.

That is the shape I expect to see far beyond product and engineering: experts maintaining systems that let the people closest to the goal deliver the value directly.

References and further reading