Figma Make AI-prompt design project

In a team prompting context, the product manager's role becomes even more load-bearing than usual. Consider a patient intake form built for hospitals and clinics. The end users sitting in the waiting room filling out the form are not the only stakeholders whose needs have to be represented in the specification. The organizations purchasing and deploying the software, the hospital administrators, compliance officers, and clinical staff, have their own requirements, and those requirements are often non-negotiable. A PM who understands the purchasing context knows which fields are legally required, which disclosures must appear and in what form, and which design choices will create liability rather than resolve it. None of that knowledge lives in a prompt by default. It has to be brought to the table deliberately, before the tool runs, by someone whose job it is to hold that context.

This is one of the clearest arguments for why team prompting is not just a nice collaborative ritual but a practical necessity. The AI tool will build what it is told to build. Getting the specification right, and right in ways that account for legal, regulatory, and client-side constraints, is precisely the contribution a strong product manager makes to that process.

In a team prompting context, a genuinely engaged engineering voice is not optional. It is the thing that keeps the specification honest. Designers and product managers, left to their own devices, are capable of speccing what engineers sometimes call a flying car: something conceptually appealing, perhaps even visually compelling in a prototype, but either unbuildable within real constraints or so performance-degraded in execution that it defeats its own purpose. A well-designed patient intake form that takes eleven seconds to load in a hospital waiting room, or that times out under network conditions common in older clinical facilities, is not a well-designed patient intake form. An engineer in the room catches that before it becomes a prompt.

The technical considerations go further than feasibility and performance. A patient intake form transmits sensitive data: diagnoses, insurance information, dates of birth, contact details, all of it protected under HIPAA and subject to the broader obligations around personally identifiable information. How that data is handled at the API layer, how it is encrypted in transit, what third-party services it touches and whether those services are compliant, these are not afterthoughts to be sorted out in a later sprint. They are constraints that belong in the specification from the start. An engineer who understands the regulatory landscape around healthcare data will surface those requirements before the tool runs, not after the prototype has already made assumptions that are expensive to unwind.

There is a quieter category of contribution worth naming as well. Engineers often hold institutional knowledge about the systems a new interface will have to connect with: legacy EHR platforms, authentication layers, data validation requirements that exist not because anyone designed them but because they accumulated over years of incremental decisions. That knowledge shapes what is actually possible, and it rarely surfaces unless someone with that context is in the room and invited to speak.

Pair programming has been a fixture of engineering culture for years, built on a simple premise: two sets of eyes will catch what one misses, and the conversation between them often produces something neither person would have reached alone. I can see an analogous practice emerging on the design and product side, and for now I'd call it team prompting.

The working session I have in mind looks something like this: a designer, a product manager, and an engineer sit down together not to review a completed spec but to draft one collaboratively, with the explicit goal of handing it to an AI tool. Each discipline brings what it sees most clearly. The designer brings the constraints of usability, accessibility, and craft. The product manager brings the user's job-to-be-done and the relevant business context. The engineer brings the technical constraints that separate a solution that is merely possible from one that is actually viable. The AI tool, given that collectively-authored specification, generates a first prototype for the team to review and revise together.

This is not entirely unlike what the best cross-functional teams already do informally. But AI compresses the feedback loop to the point where the initial specification becomes the most consequential artifact in the whole process. Getting it right before the tool runs is the new pre-work. That puts a new kind of premium on structured, cross-disciplinary thinking, exactly the kind that has always been valuable but rarely been urgent.

The details are the design. This is not a slogan. It is a working description of where the discipline actually lives. In a patient intake form, the details are: whether a field is marked required or optional, and marked correctly. Whether the micro-copy asking for a date of birth reads like a form or like a person. Whether the input fields are sized to reflect the data they are meant to hold, so that a field asking for a two-digit state abbreviation does not present itself at the same width as a field asking for a street address. These are not finishing touches. They are the substance of the work. Product managers will not catch them. Developers will not catch them. A designer who misses them will answer for them.

What AI design tools expose, with some clarity, is the difference between a designer who can operate the instruments and one who understands the music. A junior designer working with a tool like Figma Make may produce something that looks finished. The layout resolves. The components are recognizable. But the layer of judgment that determines whether the output is actually right, whether the hierarchy serves the user's task, whether the language respects the context, whether the form asks for information in the order that matches how a patient actually thinks, that layer requires something that cannot be prompted into existence. It comes from years of looking closely at the work, understanding why a decision holds up, and having been wrong enough times to know the difference.

This is not an argument against junior designers. Every experienced designer was once one. It is an argument for understanding what role depth of craft plays in a team prompting context specifically. The designer in that room is not just a stakeholder with aesthetic preferences. They are the person responsible for translating the team's collective intent into a specification precise enough that the AI tool has a chance of getting it right, and experienced enough to recognize when the output falls short. That is a job that rewards accumulated knowledge. As these tools become more capable and more widely adopted, the designers who have done that accumulation will find that AI extends their reach considerably. The ones who haven't will find that it mostly scales their blind spots.