By Shea Lutton and Eric Harper
For product managers, a prototype is an invaluable tool to validate that you’re solving customer needs and to communicate exactly how a feature should look and feel. But prototypes require a critical tradeoff, your development team has to sacrifice their current feature work in order to build the prototype, slowing down feature delivery. LLMs are eliminating this tradeoff by enabling PMs to build prototypes independently.
ChatGPT allows product managers to go far beyond simply distilling customer needs into product requirement documents. In 2025, PMs can use the power of LLMs to test customer needs themselves by building working prototypes and directly testing feature value with customers.
In our experience, using these PM techniques on revenue generating features (but at a small scale) has made us 4x more effective than traditional PM workflows. It reduces our time to validate concepts with customers, boosts our personal productivity, avoids using developer time for prototyping, increases clarity (and avoids meetings!), and ultimately lets us focus development effort on features with proven value for our customers.
Forget product requirement documents, the future of product management is independently building feature prototypes for direct customer feedback.
As early adopters, engineers have written about the many ways that LLMs make them more efficient. Less has been written about LLM impact on other roles such as product management. What is the state of the art in product management in the LLM era? Simply using ChatGPT to write emails, PRDs, or roadmap documents is a marginal gain, maybe 5% to 10% more effective week over week.
LLMs for PMs
LLMs are starting to show how useful they can be for non-engineering professions, and that will increase in the future as more people start to use these tools in different settings.
PMs can use LLMs to replicate the productivity of an entire team of PMs, UX/UI designers, engineering managers and software engineers by developing business and feature context for ChatGPT. Since the goal of a PM is to condense the most valuable customer needs into clarity for what needs to be built, building a model yourself helps you iterate faster to validate customer needs. It turns a long prototype cycle into much shorter feedback loops, moving from this workflow:
2024 Workflow:
To a shorter, independent feedback loop. Fundamentally, when PMs can work unaccompanied and get further into the development process, they can significantly accelerate the pace of feature discovery. PMs can talk to customers, build a hypothesis for what features drive the most value, independently build a prototype, and gain direct feedback on the value. That short cycle will be the way great PMs work by the end of 2025 (if they are not already!).
2025 Workflow:
The ability for PMs to validate prototypes in this way is a major step towards the teachings of the “Lean Startup” by Eric Ries or the “Startup Owner’s Manual” by Steve Blank. PMs can validate ideas and iterate without having to dedicate the critical cycles of a development team to test a new feature.
In modern software development, the development team is the key constraint that limits your rate of progress. For readers of “The Goal” or “The Phoenix Project”, this is the key insight from both books. Having PMs identify if they are solving the correct issue means that development teams are focused on solving qualified customer problems.
Planning
We’ll show you the tools, methods, and structures we use in our modern PM workflows. But first, let’s take a second to reflect on what parts of the PM process are still valuable.
Good planning is key for LLMs just as it is for humans. A one-shot prompt is as likely to deliver a valuable customer feature as 1000 monkeys are likely to write the next Principia.
Our first take-away is that the PM process of aggregating many customer needs into a priority list, then creating feature briefs for the most compelling needs, and validating those features in a detailed product requirement document (PRD) is still a highly useful exercise. It’s the most effective way to confirm that you’re focused on the most important problems for your customers. Without this examination, organizations have a tendency to focus on easy problems, regardless of how valuable they are for your customers. Our workflow uses a standard template to help us deliver organized ideas in a one page format to test the concept. If that meets our requirements, we progress into a full plan using AI tools.
All of your business, customer, and technical context is separate from feature requirements, but it’s important to the final product. We create a structured library of code prompts that allow us to load the context we need from various personas and perspectives to generate code for our business needs. This includes business context about your industry, strategy, product value, customer roles, and details of your tech stack (languages, frameworks, tenets).
The same way a clean code repo breaks source code into logical structures, we break out prompt context into user roles (both internal and external stakeholders), brand style guidelines, go to market standards, and the principles and standards for how our companies build software. PM leaders should be intentionally developing these libraries across their teams to apply your principles and standards consistently across prototypes.
We split our prompt context into small chunks to balance the cost and speed of token processing against the quality of the results. We find we get better results by starting our prompts for code with business context and feature requirements from our planning work. We take the resulting code, add additional role context and iterate several times, such as loading the security architect role and revising the code for security quality. Even for limited prototypes, security is tremendously important and there is no substitute for engaging our brains for deep security reviews of the code produced. Working to balance token/context size may be a temporary limitation as ChatGPT rapidly advances, but in early 2025, adding context and doing multiple revision passes has given us the best results.
Prototype Development
From this point, PMs can start using AI tools to directly code working mockups. Why have PMs do this and not pass the task off to a developer? Speed, accuracy, and money. The PM already has the context of the customer’s need in their head. LLMs use the context library to develop code for a working prototype, and the PMs can take those mockups directly to customers for feedback. Only when customers have reacted favorably to a feature mockup and given positive sales signals will you pass a prototype to the development team.
In our workflows, this means PMs create new dev branches in git, paste Linear ticket information into Cursor along with relevant prompts from the prompt library such as the style guide (colors, fonts, and presentation), the design principles, the needs of various customer roles, and the internal development standards such as frameworks, languages, and architecture standards. The output of this work will be qualified customer feedback.
If it’s valuable to customers, then it’s worth having your development team turn it into a real feature (with real security, real authentication, real redundancy, real SRE, and real business continuity). The ability for PMs to independently generate prototypes does not lessen the need to build secure and reliable products. You still need your engineering team.
What to Watch For
What can go wrong building a prototype this way? When the output is wrong, it usually fits into one of these categories:
- Tech incorrect – The code or solution does not work (needs iteration)
- Tech correct, but missed the broader purpose – When your code works but it’s only solving part of a broader issue (revise planning)
- Business incorrect – The result works but is not helpful to customers as expected (revise business context and replan)
As you catch these errors, add material to your prompt library to correct the misunderstanding and iterate. It’s also helpful to add negative prompts, such as a “Never Do” section that corrects initial coding mistakes. Also explicitly ask ChatGPT what questions it has and what assumptions were made.
Changing Needs
In 2024, a great PM knew their user base, knew their product inside and out, and wrote clear documents for how the next feature should be delivered for customers. In 2025, using AI enabled tools, a great PM can go much further, replicating the productivity of a team of six to eight people by building prototypes themselves to confirm if features are valuable to customers.
Your team should start collaborating on a team-wide set of role prompts and business value prompts to start producing full working prototypes. PMs need to advance their skills to take advantage of the opportunity in front of them.
In our next post we invite you to look at the suite of tools that Eric Harper and Shea Lutton use to accelerate product development such as DrawCast and RepoPrompt to boost your team’s productivity. If you would like us to come and speak with your team about how the AI era can boost your company’s productivity, please contact us.