A product manager on Reddit described failing an interview with this feedback: “I did not apply first principles thinking to my case study solution.” The frustrating part wasn’t the verdict — it was that the feedback gave no observable behavior to fix. What does “applying first principles” actually look like to someone watching a PM work?
This article answers that with a worked case study: a feature request from a top customer, taken apart step by step, with the reasoning visible at every stage. That last part matters — the same process that improves the decision is also what interviewers and product reviewers are looking for when they say “first-principles thinking.”
The setup: three customers, one request
A B2B collaboration tool has healthy usage numbers. Then, within two months, the three largest accounts all submit the same request through their account managers: “We need single sign-on.”
The conventional response writes itself. SSO is a standard enterprise feature, the requests come from the highest-value customers, and competitors already offer it. The roadmap item gets drafted: SAML/SSO integration, est. 4 months of platform engineering.
Everything about that reaction is reasonable. That’s exactly why nobody on the team notices what’s hiding inside it.
Step 1: Separate the request from the request’s content
A feature request is not a requirement. It’s a customer’s proposed solution, delivered as if it were the problem. The first-principles move is to stop treating “we need SSO” as the problem statement and treat it as evidence.
Restated as evidence: Three large accounts, in the same quarter, independently concluded that our product cannot be purchased (or renewed) as-is unless something changes about authentication.
That version sounds different — and it raises a question the original request doesn’t: why now?
Step 2: Ask the customer’s “why,” not just the internal one
The Five Whys technique is usually an internal tool — why is the project late, why is churn up. Here it gets applied outward, to the request itself. The account managers go back and ask each contact what triggered the request.
- Why do you need SSO? “Our new head of IT is standardizing all tools on one login.”
- Why is that a priority? “The security team is auditing every vendor after an incident at a sister company.”
- Why does our product matter to the audit? “The auditor flagged that our data is accessed with a standalone password.”
- Why is that a problem? “Stand-alone credentials can’t be centrally revoked when someone leaves.”
- Why does that fall on you? “Renewal can’t go through procurement until the security review passes.”
Four whys in, the picture changes completely. The request is real — but the root need is not SSO. The root need is passing a security review so the renewal isn’t blocked. SSO is one way to satisfy that need, and possibly the most expensive one.
Step 3: List the assumptions inside the conventional response
The original roadmap item rests on beliefs nobody wrote down:
| # | Assumption | Label | Evidence |
|---|---|---|---|
| 1 | These customers need SSO specifically | Inference | None of them said why yet — nobody asked |
| 2 | Without SSO, the renewals are at risk | Inference | No cancellation threats on record |
| 3 | All three requests have the same driver | Inference | Requests arrived separately; treated as one signal |
| 4 | Enterprise buyers expect SSO in a tool at this price | Convention | Industry standard, never tested against these accounts |
| 5 | SSO would satisfy the security reviews | Unknown | Depends on what each auditor actually requires |
| 6 | The team can deliver SSO in one quarter | Unknown | Platform engineering hasn’t scoped it |
As with most feature-driven decisions, almost nothing here is a known fact. (The labeling method comes from the assumption audit — the same five minutes of work applies to inherited requests, not just internal plans.)
Step 4: Rebuild from the actual need
With the root need identified — pass the security review, keep the renewal — the options multiply:
Option A: Build SSO. Four months of platform engineering. Solves credential revocation and looks good on a security questionnaire. Risk: it might not be the only gap the auditor finds, in which case the renewal is still blocked — just four months later.
Option B: Answer the actual audit criteria. Ask each customer for the security review checklist. Map which items the product already satisfies and document them. Many mid-market audits pass on evidence and policy — access logs, password policy, data handling — not on SSO specifically.
Option C: Both, sequenced. Ship the documentation and the smaller items now, scope SSO as a paid enterprise-tier add-on for the accounts that genuinely need it, and let the audit results — not the roadmap draft — decide the priority.
Notice what happened: decomposing the request didn’t kill the feature. It changed the question from “do we build SSO?” to “what unblocks these renewals, fastest?” — which is the question the business actually needs answered.
Step 5: Run the cheapest informative test
Before any engineering commitment, two weeks of work answer the highest-uncertainty assumptions:
- Get the checklists. All three security reviews, in writing. This tests assumptions #1, #2, and #5 directly.
- Check the renewal timelines. How many weeks until each review? This tests how urgent — and how hard — the deadline actually is.
- Talk to the auditors’ criteria, not just the buyers. Where a checklist item is ambiguous, ask what evidence satisfied it at other vendors.
What the test found
The security reviews at two of the three accounts required centralized access control or documented credential policy with access logs — either satisfied them. The third had a hard SSO requirement, but was also the account most willing to pay for an enterprise tier.
The team’s response: a security documentation page and access-log export shipped in three weeks (a fraction of the SSO effort), which cleared two of the three reviews. SSO was scoped for the enterprise tier, priced accordingly, and justified by a signed contract rather than a guess. Both unblocked renewals closed. The SSO build then started with a real customer attached to it.
None of this required a brilliant insight. It required refusing to inherit the customer’s framing — the same discipline The First Principles Playbook builds through its worked examples and exercises, including several product-development cases where questioning the problem statement changed what got built.
How to show this reasoning (interviews and product reviews)
The Reddit poster’s real problem was that “first-principles thinking” is invisible when it happens inside someone’s head. Here is what it looks like from the outside — the observable behaviors an interviewer or reviewer can actually evaluate:
- Restate the problem in their own words, minus the solution. “The request says SSO. The problem is an unpassed security review.” If a candidate never separates those, an interviewer has nothing to evaluate.
- Name the assumptions out loud. Not all of them — the two or three that would change the decision most. “I’m assuming the renewal is actually blocked; here’s how I’d check.”
- Show the why-chain. Five Whys on the request itself, summarizing what the customer said at each level. This is the step that looks most like “real” first-principles work to an observer, because it exposes the reasoning instead of asserting a conclusion.
- Generate more than one option, then pick the cheapest informative test. A single-solution answer with a rationale is still reasoning by analogy — just a confident one.
- State what would change the decision. “If the checklists reveal a hard SSO requirement at all three accounts, this becomes a build conversation, not a documentation one.”
A product review structured this way takes ten minutes longer than a roadmap readout. It converts “I think we should build X” into an argument other people can inspect, challenge, and improve — which is the entire point.
When to run this teardown
- The request comes from someone who can’t see the whole system — customers describe solutions, not jobs.
- Multiple requests converge suspiciously — identical asks usually share a hidden driver worth finding.
- The feature is expensive relative to the evidence — four months of platform engineering is a lot to spend on an inference.
- The deadline is fuzzy — “we need it soon” from a buyer is often a proxy for someone else’s process, not real urgency.
For routine, reversible requests — a small feature, one account, low cost — a teardown isn’t worth the time. The 60-second decision test covers which problems deserve this treatment. And for the full eight-step version of this process, the step-by-step walkthrough shows the method applied to a churn problem.
Want to run this on your own backlog? The Problem Deconstruction Worksheet walks through all 8 steps — free, printable, no signup required.