LLMs drive the cost of detail and polish to zero. ChatGPT or Claude can spit out a detailed PRD or a long list of user stories from a one sentence prompt. Much of what they write may be wrong or useless. But since it looks polished, it signals to the reader, “Trust me. This is well thought-out.”
Psychologists call that dynamic precision bias.
The Illusion of Accuracy
Precision bias is our human tendency to use precision and detail as signals for accuracy. If a number looks precise or a document looks detailed and polished, we’re more likely to trust it…whether or not there’s any objective reason to.
This is how all cognitive biases work, by the way. They’re shortcuts that save energy but sometimes lie to us. Unfortunately, while they’re good at keeping us alive, they really undermine product development.
Just in the past week, I’ve seen several PRDs, feature descriptions, and user stories that clearly show LLMs’ fingerprints. And I’ve watched developers treat all the details in those artifacts as true, breaking them down into smaller stories and even BDD scenarios without really asking anything like, “What evidence do we have for this?”
Placeholders, Not Prescriptions
Long before requirements documents were AI-generated, user stories were a response to precision bias in product development. The early eXtreme Programming practitioners noticed that detailed requirements tended to inhibit collaboration. People would ask few questions before diving into development.
So, they talked about user stories as “placeholders for conversations.” A record of what has already been discussed and just enough detail to focus the next conversation. As different decisions need to be made in the life of a user story, there’s a whole series of conversations that lead to more and more detail being captured.
This approach of incrementally and collaboratively adding detail applies beyond user stories.
For example, a very lightweight PRD would be enough as input to a Feature Mining session for an initiative. That cross-functional conversation would produce the first one or two Minimum Marketable Features, which could then be broken into user stories (again, collaboratively). And as the team works on those MMFs, a shared understanding of the initiative emerges, which informs more detail in the PRD, more features, and more user stories.
It’s not just about limiting up-front detail. If you want to create product artifacts that invite conversation rather than shutting it down, there’s also a key language change to consider. Adopt the language of experimentation rather than specification.
Certainty Is the Wrong Goal
Most new things worth building are going to have some complexity to them. So, instead of specifying all the details as if you know the future, be transparent about hypotheses and assumptions. Here’s what we believe to be true. Here’s how we’d know if we were right or wrong.
A one-pager that lays out, at a high level, assumptions about the problem to be solved, the business case for solving it, the constraints on the solution, and the tests that would validate the hypothesis is a great alternative to a detailed specification for an initiative.
It’s natural for people to want certainty. PMs want to communicate clearly and confidently. Devs want to know that they’re going to build the right thing and not have a bunch of rework.
But if you’re solving complex, meaningful problems, early certainty is an illusion. The detail doesn’t make things more accurate. It just lets you potentially build the wrong thing more confidently.
If conversations around your product artifacts mostly sounds like, “Any questions?” (and you’re hoping the answer will be “nope, that all makes sense”), then the documents may be doing too much work.
The best way to use artifacts to invite conversations is to think about the various decisions you’ll need to make together and treat the artifacts as one input to those decisions. For example,
- Where should we start on this initiative?
- How big is this feature?
- How should we break this feature into stories?
- How big is this story?
- Etc.
By writing with the decision in mind, you can avoid capturing unnecessary detail too soon. It’s not, “What’s everything I know or might get asked about for this initiative?” It’s, “What info will set up this conversation for success?”
Here’s a small change you can try this week: Take something complex and match the level of detail to the level of evidence you have. Get explicit about assumptions and hypotheses. And then let detail emerge as you interact with your team around the item.
Go Deeper
Want to learn more about building this way of working into your whole product development approach? Check out our Complexity-Aware Planning, Estimation, and Delivery (CAPED) approach, and join us in an upcoming CAPED workshop or schedule a free consultation to see if the CAPED approach is what your high-stakes initiative needs to succeed.
Last updated