Everyone prototypes now

Everyone prototypes now. AI lets product managers turn ideas into interactive concepts within hours, designers explore more directions, and engineers test assumptions earlier.

AI can also produce working code. That raises an obvious question: if anyone can build and ship, what role do specialized disciplines play?

My view is that accessible execution increases the value of expertise. Deep knowledge of customers and the domain helps teams choose the right problems. Design expertise shapes coherent experiences. Engineering expertise accounts for architectural dependencies and production quality.

A PM or designer can use AI to produce working software. Shipping it to production introduces responsibilities that extend far beyond whether the interface works.

Production changes sit within a larger system. A simple interface adjustment can affect permissions, data models, APIs, performance, accessibility, observability, security, and other parts of the product. Many of these dependencies are visible only to engineers who work closely with the architecture and codebase.

PMs create the most value by understanding customers, developing domain expertise, and setting product direction. Designers create the most value by understanding user behavior, shaping coherent journeys, and maintaining the quality of the wider product experience.

Prototyping lets both disciplines apply their expertise earlier. Ideas become tangible, assumptions surface sooner, and conversations with engineering start with richer context.

Across the team:

Product development creates many artifacts, including research plans, technical designs, analytics requirements, and launch plans. This article focuses on four that carry an idea from product intent into an experience that engineering can build.

They are also the artifacts most likely to become confused as AI makes prototypes faster and more polished.

Each artifact answers a distinct question and carries a different level of authority.

Owner: Product Management

A PRD describes the customer problem, audience, requirements, scope, constraints, success criteria, and definition of done. It gives the team direction while leaving room for design and engineering to shape the solution.

The PM authors the document, keeps it current, and communicates meaningful revisions. Design and engineering contribute early by challenging assumptions, raising questions, and identifying requirements that could restrict exploration.

A PRD can be shared broadly. It aligns engineering and cross-functional stakeholders around intent without committing the team to a particular experience.

Owner: Product Management

A concept sketch turns the PM's mental model into something product and design can react to. It reduces ambiguity, surfaces assumptions, and helps the pair decide whether an idea deserves further exploration.

Concept sketches should be quick and disposable. AI may give them a polished appearance, so their purpose needs to be explicit. They represent one possible interpretation of the PRD.

The PM shares the intent, constraints, assumptions, and open questions. The designer challenges the concept, reframes the problem, identifies gaps, and explores alternatives. A promising sketch can give design a useful head start. A weak direction can be discarded before the team invests further.

These sketches work best within the PM-design partnership and, when useful, the PM team. Wider sharing can anchor people to a particular interface before the experience has been fully considered.

When broader input is valuable, we label the artifact clearly:

Owner: Design

An experience prototype tests whether the customer journey, product concepts, interaction patterns, states, and transitions form a coherent experience. It may cover one flow or a broader journey.

A useful concept sketch can accelerate this work by providing context and early learning. Design develops the direction using its understanding of interaction patterns, customer behavior, and the wider product experience.

The designer owns the prototype and its iterations. The PM checks the direction against the customer problem, success criteria, and scope. Engineering contributes knowledge of the codebase, technical opportunities, and downstream implications.

Experience prototypes can support user research, product discussions, and early engineering feedback. At Workato, they are directional artifacts rather than the sole input for implementation.

They can also support cross-functional alignment with clear framing:

Owner: Design, developed with Product and Engineering

Some teams have begun giving experience prototypes directly to engineers. At Workato today, we still use design specifications in Figma as the build-ready reference.

A design specification captures the agreed screens, flows, states, interactions, content, and relevant component behavior. It reflects feedback from product and engineering and gives the team a precise view of the experience being built.

Figma also provides something an interactive prototype alone does not always preserve: a shared and persistent collaboration space. People can comment in context, review changes, and refer back to how a design evolved.

History matters to us. Teams sometimes uncover new information during development, revisit an earlier decision, or change direction entirely. A durable record makes it easier to understand why choices were made and where the team can safely take a step back.

The design specification becomes the primary experience reference during implementation. Engineering still shapes the technical approach, raises feasibility concerns, and collaborates on adjustments as the product takes form.

AI can make an early idea look finished. Visual polish therefore provides little information about an artifact's maturity.

Before creating or sharing one, we clarify: