Common issues with PRDs generated by AI

Taking a product idea from concept to mass production often requires multiple teams of people working together to research, build, manufacture, market, and sell the product. And working with all of those teams successfully requires detailed communication about the product idea — what it is, how it’s used, who it’s for, what it’s made of, and more. 

The document that evolved to provide this communication is the much-templated PRD, the product requirements document. Despite not having any specific standardized structure, contents, or length, it’s become the de facto standard document for capturing information, decisions, and intentions around a product before it exists. 

And now that AI can help us take ideas out of our heads and put them on paper, a detailed multi-page PRD can be generated within a matter of moments based on a short one-sentence prompt. As a quick experiment, open up your AI agent of choice, and then enter the following prompt: “Write a PRD for a new kind of flashlight.” You can also take a look at our examples from giving this prompt to Claude and Gemini: 

• Claude flashlight PRD
  
• Gemini flashlight PRD

On the surface, these example PRDs seem detailed and well-written — but as soon as we take a closer look, the confident Flashlight Product Reality quickly turns to Flashlight Product Fantasy. You may be amazed (and hopefully slightly alarmed) at how readily AI documents user personas, market sizing, feature lists, and business metrics based on zero additional information or context. 

In both of our examples, this new flashlight product suddenly has built-in GPS, over-the-air firmware updates, and a companion mobile app to adjust the brightness of your flashlight. Claude also helpfully added an accelerometer for gesture detection, an option to upload all of your contacts to the cloud for emergency notifications, and “automatic adjustments based on local weather data,” in case you ever wanted a flashlight that would adjust its brightness based on how cloudy it is.

When you ask an AI model to write a PRD, it can — and will — generate text to fill a void, and phrase it like well-researched facts. But this can easily lead development teams toward expensive mistakes — trying to meet unrealistically stringent requirements, assuming an overly positive customer response, or building an unnecessarily complex product that nobody wants. Here are a few of the business-derailing major pitfalls in AI-written product documentation, which we’ve seen not only in low-effort PRDs but also in real ones people have sent us: 

“Homer’s car” syndrome

• Specifying way too many features, especially for first-gen products. Does a flashlight need automatically adaptive lighting, motion detection, weather integration, a mobile app, and on-device machine learning? What extraneous features might it add to your product idea?
• Adding unwanted customization options. Gemini’s PRD states that the flashlight “allows users to swap modules to fit their specific needs,” including a UV module, a “bug zapper” module, and others as alternatives. Will customers buy a flashlight when they really just want a bug zapper?

Building a new hardware product is usually expensive and time-consuming, and adding unnecessary features makes development take even longer and cost even more. If a product is bundled with too many features, there’s also a risk that customers won’t want to pay extra for those additional features and may not buy the product at all. Would you pay extra for a refrigerator that also has a built-in microwave and toaster?

Delusionally optimistic

• Making up overly positive reactions from theoretical customers with no research, writing user stories with lines like “They liked it so much they bought three more right away for their friends.”
• Assuming that no design or engineering iterations is needed between first prototype and mass production. It’s not uncommon to run through a handful of concepts over 12–18 months to create a consumer electronics product.
• Making unrealistic predictions. In Claude’s flashlight example, it states a goal of capturing 15% of the market share within the first two years. This means the product would have to capture more market share than any current established flashlight brand, like Maglite, right off the bat. 

In a separate conversation, I asked Claude how a new flashlight company could plan to capture 15% of the market within two years, and here’s what it said: “The only way I can think of to plausibly get to 15% in two years would be acquisition (buy Coast or Dorcy outright) or a true category redefinition, where the “flashlight” is actually a different product that displaces flashlights — something like how smartphone flashlights ate the casual-use segment without ever competing as flashlights. A conventional new flashlight brand executing brilliantly might realistically target 1–3% in two years and consider that a major win.” Clearly, Claude didn’t do this research when writing the PRD. 

