Validate Feature Decisions Before the Spec Locks
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 behavioral experiment against a defined 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").
Evidence: what this kind of test can and cannot tell a PM
Treat everything a simulated experiment returns as a planning input, not a substitute for real usage data. The workflow below shows how one team sequenced this test; the counts and durations are that team's planning assumptions, not 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 | Test edge cases (usage spikes, cap behavior) before engineering scoping | Product issues caught before they became post-launch bugs |
The team's plan compressed a roughly six-week decision cycle to about fourteen days. Read that as one workflow's plan, not a promised timeline for every team.
Where this replaces a team vote and where it does not
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. Subconscious can test or validate studies with real human participants without changing the underlying causal question.
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 (adoption, comprehension, 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.