Prompt Like a Product Team, Not a Solo Developer

Most people prompt AI coding tools the way they would fire off a Slack message to a junior developer: "Build me a feature that does X." That is exactly the wrong approach, according to @andrew_ships. His argument is simple and grounded in how real software teams work. If you want high-quality output from an LLM, you need to give it the same depth of context that an entire product team would provide to a human engineer.

The Core Problem: Context Gaps Become Hallucinations

When you hand a model a thin prompt with no user story, no design specs, no technical approach, and no testing criteria, the model fills in those blanks on its own. It guesses. It hallucinates. The output might look like code, but it solves the wrong problem in the wrong way because you never told it what "right" looks like.

This is the same failure mode that happens on real teams when a developer gets a half-baked ticket with no acceptance criteria. The difference is that a human might push back and ask clarifying questions. An LLM will just keep generating.

Four Roles, One Prompt

The video walks through a diagram that maps out four distinct roles in a software development process, each represented by a colored circle: Product (green), Engineering (blue), Design (orange), and QA (green). Arrows from all four converge into a single node labeled "High Quality Prompt."

The point is visual and direct. Each role contributes a different type of context:

• Product Manager -- the user story, business goal, and success criteria. Why does this feature exist? What user problem does it solve?
• Engineer -- the technical approach, architecture constraints, and implementation preferences. How should it be built?
• Designer -- the design specs, layout expectations, and interaction patterns. What should it look and feel like?
• QA Engineer -- the test plan, edge cases, and acceptance tests. How do you know it works?

When you combine all four perspectives into a single prompt, you are giving the model the same variety and depth of context that a real scope-of-work document would contain.

Where This Applies

@andrew_ships names specific tools: Cursor, Windsurf, Bolt, Lovable, V0, and other LLM-native IDEs. The advice applies to any tool where you are writing natural language instructions to generate code. The principle is the same regardless of the interface. More context, delivered from multiple disciplinary angles, produces better results.

Key Takeaways

• Treat the LLM like a developer who needs a full briefing, not a mind reader who can infer your intent from a one-liner.
• Combine product, engineering, design, and QA perspectives into every prompt to eliminate gaps the model would otherwise fill with guesses.
• Include user stories, design specs, technical approach, and testing criteria as standard parts of your prompts.
• The quality of your output is directly proportional to the quality and variety of context you provide.
• Thin prompts produce hallucinated solutions. Rich prompts produce working features.