Setting unrealistic timelines or goals can have far-reaching complications. If you believe you can ship a brand new product in six months, and secure funding to cover that time, what happens when you need more development iterations but you’ve run out of money? Have you ever liked a product so much that you bought three more for your friends right away? Making bets based on false sentiments can lead to a lot of unsold products sitting on warehouse shelves.

Overly precise in all the wrong places, yet leaving large features vague

• Writing high-precision requirements without specific reasoning or justification — especially on dimensions or tolerances. Claude describes its flashlight as needing to be exactly 7.5″ x 1.8″ diameter, weighing 14 ounces. What if it weighs less? Wouldn’t that be better? Why 1.8”? This is the kind of specification that can result in wasted engineering hours spent trying to achieve a precise measurement without a specific reason. 
• Describing specific programming languages or packages to use, or even including code samples. We’ve received AI generated PRD documents that include entire sections of code snippets to be used, despite later calling out a microcontroller that uses an entirely different programming language.
• Listing things like “fully automated and configurable settings” with no details about what those settings are, or how they’ll be automated.

These kinds of specifications can lead to excess costs on expensive materials or components. For example, human hearing is 30Hz to 20kHz, but that doesn’t mean every individual loudspeaker needs to replicate this entire frequency range. A software developer given a spec of “fully automated and configurable settings” without any further details may end up spending a lot of extra time and resources creating unnecessary or undesired features.

Other things to watch out for

• Conflicting statements that don’t account for the whole picture. For example, describing in one section that the product weighs about 20 lbs, and in a different section, stating that it’s “good for travel.”
• Compliance with irrelevant standards. A “calming sounds” product doesn’t need to meet loudness standards intended for industrial alarm systems. Or listing a specific compliance system without stating the level of compliance. This would be like saying it should have an IP rating, but without saying what the IP rating should be.
• Unnecessary justification that would otherwise be obvious to a human reader. For example, stating that “it runs on electricity.”

Tips on using AI effectively 

An AI agent can be a helpful partner in the documentation process, when used in the right ways. Every product on the market once began as a document of requirements — and it’s only through a process of research and learning, business planning, and making careful trade-offs that each product grew from documented idea to reality. Using AI effectively to help with writing a PRD could be it’s own blog post, but here are a few tips:

• Use a desktop app like Claude Code or Claude Cowork, so it can write the PRD in a file that can be iterated on over time. A PRD evolves over time, and you may not have all the info when you start the process. And when you have a document that you (or Claude) can update as you go, it’s easier to start a new conversation to avoid context rot.
• Tell your AI agent that you don’t want it to make anything up and everything in the document should be based on real information that you provide.
• Ask your AI agent to act as a facilitator or even sparring partner. Start by asking it to propose an outline, and then have it ask you questions to fill in each section. Throughout the process, start a new conversation and ask the AI to critique the document. Ask it to perform a reality check on the idea, the user stories, the timeline, etc.
• Have a separate conversation if you want help with brainstorming possible use cases or features. Ask it for tradeoffs or considerations, for example, if it suggests making your product waterproof, ask it what other implications that might have. 

In many ways, asking an AI agent to write a PRD comes with the same caveats as asking a person to write a PRD. You wouldn’t just say “write a PRD for my product idea” without also telling them what the idea is, who it’s for, and how it fits into your business, so be sure to give your AI the same context and encourage it to ask follow-up questions as needed, to make sure you get the best results.

We’re firm believers in “less is more” when creating a new PRD. Work directly with your engineering and design teams to help fill in the unknowns and to reduce costs and timelines. AI may tell you which microcontroller is the cheapest, but may not know that it’s also a nightmare to program, increasing timeline and labor costs. When in doubt, reach out to informal, and we can help refine your PRD!

informal is a freelance collective for the most talented independent professionals in hardware and hardtech. Whether you’re looking for a single contractor, a full-time employee, or an entire team of professionals to work on everything from product development to go-to-market, informal has the perfect collection of people for the job.