If your company may pursue an IPO, the tempting move is to wait until the filing window is visible, then recruit executives who have done it before. That sequence solves for credentials. It does not necessarily build the decision system the business will need.
Figma took a different path. An operator who joined when the company had about 30 people and was not yet charging for its product grew into the CFO role, while the company adopted public-company habits years before its 2025 IPO. The useful lesson for you is not simply to promote insiders. It is to develop executive judgment, operating cadence, and economic instrumentation as one connected system.
Key takeaways: the playbook on one page
Expand a leader’s decision scope before expanding the title. Look for progression from doing the work, to framing the questions, to allocating resources, to improving decisions across the company.
Install public-company behaviors before the transaction demands them. Figma began operating this way three years before its IPO, using quarterly rhythms, tighter controls, a close that could withstand scrutiny, and a coherent forward-looking narrative.
Treat product, finance, and go-to-market as joint owners of the economic model. They need the same driver tree, definitions, telemetry, and assumptions before they debate pricing or investment.
Manage AI investment as a portfolio of explicit bets. Usage, customer value, cost-to-serve, decision triggers, and risks should be visible even when the underlying economics are changing quickly.
Use leadership transitions to redraw decision rights. Replacing a departing executive without reconsidering the operating model preserves yesterday’s bottlenecks.
Scale executive judgment before you scale titles
Praveer Melwani joined Figma in 2017 as its first business operations and finance hire. The company was still around 30 people and had not begun charging for the product. He became CFO in 2022 and helped lead the company through its IPO in 2025.
The important pattern is the sequence of work. Early responsibilities included building driver trees, challenging go-to-market assumptions, and establishing the mechanics of board management. Later responsibilities moved toward defining the questions the company needed to answer, directing capital, and shaping the operating cadence. The role grew because the decisions grew.
You can use that sequence as an executive-readiness ladder. It is more informative than tenure or the seniority of a candidate’s last title.
Executive mode
Work that demonstrates readiness
Failure signal to watch
Operator
Builds the model, tests assumptions, and makes the basic process reliable.
Produces accurate work but cannot explain which decision it should change.
Question-setter
Identifies the uncertainty that matters, frames options, and defines success.
Waits for the founder or another executive to determine what deserves attention.
Allocator
Connects product evidence, financial constraints, and strategic upside to resource choices.
Treats the budget as a fixed entitlement rather than a set of revisable bets.
System leader
Improves the cadence, decision rights, narrative, and judgment of the wider team.
Remains the indispensable reviewer for every important decision.
Do not promote someone merely because they are excellent in the first row. Give them work from the next row and observe what happens. Ask a strong operator to frame an ambiguous company problem, recommend where resources should move, document the trade-offs, and run the decision through the relevant functions. You are testing whether the person can create clarity beyond the boundaries of the original role.
I use a similar first-principles test when evaluating a prospective VP, especially in a function the founder does not know deeply:
Can the candidate map how the business creates and captures value?
Can they define success metrics and show where those metrics could mislead the team?
Can they explain a meaningful trade-off in plain language?
Can they describe the team and decision system they would build, rather than only the work they would personally perform?
Can they teach the executive team something useful in 30 minutes?
Run this test on your actual business context, not a generic case interview. A candidate who asks sharper questions, exposes a hidden assumption, and improves the decision has demonstrated more than someone who recites the standard playbook from a previous employer. Prior experience still matters, but learning velocity and expanding scope deserve more weight than familiarity alone.
Make IPO readiness a company cadence, not a finance workstream
Figma began behaving like a public company three years before its IPO. That is not a universal countdown for every company. The more important point is the order of operations: the habits came before the event that would test them.
Late preparation forces teams to create controls, reconcile definitions, improve forecasting, and construct a credible narrative while the stakes are already high. Early preparation turns the same work into ordinary management. It also reveals weak ownership and unreliable data while the company still has room to correct them.
Quarterly operating rhythm: Review changes in the business drivers, the assumptions behind the forecast, the resulting resource choices, and the risks that could alter the plan. A performance presentation without a decision is reporting, not an operating review.
Close and controls: Make ownership, evidence, access, and material judgments explicit. The goal is not bureaucracy for its own sake. It is to produce numbers that leaders can use without reopening the entire chain of custody every time.
Forward-looking narrative: Connect past performance to the decisions now being made. Explain what changed, why management believes it changed, what will be done next, and what evidence would invalidate that view.
Decision record: Preserve the assumptions, alternatives, owner, and follow-up trigger behind a material choice. This prevents the company from rewriting the reasoning after the outcome is known.
This discipline can accelerate decisions because product, finance, and go-to-market stop renegotiating the basic facts in every meeting. Product brings evidence about behavior and roadmap alternatives. Finance brings the model, sensitivities, and constraints. Go-to-market brings customer context, commercial implications, and execution dependencies. The executive owner makes the cross-company choice and records what would cause it to change.
A useful quarterly decision packet should answer the following questions:
Our outcome-based pricing model hinges on one principle: you pay when Fin delivers value.
As Fin takes on new roles, that principle doesn’t change, but the definition of value does.
Fin for Sales qualifies leads, engages prospects, and routes high-intent buyers to your sales team. The value it creates isn’t a resolved query, but a pipeline of qualified opportunities. So we price accordingly: $10 per qualified lead. And you, the customer, define what “qualified” means, not Fin.
This is the first outcome-based pricing model for an AI Agent for sales. Here’s why I believe it’s the right approach and how I’ve seen it change the way teams think about SaaS pricing and ROI.
Over the years, I’ve learned that the fastest way to earn trust with sales and finance leaders is to align pricing with outcomes they actually report on. The core finding from our research was unambiguous: zero buyers preferred paying for activity. They wanted to pay for results.
That insight shaped how we priced Fin for its service role, $0.99 per resolution, where a resolution means the customer’s issue is fully solved without human intervention. More recently, we evolved that model to outcomes, reflecting the broader ways Fin delivers value across complex workflows. We believe pricing should be aligned with value delivery, and the vendor should carry risk when the product doesn’t perform. In sales, the best unit of value is pipeline.
Most sales teams today are overwhelmed by leads. Early in my career, I watched reps spend hours chasing form fills that looked promising but went nowhere. That experience cemented a lesson I still use: volume is vanity; qualification is sanity.
Ensuring the right opportunities promptly reach your sales team is what makes a difference. When a prospect visits your site, engages with Fin, answers qualifying questions, and is directed to a sales rep, Fin is identifying whether the opportunity is worth your team’s time and delivering value.
Charging per conversation would penalize businesses for every curious visitor who asks a question but isn’t a buyer. And charging per token, well, that’s always been a model that protects the vendor, not the customer.
We needed a metric that captures the actual value Fin creates in a sales context: qualified leads.
The purest version of outcome-based pricing for Fin’s sales role would be a percentage of closed revenue. Fin qualifies the lead, a rep closes the deal, and we take a cut. On paper, it looks elegant; in practice, I found it breaks down for two reasons that matter to operators.
First, attribution. Between the moment Fin qualifies a lead and the moment a deal closes, dozens of things can impact the final result. The quality of human-led demos can differ, products can have outages, prospects’ budgets can get cut. Tying Fin’s price to the final outcome holds it accountable for variables entirely outside its control.
Second, measurement. To track closed revenue, we’d need deep integration into every customer’s CRM, tracking each opportunity from qualification through to close. That’s a significant implementation burden that slows time to value, which is the opposite of what we want.
So we asked: what’s the most honest proxy for the value Fin delivers, where Fin is clearly the one creating it?
A qualified lead is that proxy. It represents the moment Fin has done its job. It has engaged the prospect, gathered the relevant information, evaluated them against your criteria, and determined they’re qualified. Everything up to that point is Fin’s work. Everything after it is the rep’s. At $10 per qualified lead, the pricing reflects this boundary.
There are two key components to how this pricing model works.
First, the customer defines success. With Fin’s sales role, the customer sets their own qualification criteria based on their business context. A company with high average contract values might set a lower bar because they can’t afford to miss anyone. A company where rep time is scarce and deal sizes are smaller might set a much higher bar, filtering aggressively to only surface the most promising prospects. The criteria flex to match the business.
Second, the economics are different by design. As a Customer Agent, Fin can switch between roles like sales and service. So if you’ve deployed Fin for Sales, it can still handle support queries like prospects asking a product question. Those queries are charged at $1 per resolution, consistent with our service pricing. Disqualifications, where Fin determines a prospect doesn’t meet the criteria, are also $1. The $10 price point for qualified leads reflects the higher value of pipeline creation compared to issue resolution.
The ROI speaks for itself. Early customers are reporting significant returns using Fin for Sales. One shared a perspective that mirrors what I hear in executive QBRs:
“I would say it’s at least 10 times the value. You’re now giving the business exactly what it needs as opposed to just activity. We say this expression in sales leadership all the time – ‘I don’t pay my sales team for activity. I pay them for results.’ I want my AI engine to be the same way.”
When you compare the cost of a qualified lead from Fin against the fully loaded cost of an SDR—salary, benefits, tooling, ramp time—the economics are compelling. For many businesses, particularly those that never had SDRs in the first place, Fin for Sales isn’t just replacing headcount, but creating an entirely new capability that wasn’t economically viable before.
This pricing model came from extensive customer research—qualitative interviews and quantitative studies—exploring how buyers want to pay for AI in a sales context. We tested multiple concepts: per-conversation, per-token, per-seat, revenue share, and per-qualified-lead. The research consistently pointed to outcome-aligned pricing as the preferred model, with the qualified lead emerging as the metric that best balances value alignment, measurability, and practical implementation.
Outcome-based pricing is still rare in AI, but we think that will change. For Sales Agents, we’re the first to do it. Transparency is part of the model. If you understand why we price the way we do, you can evaluate whether it works for your business.
I’ve long believed a simple truth about AI in customer support: if AI is going to earn trust, pricing has to be aligned with value. That principle has guided my product decisions and the way I hold our teams accountable for measurable outcomes, not activity.
When we shared our perspective on pricing AI Agents in 2023, we made a simple argument: if AI is going to earn trust, pricing has to be aligned with value. At the time for Fin, that value was clear. You pay when the AI resolves a customer’s problem. If it doesn’t, you don’t. That’s fair, easy to understand, and grounded in results, not activity. We were the first to introduce this pricing model because we believed that pricing and value should be inherently linked.
That belief hasn’t changed, it’s grown stronger over time. What’s changed is what Fin can do. As we expanded capabilities and pushed deeper into complex workflows, it became clear that measuring value solely by end-to-end resolutions no longer captured the full picture of impact.
Resolutions were the right place to start. Historically, we measured value based on whether Fin fully resolved a conversation on its own. These are known as resolutions and they gave support teams a clear way to measure ROI, easily comparing the cost of AI versus human support. They also aligned our incentives with our customers, as our revenue was directly tied to Fin’s performance.
That clarity worked. Today, more than 7,000 teams use Fin. Our average resolution rate across customers has increased every month and now stands at 67%, even as Fin increasingly handles more complex queries. That progress came from building an Agent that could take on harder problems and still deliver.
But as Fin got more powerful, “success” stopped being binary. I saw this first-hand in customer design sessions where policy, risk, and compliance needs rightly demanded human-in-the-loop confirmation. We weren’t failing to deliver value; we were delivering it differently.
Over the last couple of years, we invested heavily to ensure Fin could handle the most complex parts of support. As Fin’s capabilities expanded, customers began pushing what Fin can do for them by deploying Fin deeper into their workflows to handle the toughest queries.
In some cases, this required Fin to work in tandem with a human agent because that’s what customer policies and oversight needs dictated. Subscription changes, transaction disputes, billing issues, and other multi-step support scenarios can often require Fin to gather context, read and write to external systems, and execute actions before handing off to a human agent for confirmation.
Fin is still doing what it was configured for – intentionally handing off after doing more of the heavy lifting, saving valuable time for support teams and overall time to serve for their customers. But our pricing metric only recognized value when the conversation ended in a full “AI resolution” (i.e. a human was never involved).
That’s why we’re evolving Fin’s pricing metric from resolutions to outcomes. This shift reflects how customers now define value: not just in full automation, but in safe, efficient progress toward the right result across complex, multi-step, and policy-constrained workflows.
An outcome represents when Fin successfully completes the action it was configured to perform, as part of a conversation. Resolutions are still one type of outcome Fin can deliver, where it handles the issue end-to-end. Another type of outcome can be a Procedure where Fin gathers context, takes action, and hands the conversation off when that’s what customers configured it to do.
Kick off your journey with the #1 Agent—an AI partner designed to turn resolutions into real outcomes. Tap “Start a free trial” to explore faster, smarter customer service and see how Fin delivers value from day one.
Increasing end-to-end AI resolutions is still a core component of scaling Agents, but they are no longer the only measure of Fin's success and utility. Especially as Fin takes on more complex work. Moving to outcomes recognizes that solving a customer problem with full automation isn’t always appropriate. It’s about getting to the right result, safely, and efficiently.
As Fin’s capabilities expand, teams should feel empowered to use it in more nuanced, collaborative work. Outcomes support that by allowing customers to design workflows that meet compliance requirements and include a human agent when necessary. From a product management standpoint, this is how we align incentives, keep risk controls intact, and still accelerate time-to-value.
Fin is becoming even more powerful at handling complex, multi-step support queries. With outcomes, we can support that growth without constantly reinventing how value is measured. And this change gives us a strong pricing foundation that can scale as Fin continues to grow and take on more roles beyond service. This aligns with our vision of Fin becoming a “Customer Agent,” capable of handling the entire customer experience.
What this means for pricing is intentionally straightforward. An outcome will be counted when Fin successfully completes an action it was configured to perform, as part of a conversation. That keeps the model predictable for finance leaders while staying transparent for operators and product teams managing AI workflows.
The pricing model stays simple and the definition of value becomes more accurate. In other words, we’re doubling down on fairness, predictability, and competitiveness—core tenets for any consumption SaaS pricing strategy tied to real business impact.
When we first wrote about outcome-based pricing, we said that trust is the currency of AI. That’s still true. Trust is earned when customers see pricing move in lockstep with utility and risk posture, especially as gen AI and agentic AI take on higher-stakes tasks.
Pricing has to feel fair, it has to be predictable, and it has to stay competitive. Evolving from resolutions to outcomes isn’t a departure from that belief. It’s the natural maturation of how we measure value as AI moves from simple Q&A into complex procedures and human-in-the-loop collaboration.
Fin has grown more powerful because customers asked more of it. Outcomes are how we reflect that progress honestly, while staying true to the same principles that guided us from the start. This is product strategy in action: align incentives, measure what matters, and scale what works.
And as Fin continues to get stronger, we’ll keep holding ourselves to the same standard: price based on the value delivered. That’s how we build durable trust, sustainable ROI, and a better customer experience at scale.
I’ve led product organizations through multiple growth chapters, and the pattern is always the same: the tighter the alignment between product, sales, and marketing, the faster you scale. Reflecting on the journey of Chris Degnan — the first sales hire at Snowflake who spent 11 years helping scale the company from zero to $3.5 billion in revenue as its CRO while partnering with four different CEOs — I’m struck by how consistently the fundamentals win. The playbook isn’t mysterious; it’s disciplined execution, ruthless clarity, and a go-to-market strategy that matures with each revenue stage.
At $10M ARR, the CRO role is hands-on and founder-adjacent. You’re close to the product, running point on key deals, pressure-testing messaging, and building credibility with early customers. By $1B+, the job is organization design: segmentation, international expansion, forecast accuracy, enablement, recruiting, and cross-functional orchestration. The shift is from deal quarterback to system architect — standing up repeatable, auditable processes that produce reliable outcomes across regions, segments, and industries.
Sales leaders who can’t sell the product themselves don’t last. Whether you sit in product management leadership or run the field, you need to master discovery, speak the customer’s language, and translate use cases into value. That also means getting fluent in solutions engineering — understanding integrations, data paths, security, and the operational realities buyers live with. I’ve found this hands-on competence to be the fastest way to earn trust internally and externally, and to keep product strategy grounded in market truth.
The MEDDIC methodology is the foundation for every durable sales org — and, frankly, a founder’s best insurance policy. MEDDIC forces alignment on qualification criteria, from Metrics to Economic Buyer to Decision Process and Identifying Pain. When product and sales both operate to this standard, roadmap bets improve, marketing targets sharpen, and win rates climb. It’s not paperwork; it’s pattern recognition at scale.
High-output CROs obsess over the right numbers. Pipeline coverage by segment and stage; conversion rates through each gate; sales cycle length by use case; average selling price and discount discipline; consumption predictability when you have consumption SaaS pricing; and post-sale expansion velocity. The art is deciding which two or three metrics are the organization’s true north at a given stage — then designing enablement, compensation, and operating cadence around them.
On operating cadence, the week in the life at scale is predictable for a reason. Forecast reviews that surface risk early. Deal reviews that coach to MEDDIC depth, not activity theater. Enablement blocks to uplevel managers and ICs. Recruiting time — always. Customer roadshows to refine value proposition and product positioning. And standing meetings with product, marketing, and finance to keep the GTM motion, roadmap, and unit economics in sync.
Compensation is a force multiplier or a silent saboteur. Keep it simple, consistent, and aligned to the current motion. Early on, weight new logo acquisition and land quality; as you mature, balance new business with expansion, multi-product adoption, and healthy consumption. Guardrails matter — cap over-discounting, reward multi-threading, and avoid plans that create end-of-quarter cliff behavior. The best plans reinforce the behaviors you want your culture to scale.
Technical CEOs often underestimate how much narrative, segmentation, and process discipline great GTM requires. The handoff from founder-led GTM to sales-led growth is where many teams stall. My rule: prove one repeatable motion in one segment before you add complexity. Codify the buyer’s journey, instrument the funnel, and make sure product strategy and enablement move in lockstep.
Culture sets the ceiling. You have to find the fakers, manage-uppers, and passengers quickly — people who look busy but don’t move pipeline, who talk big but avoid accountability, or who ride the momentum of others. The mantra that has saved me endless time: “When there’s doubt, there’s no doubt”. Move fast, but with humanity; be clear on expectations, coach hard, and when it’s not a fit, make the change before the team does it for you.
Feedback is the operating system of a high-performing org. Leaders at every level need to be coachable — on message discipline, on forecast rigor, on how they develop people. I’ve benefited from straight talkers who hold a high bar, and I try to pay that forward. The fastest way to raise organizational IQ is to institutionalize feedback loops across sales, product, and marketing — from post-mortems to win-loss analysis to field-sourced roadmap reviews.
What separates exceptional ICs from the rest? Hunger, intellectual honesty, and a builder’s mindset. They qualify hard, align to customer metrics early, multi-thread to power and value, and partner tightly with solutions engineering. They don’t hide from gaps; they surface them, and they know exactly what they need from product, marketing, and leadership to win.
Executive teams that scale share a few traits: crisp segmentation decisions, single-threaded ownership for outcomes, and healthy conflict that resolves into commitment. Dysfunction, by contrast, looks like metrics roulette, opaque decision-making, and a tolerance for exceptions that become precedent. Make the rules explicit and the exceptions rare.
Leaders like Frank Slootman have popularized intensity, speed, and focus — and there’s real power there when paired with clarity and data. The lesson I carry forward: move fast on people decisions, keep the message simple, and measure what matters. Equally important is knowing where that approach can backfire — when speed outruns learning, or when pressure erodes cross-functional trust. The best operators balance urgency with systems thinking.
Most AI companies will face a go-to-market reckoning. Model quality won’t save a weak motion. The winners will articulate a hard-nosed ROI, solve specific workflow pain, address data governance and security head-on, and show measurable lift — not demo dazzle. In other words, the same fundamentals apply; the stakes and scrutiny are just higher.
If you’re building or rebuilding your revenue engine, start here: define your ideal customer profile and segmentation with ruthless clarity; adopt MEDDIC and teach it across product and sales; align compensation to today’s motion; instrument the funnel and inspect it weekly; and cultivate a culture where feedback is fuel. Do that, and the path from $0 to $3.5B stops feeling like mythology — and starts looking like math.
You have an AI capability on the roadmap. A vendor can demonstrate something credible almost immediately, while engineering believes an internal version would fit the product better. Both claims may be true, and neither one answers the decision in front of you.
The useful question is not simply whether to build or buy. You need to decide which parts of the capability create strategic advantage, what you must learn before committing further, which obligations you are prepared to own, and how you will leave if the economics or technology changes.
Draw the capability boundary before comparing options
Most weak build-versus-buy debates begin with a label that is too broad. AI assistant, support automation, recommendation engine, and enterprise search each describe an experience, not a single technical capability. Comparing a vendor’s finished product with an imagined internal system at that level guarantees an uneven evaluation.
Break the experience into layers before discussing ownership. An AI product might contain data connectors, ingestion, domain retrieval, ranking, generation, orchestration, evaluation, observability, policy guardrails, workflow logic, a user interface, and a human handoff. You can make a different decision for each layer.
Classify every layer by its strategic role:
Differentiation: The layer materially affects why customers choose, retain, or expand with your product. It may encode a proprietary workflow, use unique data, or create a feedback loop competitors cannot easily reproduce.
Parity: Customers expect the capability, but it is not a meaningful reason to choose you. Reliable billing infrastructure, standard integrations, and generic analytics plumbing often belong here.
Control: The layer may not be visible to customers, but it determines whether you can satisfy security, regulatory, reliability, cost, or product-policy obligations. Control can justify ownership even when the layer itself is not differentiating.
If this layer became substantially better, would it change the product’s value proposition or merely close a feature gap?
Does operating it create proprietary data, evaluation evidence, workflow knowledge, or customer insight that compounds over time?
Would dependence on a vendor’s roadmap prevent you from making an important product promise?
Could a close competitor buy the same capability and achieve roughly the same result?
Do privacy, residency, auditability, reliability, or recovery requirements force you to retain direct control?
Can your team support the layer after launch, including incidents, upgrades, security work, and user adoption?
A retrieval-augmented generation system shows why this decomposition matters. The right answer may be to build the parts that encode domain knowledge while buying fast-moving infrastructure around them.
Layer
Strategic question
Plausible initial posture
Domain retrieval and ranking
Does relevance depend on proprietary content, metadata, permissions, or customer context?
Build when this is central to answer quality and differentiation.
Orchestration and observability
Would owning the runtime create customer value, or only infrastructure work?
Buy when a platform provides adequate reliability, APIs, and portability.
Prompts, policies, guardrails, and evaluation cases
Do these artifacts encode product behavior, risk tolerance, and domain expertise?
Own the specifications and evidence even if a vendor executes them.
User workflow and human handoff
Is the workflow part of the product’s distinctive experience?
Build the differentiated interaction; integrate commodity components behind it.
The point is not that every retrieval system should use this split. The point is to stop forcing one ownership decision across layers with different strategic value. A composed architecture can give you speed at the edges and control at the center.
Compare time to value and total ownership cost separately
Buying and building usually produce different cost curves. Buying can reduce the initial implementation burden and provide proven operations. Building concentrates cost and complexity near the beginning but may create a better fit and more favorable economics at scale. Neither profile is automatically cheaper.
Evaluate the decision across two horizons. The first is time to activated value: how long it takes before the intended users complete the intended workflow successfully. The second is total cost of ownership over the period in which the capability must operate, evolve, and eventually migrate.
Do not treat a signed contract, completed deployment, or merged pull request as time to value. Procurement, security review, data preparation, integration, enablement, in-product guidance, and user activation sit between acquisition and an actual outcome. A fast purchase with weak adoption is not a fast result.
A useful cost model is:
Total ownership cost = acquisition or development + integration + operations + change + risk exposure + exit.
Apply the same formula to both choices. Teams often present the vendor’s full commercial cost against only the internal development estimate, or compare a subscription price with an imagined build that excludes maintenance. Both comparisons are misleading.
Cost area
Evidence needed for a buy option
Evidence needed for a build option
Acquisition or development
Subscription, per-seat or consumption charges, implementation fees, support tier, and expected price changes with growth.
Product, design, engineering, data, security, and platform capacity required to reach usable scope.
Integration
Connector work, identity and permission mapping, data transformation, API constraints, testing, and CI/CD maintenance.
Interfaces with existing systems, migration of current workflows, data contracts, and platform dependencies.
Operations
Internal administration, vendor management, incident coordination, usage monitoring, and workarounds for roadmap gaps.
On-call ownership, observability, model and dependency updates, incident response, capacity management, and reliability work.
Change
Configuration limits, professional services, retraining, contract changes, and waiting for vendor roadmap delivery.
Continuing product development, evaluation maintenance, documentation, enablement, and the opportunity cost of displaced roadmap work.
Risk exposure
Vendor outages, security posture, data handling, roadmap dependence, quota changes, and concentration risk.
Internal security gaps, insufficient operational maturity, key-person dependency, and failure to meet compliance obligations.
Exit
Data export, contract termination, migration assistance, replacement integration, and reconstruction of non-portable artifacts.
Decommissioning, data migration, user transition, and replacement of internally coupled components.
Run an expected case and a stress case for both options. For a vendor, stress usage, API consumption, support requirements, and the cost of additional environments or features. For an internal system, stress incident load, model or infrastructure changes, evaluation maintenance, and continued product demands. The purpose is not to produce a perfectly precise forecast. It is to expose which assumptions can overturn the decision.
Record those assumptions in the decision memo. If vendor consumption cost must stay within an agreed envelope, state that envelope internally and assign someone to monitor it. If the build case depends on reuse across several product surfaces, name those surfaces and verify that their teams actually intend to adopt the component. An unowned assumption is not a forecast; it is hidden risk.
Turn the debate into an evidence-based decision
A scorecard is useful only when it forces explicit trade-offs. It should not turn judgment into decorative arithmetic. Establish hard gates first, agree on the relative importance of the remaining criteria before vendor demonstrations or internal prototypes create attachment, and then evaluate both options against the same outcome.
How directly does the capability support the value proposition or defensibility?
Product strategy, roadmap commitments, customer workflow evidence, proprietary data advantages, and the importance of controlling behavior.
Build becomes more attractive as the capability determines why customers choose or stay.
Urgency and time to value
What is the cost of waiting, and when can users reach a meaningful outcome?
Procurement and security timelines, integration dependencies, build scope, launch readiness, enablement needs, and adoption path.
Buy becomes more attractive when delay is costly and the purchased path can reach activated value materially sooner.
Security and regulatory risk
Can either option verifiably meet non-negotiable obligations within the launch window?
Data-flow diagrams, privacy controls, residency, retention, audit logs, access controls, certifications, threat response, model lineage, and red-team practices.
An option that fails a mandatory obligation should be removed, regardless of its aggregate score.
Integration complexity
How much continuing work is hidden behind the initial connection?
Sandbox tests, API behavior, quotas, identity mapping, data contracts, failure modes, deployment workflow, and ownership of connectors.
Build gains ground when vendor constraints create persistent product or operational work; buy gains ground when internal integration and support exceed the apparent build scope.
AI leverage and portability
Which prompts, data, evaluations, embeddings, policies, and feedback become valuable, and can they move?
Export tests, API abstraction, model-routing options, ownership terms, deletion process, evaluation access, and migration design.
Build or a hybrid architecture gains ground when the vendor captures an asset central to future differentiation.
Security, regulatory compliance, and minimum reliability are gates, not preferences. A high score elsewhere cannot compensate for an option that cannot lawfully handle the data, meet a required recovery posture, or provide necessary audit evidence. The same logic applies to internal capacity: if no team can own production incidents, an attractive prototype is not a viable build option.
Use a product trio of product, design, and engineering to set the scorecard’s priorities. Bring security, data, finance, procurement, and operations into the criteria they own. This prevents a late-stage veto from appearing as a surprise when it was actually a missing requirement.
Then run comparable discovery work. Give the vendor a production-like workflow in a sandbox. Give the internal option a thin vertical slice that touches the real data and integration boundary. Test the same cases for outcome quality, failure handling, permissions, auditability, operator effort, integration behavior, and unit economics. A polished vendor demonstration and a rough internal prototype reveal different things; common acceptance cases make the evidence comparable.
Keep confidence separate from the decision direction. A criterion can favor building while resting on weak evidence. Mark it as an assumption and define the cheapest test that would resolve it. This is more useful than adding precision to a score whose inputs remain speculative.
The final memo should fit the decision, not the politics around it. Include the capability boundary, strategic classification of each layer, intended user outcome, hard gates, scorecard, cost assumptions, evidence quality, operational owner, exit path, and re-evaluation triggers. Anyone reading it later should be able to tell why the decision was reasonable at the time and which changed condition would justify revisiting it.
Run an AI-specific risk and portability pass
AI changes more than development speed. It introduces movable models, probabilistic behavior, data-dependent quality, metered usage, and artifacts that can become strategically valuable. A normal software procurement checklist will miss several of these dependencies.
Data route: Document what enters the system, which service receives it, where it is stored, how long it is retained, whether it can be used for training, how deletion works, and whether residency requirements apply. Include prompts, retrieved context, generated output, user feedback, and operational logs.
Model and quality governance: Require a way to identify the model, configuration, prompt, retrieval state, and policy version associated with important behavior. Decide who maintains evaluation cases, reviews regressions, investigates failures, and approves consequential changes.
Security and privacy: Verify role-based access, audit logs, PII handling, privacy-by-design controls, threat detection and response, and the vendor’s red-team and incident practices. For an internal build, require equally concrete evidence rather than assuming control equals safety.
Portability: Establish ownership and export mechanisms for source data, metadata, prompts, policies, evaluation sets, feedback, transcripts, and relevant logs. Treat a contractual right to export and a technically usable export as separate requirements.
Unit economics: Map every metered event in the actual workflow. Per-seat pricing, consumption charges, model usage, and orchestration can behave differently as adoption and workflow complexity grow. Test the economic model against expected and stressed usage.
Operational responsibility: Specify who diagnoses a failure that crosses your application, the vendor platform, a model provider, and a data source. Shared architecture does not remove accountability; it makes the handoffs more important.
Portability deserves an actual exit test. Ask the vendor to produce a representative export before the contract is final. Confirm its format, completeness, permission model, and usefulness in another environment. An export button is not evidence that you can reconstruct the product behavior that matters.
Prompts require the same caution. Access to prompt text is necessary, but equivalent behavior may still depend on a model, tool interface, retrieval implementation, or vendor-specific orchestration. Preserve the intent, policies, evaluation cases, and expected outcomes around a prompt, not just the string itself.
Embeddings can also create false confidence about portability. Preserve the original content, chunking inputs, metadata, permission relationships, and evaluation set so embeddings can be regenerated if the model or retrieval system changes. The derived vectors alone are not a complete migration asset.
For vendors, negotiate transparent API quotas, usable sandbox environments, data-export terms, growth price protections, and clear ownership of AI artifacts. Pressure-test the roadmap against your deployment cadence and ask how incidents, breaking changes, and model transitions are communicated. For an internal build, apply the same rigor to service levels, incident response, observability, model lineage, retention, and ongoing staffing.
Buying does not outsource your responsibility for the product’s behavior. Building does not prove that the behavior is controlled. Choose the implementation that can produce the evidence your risk level demands within the launch window.
Make a staged commitment with explicit re-evaluation triggers
A build-versus-buy decision does not need to be permanent to be disciplined. When uncertainty is high and speed matters, a bounded purchase can be a learning instrument. When differentiation or control is already clear, a minimum lovable internal slice can establish the core while purchased components accelerate everything around it.
For a buy-to-learn path, use this sequence:
Name the uncertainty. Decide whether you are testing demand, workflow fit, quality, integration feasibility, adoption, operational burden, or economics. Do not call a general implementation a pilot.
Bound the commitment. Limit initial scope, data exposure, coupling, and custom vendor work to what the learning objective requires. Preserve an adapter or interface where replacement would otherwise become expensive.
Instrument the outcome. Track whether intended users activate, return, complete the workflow, accept the output, escalate to a human, and create operational work. Monitor consumption and connector reliability alongside product use.
Review against prewritten triggers. Deepen the vendor integration if adoption is durable, economics remain acceptable, and integration pain is manageable. Move toward building if unique requirements emerge, strategic artifacts accumulate, vendor constraints block the roadmap, or costs reach the agreed inflection point. Stop if the user outcome does not materialize.
This approach works because a purchased solution can validate value before a deeper build commitment. The learning is reusable only if you retain the data model, evaluation evidence, workflow understanding, and user-behavior insight rather than burying them inside vendor-specific configuration.
For a build-to-differentiate path, keep the first scope narrow. Build the smallest end-to-end experience that proves the differentiating hypothesis. Buy mature infrastructure around it where doing so does not surrender the key data, policy, or product behavior. Isolate components behind explicit interfaces so a model, orchestration service, retrieval system, or observability layer can change without rewriting the entire experience.
Set re-evaluation triggers before launch, while nobody is defending a sunk decision:
Product trigger: Usage fails to become durable, or customers reveal a need that the current option cannot support.
Financial trigger: Consumption pricing, operating cost, or internal staffing moves outside the approved economic envelope.
Technical trigger: Integration maintenance, API limits, reliability, or roadmap mismatch begins delaying important releases.
Risk trigger: Data handling, retention, auditability, model governance, or regulatory obligations can no longer be met.
Strategic trigger: A previously generic layer begins creating proprietary data, workflow advantage, or meaningful differentiation.
Capacity trigger: The internal team can no longer sustain the operational burden, or gains the maturity needed to own a capability previously bought.
Assign an owner and a review event to each trigger. Without ownership, continuous re-evaluation becomes a good intention that loses to roadmap pressure. The decision memo should remain a living control surface for product, engineering, finance, security, and procurement, not an artifact filed after approval.
Do not neglect activation. Whether you build or buy, budget for workflow changes, onboarding, in-app guidance, support preparation, and measurement. Deployment creates availability. Repeated successful use creates value.
Key takeaways
Decompose an AI experience into layers before deciding who should own it.
Build differentiated or control-critical layers; buy parity where a vendor can accelerate activated value.
Compare both choices across time to value and total ownership cost using the same scope and service expectations.
Apply non-negotiable gates before a weighted scorecard, then test both options against common acceptance cases.
Own the data, policies, evaluation evidence, and migration path that protect your future leverage.
Use staged commitments and prewritten triggers so changing the decision becomes responsible management, not an admission of failure.
The next time this question reaches your roadmap review, do not ask for a permanent verdict on build or buy. Ask for a capability map, comparable evidence, an operational owner, a tested exit path, and the conditions that would change the answer. That gives you a decision you can defend now without mortgaging your ability to adapt later.
I’ve learned the hard way that shipping an impressive AI demo is not the same as creating a durable revenue engine. In my role leading product strategy, I focus on one goal: connect AI capabilities to measurable customer outcomes, then price and package them so both value and margins are visible and defensible.
Monetizing AI features into profit isn’t trivial. Here are some clear strategies for capturing and pricing AI products and how to monetize with returns.
First, I clarify the business model. Add-on AI packs work when the value is concentrated in a specific workflow (for example, automated summarization or AI copilot assistance). Tiered packaging helps when AI elevates the overall experience across many features. Usage-based or consumption SaaS pricing is ideal when value scales with volume—tokens, documents processed, calls handled, or agents invoked—because it aligns price to realized outcomes.
Next, I align pricing mechanics with the customer’s value story. I anchor price against the baseline they know: hours saved, conversions gained, cases deflected, or risk reduced. Then I set floors based on unit economics—model inference, vector storage, and orchestration costs—so gross margins remain healthy as usage grows. Clear guardrails (quotas, rate limits, and context window management) prevent surprise bills and keep cost-to-serve predictable.
Packaging is where monetization becomes intuitive. I gate high-cadence, high-compute features behind premium tiers, and I expose quick wins (like smart suggestions) in core tiers to accelerate activation. For enterprise, I bundle governance, audit logs, data controls, and “privacy-by-design” features to justify step-up pricing and reduce procurement friction.
To sustain ROI, I run an eval-driven development loop. I define quality metrics (accuracy, helpfulness, latency, safety) and instrument the retrieval-first pipeline so I can isolate where value is created or lost. This lets me right-size models, tune prompts, and swap components without compromising outcomes or margins—critical for LLMs for product managers who must balance experience and cost.
Measurement is non-negotiable. I track activation, time-to-first-value, weekly engaged AI users, and feature-level retention. For revenue impact, I attribute uplift through A/B testing and minimum detectable effect thresholds, measuring conversion lift, ticket deflection, and cycle-time reductions. When customers see these numbers in their own dashboards, procurement turns into partnership.
Risk and compliance are part of the product, not an afterthought. I build in AI risk management, data governance, and red-teaming from day one. Clear data boundaries, human-in-the-loop controls, and transparent disclosures protect end users and make enterprise legal teams our allies rather than blockers.
Go-to-market matters as much as the model. I use product-led growth tactics—free AI credits, transparent meters, and in-app guides—to let users feel the value before the paywall. Sales enablement centers on the value proposition: faster outcomes, higher quality, and lower total cost of ownership, not just “gen ai” for its own sake. Pricing pages should showcase tiers, usage bands, and outcomes, eliminating guesswork.
Here’s the simple playbook I follow: validate the problem with continuous discovery, instrument the workflow, pilot with generous caps, and collect willingness-to-pay signals early. Then iterate the price meter, refine units of value (documents, messages, or actions), and align SKUs to buyer personas. Over time, I introduce agentic AI capabilities as premium modules when they demonstrably reduce steps or automate entire objectives.
When AI monetization works, it feels effortless to customers because the price mirrors the outcome. When it doesn’t, it’s usually because packaging hides value, pricing ignores unit economics, or ROI isn’t visible. By grounding strategy in value metrics, consumption-aware pricing, and rigorous evaluation, I’ve found we can scale AI revenue with confidence—and keep both customers and margins happy.
“Do you know how your AI agents are performing?” I ask this question in every review because it exposes whether we’re managing by outcomes or by anecdotes. Too often, teams point to latency, token counts, or completion rates and call it a day—useful signals, but not the story.
In my role, shipping agentic AI into production means I need decision-quality evidence, not vibes. That starts with Agent Analytics built on a unified analytics platform and instrumentation that lets me trace behavior, quantify value, and manage risk. Below are the six questions I use to separate novelty from durable impact.
1) What outcome are we optimizing for—and how do we measure it? If we can’t map the agent’s work to outcomes vs output OKRs, we’re optimizing noise. I anchor on task success rate, time-to-resolution, containment rate (no human handoff), cost per successful outcome, and downstream business impact (retention, conversion, NPS/CSAT) to keep us honest.
2) Are the right guardrails in place for AI risk management and data governance? I expect documented policies for prompt injection defenses, PII redaction, access control, and auditability. Every tool call should be permissioned, every data boundary explicit, and every failure mode observable. If we can’t demonstrate compliance by design, we’re scaling risk instead of value.
3) Can I explain every decision the agent made? Agentic AI needs traceability: prompts, intermediate reasoning, tool calls, retrieved context, and final outputs. I route key events into Amplitude analytics so product, engineering, and risk can slice behavior end to end. If we can’t reconstruct the path to an answer, we can’t debug, improve, or trust it.
4) What is the true cost per successful outcome? Raw token spend is misleading. I model total cost of ownership across retries, tool usage, escalations, and human review time—then benchmark against a consumption SaaS pricing lens. If cost per resolution trends up as volume grows, we haven’t built a scalable system; we’ve built a demo.
5) How does the agent learn without breaking what already works? My bar is a disciplined experimentation loop: offline evals, online A/B testing with clear guardrails, and a rollback plan. We predefine a minimum threshold for improvement before rollout and track regressions by persona, task type, and channel so we can localize fixes quickly.
6) Where is this agent creating durable differentiation? I look for capabilities competitors can’t easily copy: unique data advantages, superior tool orchestration, or workflows that compound learning. If the edge is just a base model prompt, the moat will evaporate; if it’s embedded in product workflows and proprietary signals, we’re building advantage.
Answering these six questions turns agentic AI from a novelty into a managed system. With Agent Analytics feeding a unified analytics platform, we can tie behavior to business outcomes, enforce governance, and make portfolio trade-offs grounded in evidence. The result is a product management leadership motion that prioritizes real ROI over vanity metrics—and scales with confidence.
If you’re not satisfied with the answers today, start by instrumenting the journey end to end, aligning metrics to OKRs, and setting clear risk thresholds. The compounding effects show up quickly when every iteration is measurable, explainable, and accountable.
Across enterprises, I’m watching AI sprint from lab experiments to business-critical workflows. That velocity is exciting—and it’s also where risk compounds. In my role partnering with CIOs and IT leadership, I’ve learned that winning with AI is as much about disciplined risk management as it is about breakthrough use cases.
Learn about the risks that AI poses to IT teams, and how they can mitigate them.
I frame the challenge as “4 AI risks for CIOs (and a guide to solve them)”: data governance and compliance, model reliability and bias, security and supply chain exposure, and operational cost/ROI drift. Below, I outline the risks I see most often and the concrete actions I take to de-risk them without slowing innovation.
Risk 1: Data governance and compliance. The fastest way to stall an AI Strategy is to overlook consent, lineage, and access controls. I establish privacy-by-design from day one: data minimization, clear retention policies, role-based access control, and auditable logs for training, inference, and feedback loops. I also insist on defensible vendor reviews (DPA, SOC2/ISO, regional data residency), PII classification, and internal model cards that document sources, sensitivities, and acceptable-use constraints. This makes IT leadership comfortable scaling from prototype to production.
Risk 2: Model reliability, hallucinations, and bias. AI that fabricates or skews output erodes trust and creates downstream risk. I operationalize quality with evaluation harnesses, golden datasets, human-in-the-loop review for high-impact actions, and red-teaming for safety. Retrieval-augmented generation with citations, content filters, and grounded prompts reduce error rates. To quantify progress, I define precision/recall targets and a minimum detectable effect (MDE) for experiments so we know when a change is truly better—not just different.
Risk 3: Security and AI supply chain. New surface area invites prompt injection, data exfiltration, and compromised dependencies. I apply zero-trust principles: strict allow/deny lists for tools and connectors, secrets isolation, egress controls, sandboxed environments for agents, and output validation before execution. Every model and plugin goes through threat modeling, dependency scanning, and vendor security reviews. For agentic AI patterns, I gate high-risk actions behind explicit approvals and granular scopes.
Risk 4: Operational cost and ROI drift. AI workloads can balloon with hidden inference costs, shadow IT, and duplicated platforms. I put governance around spend using consumption SaaS pricing guardrails, usage caps by environment, tagging by app/team, and a unified analytics platform to monitor latency, quality, and cost per transaction. This lets me reallocate budget toward the highest-impact use cases while sunsetting low-yield experiments.
Your 90-day playbook. Days 0–30: Inventory AI use cases, classify data sensitivity, choose one or two critical business workflows, and stand up core guardrails (access, audit, red-teaming). Days 31–60: Pilot with a cross-functional product trio (PM, design, engineering), define OKRs, instrument evaluations, and enable human-in-the-loop. Days 61–90: Productionize the winning flow, set usage and spend policies, enable observability dashboards, and roll out training for frontline teams with clear escalation paths.
The organizational layer matters as much as the technical one. I align stakeholders early, empower product trios to iterate quickly within boundaries, and deploy forward deployed engineers to embed with the business. This keeps trust high, reduces handoffs, and ensures that governance accelerates value rather than blocking it.
Done well, these practices turn AI risk into a competitive moat. By pairing disciplined governance with pragmatic experimentation, we capture the upside of gen ai while protecting customers, teams, and the business. That’s how I’ve helped enterprises move from scattered pilots to measurable, scalable impact—safely.
I recently sat down with Jeanne DeWitt Grosser, Head of Americas Revenue and Growth for Stripe, where she’s responsible for all sales functions and leads the company’s enterprise strategy. She joined Stripe after a career in sales at Google and also serving as Dialpad’s Chief Revenue Officer. Reflecting on our discussion, I was struck by how deliberately she treats pricing as a growth lever.
We went deep on pricing strategy. I contrasted usage-based pricing with traditional SaaS pricing, and Jeanne outlined the trade-offs clearly: usage-based pricing brings your economics closer to customer value, while subscription simplicity can reduce volatility and improve forecasting. For product leaders and founders, the choice isn’t binary—it’s about aligning monetization with your value metric and customer workflows.
We also unpacked hybrid and tiered pricing—approaches Stripe has implemented at scale. I shared how I evaluate when to layer a base platform fee with consumption pricing or when to use tiered pricing to segment by feature depth, compliance, and support. Her guidance reinforced my belief that hybrid pricing can de-risk adoption while preserving upside as customers grow.
One concept resonated deeply: treat pricing like a product. In practice, this means clear ownership, an experimentation roadmap, instrumentation, and tight feedback loops across product, finance, sales, and RevOps. She described how this shows up in Stripe’s org design, and I mapped that to my own operating model: a cross-functional pricing council, standardized experiment briefs, and monthly pricing reviews.
We compared notes on pricing experiments with outsized impact—reframing value metrics, simplifying SKUs, right-sizing tiers, and re-bundling add-ons. I emphasized a principle I rely on: reduce cognitive load to increase conversion. Small shifts—like renaming tiers to reflect outcomes rather than features—consistently improve trials, win rates, and expansion.
A steady drumbeat of customer feedback is the backbone of great pricing. We discussed tactics that work: structured win/loss, in-product pricing prompts, targeted customer advisory boards, and lightweight conjoint or price-sensitivity surveys. I also use sales call listening tours and cohort-level NRR analysis to validate whether a pricing change improved time-to-value without spiking support burden.
For founders, pricing is both art and science. The science is your data model, market benchmarks, and experimental rigor. The art is timing, narrative, and how pricing supports your go-to-market motion. Whether you’re a small startup or a larger company, start with a clear hypothesis, ship iteratively, and build the organizational muscle to revisit pricing quarterly—not once a year.
Throughout our conversation, the examples from Stripe brought the playbook to life, from usage-based mechanics to tiered packaging that scales with enterprise needs. If you’re in sales or just starting to think about pricing your product, these insights will help you align monetization with value, accelerate adoption, and expand more predictably.
I sat down with Douglas Hanna, Chief Operating Officer at Grafana Labs. Grafana Labs is an observability stack built around Grafana, a leading open-source technology for dashboards and visualization.
Douglas is a seasoned revenue leader, previously leading operations and GTM strategy at Zendesk. At Grafana Labs, Douglas has been instrumental in scaling GTM at the open-source company — building up both team headcount and its revenue model.
In our conversation today, Douglas dives deep into the process of bringing products to market at an open-source company. That focus on disciplined go-to-market execution resonates with my own experience building product-led motions that respect the community while establishing clear, sustainable paths to revenue.
We explore the different facets of building and scaling a revenue model at an open-source company. Douglas opens up the GTM playbook at Grafana Labs sharing: I found these principles especially actionable for open source monetization, SaaS pricing, and zero to one B2B marketing.
“When to commercialize a feature vs. switch to a hosted version of a product” — In practice, I look for telltale signals: features that impose heavy operational burden (security, scale, multi-tenant reliability), generate significant infrastructure or support costs, or require advanced governance. That’s when a hosted version can deliver outsized value. For individual features inside the core, I favor commercialization only when the value metric is unambiguous and the user experience remains seamless for the community. The key is a clear migration path from self-managed to hosted, with pricing aligned to usage or outcomes.
“Tried and tested frameworks for pricing and packaging” — I anchor on a few staples: value metrics that correlate with customer outcomes, willingness-to-pay testing, and the 3C lens (customer, competition, company). For packaging, a tiered “good/better/best” model helps segment needs, while usage-based or consumption pricing can unlock elasticity for developer-led adoption. I’ve seen price fences (SSO, RBAC, advanced analytics, scale limits) work well when they map to enterprise readiness rather than core functionality.
“How Grafana Labs thinks about what to put behind a paywall” — I share the same philosophy: keep community-loved, foundational capabilities open to preserve trust and growth, and place enterprise-grade scale, compliance, and governance behind the paywall. This often includes SSO/SAML, audit logs, granular access controls, advanced alerting, longer retention, and premium SLAs. The litmus test is whether the paywalled capability primarily serves larger teams’ risk, reliability, and control requirements.
“How the GTM team was built over time” — The sequencing matters. Early on, lean into product-led growth with strong developer evangelism, documentation, and onboarding. As adoption accelerates, add sales-assist, solutions engineering, and forward deployed engineers to convert complex use cases. Over time, layer in customer success, pricing operations, and ecosystem partnerships. Hiring profiles evolve from generalists to specialists, but the connective tissue remains a tight loop between product, community, and revenue.
Throughout our discussion, I appreciated the rigor in tying pricing and packaging decisions to measurable value, while safeguarding the open-core experience. That balance is the difference between short-term monetization and durable category leadership in observability.
You can follow Douglas on Twitter at @douglashanna.
If you’re building or scaling an open-source business, these GTM patterns provide a pragmatic blueprint: lead with community, monetize enterprise needs, and align pricing to real-world usage. It’s a playbook that rewards trust, clarity, and iteration — and it’s one I’ve seen drive repeatable growth when executed with discipline.
I’m often asked how to win when your product strategy spans both open source and closed source. My short answer: treat community, product, and go-to-market as one system, then sequence each move with ruthless clarity. Reflecting on Neha Narkhede’s journey helped crystallize a practical playbook for building, monetizing, and scaling category-defining platforms.
Neha Narkhede is a co-founder at Confluent, a data streaming software that raised at a $9.1b valuation in 2021. Neha later co-founded Oscilar, a no-code platform that helps companies detect and manage fraud. Before building these two companies, Neha was a Principal Software Engineer at LinkedIn where she co-created Apache Kafka. Neha is ranked #50 on Forbes’ list of “America’s Richest Self-Made Women 2023” with an estimated net worth of $520m.
Here’s what stood out to me as a product leader: the origin of Apache Kafka inside LinkedIn wasn’t just a technical breakthrough—it was an obsessive response to a clearly defined, acute infrastructure pain. Open sourcing it wasn’t a marketing move; it was a distribution masterstroke that built trust, accelerated adoption, and seeded a future enterprise business.
On company-building, the “Zero to One” at Confluent was uniquely disciplined: build for a specific customer early on, earn credibility with developers through education and evangelism, and simultaneously position as an enterprise-grade solution. I’ve seen this duality—developer-first credibility with enterprise posture—unlock velocity in complex platform markets.
Monetizing open source product works when you’re intentional about what to license and what to open source. Commercial value clusters around enterprise security, governance, scalability, observability, and reliability features—plus SLAs customers can’t get from the community. That’s how you can run two businesses within one company: a software business and a SaaS business that remove operational burden and expand the addressable market.
Confluent’s approach to SaaS versus software is instructive. Confluent Cloud delivers a consumption SaaS model where pricing aligns to value realized, not just time elapsed. Subscription SaaS versus consumption SaaS requires different GTM motions, different product telemetry, and different revenue operations. I’ve found success by matching pricing units to customer mental models and by instrumenting usage early to drive product-led expansion.
Developer evangelism played a pivotal role in category creation. It’s not merely about talks and tutorials—it’s a systematic way to collapse time-to-value, reduce perceived risk, and compress a buyer’s learning curve. When you blend education with hands-on pathways—demos, sandboxes, quickstarts—you transform top-of-funnel curiosity into bottom-of-funnel conviction.
Founder-led GTM was another powerful theme. Early on, I prioritize direct customer conversations, hands-on discovery, and live deal support. The order of operations matters: validate the ICP, close lighthouse customers, codify the repeatable sales narrative, then operationalize outbound once the signal-to-noise ratio is high. That sequence prevents premature scaling and preserves momentum.
For second-time founders, the takeaway is focus and speed. Build differently the second time by compressing cycles from speculation to product realization. Neha’s “proactive research sprint” resonates with my own practice: pressure-test the problem, define must-have requirements with real users, and ensure you’re solving problems people are actually willing to pay for—before building full-stack.
Oscilar exemplifies this clarity. A no-code platform to detect and manage fraud aligns to an urgent, quantifiable pain with measurable ROI. That’s founder-market fit: where your experience, the market’s urgency, and the product’s capabilities directly reinforce one another.
If you’re navigating open source and SaaS together, here’s the practical synthesis I use: define your ICP early; decide what to open source versus license based on enterprise risk and operational burden; invest in developer experience and evangelism to power category creation; choose pricing that mirrors value realization (consumption when possible); and keep founder-led sales at the forefront until the narrative is truly repeatable. Done well, you can run two businesses inside one company without diluting focus.
