Alpesh Kumar

AI product development now has a much cheaper first step: turning an idea into a small, interactive prototype. What has not become cheap is the judgment required to decide whether that idea should become a real product.

A rough workflow that once needed a specification, design work and an engineering sprint can now be explored in hours. That changes how teams learn. It does not remove the need to understand users, shape an experience or make deliberate technical choices.

In a recent essay on product management, a16z partner Josh Elman makes a useful distinction: demonstrations may be cheap, but a reliable product is not. The work of understanding users, making sound technical decisions and maintaining focus still remains.

AI product development has a new cheap step

For a long time, the development loop was constrained by the cost of engineering time. Teams would move from an idea to a brief, requirements, design, implementation, release and learning. The documentation and review stages were not pointless bureaucracy; they existed partly to avoid committing scarce build capacity to weak ideas.

AI-assisted tools alter the economics of the earliest stage. A team can now make a deliberately limited version of a workflow, interact with it and uncover problems that were invisible in a document. A product discussion becomes more concrete when people can react to a working path rather than imagine one.

The more useful loop is:

1. State the user problem and the assumption being tested.
2. Build the smallest prototype that can test it.
3. Use it, or put it in front of representative users.
4. Decide what the evidence changes: the workflow, the scope or the premise itself.
5. Only then invest in the design, engineering and operational work needed to make it real.

This does not replace discovery. It gives discovery another instrument.

Why a prototype is not a product

A prototype can establish that an interaction is possible. It does not establish that the experience will be reliable, understandable, secure, accessible or maintainable when it reaches real users.

Consider a hypothetical AI assistant that turns a support request into a drafted response. A quick prototype can reveal whether the draft is useful and whether the controls make sense. A production version has further questions: which data may the model access, how should mistakes be reviewed, what happens when a dependency fails, how do users correct bad output, and how is performance monitored over time?

Those questions are product work, design work and engineering work. AI can compress the gap between an idea and an experiment, but it does not make that gap disappear.

Judgment becomes the scarce resource

When the cost of making a plausible feature drops, the central decision changes from “can we build this?” to “does this belong in the product?”

That is a higher bar than it sounds. A product can become confusing when every attractive feature is added simply because it is easy to generate. Coherence comes from deciding which user need matters most, which action the product should make effortless and which ideas should remain outside the experience.

That same discipline applies to AI agents and workflows. Building an agent is not the end of the product decision. It is the beginning of questions about the task boundary, the level of autonomy, the feedback loop and the human control points. These are themes worth considering alongside how AI applications connect tools and services through MCP and APIs.

Use prototypes to answer a precise question

A strong prototype starts with a question that can change a decision. Examples include:

• Can a new user understand the workflow without an explanation?
• Does this reduce a real source of friction, rather than merely add novelty?
• Which moment makes a user hesitate, retry or abandon the task?
• Does the AI capability improve the outcome enough to justify its complexity?
• What would have to be true for this to become dependable software?

Without a question, a prototype can create the appearance of momentum while leaving the core uncertainty untouched. With one, it becomes a fast way to test a hypothesis before a team commits to a larger design.

The product manager’s job is still to create clarity

Elman argues that the most important product-management artefact is not the specification alone, but a shared story: who the product is for, what they are trying to do and why the experience matters to them.

That story gives every later decision a reference point. It helps a designer decide what deserves emphasis. It helps an engineer understand the non-negotiable behaviour. It helps a team recognise when a new feature improves the product and when it merely makes the interface busier.

AI makes it possible to learn sooner. The teams that benefit most will be those that pair that speed with disciplined research, careful product judgment and the willingness to remove what does not serve the user.

Build the small version quickly. Learn from it honestly. Then decide whether it deserves to become a product.

Source and further reading: Josh Elman, “Product Management Is Still All About Telling Stories”, published by Andreessen Horowitz on 14 September 2026.