Traditional product and engineering organizations are divided by profession. Product defines requirements, design creates interfaces, frontend builds screens, backend owns services, QA verifies the release, and operations deploys it. Every role can be highly capable, and the process can look reassuringly complete.
But as markets move faster and AI reduces the cost of prototyping and implementation, the constraint changes. The important question becomes: how many queues, translations, handoffs, and reconfirmations must a real customer signal cross before it becomes a product that can be tested?
If the answer is still a long functional pipeline, AI may accelerate every local step without helping the organization reach evidence any sooner.
I believe the basic delivery unit of an AI-era R&D organization is shifting from frontend, backend, or product departments to small, market-facing project cells. One practical cell might combine a salesperson or business partner close to customers with two product-engineering generalists. Together they own the loop from problem discovery and solution design to delivery and feedback.
When the response is strong, they keep investing. When it is weak, they revise the hypothesis, change the product form, or stop and move to a better direction.
Expertise remains; waiting behind role boundaries does not
“No frontend or backend roles” can sound like expertise no longer matters or everyone must master every discipline. That is not the useful interpretation.
What should disappear is waiting justified by job boundaries: the request has not reached my queue; this is not my stack; the page is done but the API must wait; the feature shipped so the market result is somebody else's concern.
Deep expertise remains essential for security, data, architecture, performance, and complex interaction. The change is that expertise becomes a capability a project cell can invoke instead of a fixed station where work waits.
A generalist may use AI to build a prototype, interface, service, and baseline tests. High-risk code still receives specialist review. The cell can deliver end to end, while platform capabilities continue to enforce shared standards.
The more precise principle is:
A job title should not decide where work stops. The outcome should decide how far the team carries it.
Put differently: expertise remains, but it no longer needs to take the form of departmental walls.
From functional queues to project cells
Functional organizations allocate work through sequential queues. Project cells start with a testable business problem rather than a predetermined feature list.
A minimal cell can contain:
| Member | Core contribution | Should not be limited to |
|---|---|---|
| Sales / business | Customer signal, context, validation access, commercial feedback | Passing requests downstream |
| Product-engineering member A | Hypothesis, interaction, end-to-end implementation, observation | Documents or frontend only |
| Product-engineering member B | Engineering, integration, quality, delivery, runtime feedback | One layer of code only |
“One salesperson and two builders” is an illustrative pattern, not a universal staffing formula. An experience-heavy product may need design engineering; a data product may need an ML or data specialist; a mature product may include operations or customer success. Headcount and titles matter less than whether the cell has the minimum capabilities and authority to complete a discover-build-deliver-validate loop.
It cannot require a fresh resource negotiation at every step, and it cannot treat deployment as the end of the work.
The group owns an outcome: sustained use, a problem demonstrably solved, a pilot that can expand, or an improved commercial result. Code volume, feature count, and on-time delivery remain process signals, not the final result.
The operating loop
The cell should begin with a signal, not a specification:
Real customer signal
↓
Define the problem and smallest hypothesis
↓
Choose the lowest-cost product form
↓
Build and deliver a testable version
↓
Observe usage, value, and commercial evidence
↓
Iterate / revise / change form / stop
Start with customer reality
A customer asking for a dashboard may actually need earlier anomaly detection. A request for a chatbot may reflect fragmented information, slow decisions, or expensive service. Sales supplies context and access; the whole cell separates the problem from the proposed solution.
Sales brings back an unvalidated problem signal, not a requirements list.
Write a falsifiable hypothesis
The group states whose problem it is solving, why that problem matters, and what evidence would support or reject the direction. The smallest hypothesis is not a shorter PRD. It is a judgment that can be proven wrong.
Let the product form serve the test
The first version might be a service supported by an internal tool, a plugin inside an existing workflow, an automatically generated report, a conversational entry point, or an agent workflow that still requires human confirmation.
AI makes prototypes operational rather than merely presentational. Small teams can put interfaces, data, and partial automation into real tasks and observe behavior instead of collecting opinions about mockups.
Treat launch as the beginning of validation
The cell must see how the product is used, where people need explanation, whether they return, whether sales becomes easier, and whether delivery cost grows linearly with usage. Feedback passed through layers is not a closed loop.
Decide explicitly
Continue, pivot, and stop conditions should not be invented after results arrive. At kickoff, the cell defines a validation window, cost ceiling, required evidence, and decision point. After each cycle, it chooses one path against those standards:
- Continue: problem, usage, and value signals are strengthening.
- Revise the hypothesis: the problem exists, but the user, context, or value judgment was wrong.
- Change the product form: the problem is real, but the current delivery method is too costly or difficult to adopt.
- Stop: evidence remains weak, and more features would only hide a bad direction.
Stopping is a valid reallocation of scarce capacity. The expensive failure is continuing because the organization has already invested.
A project cell needs both the authority to start quickly and the discipline to stop in time.
AI increases capability density
Project cells do not work because an org chart became flatter. They work because AI expands the range each person can cover.
Product judgment can become an interactive prototype faster. Engineers can cross interface, service, and data boundaries. Sales can structure interviews and feedback. QA can generate boundary scenarios earlier. Agents can assist with research, code, analysis, and release preparation.
The reliable division of responsibility is:
- AI expands, generates, organizes, and executes;
- people own goals, authoritative facts, risk boundaries, and key judgment;
- automated tests, review, permissions, and release mechanisms protect quality;
- the project cell owns the business result.
The real value of AI is not making ten existing roles individually faster. It is enabling a smaller team to complete a full learning loop.
Remove functional walls, not quality boundaries
Reducing handoffs must not mean removing constraints. Cells can make most daily decisions autonomously, while the organization provides shared capabilities for identity, data access, audit, continuous delivery, observability, rollback, incident response, common components, model gateways, security, privacy, and compliance.
These capabilities should be productized as internal platforms rather than recreated as approval queues. A platform team helps every cell move safely; it does not take ownership of each project.
Project cells create speed at the edge; shared platforms preserve reuse, quality, and safety underneath.
Management changes too
Managers move from assigning tasks and tracking utilization to defining direction, authority, constraints, and resource boundaries. They decide which problems deserve validation, what the cell can decide, what budget and time window apply, when escalation is required, and how conflicts between projects are resolved.
They also protect cells from a stream of unpriced interruptions. Every new priority must state what it replaces or delays. When everything is urgent, every validation loop slows down.
Management does not disappear. It shifts from managing motion to managing context, so teams can make informed decisions and the organization can see risk, cost, and results.
Evaluation must change with it. If teams are still rewarded for requirements completed, code produced, or launches delivered on schedule, project cells will collapse back into task execution. Better measures include time from signal to testable product, learning gained per cycle, movement in user behavior and value, timely stopping of weak directions, and reusable capabilities created without compromising quality.
Evidence for continuing
Metrics vary by product, but every project should examine four kinds of evidence:
| Dimension | Question |
|---|---|
| Problem strength | Does the problem occur often enough that users seek a solution? |
| Usage behavior | Do users complete the core action and return voluntarily? |
| Value result | Does the product reduce cost, grow revenue, lower risk, or improve a critical experience? |
| Commercial evidence | Will customers pay, renew, recommend, or expand usage? |
| Delivery economics | Can the product scale, or does every new customer require equivalent manual effort? |
| Strategic value | Does the work create reusable capability or open an important market entry point? |
Trial does not imply retention. One sale does not imply repeatability. Frequent use can still be supported by unsustainable manual work. Cells should agree on evidence before the test, then update their judgment as reality arrives.
Feedback cycles also differ by product. A click, a compliment, or a single trial can be noise; enterprise procurement, complex workflows, and infrastructure products often require longer observation. Fast validation does not mean premature judgment. It means obtaining reliable evidence at the lowest cost appropriate to the product cycle.
This model is not for every kind of work
Project cells fit work with high uncertainty, direct access to real users, and a need to test product forms quickly: new-product discovery, AI application experiments, new-market pilots, and rapidly changing customer problems.
They should not be copied unchanged into every system. Core transactions, infrastructure, regulated domains, and high-security environments still require stronger separation of duties, specialist review, and change control. A cell operating there needs higher standards for automated verification, audit, and release.
Three questions help determine fit: Is the problem still highly uncertain? Can the cell obtain direct, authentic feedback? Can failure be recovered within a controlled cost? If most answers are no, the priority may be reliability, correctness, and scale efficiency rather than faster experimentation.
Common failure modes
Sales becomes the requirements commander
Sales is closest to customers, but a customer's proposed solution is not automatically the product answer. Sales supplies evidence and validation access; the cell defines the problem and response together.
Two builders inherit unlimited responsibility
A small team cannot own an oversized project indefinitely. Cells require narrower problems, strong platform capabilities, and explicit stopping rules. Otherwise, agility becomes exhaustion.
Role removal eliminates specialist review
Cross-stack delivery does not justify sending every change to production without review. More frequent releases demand stronger automated gates and risk-triggered specialist attention.
Every cell rebuilds infrastructure
If identity, data, models, monitoring, and deployment are rebuilt for each project, more cells create more debt. Shared capabilities belong in platforms, not another ticket-taking department.
The organization rewards success but punishes stopping
When stopping means failure, teams add features to defend the original direction. Good validation includes proving cheaply that a path is not worth pursuing.
Start with one experiment
Do not begin by announcing the end of frontend and backend titles. Select a bounded, low-risk problem with access to real users. Form a minimal cell, provide a clear outcome, a validation window, necessary authority, and platform support.
Ask the cell to deliver evidence, not merely features. Then review how long it took to move from signal to testable product, how much waiting disappeared, which specialist capabilities were still necessary, whether the team can explain continue/change/stop decisions, and whether the model can be repeated without sacrificing quality.
Only after the loop works should the organizational structure follow.
The basic unit should be a result loop
Industrial organizations gained efficiency through specialization. Internet companies used cross-functional teams to shorten delivery. AI further reduces the cost of acquiring knowledge, building prototypes, and executing across the stack, allowing smaller teams to carry more complete responsibility.
The central question for a future R&D center is no longer how many frontend, backend, product, and QA roles it contains. It is how many high-quality market validation loops it can run at once.
Expertise, platforms, and governance remain. But capabilities should move around project cells instead of projects moving through functional departments.
The goal of a small team is not to make fewer people produce more features. It is to let the people closest to a problem complete one real test at the lowest responsible cost.
The evolution is not about turning everyone into a directionless “full-stack individual.” It is about combining a few complementary people into a complete learning loop. Expertise remains while fixed handoffs disappear; platforms remain while departmental walls become thinner; managers move from distributing tasks to configuring goals, authority, resources, and stopping conditions.
When one business partner and two product-engineering members can discover, build, deliver, observe, and decide whether to continue, change, or stop, AI becomes more than an individual productivity tool. It becomes infrastructure for a different kind of organization.
Practices from internet and AI companies
This model is not an organizational label invented from scratch. AI changes the economics of cross-disciplinary execution, allowing smaller teams to own more of the loop from customer signal to product outcome. These three first-party practices support the article's central themes of live feedback, small-batch iteration, and end-to-end accountability.
- OpenAI: Building OpenAI with OpenAI: OpenAI describes GTM, product, and engineering teams studying real workflows together, defining success, and testing changes in live deployments—closely matching a project cell that connects business signals directly with product iteration.
- Google DORA: Working in Small Batches: small batches shorten feedback loops and make hypotheses easier to test and revise. DORA also connects this capability with turning AI-enabled development speed into product and organizational performance rather than additional friction.
- Amazon AWS: Two-Pizza Teams and end-to-end ownership: the point of a small team is not size alone, but embedded resources, autonomy, accountability, and ownership of the end-to-end customer experience.