8. aprill 2026

AI Prototyping Is Changing How We Build Products at Uber

“Two Hours of Prototyping Unblocked Four Weeks of Discussion”

That's how a product manager on Uber's Merchant team described the impact of using AI in their product development lifecycle. They used AI to quickly customize a prototype to a specific merchant's catalog as part of a product research exercise. The merchant understood it immediately and gave specific and actionable feedback. Internal alignment followed just as quickly. The ambiguity that had stalled the project evaporated.

This moment wasn’t an outlier. Over the past year, we’ve experimented with AI-powered prototyping across Uber’s Product organization. We kept seeing the same pattern: ideas that once required weeks of cross-functional coordination could now become tangible in hours. Clickable flows and interactive demos showed up much earlier in the product lifecycle, often before a PRD (Product Requirements Document) was fully formed.

That shift also changed the nature of conversations. Instead of debating abstract descriptions, teams could react to something concrete. AI prototyping is reshaping how teams explore ideas, align on direction, and move toward execution — not as a replacement for established product practices, but as a capability that makes them more effective.

Why This Matters at Uber: We Build Globally, We Live Locally

At Uber, even small product changes span multiple teams across regions and functions, including product, engineering, operations, policy, and legal. Creating shared understanding at scale is challenging.

AI prototyping reduces the cost of coordination by making ideas tangible early. Instead of debating written descriptions, teams react to the same artifact, moving faster toward what matters most: building high-quality, intuitive experiences for our customers. At Uber’s scale, this translates directly into faster iteration and better decisions.

What We Mean by “AI Prototyping”

By “AI prototyping”, we mean using AI-assisted tools like Lovable™, Figma® Make, Claude® Code, and Cursor® to generate and iterate on interactive flows quickly so teams can test assumptions, gather feedback, and align before decisions harden.

Three Patterns We Kept Seeing

Prototyping wasn't driven by a mandate or a new process. Teams reached for prototypes instinctively when they needed to move faster or work through ambiguity.

One clear signal came from the global Uber tech hackathon. Nearly 40% of submissions incorporated a prototyping tool. Prototypes weren’t used as final polish. They were used to think through ideas, explain systems, and align quickly under time pressure.

Looking across these experiments and day-to-day work, three patterns stood out: greater exploration of ideas, faster alignment, and unblocked execution.

1. Greater Exploration of Ideas

One of the clearest shifts was how easily teams could explore multiple ideas early, which changed the shape of decision-making that followed.

Historically, exploring multiple directions was expensive and coordination-heavy. That naturally pushed teams to converge early. AI prototyping lowered that barrier.

Instead of narrowing quickly, teams could explore a broader set of possibilities upfront, often before designs or specifications were locked‌ in. A product manager on the Business Platform team described exploring six distinct concepts for the same problem in about 20 minutes. Previously, that level of exploration required multiple iteration cycles.

Two smartphone screens display a ride voucher sharing process. The left screen shows a blue paper airplane icon above the text 'Send your voucher,' offering 2 rides with $25 off each, expiring in 24 hours, and buttons to copy the voucher link or see sharing options. The right screen features a hand holding a phone with a voucher graphic, and text indicating the voucher is ready to share, valid for 1 ride, up to $50 off, expiring in 24 hours, with a button to share the ride voucher.

Figure 1: Exploring different solutions for the voucher sharing product.

The important change wasn’t speed for its own sake. Exploration moved earlier in the lifecycle. Teams could test assumptions before PRDs were locked, before architecture decisions hardened, and before committing to a single path forward.

2. Faster Alignment

If exploration was the first visible shift, alignment was where the impact became most apparent.

A large part of product work is helping teams build shared understanding across product, design, engineering, and leadership. Even with strong PRDs, alignment often depends on how well people can translate written intent into a common mental model of the experience.

AI prototyping changed the starting point of those conversations.

Instead of asking teams to imagine how something might work, PMs or designers could put a concrete, interactive artifact in front of them. Conversations moved quickly from “what is this?” to “is this the right approach?”

