Your Customer-Centricity is a Corporate Ritual
Why surveys only capture coping mechanisms instead of true opportunity
I’ve spent the past 20 years struggling to understand customer-centricity. I’ve been through all the theories and approaches. This is my stake-in-the-ground on the topic. You can disagree. Bring the receipts if you do. 🫡
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 do not capture opportunity; they capture the customer’s adaptation to existing inefficiencies. Quantitative surveys don’t really do any better.
True customer-centricity is not narrative; it’s 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.
If you don’t understand the current architecture, you’ll never be able to invert it, or substract what shouldn’t be there at all.
The Passenger Fallacy (Structural Blindness)
The core error of narrative-led innovation research is the belief that because someone uses a service, they understand how to improve it. This is 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 can’t, 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 (one of many journeys), 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’ll 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”). Even Jobs-to-be-Done research is caught in this trap.
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.
I challenge anyone to design a customer survey (even ODI) that can provide the necessary inputs to drive disruptive innovation:
How would it address CapEx, Labor, Demand, or Network inversions?
How would it address the hundreds of ways one of those inversions could be configured?
How would such a survey inform business model design?
How would such a survey inform the following moat-building innovation areas: profit model, network, structure, process, product performance, product system, service, channel, brand, and customer engagement?
How could you kill this initiative before even doing a 6-figure survey?
How does such a survey guaranty that a problem even exists, before or after you run it?
Innovation teams need to start out with an understanding of the current business model, and the current constraints.
The bottom line is this — you don’t need 150 high-density success metrics from a customer. In fact, you can’t possibly field enough surveys to capture what you’d need for disruptive innovation. Disruption comes from identifying the higher level of abstraction — and that cannot be a guess (yet it always is). How many jobs would you need to survey to nail this? Many. Or, you can trust the expert consultant — who reasons even more from analogy than you do. 😂 You’d need dozens of surveys at $250k a pop to figure this out. And there is no evidence that it can be done consistently (meaning: without leaning on luck).
Fortunately, it’s much easier than that. If you’re trainable.
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. This is why they fail 99% of the time. 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 side benefit is that you’ll never be a feature on someone else’s platform.
FACT: You can’t scale yourself out of the Jevons Paradox if you’re just implementing sustaining innovations. More on that inside my models.
The Anti-Bloat Principle: First Principles vs. JTBD
Traditional Jobs-to-be-Done (JTBD) 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:
1. First Principles is the Stake in the Ground
I start with the mathematical and physical floor of the domain. I don’t ask the customer where to start; I 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): The mathematical representation of the gap. If N/D is ~1.0, the market is already efficient and the opportunity is dead. If N/D is > 1.0, the gap is real and we drive our stake into the ground there.
I don’t ask clients to understand my methodology or become fluent in some uncomfortable language. I start with the challenge or idea that they are currently staring at. They tell me. I input it.
If you’re starting point is off in a big bang consulting exploration, the “off” amplifies at each step. The final product is 100% wrong. Do you make $500k bets like that a lot?
2. JTBD is the Compass
Once the stake is driven into the ground by the N/D calculation (the Inefficiency Index), JTBD is used strictly to orient the foundation. The foundation is a first principle derived from an agreed upon theorem. The first principle is used to define the core job executor and the required functional outcome, filtering out the noise of dozens of adjacent, non-core jobs. No consultant (or analysis paralysis) needed.
At the level of functional disruption, users don’t care about features, UI widgets, or custom configurations. The utility axiom is simple: People want services to be fast, cheap, and accurate.
Additional customer data capture, emotional maps, and journey flows are useful for minor optimizations of existing journeys—they are absolutely useless for functional disruption.
While there is always room for nibbling around the edges, the emergence of artificial intelligence and agentic solutions make business model inversion mandatory as change is accelarating, and old models just can’t keep up with it. From this point forward, disruptive models will be a constant, recurring requirement. No more 20 years to enjoy the ride.
The 3-Step Validation Pipeline
Because we hypothesize our complete strategy upfront based on First Principles, I don’t use surveys to search for problems. Instead, I use a lean, 3-step pipeline to validate the engineering math and my proposed solution mechanic directly with the defined job executor:
Step 1: Spread the Inefficiency (Map & Interview Guide)
First, I chronologically map the job executor’s process map using a solution-agnostic framework. I then take the calculated N/D inefficiency and spread it across the steps of this map, identifying where the time and cost concentrate.
Define → Locate → Prepare → Confirm → Execute → Monitor → Resolve → Modify → Conclude
I draft a lean interview guide and validation playbook early, focusing my qualitative conversations solely on verifying that the theoretical friction coordinates with the executor’s actual day-to-day reality.
The is the first validation gate. If the 8-10 interviews that are conducted do not validate these assumptions, the project is killed. No six-figure embarrassment. No propping up the lifestyle of some consulting partner.
Step 2: Develop & Rank the Innovation Levers
Once the friction coordinates are mapped and validated with the core job executor, it’s time to pull the levers. We aren’t brainstorming features here; we’re analyzing the architectural constraints—CapEx, Labor, Demand, and Network—and determining exactly how to break them.
Using the constrained AI pipeline, we run the validated inefficiencies through scores of structural inversion and subtractive models (most digital transformation is additive). We’re looking for specific mechanics: Can we completely decouple human labor from execution? Can we bypass the traditional middleman to collapse margin requirements? These levers are then ranked mathematically by their potential to drive the N/D ratio (the Inefficiency Index) closer to 1.0. It isn’t about what’s easiest to build or what the customer asked for; it’s about what destroys the incumbent’s cost curve the fastest and pushes the solution toward the physics floor.
Step 3: Score the Growth Paths & Competition
You don’t just attack a market blindly. You have to score the available growth paths against the competition’s inability to react. Incumbents are trapped inside their hardened architectures. They can’t simply adopt an inversion without cannibalizing their own legacy revenue or writing off massive, sunk CapEx.
We map the proposed functional disruption directly against their current operational setup. If a competitor can easily copy the mechanic using their existing infrastructure, it’s a bad bet. We’re looking for the growth paths where the mathematical gap is the widest and the competitor’s structural inertia is the heaviest. This ensures we’re targeting areas where the existing market is fundamentally incapable of matching a fast, cheap, and accurate alternative.
Step 4: Develop the Business Model & Moat Concept
A disrupted cost structure doesn’t mean much if you don’t wrap it in a defensible business model. We aren’t relying on UI/UX, feature bloat, or brand loyalty to protect the innovation. Instead, we architect structural moats that span the profit model, network effects, and core processes.
Because the JTBD compass has already locked in the functional outcome, we can configure a business model that strictly monetizes the newly created efficiency. We design a system where the unit economics are so fundamentally inverted that competitors simply can’t afford to compete on the same playing field. The moat isn’t built on a narrative; it’s built on math that the rest of the industry is structurally forbidden from replicating.
Theoretically, you could move to Step 6. However, many existing Enterprises will require a deeper understanding and validation of Willingness to Pay and Demand Density. In those cases, we can run a JTBD survey. But not for exploration—for confirmation. Therefore we can limit it to only steps that validate earlier with interviews. Shorter. Less expensive. Faster.
Step 5: Quantify Demand Density & Willingness to Pay (WTP)
If qualitative interviews confirm the friction, we optionally run a highly structured, quantitative survey (startups need not apply 😉).
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, Van Westendorp, or some other pricing bounds to ensure our mathematical model maps to commercial reality.
This is a fundamentally different (and less costly) approach than you’ll find elsewhere in the Jobs-to-be-Done world. In fact, you might even kill the the project after this stage.
Step 6: Prove the Solution Mechanic (MVPr)
Finally, we build a Minimum Viable Prototype (MVPr). This is not an MVP in the traditional sense; it is a manual concierge 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. We run this manual concierge to prove that the mechanic achieves the fast, cheap, and accurate outcome before writing a single line of production software, or building a factory.
We are still learning while others will rush into earning (MVP). If you learn that the improvement can be implemented, you kill it here as well.
V. Tying it Back: The Venture Proof Platform Architecture
The architecture of the Venture Proof platform is the physical manifestation of this Point of View. It’s built to enforce this rigorous, mathematical methodology and shield the strategist from narrative bias:
The Venture Proof Math Engine: A deterministic, zero-AI arithmetic engine that calculates the N/D ratio 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.
The Constrained AI Pipeline: Employs LLMs locked to temperature 0.0, utilizing a multi-layer agentic challenge system, and forced through strict JSON schemas. 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.
Several of my blog posts have links to the results, and the platform itself. Check it out.
True Customer-Centricity is Architectural
I’ve spent a lot of time tearing down traditional qualitative surveys and feature-bloated roadmaps, but don’t mistake that for abandoning the customer. True customer-centricity isn’t about making the user the architect of your product; it’s about respecting them enough to fix the fundamental math they’re trapped inside.
When you rely on focus groups or endless feature requests to dictate your next move, you aren’t actually listening to the market. You’re just outsourcing the hardest part of innovation to people who are structurally blind to the solution. That isn’t customer-centricity—that’s an abdication of responsibility.
By anchoring our strategy to the physical floor and calculating the exact friction they experience on a day-to-day basis, we aren’t ignoring their voice. We’re targeting their ultimate, undeniable demand: getting the core job done fast, cheap, and accurately.
The most profound way to serve a customer isn’t to ask them how to build the airplane. It’s to engineer an underlying architecture that gets them to their destination with zero friction, completely shielding them from the complexity of the engine. That’s the only way to deliver disruptive value they couldn’t even imagine asking for.
Is your organization interested in true innovation? Or does it prefer to just look busy and hire consultants? The world is changing quickly. If you’re not adapting to it, you’re not innovating. I work with organizations who are serious about attacking problems and who are tired of defending the current paradigm. Is that you? (my availability is limited).
Submit a problem or challenge: Click here
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
Always attack…Never defend