Context
a16z's Alex Rampell and Joe Schmidt talk with Keith Peiris, cofounder and CEO of Lightfield, about walking away from Tome (an AI presentation tool he'd grown to 25 million users) to build an AI-native CRM around what he calls a "business world model." The conversation matters to PMs because it covers two concrete, decision-relevant problems: how to recognize a product is fundamentally capped by its technology (not just under-executed) and worth abandoning, and how to design a system of record when AI can infer structure instead of requiring a rigid schema up front.
The Big Idea
Peiris killed a fast-growing, 25-million-user product because the underlying technology had a ceiling no amount of iteration could fix, then built his next company around the opposite bet: that AI-inferred structure ("intelligence") can replace the rigid schema that has always been the most consequential and hardest-to-fix decision in any CRM implementation.
His evidence for the first half: Tome's core limitation was that the model couldn't capture enough context about a presenter, their audience, and the relationship between them, a ceiling general reasoning improvements wouldn't fix. His evidence for the second half: Lightfield's schema-less design, connect email, calls, and data sources and let the system infer structure and fill in fields later, let customers get from signup to a working, populated CRM in about five minutes, compared to CRM consultants telling him the data-model decision is the single most consequential (and hardest to reverse) choice in a traditional CRM rollout.
Key Insights
A capped ceiling, not slow progress, is the real signal to pivot
Peiris describes the moment his team considered simply shrinking the team and waiting for the underlying models to improve (he calls this temptation "hopium"), but concluded the specific gap, no amount of general reasoning capability would give the model enough context about a specific presenter, their specific audience, and the relationship between them, meaning better models wouldn't close it. The distinguishing test he applied: could he picture a discerning, expert user (an investment banker, a consultant) finding the product genuinely indispensable at any foreseeable capability level? When the honest answer was no, that was the signal to stop iterating and pivot rather than wait.
Following customer requests past the product's original scope revealed the real problem
When Tome's team found sales and marketing teams among their B2B users, they ran free pilots making presentations for those teams, and the teams kept asking for adjacent help ("can you do research," "can you help us qualify leads") that had nothing to do with presentations. Rather than redirecting customers back to the original use case, Peiris's team explicitly "followed the heat," and asking for access to customers' CRM, call recordings, and data warehouse to do that adjacent work is what exposed the real, much bigger problem: making sense of fragmented, often-conflicting data spread across a company's systems was harder and more valuable than anything about presentations.
Negative pricing (paying customers to use an unfinished product) can surface real signal fast
After building a go-to-market assistant that users liked but wouldn't pay for (because it worked on data Lightfield didn't own, competing directly with ten similar tools), Peiris's team rebuilt a CRM from scratch, then couldn't get anyone to try a four-month-old, unproven product. Their fix: offering free desk space in their own office to any startup willing to use the unfinished CRM. Ten startups took the offer, and despite constant complaints about missing features and slow performance, they used the product daily and gave feedback every couple of hours, a much stronger engagement signal than Tome had ever produced even at 25 million users, which told Peiris this problem was worth building around.
The activity log, not the schema, became the core primitive
Three of Lightfield's five founders came from Facebook, and they modeled the CRM's foundation on a chronological activity log (a "timeline") of every interaction between a business and its customer, rather than starting from predefined fields and stages. Fully unstructured storage made queries too slow (Peiris calls it "the needle in the haystack problem"), so they landed on a semi-structured approach: unstructured data (emails, calls, product usage) gets stored in the activity log, and the system infers causality and fills in traditional CRM fields (stages, statuses) from that log after the fact, rather than requiring the fields to be filled in manually first.
Schema decisions are the single most consequential, hardest-to-reverse choice in traditional CRM setup
Peiris says his team interviewed CRM implementation consultants specifically to learn what actually mattered in their work, and the consistent answer was the data model: get the stages, fields, and structure wrong at setup, and the damage is largely permanent, because reps won't go back and retroactively fill in historical data correctly. Lightfield's response was to make the product effectively schema-less at onboarding, connect data sources and let the system assemble relationships automatically, with structured fields available to edit or fill in later, summarized in Peiris's phrase "intelligence is greater than schema."
Pricing had to split into four separate buckets by expected willingness to pay
Lightfield tested pure per-seat pricing first (well received, but usage was wildly uneven, a small number of power users drove far more consumption than the pricing captured) and pure consumption-based pricing second (customers stopped touching the product entirely rather than accumulate charges). The eventual model splits work into four categories with different pricing logic: routine CRM upkeep (capturing meetings, updating records) bundled into a platform or seat fee customers expect to be fixed and budgetable; pipeline generation and workflow automation priced on consumption, since customers can see a direct ROI link (more qualified meetings, correctly routed leads); and forecasting/scenario-planning intelligence treated as a premium, willingness-to-pay-justified capability. Peiris's broader point: in a services-adjacent business like sales tooling, outcome-based pricing doesn't work cleanly because a vendor's actual outcomes depend heavily on the strength of a customer's own product-market fit, something the vendor can't control.
Mental Models & Frameworks
Greenfield versus brownfield, and the "logo as marketing, not revenue" strategy
Rampell's framing: brownfield markets are "trampled by an incumbent" whose customers are effectively hostages (his phrase: "the best companies have hostages, not customers"), and displacing them takes either redefining the problem (cloud versus on-premise) or picking off greenfield customers who have no incumbent tool yet. Peiris's twist on this: Lightfield deliberately serves early-stage, low-revenue startups not primarily for the revenue itself, but because winning them produces reference customers ("we've got healthcare," "we've got fintech") that make later brownfield sales into established markets easier, since buyers in Peiris's experience trust a vendor mainly once they see a peer in their own vertical already relying on it.
The four-bucket pricing split by ROI legibility
A generalizable pricing framework Lightfield arrived at through trial and error: separate a product's functions by how legible their return is to the customer. Routine upkeep work (low visible ROI per action, expected as baseline) gets a fixed platform or seat fee; work with a clear, attributable ROI (pipeline generation, automated routing) gets consumption pricing; work that's genuinely premium and hard to substitute (deep intelligence, forecasting) can command outcome-adjacent premium pricing. Use it when a product's usage pattern is highly uneven across a user base (a small number of power users driving disproportionate consumption): match the pricing structure to which specific function is being used, not a single blanket model.
Trade-offs & Nuance
Being maximally accommodating versus building for the frontier user
Peiris describes deliberately not being "religious" about how users interact with Lightfield: the company still ships full dashboards and table views for users who want a familiar, traditional CRM experience, while also supporting a fully conversational, agent-driven workflow (writing a "recipe" instead of manually configuring a sales sequence with branching logic) for users willing to work at the frontier. The trade-off is real effort spent maintaining both paradigms simultaneously, but Peiris frames it as necessary for an enterprise-grade product: skeptical sales leaders who initially distrust the agent-driven approach need the traditional option available while they build trust, and forcing everyone onto the more advanced paradigm immediately risks losing exactly the buyers with veto power over the purchase.
Winning the founder isn't the same as winning the eventual VP of sales
Rampell raises a specific brownfield objection: greenfield startups often later hire experienced VPs of sales who were trained on Salesforce and resist switching regardless of whether the new tool is better. Peiris's answer is to make Lightfield free and useful to everyone in the company (engineering, finance, customer success) beyond just the sales team, so that by the time a skeptical, Salesforce-trained VP of sales arrives, the rest of the organization already depends on Lightfield as the shared source of truth, creating internal pressure on the new hire to adapt rather than rip the tool out.
Common Mistakes
Mistake: letting a team fragment into siloed swim lanes during a pivot
Peiris says one of his clearest regrets from Tome was that separate product, marketing, and CS leaders each guarded their own "swim lane" and resisted feedback outside it, which he says made the company too rigid to pivot when it needed to. At Lightfield, the fix was structural: no fixed swim lanes, a daily company-wide standup that re-ranks the most important problems across engineering, delivery, and customer success, and work gets picked up by whoever is free rather than assigned by role, explicitly because AI tools now let a generalist ramp up on unfamiliar work (a designer picking up a linear-connected task, anyone querying customer context through Lightfield itself) fast enough to make this practical.
Practical Application
Test whether a product's limitation is a ceiling or a gap that will close with better technology
Before continuing to invest in a product that isn't working the way you hoped, explicitly separate two possibilities: the gap will close as the underlying technology (a model, an API, a platform capability) improves, or the gap is structural and no plausible improvement in that dependency fixes it. Peiris's test question, could you picture your most demanding, expert user relying on this indispensably at any foreseeable capability level, is a concrete way to force that distinction rather than defaulting to "it'll get better."
When users ask for things outside your product's scope, follow the request before defending the roadmap
If customers are repeatedly asking your team to do adjacent work your product wasn't built for, treat that as a signal worth investigating directly (get access to the systems and data involved) rather than redirecting them back to the intended use case. Lightfield's pivot came directly from doing exactly the adjacent work customers asked for and noticing that work, not the original product, was where the real, harder problem lived.
Consider negative pricing to get real usage signal on an early, unfinished product
If you can't get anyone to try a genuinely new but unproven product, consider what Lightfield did: pay users in some non-cash form (free resources, direct support, anything valuable to them) in exchange for real, frequent usage and fast feedback, rather than waiting until the product is polished enough to charge for. The signal to watch for isn't satisfaction, it's frequency and specificity of complaints; users who complain constantly but keep coming back are showing you real engagement, not rejection.
Split pricing by how legible each function's ROI is to the buyer, not by a single model
When pricing a product with highly uneven usage across customers, don't default to a single seat- or consumption-based model. Separate functions into routine/expected work (fixed fee), work with clearly attributable value (consumption-based), and premium/hard-to-substitute capability (value-based), and price each bucket according to how easily a buyer can see the return on that specific function.
Bottom Line
Keith Peiris's two decisions, killing a 25-million-user product because its technical ceiling was structural, then building Lightfield's CRM around AI-inferred structure instead of a rigid schema, both come down to the same underlying judgment: know precisely which constraint is fixable with more iteration and which one requires abandoning your current approach entirely, and build your next bet specifically against the constraint that was actually unfixable.