A product manager working on complex, cross-functional systems summarized the effect: “We achieved high-level alignment across product, partners, design, and engineering with much lower turnaround time than a document-only process.”

This shift also changed how ideas travel upward. A product manager on a platform team noted: “Using a prototype to show rather than tell made it easier for senior stakeholders to understand the direction and engage in more substantive discussions.”

When teams could react to the same tangible artifact, feedback became more specific and actionable. Alignment happened earlier, with fewer interpretation gaps to resolve later.

Importantly, this did not replace PRDs or design reviews. It strengthened them. Teams entered those forums already grounded in something concrete, which made written discussions more focused and productive.

3. Unblocked Execution

Alignment is about shared understanding. Execution is about momentum.

The third pattern we saw was how AI prototyping helped teams move from alignment to action by collapsing uncertainty earlier in the lifecycle.

Execution rarely stalls because teams disagree. It stalls because key questions surface too late. Scope, sequencing, and what counts as the MVP often come up right when engineering is ready to start, slowing progress even after alignment has been reached.

Prototyping pulled those questions forward.

Uber Eats Manager dashboard displaying the menu for Bear Steak Sandwiches - Shared. The 'Classic Combos' section lists four items: Original Steak Classic Combo, Original Steak Classic Combo (Chimichurri on the Side), Steak Alla Vodka Classic Combo, and Steak Avocado Classic Combo. Each item shows delivery and pickup prices, along with availability status marked as 'In stock.' Navigation options are visible on the left sidebar, including Home, Stores, Orders, Performance, Customers, Reports, Marketing, Catalogs, Users, and Settings.

Figure 2: A prototype that helped define the MVP for Uber Eats Manager’s catalog management experience.

Across several teams, another execution benefit showed up repeatedly: clearer MVP definition. Having a prototype made it easier to agree on what was in scope versus what could come later.

As one PM put it, “having a prototype made it much easier to distinguish MVP from post-MVP,” which allowed engineering to start sooner with clearer boundaries and fewer open questions.

Execution did not get faster because teams skipped steps. It got faster because teams entered those steps with fewer unknowns and could start building earlier with clearer scope.

Prototyping Didn’t Kill the PRD, It Became Its Sidekick

As AI prototyping became more popular, a natural question emerged: Do we still need PRDs? In practice, we found the opposite.

Prototypes are powerful because they make ideas tangible. They give teams something concrete to react to and make early discussions faster and more grounded. But prototypes are experiential artifacts: they show what an idea might look like or how it might work, not why a direction was chosen, what tradeoffs were made, or which constraints shaped the decision.

This is where PRDs continue to matter. If prototypes help teams experience the future, PRDs help teams align on it. One without the other creates risk. A prototype without a PRD can drift away from the problem the team intends to solve. A PRD without a prototype can remain abstract, leaving room for inconsistent interpretations.

You can think of it like Batman and Robin. Each can operate solo, but they’re far more effective together. Prototypes open up the space quickly. PRDs slow things down just enough to make decisions explicit and durable. This becomes even more important when many cross-functional stakeholders, such as legal, ops, policy, marketing, data science, and platform teams, are involved in review and sign-off. In those cases, a prototype can accelerate early product conversations, but the PRD is still what carries the detail and clarity needed for final decisions.

What emerged wasn’t a replacement, but a pairing: problem framing → early prototyping → a sharper, more informed PRD → final designs.

Cartoon superheroes resembling Batman and Robin shaking hands, labeled 'Strategy / PRD' and 'Prototype' respectively; Batman holds a rolled-up document, Robin holds a tablet with a wireframe design.

Figure 3: The relationship between PRDs and prototypes.

Prototype-First Versus PRD-First

In practice, the right starting point depends on what you’re building.

Prototype-first if…

