Traditional customer-centricity has deteriorated into a corporate ritual of focus groups, user surveys, and net promoter scores. This narrative-based approach operates on a flawed assumption: that the customer understands their own problems well enough to dictate the solution. In reality, qualitative surveys (even with ‘scores’) do not capture opportunity; they capture the customer’s adaptation to existing inefficiencies.
True customer-centricity is not narrative; it is architectural, mathematical, and deterministic. It bypasses the user’s vocalized preferences to analyze the physical and economic constraints of the industry architecture they are trapped inside.
A lof ot JTBD practitioners will tell you that their approach is based on First Principles. I think I’ve been demonstrating over the past year that it’s not. Your cognitive bias mileage may vary. 😉
A Note to Legacy Researchers: If the following perspective feels uncomfortable, it’s because it challenges the Passenger Fallacy: the belief that users understand the systems they occupy well enough to improve them. Traditional research often mistakes coping mechanisms for “user needs.” When you ask a customer what they want, they will describe a better way to navigate a broken architecture—like asking for a faster way to export a spreadsheet rather than questioning why the spreadsheet exists at all. To move from optimization to functional disruption, we must stop treating narrative as truth and start treating physics as the floor. Our job isn’t to listen to the passenger’s complaints about the cabin temperature; it’s to engineer the engine that makes flight possible in the first place.
The Passenger Fallacy (Structural Blindness)
The core error of modern user research is the belief that because someone uses a service, they understand how to improve it. This is what I call the Passenger Fallacy.
An airline passenger can tell you that the cabin is too cold, the seat is too cramped, or the chicken is dry. They cannot, however, design a bypass turbofan engine, calculate lift-to-drag ratios, or optimize the fuel burn rate of a Boeing 787. They experience the symptoms of flight, but they are entirely blind to the physics and engineering of aviation.
In the same way, end-users of business software or industrial services operate inside the system. They have no visibility into:
The legacy database schemas causing synchronization lag.
The manual batch-processing scripts running behind the scenes.
The commercial margins, regulatory overhead, or operational compromises that dictate their workflows.
When you ask a user what they want, they will describe their coping mechanisms—how they copy-paste data between three different screens, how they manually format a spreadsheet, or how they wait for a weekly report. They ask for features that make these workarounds slightly less painful (e.g., “Give me a button to export this to Excel”).
If you build what they ask for, you are not innovating; you are codifying the competitor’s broken architecture. You are building a prettier dashboard for a manual process.
Established Industries are Hardened Architectures
Established industries are not merely collections of brands and products; they are hardened architectures. An industry architecture is a structured arrangement of:
Labor: How many human hours are required to deliver a unit of value?
Capital Expenditure (CapEx): What infrastructure must be owned, leased, or maintained?
Latency: How much time passes between the request for service and its delivery?
Margin: What toll must be paid to middlemen to maintain trust and coordinate transactions?
For example, the traditional management consulting industry is architected around billable hours, human synthesis, and PDF deliverables. The retail banking industry is architected around centralized databases, high-overhead compliance teams, and multi-day settlement clearinghouses.
When a startup attempts to compete by sending out surveys and building a new mobile app, it almost always adopts the incumbent’s underlying architecture. They hire the same types of operational staff, buy the same third-party enterprise tools, and price their services the same way.
This is the startup trap. If you compete on the same architecture, you are bound to the same cost curve. Your unit economics are mathematically constrained by the same physical limit. To win, you must address the architectural problem itself to invert the cost and time dimensions of service delivery.
The Anti-Bloat Principle: First Principles vs. JTBD
Traditional Jobs-to-be-Done (JTBD) and Outcome-Driven Innovation (ODI) practitioners often spend months mapping dozens of adjacent jobs and compiling surveys with 120+ metrics. This approach is slow, expensive, and encourages feature creep. It treats every user statement with equal weight, resulting in bloated product roadmaps that attempt to do everything and solve nothing.
I reject this complexity through two foundational rules:
First Principles is the Stake in the Ground
We start with the mathematical and physical floor of the domain. We don’t ask the customer where to start; we calculate it.
The Numerator (N): The current commercial cost to deliver the outcome (human labor, software overhead, operational waste).
The Denominator (D): The “Physics Floor”—the absolute minimum cost to deliver the outcome using raw compute, energy, and materials.
The Ratio (N/D) - aka The Physics Gap: The mathematical representation of the gap. If N/D ≈1.0, the market is already efficient and the opportunity is dead. If N/D » 1.0, the gap is real and we drive our stake into the ground there.
JTBD is the Compass
Once the stake is driven into the ground by the N/D calculation, JTBD is used strictly to orient the foundation. It defines the core job executor and the required functional outcome, filtering out the noise of dozens of adjacent, non-core jobs.
At the level of functional disruption, users do not care about features, UI widgets, or custom configurations. The utility axiom is simple: People want services to be fast, cheap, and reliable.
Additional customer data capture, emotional maps, and journey flows are useful for minor optimizations of existing (or new) journeys—they are useless for functional disruption. And that’s a fact.
The 3-Step Validation Pipeline
Because we hypothesize our complete strategy upfront based on First Principles, we do not use surveys to search for problems. Instead, we use a lean, 3-step pipeline to validate our engineering math and our proposed solution mechanic directly with the defined job executor:
Step 1: Spread the Inefficiency (Map & Interview Guide)
First, we chronologically map the job executor’s process map using a solution-agnostic framework (Define → Locate → Prepare → Confirm → Execute → Monitor →Resolve → Modify → Conclude).
Note: The Job is not ‘made up’ by a consultant or passengers. It’s derived solely from First Principles — something you can point at.
We then take our calculated Physics Gap and spread its components across the steps of this map, identifying where the time and cost concentrate. We draft a lean interview guide and validation playbook early, focusing our qualitative conversations solely on verifying that the theoretical friction coordinates with the executor’s actual day-to-day reality.
Step 2: Quantify Demand Density & Willingness to Pay (WTP)
If qualitative interviews confirm the friction, we optionally run a highly structured, quantitative survey.
What we do NOT ask: We do not ask them what features they want or what their general problems are.
What we DO ask: We present the value model of our proposed inversion. We measure demand density (how many executors face this exact friction node) and willingness to pay (WTP) using Gabor-Granger or Van Westendorp pricing bounds to ensure our mathematical model maps to commercial reality.
Step 3: Prove the Solution Mechanic (MVPr)
Finally, we build a Minimum Viable Proof (MVPr). This is not an MVP in the traditional sense; it is a manual concierge pilot service or a raw command-line script that tests only the structural inversion mechanic (e.g., decoupling labor from execution) at the highest-friction step(s). We run this manual concierge to prove that the mechanic achieves the fast, cheap, and reliable outcome before writing a single line of production software.
Tying it Back: The Lattice OS Application Architecture
The architecture of the platform I developed (Venture Proof) is the physical manifestation of this Point of View. It is built to enforce this rigorous, mathematical methodology and shield the strategist from narrative bias:
The Lattice OS Math Engine: A deterministic, zero-AI arithmetic engine that calculates the Physics Gap and models Jevons rebounds. It ensures that the “stake in the ground” is based on exact decimal math, not LLM hallucinations or human wishful thinking (or consulting bias).
The Constrained AI Pipeline: Employs LLMs locked to temperature 0.0 and forced through strict JSON schemas and structured rubrics. The AI decomposes strategic problems, maps processes, and flags structural inversions, preventing corporate jargon or marketing fluff from polluting the strategic architecture.
The Automated Validation Playbook Generator: Generates the lean interview guides, targeted WTP surveys, and MVPr test protocols automatically based on the friction scoring, bypassing expensive and slow consulting cycles.
I’ll get into this in another post, but don’t believe that this is 100% automated. There is still human insight and governance involved for now. Humans can override hundreds of levers in this process in order to shape outcomes closer to enterprise capabilities or desires. But this system learns what works, and what doesn’t and gets smarter over time. Focusing on a shrinking number of edge cases will mean that strategy formulation will become faster, cheaper, and so reliable that humans will default to higher level roles that no longer require the do-work. That’s the goal. That’s the desired outcome.
Is your organization interested in differentiated innovation? The world is changing quickly. If you’re not adapting to those changes, you’re not innovating. Seeking reassurance from consultants fails, nearly always (sometimes they get lucky). I work with organizations who are serious about attacking problems using first principles. Many have been burned once, and they don’t want it to happen again. Is that you? (my availability is limited).
Book an appointment: Click here
Email me: mike@pjtbd.com
Call me: +1 678-824-2789
Join the community: Click here
Follow me on 𝕏: https://x.com/mikeboysen
Articles - jtbd.one - De-Risk Your Next Big Idea
Research - studio.jtbd.one/research
Slaying the Sacred Cows of Innovation