Validate Feature Decisions Before the Spec Locks
A product manager can run a defined simulated stated-choice comparison against a modeled target population to shortlist feature assumptions before the spec locks, replacing team votes with documented planning evidence. The shortlist then needs suitable human or live validation before the team relies on it. A product manager writes a PRD, hands it to engineering, and finds out six weeks later that an assumption about the target customer was wrong. The team has spent a sprint on the wrong problem, and the spec window that would have caught the error already closed.
The usual fix, more user research up front, runs into its own limit: recruiting, scheduling, and running a study takes weeks the roadmap does not have. Instead, the loudest opinion in the room decides, and the PRD locks around that opinion rather than evidence.
What causes the wrong feature to ship
The failure is not a lack of customer data. It is a gap between when a PM needs an answer and when real research can produce one, and in that stretch most teams have no fast way to check a hypothesis against a target customer, so the team votes instead.
Subconscious closes that gap by running a controlled stated-choice experiment against a modeled population before the spec locks: state the decision, the audience, the alternatives, and the outcome, then compare which action moves that outcome. That is a test, not a chatbot opinion, and it follows the same discipline as structured concept testing, which compares alternatives against a described audience instead of asking which one a team prefers (Qualtrics, "Concept Testing: Definition, Methodology & Examples").
What can this kind of test tell a PM, and what can't it?
Treat everything a simulated experiment returns as a planning input, not a substitute for real usage data. The workflow below is a hypothetical scenario, not a record of a real team. Its counts and durations are planning assumptions, not observed results or a guarantee.
| Day | Activity | What it produced |
|---|---|---|
| 1 | Run three pricing-structure alternatives past a defined panel of target buyers | Directional reaction to each option and the reasoning behind it |
| 2 | Synthesize the reasoning behind the split reactions | Two competing arguments to bring back to the team, not a single winner |
| 3–7 | Test page-level framing for the two remaining options | Which framing read as clearer, which line resonated |
| 8–10 | Present both options with panel evidence attached; flag remaining questions for real customers | A decision made with evidence instead of only opinion |
| 11–14 | Discuss edge cases (usage spikes, cap behavior) before engineering scoping | A list of technical assumptions for engineers to test |
In this hypothetical plan, a decision cycle of about six weeks is compressed to about fourteen days. That is an estimate for an invented scenario. No team has reported this saving, and it is not a promised timeline. A simulated discussion of edge cases can raise questions. It cannot show how the software behaves, so reserve claims that a defect was caught for reproducible software or prototype checks.
When does this replace a team vote, and when doesn't it?
A synthetic panel is a reasonable substitute for the low-stakes, high-frequency calls a PM currently makes by consensus: which of three feature names sets the right expectation, whether an empty state explains its value, whether admins will understand a settings trade-off. None of these individually justify a formal research project, but a wrong call on any of them still costs engineering time.
It is not a substitute for the things that establish whether a feature actually works: foundational customer interviews, a beta program, in-app analytics, or watching a real user click through a live prototype. For a major pricing model change or a category expansion, the sequence is to generate and narrow hypotheses with a fast test, then validate the leading hypothesis with real people. The same question can then be put to real participants in a matched human study, which is scoped per decision (see the research).
A practical decision process
- Pick one feature or spec decision that is currently being settled by opinion.
- Define the audience, the alternatives under consideration, and the outcome that matters (for example stated intent to adopt, stated comprehension or stated willingness to pay).
- Run the alternatives through a controlled comparison and read the reasoning behind the results, not just a preference count.
- Take the result into the PRD as documented evidence, alongside the open questions that still need real customer or usability confirmation.
- For decisions with real budget or roadmap risk, schedule the human-validation step before committing engineering capacity.
Where this fits and where it fails
This approach fits PM-owned decisions that are too frequent and too small for a formal research project but too consequential to settle by whoever argues loudest: naming, onboarding copy, settings framing, early pricing structure reactions. It fails as a substitute for discovering problems nobody has framed yet, for usability observation on a real prototype, or for any claim about actual production behavior.
Related reading
- AI research tools compared for product managers
- Book a decision review and bring the feature alternatives, the target customer and the PRD section the decision changes