The problem area is ambiguous or unfamiliar
The team needs fast stakeholder alignment
The solution space requires exploring multiple directions
The user flow complexity is high
The initiative needs leadership buy-in to unlock resources
The product is internal-facing or low-stakes
The goal is early vision exploration

PRD-first if…

The product is mobile-first (AI prototyping tools often underperform here currently)
The problem is strategic, not UI-heavy
The product is mature and changes have ripple effects
The domain is high-risk, compliance-sensitive, or safety-critical
The dependencies are complex (legal, infra, data)
The scope involves modifying an existing feature with clear constraints
The product is external-facing and fidelity expectations are high

Pitfalls of AI Prototyping (And How We Avoided Them)

As prototyping got easier, we also learned where it can go wrong — especially when prototypes get mistaken for decisions. The goal isn’t to prototype less; it’s to prototype with guardrails.

Table outlining five common prototyping pitfalls, their signs, and suggested guardrails. Pitfalls include prototype seduction, skipping the “why,” anchoring bias, poor collaboration, and the misconception that prototyping is free. Each row lists signs of the pitfall and practical guardrails to avoid them, such as labeling prototypes as representations, attaching problem statements, running problem-framing workshops, pairing prototypes with feedback documents, and timeboxing iteration cycles.

Figure 4: Pitfalls and guardrails of AI prototyping

What Changed When Everyone Could Prototype

We made a deliberate decision early on to open up AI prototyping beyond product teams.

Instead of limiting prototyping to PMs or designers, we made it accessible across engineering, platform, and operational teams. We wanted to see what would happen if more people could turn ideas into something tangible.

The results were immediate. Engineers used prototypes to spin up interactive dashboards and rethink engineering workflows. Operational teams used them to simplify processes and explore internal tools. For example, EMEA sales teams built their own opportunity tracker to find relevant leads instead of relying on an off-the-shelf tool. Instead of describing ideas in documents or tickets, teams could show what they meant.

When ideas can be shared in a form others can interact with, the best ideas rise regardless of where they come from. Assumptions surface earlier, discussions become more concrete, and proposals are evaluated on their merit rather than their source.

This directly reinforces a core value at Uber: Great Minds Don’t Think Alike. By opening up prototyping across the company, we created space for more perspectives to shape solutions earlier. Engineers, operators, designers, and product teams could all contribute meaningfully, and the resulting ideas were stronger because of it.

Open Questions: What’s Next

As AI prototyping becomes faster and more widely used, the questions we’re asking have shifted from whether this works to how the rest of the product system should evolve around it.

What’s the Evolving Role of the PRD?

If going from idea to prototype is now fast and cheap, the PRD can no longer be the primary place where ideas are defined. Its value increasingly lies in capturing intent, tradeoffs, success metrics, and decisions. We’re actively exploring where AI can help draft and refine this thinking, and where human judgment needs to remain explicit and durable.

How Do We Use AI to Gather Insights Faster?

When prototypes are easier to create, teams can test assumptions earlier and more often. That shifts the bottleneck from building artifacts to learning from them. We’re thinking about how AI can help synthesize feedback, surface patterns, and turn interactions into insights at a pace that matches this new speed.

How Do We Move From Prototype to Production?

Prototypes are powerful for exploration, but production requires rigor. We’re working through how prototypes inform architecture, design systems, and engineering work without being mistaken for shippable solutions. The challenge isn’t speed alone, but knowing when to transition from exploration to commitment.

Conclusion

AI isn’t just accelerating early-stage work. It’s changing how product development, decision-making, and execution fit together end to end.

Product development has followed largely the same lifecycle for decades. With AI, we have an opportunity to rethink it. The patterns we’re seeing are already translating into faster iteration cycles, earlier alignment, and clearer decisions before teams commit to building.

We’re taking steps at Uber to evolve how teams explore, align, and execute, and we’ll continue sharing what we learn as this drives real gains in speed and quality — including how these workflows extend beyond prototyping into deeper building and iteration.

We’re excited to keep learning alongside the broader tech community about what works and what doesn’t.