Abhilash John The Three Mirrors of a Product
Your UI, API, and data model each reveal different truths about your product. Learn how to read all three mirrors and align them before misalignment compounds.
AI Summary
What your product actually reveals about itself and to whom
There’s a well-worn saying in product circles: show me your roadmap and I’ll tell you your strategy. But roadmaps are aspirational. They’re manicured. They’re PowerPoint slides.
To understand what a product truly is, what it believes, what it commits to, and where it’s going, you need to read three different artifacts: the UI, the API contract, and the data model. Each holds a different truth. Each speaks to a different audience. The gap between them is usually where technical debt, strategic confusion, and unmet customer expectations quietly accumulate.
The UI: What You Offer to the Customer
The user interface is the most public face of your product. Prospects see it in demos, customers navigate it every morning, and your marketing team screenshots it for landing pages.
The UI doesn’t just show what your product does. It shows what you’ve decided is worth surfacing. Every button represents a choice. Every menu item was included by someone. Every modal that says “coming soon” is a promise you’ve made without yet delivering.
This makes the UI a curatorial artifact. It reflects taste, prioritization, and audience understanding. A great UI says: we know which 20% of capabilities matter to you 80% of the time, and we’ve made those effortless. A poor UI says: we built everything and couldn’t decide what was important, so here’s a settings panel with 47 options.
The UI can also lie. It can show aspirational features still under construction, hide real power behind confusing navigation, make a narrow product feel comprehensive, or make a comprehensive product feel shallow. Product demos can be misleading: what you see in a walkthrough is the best-case interpretation of a codebase, choreographed by someone who knows where the landmines are.
In practice: When evaluating a competitor’s product, look past the UI polish. It’s the easiest layer to fake. When evaluating your own product, ask harder questions: Does our UI reflect our priorities, or our history? Are we surfacing features because customers need them, or because we built them?
The UI is a promise. Make sure you can keep it.
The API Contract: What You Actually Support
The API is where things get honest.
An API contract is a formal commitment. When you expose an endpoint, give it a name, version it, document it, and let someone else’s system depend on it, you’ve done something much more serious than shipping a UI. You’ve said: this capability is real, stable, and load-bearing. Breaking it has consequences. Changing it requires communication. It has a lifecycle that extends far beyond any product sprint.
Reading a company’s API documentation tells you more about their product than their website does. The website is marketing. The API is engineering. The website shows what they want you to believe they do. The API shows what they’ve built and stood behind.
Enterprise buyers, technical evaluators, and developers go straight to the API docs for a reason. They’ve learned that the API is the most reliable signal of what a product can do. Features that exist in the UI but lack corresponding API surface are often fragile, incomplete, or not ready for production workloads.
The API contract also reveals architectural maturity. Do the endpoints compose logically? Are there obvious gaps where the UI papers over missing functionality? Are the objects in the API first-class and well-named, or are you passing blobs of metadata around because the model hasn’t been formalized?
In practice: If you’re building a product and haven’t yet asked “what would we expose in a public API?”, ask it now. API design forces clarity that no amount of UI iteration produces. If a feature can’t be described as a clear API endpoint, it probably isn’t clearly understood internally.
The API is a commitment. Be deliberate about what you commit to.
The Data Model: Your Vision Made Structural
The data model is the most revealing artifact of all.
The data model isn’t customer-facing. It isn’t publicly documented. It doesn’t appear in demos or sales calls. Yet it is, in many ways, the truest expression of what a product believes about the world it’s trying to serve.
A data model answers the question: what do we believe are the fundamental objects in this domain, and how do they relate to each other?
This sounds technical. The strategic consequences are significant.
Consider a B2B SaaS company that treats customer and account as the same object. That’s a statement of belief: we think the buyer and the user are always the same. The moment you need to support enterprise procurement, resellers, or multi-stakeholder deals, the data model becomes a constraint, and refactoring it is expensive, slow, and risky.
Or consider a revenue recognition platform. If contract is a first-class entity with structured fields for start date, end date, renewal terms, pricing schedule, and amendment history, then the platform can reason about revenue over time. If contracts are stored as uploaded PDFs in a documents table with a type = "contract" flag, the system can store contracts but cannot understand them. The UI might look the same. The API might expose the same endpoints. But the data model reveals that one of these systems has internalized the domain, and the other is still pretending.
The data model is the most honest signal of a product’s vision. You can fake a UI. You can version-lock an API. The data model reflects the deepest choices your team has made about what the problem is. It encodes your assumptions about reality.
The most revealing thing to look for: which entities are first-class, and what’s buried in a metadata blob?
A metadata JSON column is almost always a hedge, a way of saying we aren’t sure what this is yet, so we’ll figure it out later. Sometimes that’s fine early on. In mature products, an overloaded metadata column signals that the domain model never caught up to the product’s ambitions. The features got built; the understanding never crystallized.
Conversely, when a product has clean, expressive, well-named entities, subscription, entitlement, invoice_line_item, usage_event, you’re looking at a team that has genuinely internalized their domain. That kind of model is hard to copy quickly. It’s accumulated wisdom about what the problem is.
In practice: Periodically ask yourself: If someone read only our schema, no code, no docs, no demos, what would they conclude we were building? Does that match our ambitions? If the answer is no, you have a gap between your vision and your foundation. That gap will widen over time unless you address it deliberately.
The data model is a worldview. Make sure it’s the right one.
The Gap Between the Three
Each layer has its audience: the UI speaks to customers, the API speaks to builders, and the data model speaks, often only, to your own engineering team. The most strategically important thing to understand is what happens when these three layers are out of sync.
UI ahead of API: You’re showing customers capabilities that aren’t properly supported at the integration layer. This creates support debt, manual workarounds, and customers who are eventually surprised when they try to automate something that looked simple in the dashboard.
API ahead of data model: You’ve exposed endpoints that the underlying data can’t fully sustain. This often manifests as inconsistent responses, performance issues at scale, or subtle bugs that only appear when customers push the system in ways you didn’t anticipate.
Data model ahead of everything else: This is a good problem to have, it means you’ve thought carefully about the domain, but it can mean the product’s ambition isn’t yet legible to customers or builders. Vision without visible expression is invisible.
The goal isn’t perfect alignment at all times, since products are constantly in motion, but conscious misalignment: knowing which layer is leading and which is lagging, and having a plan to close the gap.
A Practical Lens for Founders and Product Leaders
Write one sentence describing what each of your three layers currently says about your product:
- _Our UI says we are ____
- _Our API says we are ____
- _Our data model says we are ____
If those three sentences describe the same company with the same mission, you’re in good shape. If they describe different companies, or you struggle to complete one of them, you’ve found your highest-leverage area of product work.
The most durable software products are the ones where all three layers tell the same story. The UI makes a promise. The API keeps it. The data model was built for a world where that promise is kept at scale.
That coherence doesn’t happen by accident. It happens when product, engineering, and design share a common understanding of what the product is, and build accordingly.
The UI is what you offer. The API is what you support. The data model is what you believe. Build all three with intention.
A Special Case: Why Pricing and Quote-to-Cash Systems Almost Always Fail This Test
Nowhere is the gap between these three layers more consequential, or more commonly ignored, than in pricing, quoting, and billing infrastructure.
Pricing is a capability, not a feature. The ability to experiment with new models, respond to competitive pressure, support usage-based components alongside seats, and evolve your monetization strategy without an engineering sprint is one of the most durable competitive advantages a company can build. Most billing and quote-to-cash systems make this capability nearly impossible.
Most of these systems were built with a fixed mental model of what a “deal” looks like: a customer, a product, a quantity, a price, a term. That model, encoded in the data layer, expressed through the API, and surfaced in the UI, was reasonable in 2010. It is increasingly untenable today.
The pricing reality for a modern SaaS company looks like this: A company that started with per-seat pricing wants to layer in usage-based components for API calls. Its enterprise segment needs custom committed minimums with overage. Its PLG motion needs a free tier with self-serve upgrade triggers. Its AI product needs to price by tokens, see the AI token pricing tracker for current per-token rates across providers, by workflow, or by outcome, and that unit might change every six months as the market figures out what value looks like. None of these is an edge case. Each is a growth motion.
A system built around a rigid product catalog and a quote-to-invoice pipeline will struggle with all of them. Most modern billing platforms have added fields, toggles, and templates to accommodate surface-level variety, but the data model underneath was never built to represent pricing as a dynamic, composable, intelligence-bearing construct. The metadata columns pile up. Workarounds accumulate. The pricing system becomes the bottleneck for every new commercial idea.
The most common failure is treating pricing as configuration rather than domain. In a well-designed system, price isn’t just a number attached to a product. It’s an entity with its own lifecycle, logic, and relationships: effective dates, conditions (customer segment, geography, volume tier, contract term), and a relationship to usage events, entitlements, and revenue schedules. A system that doesn’t model pricing this way will always require human intervention: a RevOps person manually adjusting an invoice, a finance team reconciling recognized revenue against what was billed, a sales engineer building CPQ workarounds to cover the gap between what the data model understands and what the business does.
The second failure is the disconnect between the quoting layer and the billing layer. In most legacy Q2C stacks, a quote is a document, a PDF or a structured form, that gets converted into an order. The commercial terms live in that document, but they don’t fully propagate into the systems that execute on them. Contract terms that sales sold aren’t perfectly reflected in what billing enforces. Renewal logic is handled by a reminder email rather than a system. Pricing intelligence, understanding which configurations sell, which structures churn, which tiers convert, is trapped in a spreadsheet rather than emerging from a well-structured data layer.
The third failure, increasingly critical, is the absence of pricing intelligence as a first-class output. Pricing isn’t just about collecting revenue correctly; it’s about learning. Which price points are closing deals? Which usage patterns predict expansion? Which configurations are associated with fast time-to-value versus high churn? A system that processes transactions but doesn’t generate pricing intelligence leaves one of the most valuable feedback loops in your business entirely dark.
Evaluating a pricing and Q2C system:
The right evaluation maps directly to the three layers discussed throughout this piece.
At the data model layer, ask: is pricing a first-class entity? Can the system natively represent a price as a function of usage, time, segment, and commitment, or does modeling your pricing require bolting together workarounds? Can it represent the full commercial terms of a contract, not just the headline number but the structure, in a way that downstream systems can execute against? How does it handle amendments, mid-cycle changes, and retroactive adjustments? If the answers require extensive custom configuration or professional services, the data model is telling you something.
Use the OpenAI pricing calculator as a reference for what an API-first, programmatically configurable pricing tool looks like. At the API layer, ask: can every pricing construct the system supports be created, modified, and queried programmatically? Can your engineering team build pricing experiments without touching the billing system’s UI? Can usage events be ingested in real time, and can entitlement checks happen at the speed of your product? A billing system whose API is a thin wrapper around its admin console isn’t designed for a world where pricing is a dynamic, product-integrated capability.
At the UI layer, ask: who is the UI built for? A system designed for finance teams optimizes for invoice management and revenue reporting. A system designed for RevOps prioritizes CPQ workflows and approval chains. A system designed for growth surfaces pricing analytics and experimentation primitives. None of these is wrong, but if the UI doesn’t reflect your actual operational model, you’ll be fighting the system rather than using it. More importantly, ask whether the UI is downstream of the data model or upstream of it: does the system let you express any pricing logic its data model supports, or is the UI the ceiling?
The guide to implementation best practices for usage-based pricing covers the full billing-stack requirements. And the most important question: how long does it take to go from a new pricing idea to a live, correctly-billed commercial motion? If the answer is measured in weeks or requires a vendor implementation engagement, the system isn’t built for the pace at which modern pricing models evolve. The best systems make pricing a product capability, something your team can iterate on as fluidly as you iterate on the product itself.
The companies that will win the next decade of B2B software aren’t just the ones with the best product. They’re the ones that can monetize intelligently, adapt pricing to the value they deliver, and build commercial infrastructure that compounds rather than constrains. That starts with choosing systems whose UI, API, and data model were all built with that future in mind.
The UI is what you promise. The API is what you commit to. The data model is your worldview. In pricing, getting all three right matters more than anywhere else.