Tag: competitive differentiation

  • Competing on Experience: A Retail Banking Product Strategy

    Competing on Experience: A Retail Banking Product Strategy

    A rate promotion can win a comparison. It cannot, by itself, make a customer trust your bank as the place where their financial life should run. If you are deciding where retail banking growth should come from, separate the offer that gets attention from the experience that earns the primary relationship.

    That distinction changes the roadmap. The competitive front is moving beyond rate and toward experience. The practical question is not whether user experience matters. It is which moments change customer behavior, which failures weaken trust, and how you improve those moments without compromising security, compliance, or financial value.

    Experience is the banking system, not the app’s finish

    Retail banking experience is often reduced to interface quality: fewer taps, cleaner screens, faster navigation, and more polished personalization. Those things matter, but they are only the visible layer.

    The real experience is the customer’s ability to achieve a financial outcome and remain confident about what happened. It includes product rules, identity checks, transaction processing, status messages, notifications, support handoffs, fraud controls, and back-office resolution. A payment blocked in the app, explained by a contact-centre agent, and resolved by an operations team is one customer experience, even if three departments own it.

    This is why experience-led competition is not a choice between price and design. An uncompetitive product cannot be rescued by a delightful interface. A confusing or unreliable experience can still destroy the value of a good rate. Product value earns consideration; the surrounding experience determines whether customers can understand, access, and continue using that value.

    A useful experience test asks whether a customer can:

    • Complete the intended job safely, without avoidable repetition or channel switching.
    • Understand the current status, including pending, failed, restricted, or completed states.
    • See what will happen next, what action is required, and who owns the next step.
    • Resume the journey without re-entering information the bank already has.
    • Get an appropriate human handoff when self-service is no longer the right path.
    • Recover from an exception with the same clarity as the happy path.

    If your roadmap mainly improves navigation while these underlying conditions remain broken, you are decorating operational friction. The more durable advantage comes from building a system that can detect a failing journey, explain why it is failing, change it safely, and measure whether customer and business outcomes improved.

    Compete where uncertainty and consequence meet

    Customers do not experience your organizational chart. They arrive with an intent: open an account, move money, understand a balance, protect a card, resolve a problem, or make a financial decision. Map the experience around those intents rather than around pages, features, or departmental ownership.

    The highest-leverage moments tend to combine uncertainty with consequence. A cosmetic inconsistency may be annoying. An unexplained transfer status can make a customer unsure whether to wait, retry, contact support, or move money another way. That uncertainty creates repeat actions, operational work, and avoidable risk.

    Customer momentQuestion the experience must answerSignals of failureUseful measures
    Opening and funding an accountIs my account ready, and what must I do next?Repeated verification, unexplained waiting, abandonment, or an opened but unfunded accountVerified-and-funded completion, time between milestones, repeat attempts, and assisted contacts
    Moving moneyDid the payment or transfer go where I expected?Duplicate submissions, repeated status checks, reversals, or support contactsFirst-attempt completion, repeated actions, status comprehension, and exception resolution
    Understanding activityWhat happened to my money, and is action required?Ambiguous labels, repeated transaction views, unnecessary disputes, or channel switchingSelf-resolution, help-seeking behavior, dispute initiation, and successful next action
    Handling an exceptionAm I protected, who owns this, and when will I hear more?Multiple handoffs, repeated explanations, contradictory status, or unresolved follow-upResolution completion, handoffs, repeat contacts, status visibility, and recurrence
    Considering another productIs this relevant to my need, and do I understand the commitment?Generic offers, confused eligibility, abandonment after disclosure, or acceptance without meaningful useEligible journey completion, comprehension signals, post-acceptance use, and complaints

    Use this map to choose investments. Do not start with the most visited screen or the loudest internal request. Start with a customer moment where failure has a meaningful consequence and where the bank has enough evidence and control to improve the outcome.

    You also need to distinguish necessary friction from accidental friction. Identity verification, security challenges, disclosures, and eligibility checks may be essential. The product problem is not simply to remove them. It is to remove ambiguity, redundant work, dead ends, and unexplained waiting while preserving the control itself.

    That distinction prevents a common mistake: treating completion speed as the only definition of good experience. A slightly longer journey can be better if it improves understanding or prevents a harmful error. A shorter journey can be worse if customers complete it without knowing what they agreed to. Optimize for a safe, understood outcome rather than minimum interaction at any cost.

    Measure behavior, not a vague experience score

    A single experience score is attractive because it makes portfolio reporting easy. It is weak as a product-management instrument. The average can improve while an important customer group gets stuck, and it rarely identifies what a team should change next.

    Build a measurement hierarchy for each priority journey instead:

    1. Customer outcome: Did the customer complete the intended financial job and understand its result?
    2. Journey quality: How many retries, backtracks, unexplained waits, handoffs, help requests, and channel switches occurred?
    3. Trust and risk guardrails: Did errors, complaints, disputes, fraud exposure, accessibility failures, or regulatory incidents change?
    4. Business effect: Did the improvement lead to appropriate activation, ongoing use, retention, relationship growth, or lower avoidable service demand?

    This order matters. If a redesigned onboarding step gets more clicks but does not produce more ready-to-use accounts, the local conversion is not the outcome. If contact volume falls while abandonment rises, the experience did not improve; customers may simply have stopped asking for help. If a faster transfer flow increases mistaken submissions or disputes, speed came at the expense of safety.

    Do not mistake activity for customer value

    Several familiar digital metrics are ambiguous in banking:

    • More logins can indicate engagement, but they can also indicate anxiety about an unresolved transaction.
    • Longer sessions can reflect exploration, but they can also mean that information is hard to find.
    • Higher self-service can indicate convenience, but only if customers complete the job rather than abandon it before contacting the bank.
    • Faster completion is useful only when comprehension, accuracy, security, and accessibility remain intact.
    • Feature adoption matters only when the feature helps customers reach an outcome and supports a legitimate business result.
    • Overall satisfaction can reveal direction, but an aggregate score usually cannot diagnose a specific broken journey.

    Read these measures in context. Pair activity with state, intent, and downstream behavior. A customer who repeatedly checks a pending payment belongs to a different behavioral pattern from one who regularly reviews a completed monthly statement, even if both produce the same page-view event.

    Segment by the journey conditions that change the experience

    An average funnel can hide the problem you need to solve. Break the journey down by factors such as entry channel, new versus established relationship, first attempt versus repeat attempt, product held, authentication path, assisted versus unassisted completion, and exception type. Use customer attributes only when their use is lawful, necessary, governed, and appropriate for the decision.

    For each segment, look for a behavioral chain: the change you made, the immediate behavior it should influence, the customer outcome that should follow, and the business effect you expect. Name a guardrail beside that chain. This turns an experience idea into a testable product hypothesis rather than an aesthetic preference.

    Build a product operating system for experience improvement

    Experience-led competition depends on the speed and quality of organizational learning. A bank will not create that capability through a collection of isolated redesign projects. You need a repeatable path from customer problem to evidence, intervention, safe release, and measured outcome.

    1. Choose one consequential customer moment. Use complaints, service reasons, journey abandonment, operational exceptions, and business performance to locate a problem. Write down why this moment matters to the customer and the bank.
    2. Define an outcome contract. State the job the customer must complete, the status they must understand, and the controls that cannot be weakened. Include required disclosures, security conditions, accessibility needs, and the fallback path when digital completion is inappropriate.
    3. Draw the service blueprint. Map the visible steps together with decision rules, systems, queues, messages, handoffs, and manual operations. Mark ownership at every transition. This exposes failures that a screen-by-screen journey map cannot show.
    4. Instrument the journey safely. Create stable events for meaningful states such as journey started, verification submitted, status displayed, action completed, help requested, assisted handoff, and case resolved. Do not place account balances, credentials, free-form customer text, or unnecessary personally identifiable information in analytics events. Apply your institution’s privacy, security, retention, and regulatory controls before collection.
    5. Combine behavioral and operational evidence. Funnels and journey paths show where behavior changes. Support reasons, complaints, accessibility feedback, and operational exceptions help explain why. Review them together so the team does not optimize a digital metric while moving the problem into another channel.
    6. Prioritize by consequence and evidence. Consider customer harm or inconvenience, business effect, strength of evidence, frequency, controllability, dependencies, and implementation risk. Avoid a false-precision scoring formula when the underlying evidence is weak.
    7. Test within explicit guardrails. A/B testing can help evaluate navigation, explanation, sequencing, prompts, or other reversible presentation choices. Do not use experimentation to weaken security, vary legal entitlements, obscure fees or rates, bypass required disclosures, or produce unfair treatment. Obtain the necessary risk, compliance, legal, and accessibility review, release through controlled exposure where appropriate, and prepare a rollback path.
    8. Review the full outcome after release. Check the customer outcome, journey diagnostics, risk guardrails, and business effect. Then inspect important segments for uneven results. A local lift is not a win if the end-to-end journey, a vulnerable segment, or an operational queue deteriorates.

    Treat service recovery as a product surface

    Many roadmaps stop at the moment an automated journey fails. The customer experience does not. Recovery should be designed with the same care as onboarding or payments.

    A useful recovery design preserves context across channels, gives the customer a stable case or transaction status, identifies the next owner, explains what the customer needs to do, and closes the loop when the case changes. It should also distinguish between a person who needs reassurance, one who must provide information, and one who requires immediate specialist help.

    Measure the journey from the original intent through resolution. A digital team should not claim success because a customer left the app if the customer then had to repeat the story to multiple agents. Equally, a support contact is not automatically a failure; for a consequential or complex situation, a timely and informed human intervention may be the right product outcome.

    Fund the capabilities that improve multiple journeys

    Portfolio reviews tend to favor visible features because they are easy to present. Experience advantage often depends on less visible foundations: a consistent status model, reusable identity and permission services, cross-channel case context, notification preferences, governed event definitions, experimentation controls, and reliable links between digital behavior and operational resolution.

    These capabilities should not become open-ended platform programs. Tie each one to a priority customer journey, prove that it improves an outcome, and then reuse it. That creates compounding value without asking the organization to fund infrastructure on faith.

    Product leadership also needs clear decision rights. Product owns the intended customer and business outcome. Operations owns the viability of manual paths and queues. Service teams contribute failure reasons and recovery evidence. Data owners govern definitions and access. Risk, compliance, legal, security, and accessibility partners define constraints and review consequential changes. Shared ownership should clarify the decision, not create a committee in which nobody is accountable.

    Key takeaways

    • A competitive rate or fee can attract attention, but the end-to-end experience determines whether customers can realize that value and keep using the relationship.
    • Manage journeys around customer intent, including operational handoffs and recovery, rather than optimizing isolated screens or departmental metrics.
    • Prioritize moments where uncertainty has a meaningful customer or business consequence.
    • Measure customer outcomes, journey quality, trust and risk guardrails, and business effects as a connected hierarchy.
    • Do not treat logins, session time, self-service, feature adoption, or a single satisfaction score as proof of value without behavioral context.
    • Use experimentation for reversible experience choices within explicit legal, security, accessibility, fairness, and compliance constraints.
    • Invest in reusable journey capabilities only when a priority customer outcome gives them a concrete reason to exist.

    At your next roadmap review, ask every retail banking initiative to name the customer moment, observable behavior, end outcome, business effect, and non-negotiable guardrail. If it cannot, it is not yet an experience strategy. Start with the journey that creates both customer uncertainty and operational work, repair that system end to end, and use what you learn to improve the next one.

    References

  • Crafting Beloved Tech Brands: My Moonshot Marketing Playbook for the Post-LLM Era

    I spend a lot of my time asking a deceptively simple question: what does excellent marketing actually look like in 2026? From the vantage point of product leadership, the answer isn’t a spreadsheet or a channel plan—it’s a feeling. Beloved tech brands earn the benefit of the doubt, create gravity around their roadmap, and make customers proud to belong. That kind of momentum is not an accident; it’s a system.

    Here’s the hard truth I’ve learned building and scaling products: giving teams different goals creates dysfunction. When brand, demand gen, product marketing, and comms run on fragmented OKRs, you manufacture internal headwinds. “Marketing is one engine – not separate pieces.” One strategy, one narrative, one set of outcomes—expressed through different craft disciplines and time horizons.

    That unity of purpose clarifies executive roles, too. The real difference between an SVP and a CMO is scope and narrative ownership. A great CMO architects the whole system—portfolio allocation, brand architecture, integrated go-to-market strategy, and the bar for creative taste—while refusing to get dragged into decisions they should never be making (for example, approving every headline or micromanaging channel tactics). Leaders should decide the outcomes, standards, and constraints; teams should control the craft.

    On portfolio design, I run marketing like a portfolio of moonshots. You need a healthy mix: proven programs that compound, emergent bets that learn fast, and a small set of true moonshots that can change the slope of the curve. The point isn’t bravado; it’s risk-balanced exploration. If everything ships safely, you’re under-investing in differentiation. If everything is a swing for the fences, you’re not building a repeatable growth engine.

    This is where taste becomes a strategic advantage. “Ubiquity is the opposite of cool.” If you want to be beloved, you cannot treat every channel, audience, and moment as equal. Early on, selective distribution, distinctive creative codes, and tight community loops create status and meaning. Later, you scale without sanding off the edges that made the product special.

    Why do a few companies build a flywheel of momentum while others stall? They align story, product, and distribution. The product earns trust, the narrative creates aspiration, and the go-to-market strategy ensures the right customers experience both at the right time. Then perception cycles kick in—the Silicon Valley clock turns—and irrational optimism or skepticism can amplify signals. The antidote is compounding proof: consistent product shipping, community advocacy, and creative that makes people care.

    Scaling taste across an organization is teachable. I codify brand principles, narrative guardrails, and examples of “right” versus “almost right.” I replace abstract feedback with decision rubrics—what we keep, kill, or revise and why. I run recurring creative reviews with a small cross-functional council, so judgment compounds. Taste can’t be fully automated, but it can be operationalized: shared references, a story bible, and a high bar for craft that’s explicit, not mystical.

    In a post-LLM world, the fundamentals haven’t changed—but the frontier has. Generative tools supercharge iteration and research, yet the artistry never really left. You still need a point of view, a tension worth resolving, and a value proposition that’s felt, not just stated. Can taste be encoded in software? Parts of it—pattern libraries, style constraints, data-driven feedback—absolutely. But the spark that makes work unforgettable remains human: judgment, risk tolerance, and the courage to ship something that might not fit the playbook.

    That’s why telling an optimistic, yet realistic story about AI matters. Over-automation drains humanity; under-automation wastes potential. The best work pairs AI Strategy with craft leadership: LLMs for rapid exploration, humans for narrative decisions and ethical judgment. Your message should show how AI expands customer agency, not just efficiency.

    The brand-versus-growth debate is a false choice. The right story accelerates pipeline, and the right demand programs reinforce the brand. Look at Apple’s discipline around product truth and design codes, or Google Chrome’s “The Web Is What You Make of It (Dear Sophie)” for proof that emotion and utility can co-exist. Notion, Pinterest, Square, HubSpot, and Harley-Davidson show how community, identity, and product-led growth interlock when the company knows exactly what it stands for.

    When it comes to launches, I’ve learned that announcement videos full of humans, lack humanity. Overproduced gloss often dilutes the truth customers seek: what problem does this solve, how quickly can I feel the value, and why does it matter now? Real users, real context, and a crisp arc from problem to promise will outperform most theatrics.

    Practically, I architect my week to protect taste and outcomes. Early-week for strategy, portfolio reviews, and cross-functional alignment; mid-week for deep creative and product marketing work; late-week for decision clears and postmortems. I time-box “disruptive energy”—space to chase non-obvious ideas—and I guard it like any critical meeting. Without protected cycles for exploration, the urgent will always suffocate the important.

    If there’s a single takeaway: playbooks are obsolete, but the fundamentals are not. The channels change; the psychology doesn’t. Run one engine. Allocate a true portfolio. Scale taste with rigor. In the AI era, make people care. That’s how beloved tech brands are built—and how they endure.

    Book a consult png image
  • What the Intercom-to-Fin Rebrand Teaches Product Leaders

    What the Intercom-to-Fin Rebrand Teaches Product Leaders

    If you are deciding whether an AI product should become your company name, you probably do not have a naming problem. You have a portfolio commitment problem. The rename will make your bet visible, but it will also force you to explain what existing customers still own, what will keep improving, and what now defines the company’s future.

    The Intercom-to-Fin move offers a clean way to think about that decision. The company is now named Fin, while Intercom remains its customer service software platform; Intercom 2 has also launched as a complete rebuild with continued investment behind it. The growth brand moves up to the corporate level without erasing the durable product brand beneath it. That is the strategic work of this rebrand.

    The decisive choice is what you do not rename

    The most important word in this rebrand is not Fin. It is “remains.” Intercom remains a product, a customer commitment, and a place where the company can keep creating value. Fin becomes the corporate identity and the clearest expression of the next growth thesis.

    Changing the company name while retaining the established product name is not an incomplete rebrand. It is deliberate brand architecture. The two names answer different customer questions:

    • The company brand answers: What future is this organization building toward?
    • The product brand answers: What can I buy, operate, renew, and rely on today?
    • The category brand answers: What new capability should I understand, budget for, and compare with alternatives?

    Those answers do not always belong under one name. Forcing them together can make the new strategy sound smaller than it is or make the established product appear to be on its way out. Keeping Intercom as the platform avoids turning corporate ambition into accidental product deprecation.

    Before approving a similar rename, write a transition contract. This is not a legal document. It is a short internal statement that every product, sales, marketing, support, recruiting, finance, and communications leader can use without improvising. It should answer:

    1. Exactly which entity is being renamed?
    2. Which products keep their current names?
    3. What changes for an existing customer because of the rename?
    4. What explicitly does not change?
    5. Where will investment increase, continue, or decline?
    6. How should someone describe the relationship between the company and each product?

    If the answers vary by executive, your organization is not ready to communicate the rename. Customers will encounter every inconsistency as a separate strategic story.

    A new category needs a clean place in the buyer’s mind

    Established brands are efficient because buyers use them as shorthand. The same shorthand becomes restrictive when a company wants to define a substantially different category. People do not continuously reassess every vendor from first principles. They attach new information to what they already believe.

    That is why a legacy name can create friction even when it has strong awareness and customer trust. The problem is not that buyers dislike the old brand. The problem is that they already know where to file it. Every pitch for the new category begins with a correction: the company you associate with one product is now asking you to understand it as something else.

    Fin had time to develop as a distinct service-agent identity before becoming the company name. The business introduced Fin three years before the corporate rename and deliberately led with that name while keeping Intercom in the background. That sequence matters. It allowed the category proposition to earn meaning before the corporate identity was placed behind it.

    You should look for the same underlying evidence before elevating a product brand:

    • Prospects ask for the new product or category by name instead of treating it as another feature of the established platform.
    • The product has a distinct job, competitive set, buying conversation, and roadmap.
    • Your largest resource-allocation decisions increasingly revolve around the new category.
    • The existing company name repeatedly requires explanation before buyers understand the new proposition.
    • The legacy product can remain a coherent, investable business under its own name.
    • Leadership is willing to keep prioritizing the category when it competes with comfortable, near-term work elsewhere in the portfolio.

    Wait if the new product still depends almost entirely on legacy demand, if “AI” is the only thing making it sound like a new category, or if leaders cannot explain the future of the existing portfolio. A corporate rename should settle a strategic truth that is already visible in the product and resource decisions. It cannot manufacture that truth.

    Test the strategy before you test the name

    Name preference is the least important question at the start. A memorable name cannot rescue an unstable thesis, and a room full of favorable reactions cannot prove that the proposed architecture makes sense. Test the decisions the name is meant to encode.

    Strategic permanence

    Ask whether the new identity can survive normal product evolution. A company named after a feature will eventually outgrow its name. A company named for a durable category, customer outcome, or long-term platform has more room to expand.

    Pressure-test the choice against plausible roadmap changes. If the current interface changes, the underlying models improve, or the product expands into adjacent workflows, does the name still represent the company? If one disappointing planning cycle would make leadership retreat to the old story, the corporate rename is premature.

    Customer comprehension

    Do not ask customers whether the new brand “makes sense.” That question invites politeness. Show them the proposed naming hierarchy without an explanation and ask them to describe:

    • What the company does.
    • What they can buy.
    • What happened to the existing product.
    • Which name they expect to see in the application, documentation, support experience, and commercial relationship.
    • Whether the new offering feels like a feature, a product, a platform, or a category.

    The vocabulary in their answers matters more than a preference score. If customers merge the company and product into one ambiguous object, the hierarchy needs work. If established customers assume their product is being replaced, the continuity story is too weak. If prospects still describe the company only through the old category, the new position has not yet become legible.

    Portfolio durability

    Every product affected by the rename needs a stated fate: promoted, retained, integrated, or retired. Silence creates its own answer, and customers usually interpret it as declining commitment.

    The Intercom-to-Fin architecture avoids that ambiguity. The corporate brand follows the AI growth engine, while the established platform receives a rebuilt product and continued investment. You can apply the same discipline by requiring a roadmap, owner, customer promise, and success measure for every brand that survives the transition.

    Operating commitment

    A company name is a resource-allocation claim. Check whether hiring plans, executive attention, roadmap capacity, sales enablement, partner priorities, and operating metrics already support the future implied by the name.

    This is where weak rebrands reveal themselves. The homepage changes, but planning continues to favor the old center of gravity. Sales compensation rewards the previous motion. Product teams keep describing the AI offer as an add-on. Recruiting language promises one future while internal goals fund another. If those contradictions remain, the market will believe the operating behavior rather than the new identity.

    Turn the rebrand into an operating model

    A corporate rename touches more than brand assets. It changes the nouns people use to make product, commercial, and technical decisions. Treat it as a cross-functional migration with a defined architecture, owners, dependencies, and observable failure modes.

    Before launch, remove internal ambiguity

    Start with an inventory of named objects. Separate the corporate brand, legal entity, product names, application name, AI agent, domains, documentation, status pages, integrations, partner listings, support channels, and customer-facing team names. They may not all change together, and some should not change at all.

    Create a controlled vocabulary for each object. Record the approved name, a plain-language definition, the transition phrase, phrases to avoid, and the person responsible for exceptions. Then apply it to roadmap documents, release notes, sales materials, onboarding, job descriptions, support macros, analytics labels, and executive reporting. This prevents each function from inventing a slightly different portfolio.

    Keep the public brand change separate from legal and payment instructions. A new display name does not automatically mean that the contracting entity, tax information, or bank details changed. Telling customers to update those records without confirmation can create payment failures, procurement delays, and fraud risk. Legal and finance owners should identify any real operational changes and communicate them through established, verifiable channels.

    Build the customer FAQ from actual consequences, not brand language. Cover logins, existing contracts, invoices, data handling, support access, integrations, domains, saved links, product roadmaps, and administrative work. For every item, say whether action is required. “No action required” is useful only when you have verified it across the relevant systems.

    At launch, separate ambition from continuity

    Lead with the scope of the change. Say which name belongs to the company, which belongs to the existing product, and how the new category fits. Then explain why the corporate identity is changing. Follow that with a precise account of what existing customers should expect.

    Do not rely on “nothing changes” as reassurance. It is usually too broad to be credible, especially when a new product strategy and increased investment are central to the story. Name the stable elements instead: the product that remains, the workflows that continue, the commitments that persist, and any interfaces or commercial records that stay the same.

    Use the same architecture everywhere a customer can encounter the company. A clear launch page cannot compensate for an application header, help center, invoice, partner marketplace entry, or sales deck that implies a different relationship. Transitional wording can help connect the names, but it should have an exit condition rather than becoming permanent clutter.

    After launch, measure the translation tax

    Launch reach tells you that people saw the rename. It does not tell you that they understood it. Establish a pre-launch baseline where possible, then monitor evidence of confusion:

    • Support conversations asking whether the existing product is being discontinued or replaced.
    • Sales calls in which representatives must repeatedly correct the company-product relationship.
    • Documentation searches that mix old and new names in ways your information architecture does not handle.
    • Broken redirects, failed bookmarks, authentication problems, or integration errors caused by changed domains or labels.
    • Procurement and accounts-payable questions about the company name, contracting entity, or invoice sender.
    • Prospect descriptions of the category after encountering the new positioning.
    • Retention, adoption, and expansion for the established product, tracked separately from awareness of the new corporate brand.

    Review the language in those interactions, not just their volume. The words customers use will show whether the new mental model has formed. Retire transition copy only when support, sales, search, and customer interviews indicate that people can move between the names without assistance.

    Key takeaways for your own portfolio decision

    • The Fin corporate name expresses the future growth bet; retaining Intercom protects a valuable product identity and signals continued commitment.
    • A corporate rename is a brand-architecture and resource-allocation decision, not a cosmetic marketing project.
    • Elevate a product name only when the category, roadmap, buying conversation, and operating priorities already support it.
    • Tell customers exactly what is renamed, what remains, what changes, and whether they need to act.
    • Validate comprehension with unscripted customer explanations, not name-preference questions.
    • Measure confusion across support, sales, documentation, procurement, integrations, and product health after launch.

    If this decision is in front of you, bring a one-page transition contract to your next portfolio review. Ask product, sales, support, legal, finance, and recruiting to describe the company and its products using the same nouns. If they cannot, keep working on the architecture. If they can, and your resource allocation already matches the story, the rename can do its real job: make the strategy easier for the market to understand.

    References

  • Never Stop Disrupting: Why the Fin API Platform Signals a New Era for Agentic AI

    Never Stop Disrupting: Why the Fin API Platform Signals a New Era for Agentic AI

    Disruption is the only sustainable strategy in product. When a platform meaningfully changes how we build and operate, I pay attention—not just as a product leader, but as someone accountable for turning AI Strategy into durable competitive differentiation. That’s why the launch of the Fin API platform stands out: it’s a concrete step toward agentic AI at enterprise scale.

    Today, I’m diving into what this launch includes, why it matters for product strategy, and how I’d navigate the build vs buy decision in this new landscape. My goal is to translate the announcement into actionable guidance for product teams, CX leaders, and forward-deployed engineers who are building the next generation of customer support and product-led experiences.

    Fin is a customer agent platform that at present resolves over 2M customer issues a week, growing at a rapid exponential pace. It’s relied on by the best brands, large and small, in every vertical you can imagine. From Atlassian and Riot Games, to smaller hot upstarts like Mercury and Polymarket. It runs on a family of models trained by its AI group. Last week, they announced Apex, which is the world’s first specialized customer service LLM. In production tests over the last 6 months, it beat every single frontier model, including those from Anthropic and OpenAI, on resolution rate, latency, hallucination rate, and cost.

    With this launch, teams can access the platform’s core capabilities and underlying models directly via API, with contracts starting at $250k per year, and usage rates that are by far the cheapest in the industry for each of the model’s subcategories. For leaders evaluating total cost of ownership, this is a meaningful data point: it shifts the economics of scaled automation from experimental to operational.

    Why now? Because builders want options. I hear from teams daily that want to design their own agents, tune prompts and policies, and integrate with bespoke CRMs, data lakes, and product surfaces. The Fin announcement meets that demand with three clear build-paths, each mapping to a different operating model and maturity stage.

    First, for the vast majority of companies, the Fin Agent Platform is the pragmatic starting point. Fin reports ~8k companies on it today. It addresses 99% of customer needs out of the box—without exhausting consulting engagements—while delivering top-tier resolution rates. If your priority is time-to-value, governance, and platform scalability, this route de-risks implementation and accelerates outcomes.

    Second, for teams that need custom surfaces or channels, the Fin Agent API lets you present Fin in unique contexts. You get the Fin platform’s orchestration and controls, but you’re free to bypass the default messenger, email, voice, or any prebuilt channel and embed the agent natively in your product. I see this as the sweet spot for product-led growth motions where conversation design and UX writing are strategic levers.

    Third, for companies building hyper-specific agents—think service plus in-product actions—the new API access to Apex and the broader collection of models is the obvious move. Unlike generalized models, these are purpose-trained for customer service scenarios and operational policies. If you have strong in-house solutions engineering, a retrieval-first pipeline, and eval-driven development in place, this path maximizes control without reinventing the model layer.

    This also opens the door for vertical specialists. Fin-like businesses focused on deep domains can emerge quickly—Fin for dentists? Why not? Fin for car dealerships? Sure. I expect startups and modern CX providers (including players like Decagon and Sierra) to carve out niches where domain data, workflows, and compliance are the real moats. That’s where differentiated AI beats generic capability.

    There’s a defensive reason to pay attention here. The software landscape is shifting fast: the moat is no longer feature parity—it’s the quality of your agents and the data flywheels powering them. Building software is simply less hard now, and I’ve watched engineering teams more than double measurable productivity as they adopt AI-assisted development. The implication is clear: the interface-and-features era is giving way to an agents-and-outcomes era.

    Serious software companies must evolve from being a features company to an agents company—and build those agents on differentiated AI. More value will accrue at the model and orchestration layers, where safety, latency, cost, and resolution quality are won. That puts a premium on prompt engineering discipline, policy routing, continuous discovery of edge cases, and rigorous offline/online evals to keep hallucination rates low while maintaining speed.

    How would I choose among the three build-paths? If you’re early or resource-constrained, start with the Fin Agent Platform to validate outcomes and align stakeholders. If you need branded experiences and tighter product integration, use the Fin Agent API to control surfaces without owning the heavy lifting. If you have strong ML ops and a mature customer support ai strategy, go model-level with Apex and companions, layering in your own guardrails, context window management, and test harnesses. In each case, balance velocity, control, and risk—your build vs buy decision should be grounded in clear metrics and an explicit product strategy.

    Where does this lead? We’ll see more companies expose specialized model families with clearer economics and stronger governance. For now, I’m excited to see what teams build with the Fin API platform—and how they turn agentic AI into measurable improvements in resolution rate, CSAT, cost-to-serve, and ultimately, customer loyalty.

    Inspired by this post on The Intercom Blog.

    Book a consult png image
  • Apex Arrives: Vertical AI That Beats GPT-5.4 on Customer Service Speed, Accuracy, and Cost

    Apex Arrives: Vertical AI That Beats GPT-5.4 on Customer Service Speed, Accuracy, and Cost

    I just watched one of the most significant leaps in customer service AI in years. Last week, a quiet but seismic release landed in CX: Fin introduced Apex, a vertical model purpose-built for support that raises the bar on speed, accuracy, and cost. As a product leader, this is exactly the kind of breakthrough that changes roadmaps, vendor strategies, and what customers can expect from modern service operations.

    It’s a brand new model for Fin called Apex, and it’s objectively the highest performing, fastest, and cheapest model for customer service. It beats the very best models in the industry including GPT-5.4 and Opus 4.5.

    In this analysis, I’ll unpack why the launch matters for the customer service agent category, what it signals for frontier labs and open‑weight ecosystems, and how leaders should rethink their AI Strategy, build vs buy decisions, and eval-driven development roadmaps.

    Fin was already the highest performing and most sophisticated agent in the customer service space, consistently beating impressive competitors like Decagon and Sierra at an average win rate in the 70s. It operates at tremendous scale, now resolving almost 2M customer issues per week, a number that’s growing at an exponential clip. In its short life it’s grown to nearly $100M in recurring revenue.

    As of last week, ~100% of all (English language, chat and email) customer conversations are now running on Apex. Since day 1, the Fin engine has comprised a system of models, and last year the team began replacing off‑the‑shelf models with custom ones trained on proprietary data. The core answering model had been a frontier labs offering—initially versions of GPT and more recently Sonnet 4.0. Now, that core answering model is Apex 1.0.

    This model resolves customer issues at a materially higher rate than any other model available. One of their largest customers in the gaming space saw the resolution rate improve overnight from 68% to 75% (i.e. a reduction in unresolved conversations of 22%). The team notes they had never seen a jump this large from a single improvement since they started Fin.

    Just as important, it’s dramatically faster, has fewer hallucinations, and is far cheaper than other available models—exactly the attributes operations leaders weigh most when deploying agents at scale. In practice, these are the levers that unlock higher CSAT, tighter SLAs, and better unit economics.

    Achieving all three simultaneously is extraordinarily hard. Credit goes to foundational research from a 60‑person AI group run by Fergal Reid, and, crucially, to domain‑specific proprietary evals drawn from billions of human and agent interactions produced by the Fin resolution engine—already hand‑tuned to be the most effective in the category. That creates a flywheel: an eval‑driven development loop that trains models to keep improving at the edge of the system’s abilities. In other words, Apex 1.0 looks like the tip of the iceberg.

    Zooming out, service is one of the few categories where generative AI has already delivered commercial impact at scale (alongside coding, and arguably the legal industry). With TAMs measured in the hundreds of billions, competition is intense and well capitalized. The pattern I’ve seen repeatedly is clear: winners in these spaces must become full‑stack AI companies. As features become ~free to build, durable competitive differentiation shifts under the hood—to proprietary data, post‑training, inference efficiency, and the quality of the eval loop.

    Dual bar charts showcasing Fin Apex 1.0 with -65% hallucination reduction and a 3.7s time to first token, benchmarked against Sonnet 4.6, Opus 4.5, and GPT-5.4 on a clean, light background.
    Fin Apex raises the bar for finance-ready AI, highlighting a -65% cut in hallucinations and a quicker first token at 3.7s (0.6s faster), compared with Sonnet 4.6, Opus 4.5, and GPT-5.4 in side-by-side charts.

    That’s why competitors will need to release their own models. Many appear to be just starting to hire the talent to do so, which likely gives Fin at least a year of head start. For product leaders, this is a strong signal to revisit build vs buy assumptions, and to quantify when owning your post‑training pipeline and evals becomes the rational move.

    Honestly, 2–3 years ago I expected AI application differentiation to live mostly in what we built around third‑party models. The AI game humbles all of us; today it’s obvious that vertical models paired with proprietary evals create compounding moats.

    In a podcast interview last week, Andrej Karpathy said:

    "I do think we should expect more speciation in the intelligences. The animal kingdom is extremely [diverse] in the brains that exist. And there’s lots of different niches of nature… And I think we should be able to see more speciation. And you don’t need this oracle that knows everything. You kind of speciate it. And then you put it on a specific task. And we should be seeing some of that because you should be able to have much smaller models that still have the cognitive core."

    The frontier labs still have the very best models, but open‑weight models aren’t far behind—making pre‑training look increasingly like a commodity. The frontier is moving to post‑training, which is precisely what we see with Apex (and Cursor’s Composer 2), and what we should expect to dominate going forward.

    Labs now face a dual reality. On one hand, horizontal general‑purpose models can over‑serve specific verticals (e.g., customer service doesn’t need an oracle that knows everything). On the other, open‑weight models are good enough that high‑quality, domain‑specific post‑training can produce superior models for special‑purpose jobs—and in the ways that matter for those jobs. In service, soft factors like judgement, pleasantness, and attentiveness matter alongside hard factors like resolution effectiveness, speed, and cost.

    I’m still bullish on the labs. Many organizations remain heavy customers of Anthropic—whether as part of multi‑model systems or through deep usage of Claude Code in engineering teams (see this example of Claude Code adoption). Yet classic disruption (à la the late, great Clay Christensen) is now at their door. The way out is to disrupt themselves by building cheaper specialized models too, which likely requires acquiring the evals—or the companies with the evals—needed for each task. Expect creative data partnerships, M&A consolidation, and a wave of hyper‑specific model providers that compete head‑to‑head with the labs.

    In the meantime, Fin appears to be the only vendor in its space with a custom model that’s also objectively superior to everything else out there. I’m excited to see it deployed broadly for end customers, and I’m watching closely for the next announcement that will accelerate that rollout. For product leaders, the message is clear: the age of vertical models and agentic AI is here—bring your evals, or bring your checkbook.

    Inspired by this post on The Intercom Blog.

    Book a consult png image
  • Inside Partner Product Marketing: Lessons that Elevate Go-to-Market and Product-Led Growth

    Inside Partner Product Marketing: Lessons that Elevate Go-to-Market and Product-Led Growth

    I’ve learned that the most effective partner product marketing is less about decks and more about decisions. When I collaborate with partner product marketing managers, we translate complex capabilities from a unified analytics platform into crisp, outcome-led narratives that customers can act on. This is where product positioning and go-to-market strategy intersect to create momentum for product-led growth.

    In my experience, the strongest partner product marketing managers operate like solution orchestrators. They align value propositions across partners, clarify the problem-solution fit, and articulate competitive differentiation without drowning teams in feature lists. By anchoring messaging in clear customer pains and measurable gains, they help everyone—from solutions engineering to sales—tell the same story with confidence.

    My playbook starts with outcomes. We define the “why” in terms customers care about, then quantify it with retention analysis, user activation, and time-to-value. That evidence shapes positioning, enables tighter points of parity and differentiation, and ensures our value proposition resonates in market. The result is faster alignment and fewer cycles spent debating messaging without data.

    Cross-functional execution makes or breaks the strategy. I partner closely with solutions engineering to validate solution patterns, and with sales to balance sales-led motions alongside product-led growth. Strong stakeholder management keeps discovery loops tight: we capture objections early, refine narratives quickly, and reduce friction across the funnel.

    On the tactics side, I rely on A/B testing to de-risk bold messaging changes and to optimize in-app guides and product tours. We set a minimum detectable effect upfront, instrument journeys with Amplitude analytics, and iterate quickly. This gives the team statistical confidence while keeping speed high—especially when refining narratives for complex partner solutions.

    Ultimately, great partner product marketing illuminates the shortest path from capability to customer value. When we pair disciplined positioning with data-driven learning, we strengthen our go-to-market strategy and build durable competitive advantage. That’s how we turn strong solutions into market-leading stories that win—and keep—customers.

    Inspired by this post on Amplitude – Best Practices.

    Book a consult png image
  • A Practical Framework for AI-Era Build-versus-Buy Decisions

    A Practical Framework for AI-Era Build-versus-Buy Decisions

    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.

    My default is to build where the capability creates differentiation and buy where it provides parity. The control category prevents that principle from becoming simplistic. A commodity function can still require an internal boundary, a contractual guarantee, or an owned abstraction if failure would compromise a core promise.

    Ask these questions for each layer:

    • 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.

    LayerStrategic questionPlausible initial posture
    Domain retrieval and rankingDoes relevance depend on proprietary content, metadata, permissions, or customer context?Build when this is central to answer quality and differentiation.
    Orchestration and observabilityWould 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 casesDo 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 handoffIs 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 areaEvidence needed for a buy optionEvidence needed for a build option
    Acquisition or developmentSubscription, 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.
    IntegrationConnector 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.
    OperationsInternal 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.
    ChangeConfiguration 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 exposureVendor 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.
    ExitData export, contract termination, migration assistance, replacement integration, and reconstruction of non-portable artifacts.Decommissioning, data migration, user transition, and replacement of internally coupled components.

    Buying often wins the first horizon while integration work, consumption pricing, roadmap gaps, training, and connector maintenance accumulate later. Building reverses the pressure: the early commitment is larger, and any long-run advantage depends on sustained adoption, sufficient scale, and a team that can operate what it creates.

    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.

    A practical scorecard covers differentiation, urgency, security and regulatory risk, integration complexity, and AI leverage and portability.

    DimensionDecision questionEvidence to collectWhat changes the decision
    DifferentiationHow 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 valueWhat 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 riskCan 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 complexityHow 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 portabilityWhich 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:

    1. 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.
    2. 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.
    3. 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.
    4. 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.

    References

  • A Proven Go-to-Market Playbook: Align ICPs, Positioning, Pricing, Channels, and Launch for Revenue

    A Proven Go-to-Market Playbook: Align ICPs, Positioning, Pricing, Channels, and Launch for Revenue

    I’ve led and learned from dozens of launches, and one truth holds: a sharp go-to-market strategy is the difference between shipping features and creating value. In this piece, I share the playbook I use with my product marketing teams to align product, sales, success, and growth around a single, measurable plan.

    Step-by-step go-to-market strategy for product marketing: Define ICPs, positioning, pricing, channels, launch plan, and metrics to drive adoption and revenue.

    I start by defining our ideal customer profiles (ICPs) with continuous discovery: blending qualitative interviews with quantitative signal from retention analysis and usage. We map jobs-to-be-done, pains, and buying triggers, then size segments and select the entry ICP that maximizes product-market fit odds. From there, we articulate points of parity and competitive differentiation to clarify where we must match the market and where we will win.

    With ICPs locked, I craft positioning and messaging that ladder to a clear value proposition. I test headlines and narratives via A/B testing across ads, email, and in-app guides, and I tighten UX writing inside product tours to reinforce the promise. The goal: consistent, resonant language that sales can champion and self-serve users can understand in seconds.

    Next, I align pricing and packaging to the value metric customers actually care about—keeping SaaS pricing simple to start, with room for advanced consumption SaaS pricing when usage scales. I pair pricing with onboarding that speeds user activation, removes friction with thoughtful tooltip design, and sets customers up for early wins.

    Channel strategy is a focus decision. Depending on motion, I mix product-led growth, targeted outbound, partner co-marketing, and community. I ensure CRM integration and enablement content are ready on day one so marketing, sales, and success can execute in lockstep.

    I translate the strategy into a concrete launch plan tied to product roadmapping and sprint planning: milestones, assets, demos, and a clear owner for every dependency. We rehearse the narrative, pressure-test objections, and equip field teams with competitive battlecards and objection handling.

    From the outset, we define success metrics that ladder to revenue: awareness, activation, conversion, expansion, and retention. Leading indicators beat lagging ones, so I instrument a unified analytics platform to monitor activation rate, time-to-value, and feature adoption in near real time, then feed insights back into the roadmap.

    After launch, we run tight feedback loops—win/loss analysis, in-product surveys, and cohort-based retention analysis—to refine messaging, re-bundle packaging, or adjust channels. The team owns outcomes, not output: we iterate until we see durable signals of product-market fit and efficient growth.

    If you need a simple way to operationalize this, print the one-liner above, share it with your cross-functional partners, and commit to weekly reviews. When everyone can state the ICP, the promise, the price, the channel plan, and the metrics, execution accelerates and the market responds.

    Inspired by this post on Product School.

    Book a consult png image
  • Enterprise Go-To-Market That Wins: How Product Marketing Supercharges Analytics Adoption

    Enterprise Go-To-Market That Wins: How Product Marketing Supercharges Analytics Adoption

    In my role leading product management at HighLevel, I’ve learned that enterprise go-to-market lives or dies by the strength of the partnership between product and product marketing. When we operate as one team, we turn complex capabilities into clear outcomes that resonate with buyers and drive adoption at scale.

    I’m especially energized by the archetype of a product marketing manager at a leading analytics platform—someone “focusing on go-to-market solutions for enterprise customers.” That mandate requires rigor across product positioning, value proposition design, competitive differentiation, and sales enablement, all while aligning deeply with engineering and customer success. In practice, it means translating signal from a unified analytics platform into narratives and plays that close deals and expand accounts.

    Day-to-day, I partner with product marketing to validate messaging through continuous discovery and data. We use Amplitude analytics to instrument activation, engagement, and retention analysis—then feed those insights into product-led growth motions like in-app guides and product tours. A/B testing grounded in a clear minimum detectable effect (MDE) helps us separate noise from impact, while points of parity and true differentiation shape the story sellers can confidently carry into enterprise conversations.

    This is also where outcomes vs output OKRs keep us honest. Rather than celebrating launches, we anchor on measurable behavior change: faster time-to-value, higher user activation, deeper feature adoption, and multi-threaded stakeholder engagement. Product trios provide the operating rhythm, and stakeholder management ensures sales, marketing, and success move in lockstep with the roadmap and GTM calendar.

    If you’re building an enterprise GTM motion, start by tightening your value proposition to the top three pains your best-fit accounts actually feel, validate with real usage data, and then enable your field teams with crisp, data-backed talk tracks. With the right PM–PMM alignment and analytics foundation, your go-to-market strategy becomes a compounding advantage—not just a launch plan.

    Inspired by this post on Amplitude – Perspectives.

    Book a consult png image
  • How Startups Earn Visibility in ChatGPT and Perplexity

    How Startups Earn Visibility in ChatGPT and Perplexity

    A prospect asks ChatGPT or Perplexity for the kind of product you sell. Several competitors appear. Your startup does not. That does not automatically mean your product is weak or your SEO has failed. It often means the system cannot find enough clear, consistent, and corroborated evidence to include you confidently.

    Your job is not to force your company into every answer. It is to make your startup easy to identify, accurately categorize, and safely recommend when it genuinely fits the question. That requires coordinated work across positioning, content, technical structure, third-party proof, and measurement.

    Key takeaways

    • Measure visibility across important buyer questions, not as one universal AI-search ranking.
    • Build a page for each major decision: category, use case, integration, price, comparison, and deployment risk.
    • Make important claims explicit in visible HTML, then reinforce them with accurate metadata and schema.
    • Support first-party claims with reviews, partner pages, case studies, documentation, and other independent evidence.
    • Use a stable prompt set to find specific visibility failures, change the relevant evidence, and retest.

    Measure recommendation coverage, not an imaginary rank

    Conventional search encourages a positional question: where do I rank? AI search requires a different question: for which buyer decisions can the system understand and support a recommendation of my product?

    AI search behaves more like a synthesis engine than a page of ranked blue links. It assembles an answer around the wording and context of a prompt. Change the question from best software for a category to best software for a particular team, workflow, integration, budget, or risk profile, and the eligible recommendations may change.

    There is therefore no single visibility score that tells the whole story. A startup can be visible for category discovery but absent from integration questions. It can be named as an alternative yet omitted when the buyer adds a security requirement. It can also be mentioned with an outdated description, which is exposure without useful discovery.

    A practical baseline should distinguish four outcomes:

    • Discovery: Does your company appear when the prompt describes a problem you solve?
    • Positioning: Is it placed in the right category and associated with the right audience and job?
    • Fit: Does the answer explain when your product is appropriate, including relevant trade-offs?
    • Evidence: Are the supporting claims current, specific, and connected to credible pages?

    Start with the questions that already matter in your buying journey. Include category exploration, problem framing, use-case fit, integrations, commercial value, alternatives, and deployment risk. Preserve the exact wording of each prompt. If you rewrite the test every time, you will not know whether your evidence improved or the question merely changed.

    Record more than whether your name appeared. Save the product description, recommendation context, claims, citations, omissions, and factual errors. A mention is not a win if the answer sends the wrong buyer to your product or attributes a capability you do not offer.

    Turn buyer intent into an answerable page system

    Many startups try to solve AI visibility by publishing more blog posts. Volume is rarely the first constraint. The more common problem is that the website has no precise page capable of answering the buyer’s actual question.

    Your homepage cannot carry the entire decision journey. Give each high-value intent a clear destination:

    Buyer decisionQuestion the page must answerBest page typeEvidence to include
    Category explorationWhat is this product, and who is it for?About or category pagePlain category definition, target customer, core job, and differentiator
    Problem framingHow should I understand and solve this problem?In-depth explainerMethod, terminology, constraints, and links to primary material
    Solution fitCan this product handle my workflow?Use-case pageUser, workflow, inputs, outputs, limitations, and customer evidence
    Integration fitDoes it work with the rest of my stack?Integration page or documentationPrerequisites, supported connection, setup steps, data flow, and known limits
    Commercial fitWhat will I pay, and what value should I expect?Pricing and value pagePricing structure, inclusions, exclusions, assumptions, and verifiable outcomes
    Competitive choiceWhen should I choose this product instead of an alternative?Comparison or alternatives pagePoints of parity, meaningful differences, trade-offs, and cited claims
    Deployment riskCan my organization use it safely?Trust centerSecurity, privacy, compliance, governance, and data-handling information

    Each page should lead with a direct answer. Do not make a retrieval system infer your category from a slogan or reconstruct an integration from a press release. A useful positioning sentence follows a simple structure: [Product] is a [category] for [audience] that needs to [job], distinguished by [relevant difference]. Use the same underlying definition wherever the product is introduced.

    Use-case pages need more than a collection of benefits. Name the user, triggering problem, workflow, expected output, dependencies, and boundaries. If the product is suitable only under particular conditions, state them. Precise qualification can reduce superficial visibility while improving the quality of the recommendations that remain.

    Integration pages deserve the same care. A logo wall proves very little. Explain what connects, in which direction data moves, what setup requires, and which workflows the connection supports. Link to technical documentation and the partner’s corresponding page when one exists.

    Comparison pages should help a buyer make a decision, not manufacture a victory. Start with the shared category, acknowledge points of parity, identify the conditions that make each option a better fit, and cite claims that a reader can verify. A fair statement such as one product suits a particular workflow while another suits a different operating model is more useful than an unsupported declaration that yours is best.

    Transparent pricing matters for the same reason. If a public amount is not available, you can still explain the pricing unit, packaging logic, included capabilities, major variables, and purchasing path. The aim is to remove avoidable ambiguity from a commercial-fit question.

    Make the corpus easy to retrieve and hard to misread

    Good information can remain invisible when it is buried in a PDF, hidden behind vague navigation, contradicted by metadata, or scattered across pages with no canonical version. Retrieval-friendly content reduces the work required to locate, segment, and interpret an answer.

    Work through the site in this order:

    1. Make the visible narrative consistent. Use the same product name, category, audience, and core capability across the homepage, About page, product pages, documentation, and trust center. Resolve genuine contradictions before adding markup.
    2. Give every important answer a stable URL. Use descriptive headings, short focused sections, sensible internal links, and linkable anchors. Keep documentation in HTML when possible, even if you also offer a PDF.
    3. Add schema that describes the visible page. Organization, Product, FAQPage, HowTo, and Article JSON-LD can clarify entities and content types when they accurately match what a person can read on the page.
    4. Align the surrounding signals. Titles, meta descriptions, canonical URLs, and Open Graph data should reinforce the same identity and purpose rather than introducing alternate names or claims.
    5. Remove retrieval friction. Maintain a clean sitemap, review robots.txt for accidental blocking, keep important pages reachable through navigation, and provide fast mobile-first experiences.
    6. Keep technical material usable. Provide copyable commands, configuration examples, prerequisites, expected results, and failure conditions where they are relevant.

    Schema is a translation layer, not evidence. Product markup cannot rescue an unsupported claim, and FAQ markup cannot turn a thin sales page into an authoritative answer. Add structured data after the visible content is accurate and complete.

    The trust center is especially important for B2B products. Security, compliance, privacy, governance, and data-handling questions often enter the buying process before a prospect speaks to sales. Give each topic a clear, current answer. Avoid mixing aspirational commitments with controls that are already in place.

    Freshness also needs visible ownership. Release notes should reflect material product and integration changes. Outdated feature claims should be corrected or retired instead of left to compete with the current version. Schedule a quarterly review of commercially important pages, documentation, comparison claims, and trust material. The goal is not to alter dates cosmetically; it is to ensure that the underlying answer remains true.

    Earn corroboration where your company cannot control the wording

    Your website establishes what you claim. Independent surfaces help establish whether anyone else has reason to believe it. That distinction becomes important when a recommendation involves operational risk, meaningful spend, or a crowded category.

    Map each commercially important claim to the strongest available proof:

    • Adoption: detailed customer stories, current review profiles, and customer outcomes with verifiable metrics.
    • Compatibility: partner directories, joint integration pages, and documentation that confirms the supported connection.
    • Technical maturity: accessible documentation, maintained repositories where relevant, and README files that accurately explain installation and use.
    • Category authority: reputable industry mentions, analyst coverage, or citations by practitioners and institutions with relevant expertise.
    • Deployability: security, compliance, governance, and privacy material that a buyer can inspect rather than a generic statement that the product is secure.

    Do not chase mentions indiscriminately. A third-party page is useful when it verifies a claim a buyer cares about. An integration listing that confirms compatibility can be more valuable for an integration prompt than broad publicity that says nothing about the product’s operation.

    Case studies should make their evidentiary limits visible. Identify the customer context, starting problem, product use, measured result, and method behind the metric. If the outcome is self-reported or cannot be independently verified, describe it that way. Specificity makes the claim easier to evaluate; inflated certainty makes the entire corpus less trustworthy.

    Build a proof inventory before launching another content campaign. For each positioning claim, record the first-party explanation, customer evidence, independent corroboration, current URL, owner, and freshness status. Empty cells reveal whether you have a writing problem, a product-evidence problem, or a distribution problem.

    This inventory also prevents a common sequencing mistake. A startup may publish many pages around a claim that no customer, partner, reviewer, or technical artifact supports. More repetition does not create stronger evidence. First establish the truth of the claim, then make that truth easy to discover in the places a recommendation system can retrieve.

    Run AI visibility as an eval-driven product loop

    AI-search work becomes vague when the team alternates between random prompts and random content changes. Treat the discovery experience as a product surface with defined test cases, observable failures, and controlled iterations.

    1. Define a stable prompt set. Represent the buyer intents you want to serve, using the language a real evaluator would use at each decision stage.
    2. Capture a baseline in ChatGPT and Perplexity. Record the exact prompt, system, test date, answer, recommendation context, cited pages, and factual errors.
    3. Classify the failure. Distinguish absence from miscategorization, weak fit evidence, missing corroboration, stale information, or retrieval of the wrong page.
    4. Change the evidence connected to that failure. Improve the category definition for a positioning error, an integration page for a compatibility gap, or the trust center for an unsupported deployment answer.
    5. Rerun the same test cases. Look for improved coverage and accuracy without assuming that a single response proves a durable change.
    6. Connect visibility to buyer behavior. Track referrals from AI-driven surfaces, landing-page engagement, qualified demand, and pipeline where your analytics can identify them responsibly.

    Use a simple evaluation record rather than one blended score. Mark whether the product was present or absent, whether its category was correct or wrong, whether fit was supported or merely asserted, whether citations were current, and whether the linked page offered a useful next step. Separate fields tell you what to fix. A single number hides the cause.

    Answer variability is part of the environment, so treat one run as an observation rather than a verdict. The useful signal is whether the same class of important prompts becomes more consistently accurate after you improve the relevant material.

    A/B testing can help when a page receives enough appropriate traffic and the change can be measured through user behavior. Test answer placement, headings, proof presentation, or the route to a next step. Do not A/B test incompatible facts about what the product is. Positioning consistency is a prerequisite for the evaluation, not an experiment variant.

    Avoid the shortcuts that create activity without evidence: bulk publishing shallow pages, applying every available schema type, writing hostile comparison copy, leaving essential documentation only in PDFs, and reporting raw mentions without checking accuracy or commercial relevance.

    In your next working session, choose the buyer question closest to an active product decision. Inspect the answer, identify the missing or unreliable evidence, improve the page that should resolve it, and add one credible corroborating signal. Then preserve the prompt and retest it. Repeating that loop across the decision journey is how AI visibility becomes an operating capability instead of a one-time content project.

    References

  • How to Turn Enterprise Positioning Into Measurable Adoption

    How to Turn Enterprise Positioning Into Measurable Adoption

    Your enterprise narrative is landing. Executives understand the promise, demos create interest, and qualified accounts enter the pipeline. Then the signal gets murky. Pilots start but do not spread. Users complete setup but do not return. One champion is active while the rest of the account remains untouched.

    The problem may be positioning, onboarding, product value, or the handoff between them. You cannot tell from pipeline, traffic, or active-user totals alone. The practical answer is to treat positioning as a behavioral hypothesis: name the product behavior your promise should cause, instrument the path to that behavior, and use account-level adoption data to decide what to change.

    Treat positioning as a prediction about customer behavior

    Positioning is usually expressed as language: an ideal customer profile, a value proposition, a category, a differentiator, and a set of reasons to believe. That language matters, but it is only the commercial side of the contract. The product side must predict what a well-matched account will do after buying.

    If the promise is faster execution, what workflow should finish sooner? If the promise is easier collaboration, which roles must participate? If the promise is better operational control, what should an administrator configure and what governed action should an end user complete? A claim that cannot be translated into observable behavior is difficult to validate and even harder to improve.

    Write each positioning hypothesis with these components:

    • Account condition: the firmographic, operational, or technical situation that makes the problem important.
    • Buying situation: the event, constraint, or unresolved job that creates urgency.
    • Current alternative: the process, incumbent product, or workaround the account uses now.
    • Promised outcome: the change the buyer expects, stated without substituting a feature for an outcome.
    • Product mechanism: the capability or workflow that should create that change.
    • Observable proof: the behavior that would indicate the mechanism is working.
    • Boundary: the conditions under which the promise is unlikely to hold. This keeps an attractive message from pulling unsuitable accounts into the funnel.

    Enterprise positioning also has to survive translation across a buying committee. The economic buyer needs an outcome, the champion needs a credible path to change, the administrator needs implementation confidence, and the practitioner needs a job that becomes easier. These are not separate value propositions. They are role-specific expressions of the same one.

    Mapping the buyer committee and carrying a consistent value proposition from the website through the demo and proof of concept makes this translation explicit. Without that continuity, marketing can attract an account with one promise, sales can demonstrate another, and the product can activate users around a third. Each stage may look locally successful while the account as a whole fails to adopt.

    My rule is simple: do not approve a positioning claim until you can finish this sentence: A well-matched account that believes this promise should complete this behavior, through this product mechanism, within its normal operating cycle.

    Build the measurement model before you launch the message

    Analytics cannot rescue a vague positioning hypothesis after launch. Instrumentation needs to begin with the decision you expect the data to support. Otherwise, the dashboard fills with convenient events such as page views, logins, and clicks while the meaningful workflow remains invisible.

    Build a measurement spine that follows an account from exposure to durable value:

    1. Message exposure: the eligible account or buyer encountered a specific narrative, use case, campaign, demo, or proof-of-concept story.
    2. Qualified intent: the account took an action that indicates interest in that use case, not merely general awareness.
    3. Setup: the required data, configuration, permissions, or integration became available.
    4. Activation: an intended user completed the smallest workflow that produces recognizable value.
    5. Repeat value: the account completed that workflow again within the natural cadence of the job.
    6. Adoption breadth and depth: usage reached the intended roles, teams, use cases, or volume instead of remaining with one early user.
    7. Account outcome: product evidence and customer evidence together indicate that the promised operational result is occurring.

    Setup and activation are not the same. Connecting a data source, inviting colleagues, or configuring permissions may be necessary, but those actions do not prove that the customer received value. A login is even weaker. Define activation around a completed job whose output the user can recognize and use.

    The observation window should match the product’s real usage cadence. A workflow performed as part of a recurring business cycle should not be judged by an arbitrary daily metric. At the same time, an open-ended window makes every account look potentially active forever. Define the expected cadence with product, product marketing, sales, and customer success before looking at results, then apply it consistently to comparable cohorts.

    Enterprise adoption also lives at two grains: the user and the account. User-level data tells you who completed a workflow and where friction occurred. Account-level data tells you whether value is becoming institutionalized. One highly active champion can conceal a failed rollout, while low daily activity can misrepresent a valuable but naturally episodic workflow.

    At minimum, connect meaningful events to:

    • a stable account identifier and user identifier;
    • the user’s intended role or workflow role;
    • the account segment and target use case;
    • the message, campaign, demo narrative, or proof-of-concept hypothesis that created exposure;
    • whether activation was assisted or completed independently;
    • the event definition or version when instrumentation changes; and
    • the timestamp needed to construct eligible cohorts and observation windows.

    Do not place sensitive customer information into analytics merely because it could help segmentation. Collect the minimum properties required for the decisions you have defined, apply appropriate access controls, and use governed identifiers rather than copying operational data into event payloads.

    A shared view of activation cohorts and retention is valuable because it gives product, marketing, and revenue teams the same account history. The platform matters less than the semantic contract: everyone must use the same definition of eligible exposure, activation, repeat value, and retained adoption.

    Connect each buyer promise to product evidence

    The cleanest bridge between positioning and adoption is a message-to-signal map. It prevents teams from measuring whatever happens to be available and calling it proof. The rows below are examples; your evidence must reflect the workflow and operating cadence of your product.

    Positioning claimRequired product behaviorFirst useful signalLater adoption signal
    A shorter path to valueAn eligible user completes the core workflow from a valid starting stateTime from readiness to first completed workflow, separated by assisted and independent pathsThe workflow repeats without extraordinary intervention and reaches additional eligible users
    Easier cross-functional collaborationThe intended roles contribute to and complete a shared workflowMulti-role participation in the first successful workflowShared work repeats across the account’s relevant operating cycles
    Greater operational controlAn administrator configures the intended controls and users complete work through themConfiguration followed by a governed end-user workflowAdditional eligible groups adopt the same operating model without bypassing it
    Clearer decision-makingA user produces, shares, or applies an output in the target decision processCompletion of the first decision workflow, not creation of an unused artifactThe account returns to the workflow at the next relevant decision point

    The first signal is not the business outcome. It tells you whether the proposed mechanism has started. Later signals test whether value persists and spreads. A revenue, efficiency, or risk claim may also require evidence from the customer’s operating systems or a validated customer-success record; product telemetry alone should not be stretched into proof it cannot provide.

    Use the same map to define a proof of concept. Before it begins, write down:

    • the account and use case being evaluated;
    • the valid starting condition, including required data and configuration;
    • the role expected to complete the workflow;
    • the activation milestone and the promised outcome it represents;
    • the evidence system for each signal;
    • the observation window based on the workflow’s natural cadence;
    • the assistance that will be provided and how it will be recorded; and
    • the decision rule for proceeding, refining the implementation, or stopping.

    This success contract protects you from a common analytical mistake: redefining success after seeing what the account happened to do. It also exposes gaps early. If sales can demonstrate the promise but the account cannot complete the workflow with its own data and roles, the proof of concept has measured presentation quality, not adoption readiness.

    Assistance is not inherently a failure in an enterprise motion. Complex products often require implementation support. Track it explicitly. The important distinction is whether assistance creates a repeatable operating path or temporarily conceals product, data, or organizational friction.

    Read the funnel without confusing correlation with proof

    Once the measurement spine is live, resist the urge to compress it into one conversion rate. The relationship among response, activation, retention, and account breadth tells you where to investigate. No single pattern proves a cause, but each pattern produces a better next question.

    Observed patternWorking interpretationNext action
    Strong response, weak activationThe promise attracts interest, but the account may be unsuitable, the handoff may be broken, or the first-value path may not match the promiseSeparate fit, setup completion, and workflow friction before changing the message
    Weak response, strong activation and repeat value among exposed accountsThe product may deliver for the reached use case while the narrative or acquisition channel fails to communicate that valueTest a clearer outcome and mechanism with the same eligible audience
    Strong activation, weak repeat valueThe first experience works, but the product may lack recurring utility, the wrong cadence may be measured, or adoption may depend on continued assistanceInspect the next natural use occasion and compare independent with assisted accounts
    Strong repeat use by one person, weak account breadthA champion has value, but organizational adoption is blocked by role, permission, enablement, integration, or workflow requirementsMap the missing roles and instrument the handoff from champion success to team use
    Strong activation, repeat value, and growing breadth in one use-case cohortThe positioning and product mechanism are aligned for that cohortProtect the segment definition, validate the account outcome, and scale deliberately rather than generalizing to every enterprise account

    Strong and weak are relative to comparable cohorts, not universal thresholds. Compare accounts with the same eligibility, target use case, exposure definition, and observation opportunity. A pooled enterprise average can hide a message that works well for one use case and fails for another.

    Segment the analysis by the dimensions that can change the mechanism: account condition, use case, buyer or user role, positioning variant, implementation path, and assisted status. Do not create segments simply because the properties exist. Each cut should correspond to a decision you might make differently.

    If you want a causal answer about messaging, random assignment is the cleanest option when it is practical and appropriate. Keep eligibility, exposure, and the outcome window consistent. If sales representatives choose which account receives each narrative, the resulting comparison is confounded by their knowledge of the account. It can still generate hypotheses, but it should not be presented as an A/B test or as proof that one message caused better adoption.

    When randomization is not feasible, triangulate. Compare stable cohorts, examine the same segment before and after the change, inspect the stage where behavior diverges, and collect direct customer evidence about what they expected. Concurrent product changes, pricing changes, enablement, and account mix can all affect a before-and-after result, so preserve that uncertainty in the decision.

    AI-generated discovery adds another exposure layer. An AI visibility score, competitor ranking, and use-case-level view of how a brand appears in model-generated answers can reveal where the market narrative is present or absent. Those signals belong near the top of the positioning funnel. They do not demonstrate product adoption.

    Use AI visibility to prioritize narrative questions: Which intended use cases are missing? Where are competitors associated with a value your product intends to own? Which points of parity are overshadowing a meaningful differentiator? Then test changes through attributable journeys where attribution is available. If the path from model exposure to account activity cannot be observed reliably, report visibility and downstream adoption as separate signals instead of manufacturing a causal connection.

    Make the data change a product or go-to-market decision

    A dashboard does not create alignment by itself. The operating model needs clear ownership for the hypotheses, definitions, and decisions behind it.

    • Product management owns the product mechanism, activation milestone, friction diagnosis, and product response.
    • Product marketing owns the audience, positioning hypothesis, message variants, and consistency across buyer-facing surfaces.
    • Sales and solutions engineering record which narrative and use case were presented, qualify account conditions, and preserve the proof-of-concept success contract.
    • Customer success validates the customer’s operating outcome and identifies the roles or workflows required for broader adoption.
    • Revenue operations and data partners maintain identity resolution, exposure metadata, metric definitions, and data-quality checks.
    • Product and revenue leaders decide whether the evidence supports scaling, refining, fixing, or stopping a bet.

    Choose a review rhythm that allows the relevant behavior to occur. Reviewing faster than the product’s natural adoption cycle produces noise and encourages teams to react to incomplete cohorts. Waiting until a quarterly business review can conceal fixable handoff problems. The right cadence is the shortest interval that still gives an eligible cohort a fair opportunity to reach the milestone under review.

    Run each review in a fixed order:

    1. Confirm instrumentation health, cohort eligibility, and observation completeness.
    2. Read movement across exposure, intent, setup, activation, repeat value, and breadth.
    3. Find the first stage where the target cohort diverges from a relevant comparison cohort.
    4. Break that stage down by use case, role, positioning variant, and implementation path.
    5. Add qualitative evidence to explain expectations, objections, and workflow friction.
    6. Make one explicit decision: scale, refine the narrative, fix the handoff, change the product path, narrow the segment, or stop the bet.
    7. Record the owner, expected behavioral change, and signal that will be reviewed next.

    Do not let every weak metric become a messaging problem. If suitable accounts understand the promise but cannot reach first value, fix the product or onboarding path. If activated accounts repeatedly receive value but suitable prospects do not understand why it matters, refine positioning or channel execution. If one role succeeds but the account cannot broaden, address the organizational and administrative path. If the promised outcome is not credible for the segment even when the workflow works, narrow or replace the claim.

    Key takeaways

    • Write positioning as an account condition, promised outcome, product mechanism, observable behavior, and explicit boundary.
    • Measure setup, activation, repeat value, and account breadth separately; none can substitute for the others.
    • Carry message and use-case exposure into account-level analytics so downstream behavior can be traced to a real hypothesis.
    • Use response, activation, retention, and breadth patterns to choose the next investigation, not to declare an unsupported cause.
    • Treat AI visibility as a positioning signal at the discovery layer, not as evidence of customer adoption.
    • End every review with a decision, an owner, and a behavioral signal that can confirm whether the intervention worked.

    Start with one enterprise claim already in market. Name its target account, mechanism, activation behavior, repeat-value signal, and breadth signal. Then inspect one eligible cohort from message exposure through adoption. If you cannot connect the claim to a behavior, rewrite the claim before increasing go-to-market spend. If you can connect it, the first broken transition will tell you where the next product or positioning decision belongs.

    References

  • How to Scale Enterprise Sales Without Breaking Product Strategy

    How to Scale Enterprise Sales Without Breaking Product Strategy

    You have enough mid-market traction to believe enterprise should be next. Large accounts enter the pipeline, ask for security reviews, role controls, auditability, service commitments, and roadmap exceptions, then take far longer to close than expected. Sales wants more product support and more headcount. Product sees a queue of one-off requests. Leadership cannot tell whether the constraint is the product, the sales motion, or both.

    The decision in front of you is not simply whether to hire more reps. It is whether you have built an enterprise deal that a capable rep can reproduce. You can answer that by testing four parts of the system: enterprise readiness, product-market-sales fit, ICP discipline, and capacity. Fix them in that order, and sales hiring becomes an investment in a working motion instead of an expensive attempt to discover one.

    Treat enterprise deal friction as a product diagnostic

    A stalled enterprise deal is often labeled a sales execution problem because the failure appears in the pipeline. The underlying constraint may have been created much earlier. Enterprise buyers need more than a useful product. They expect architecture that can withstand their operating environment, deep security and compliance support, robust role-based access control, data governance, audit trails, predictable service levels, and a credible path through implementation and change management.

    They also need enough evidence to defend the purchase internally. A persuasive demo cannot substitute for a precise value proposition, relevant customer references, a clear implementation plan, and an answer to a basic competitive question: who do you beat, for which customer, and why?

    That is why you should classify enterprise friction before committing to a remedy. Do not let every objection become a feature request, and do not let every loss become a coaching problem. Look for the pattern behind the objection.

    Pattern you observeLikely constraint to investigateWhat to do next
    Qualified opportunities repeatedly stop during security, governance, or legal reviewEnterprise product readinessTurn recurring requirements into a readiness backlog with an owner, a reusable evidence package, and a clear completion test.
    Pilots generate positive user feedback but do not produce a buying decisionBusiness proof, stakeholder alignment, or change managementDefine the decision criteria, economic outcome, buyer group, rollout plan, and procurement path before the pilot begins.
    Deal quality and cycle length vary sharply by repQualification, positioning, or enablementStandardize the ICP, discovery questions, proof package, objection handling, and stage-exit criteria.
    Customers close but do not retain or expand as expectedProduct value, customer fit, or adoptionReview retention and expansion by segment, then inspect whether the promised outcome was achieved after implementation.
    One prestigious account requires a large, account-specific roadmap detourICP discipline and exception governanceMeasure the reusable value and roadmap displacement explicitly. Decline the work if it forces the product away from its native strengths.

    The table gives you hypotheses, not automatic verdicts. Validate them by tracing recent opportunities from discovery through implementation. A deal that died in procurement may still have entered the pipeline with a weak business case. A security objection may conceal low executive urgency. The purpose of classification is to identify the first broken link, not the final place where the deal stopped moving.

    Build an enterprise readiness contract across functions. Product and engineering own architecture, access controls, auditability, governance, extensibility, and reliability. Security and compliance own the evidence buyers need to evaluate those capabilities. Product marketing and sales own the value proposition and competitive proof. Customer success and solutions engineering own implementation, adoption, and change-management readiness. Leadership owns the exception policy when a deal asks the company to depart from its strategy.

    Test this contract with lighthouse customers that closely match your intended market. A friendly pilot can confirm that users like a workflow while avoiding the hard parts of an enterprise purchase. A useful lighthouse account exercises the full system: technical validation, security review, procurement, implementation, adoption, and proof of value. The objective is not merely to secure a logo. It is to learn whether the offer survives the buying process you intend to scale.

    Prove product-market-sales fit before adding headcount

    Product-market fit and product-market-sales fit answer different questions. Product-market fit tells you that the product creates meaningful value for a customer. Product-market-sales fit tells you that your company can repeatedly find the right customer, communicate that value, navigate the buying process, close the deal, and retain or expand the account.

    The distinction matters because headcount amplifies the system you already have. If the motion is repeatable, new sellers can extend it. If the motion still depends on founder intuition, bespoke promises, or product heroics, new sellers create more variance, more roadmap pressure, and a larger pipeline of deals the company is not prepared to win.

    I would use five signal groups to evaluate repeatability:

    • Win rate by segment: Separate results by ICP, use case, company profile, and motion. A blended win rate can hide a strong fit in one segment and persistent losses in another.
    • Sales-cycle time: Measure time by stage, not only the total. This shows whether discovery, technical validation, security, procurement, or contracting is the recurring bottleneck.
    • Ramp time to a first deal: Track when a new rep can independently qualify, position, and advance the right opportunity. A first deal closed through heavy founder intervention is not proof of rep productivity.
    • Multi-threading depth: Inspect whether the opportunity includes the user champion, economic buyer, technical and security stakeholders, and procurement. A single enthusiastic contact is interest, not enterprise consensus.
    • Retention and expansion: Review net revenue retention and the percentage of customers that expand within two quarters. The sale is not repeatable if the value promised during evaluation fails to materialize after purchase.

    Do not turn these into one composite score. Each signal diagnoses a different part of the motion. A healthy win rate with weak retention points toward customer fit, product value, implementation, or expectation-setting. Strong customer outcomes with poor win rates may point toward positioning, proof, qualification, or segmentation. Long cycles concentrated in technical review suggest a different intervention from long cycles caused by an absent economic buyer.

    Use a consistent diagnostic loop for one clearly defined segment:

    1. Define the ICP, use case, required outcome, buying group, and disqualifying conditions.
    2. Choose a cohort of opportunities that entered the motion under comparable qualification rules.
    3. Review win rate, stage duration, multi-threading, rep ramp, retention, and two-quarter expansion without blending other segments into the result.
    4. Inspect representative wins, losses, and stalled deals to explain the pattern behind the metrics.
    5. Classify the primary constraint as product value, enterprise readiness, positioning, enablement, segmentation, or execution.
    6. Change one part of the system, then observe the next comparable cohort before declaring the motion fixed.

    This discipline prevents a familiar cycle: sales asks for features, product ships them, the deals remain stuck, and leadership responds by adding pipeline or people. The intervention should follow the diagnosis. Ship when the product cannot deliver the required outcome. Improve enterprise foundations when buyers cannot approve or operate it safely. Sharpen the message when customers receive value but prospects cannot understand why it matters. Rework segmentation when success is concentrated in a narrower market than the company is pursuing.

    Before approving a major increase in sales capacity, verify that a seller other than the founder can identify the right account, run discovery, explain the differentiated outcome, assemble the buying group, use a reusable proof package, and advance the account without creating an unplanned product strategy. You do not need perfect metrics. You do need enough consistency to know which constraint the new headcount is intended to remove.

    Use the ICP to protect the roadmap and sharpen the reason you win

    An ICP is useful only when it changes decisions. If every large opportunity qualifies because the contract might be valuable, the ICP is a marketing description rather than an operating constraint.

    Make the profile specific enough to govern qualification and product trade-offs. It should identify the customer characteristics that matter, the urgent job being solved, the operating and technical environment, the expected outcome, the buying group, the conditions that create urgency, and the conditions that should disqualify the account. A segment name such as enterprise software is not an ICP. It does not tell a rep which account to pursue or a product leader which request deserves roadmap capacity.

    When an opportunity produces a major request, classify it before estimating the work:

    1. Enterprise foundation: Is this a baseline capability, such as governance, auditability, reliability, or access control, that the target market broadly requires?
    2. Native ICP need: Does it strengthen the core outcome for many customers you deliberately want to serve?
    3. Reusable extension: Can it be handled through configuration, extensibility, or a shared platform capability without distorting the core product?
    4. Account-specific exception: Is it valuable mainly to this buyer, with ongoing support and complexity that the headline contract does not reveal?

    The fourth category deserves an explicit decision, especially when the account is prestigious. A marquee logo does not automatically create a market. If its requirements force unnatural changes, consume disproportionate engineering capacity, or weaken the product for the customers who already value it, walking away can preserve more long-term enterprise value than closing the deal.

    If leadership wants to make an exception, write down the bet. State the expected strategic value, the roadmap work displaced, the number and type of ICP customers that could reuse the capability, the ongoing implementation and support burden, and the assumption that would cause you to stop. This turns logo enthusiasm into a reviewable allocation decision.

    ICP discipline also makes competitive positioning more precise. Enterprise products need points of parity and a decisive reason to win. The points of parity make the offer eligible: buyers may require security, reliability, administrative controls, data governance, and procurement readiness before they will seriously evaluate it. Those capabilities matter, but they may not determine the final choice.

    The reason to win should be a binary, testable differentiator. It could be meaningfully faster time to value, a step-change in accuracy, or an economic model that changes the cost of achieving the outcome. The important word is testable. A buyer should be able to design an evaluation in which your claimed advantage either appears or it does not.

    Force the positioning into one sentence: For this ICP, facing this urgent job, the product produces this observable outcome under these conditions because of this capability. Then ask a harder question: if that outcome disappeared from the evaluation, would the buying decision change? If not, you have described a benefit, not a decisive differentiator.

    Build the proof package around that claim. Include relevant customer references, the evaluation criteria, the evidence required to verify the outcome, a map of common objections, the implementation path, and the conditions under which the claim does not apply. This gives sales something more useful than a broad feature comparison. It gives the buyer a defensible reason to choose.

    Scale a capacity-driven sales system, not a collection of deals

    Plan backward from productive capacity

    A capacity-driven plan connects the revenue goal to productive sellers, qualified pipeline, territory potential, conversion, and time. It does not assume that hiring a rep instantly creates quota capacity or that a generic pipeline-coverage ratio applies equally to every segment.

    Start with the capacity that can actually sell during the planning period. Separate productive reps from people who are still ramping. Use your observed ramp time, segment-level win rate, sales cycle, and deal profile to estimate which pipeline can mature in the period. If those observations are unstable, expose the uncertainty instead of hiding it inside an aggressive target.

    Calibrate territories to ICP density and buying intent, not visual symmetry. Two territories with the same number of named accounts may offer very different opportunity if one contains more customers with the triggering conditions, technical fit, and urgent job your motion requires. When territory potential is weak, coaching the rep harder does not create market demand.

    Your capacity review should answer concrete questions:

    • How much quota is carried by sellers who are currently productive, and how much depends on future ramp?
    • How much qualified pipeline matches the ICP and can realistically complete the remaining buying stages inside the period?
    • Which stage consumes the most time, and is its constraint sales capacity, technical readiness, security review, procurement, or executive alignment?
    • Does each territory contain enough relevant accounts and intent to support the assigned capacity?
    • Can solutions engineering, implementation, and customer success support the volume that sales is expected to close?

    This is also why qualification quality matters more than a large top-line pipeline number. A non-ICP opportunity can occupy discovery, solutions engineering, product, legal, and executive time while contributing little probability of a repeatable win. Make disqualification visible as good judgment, not failed selling.

    Encode the motion before asking people to reproduce it

    A scalable playbook does not need to become a bureaucracy. It needs to preserve the decisions that make the motion work. At minimum, a seller should have:

    • A precise ICP and explicit disqualifiers.
    • A problem and outcome narrative tailored to that ICP.
    • Discovery questions that expose urgency, current cost, decision criteria, and buying constraints.
    • A stakeholder map covering the user, champion, economic buyer, technical and security reviewers, and procurement.
    • The binary differentiator and the evidence used to test it.
    • A reusable security, governance, and procurement package.
    • Objection handling tied to real failure modes rather than generic rebuttals.
    • An implementation and change-management path that makes the promised outcome credible.
    • Consistent pipeline stages and exit criteria so forecasts represent buyer progress rather than seller optimism.

    Enablement is working when new reps use a consistent talk track, handle predictable objections without inventing promises, and know when to disqualify. Completion of training is an activity measure. Independent execution of the motion is the outcome.

    Founders still need to learn the sale before this handoff. The purpose is not to make the founder the permanent closer. It is to encode customer truth into the product, positioning, qualification rules, and proof. The handoff becomes safer when the motion can be explained, observed, and coached instead of residing in the founder’s intuition.

    Hire a sales builder and test how that person makes decisions

    Your first senior sales leader is a leverage point because the person will shape both the team and the operating system. Look for pattern recognition in your specific segment, a builder’s ability to create useful process without unnecessary bureaucracy, rigorous pipeline hygiene, and the ability to work with product on where the company wins and why.

    Past titles and quota results do not reveal enough. Use scenario loops that expose judgment:

    • Give the candidate an attractive but non-ICP opportunity and ask how it would be qualified or disqualified.
    • Present a late-stage deal stalled across several stakeholders and ask how the candidate would identify the real constraint.
    • Ask for a first 90-day plan that separates diagnosis, playbook construction, pipeline inspection, hiring, and execution.
    • Show two reps describing the product differently and ask how the candidate would coach toward a consistent message without erasing useful learning.
    • Ask how product feedback would be separated into enterprise foundations, repeatable ICP needs, positioning problems, and one-off account requests.

    Listen for sequencing as much as content. A leader who wants to hire a large team before inspecting the segment, pipeline, and motion may be importing a scaling playbook into a company that is still discovering how it wins. A builder should be able to say what must be learned before each additional investment.

    Keep product, sales, and delivery in one operating rhythm

    Enterprise GTM degrades when sales reviews pipeline, product reviews output, and customer success reviews adoption in separate systems. The customer experiences one journey. Your operating rhythm should connect the promise made during evaluation to the value delivered after launch.

    A weekly operating review should focus on the current constraint. Ask whether the customer’s core job was solved, whether sales and success can prove the outcome with a repeatable story, which deals are exposing a shared readiness gap, and whether the next action belongs to product, enablement, qualification, or implementation. End with a decision, an owner, and the evidence that will show whether the decision worked.

    Use outcome-based objectives so teams do not confuse shipped features, completed training, or created pipeline with customer value. Product trios can keep discovery, design, and engineering close to customer evidence. Continuous delivery and deployment-frequency measures can show whether the organization has enough learning and delivery cadence, but speed cannot come at the expense of the reliability enterprise customers expect.

    If you are scaling several products, give each product line clear ownership of its roadmap, customer outcome, positioning, and GTM target. Anchor those lines to shared platform capabilities for identity, data, and extensibility. This preserves the focus of a small business unit while preventing every product from rebuilding the enterprise foundation independently. Product managers then operate as owners of outcomes and business-like metrics, not merely coordinators of feature delivery.

    The standard for each product should remain demanding: it must be able to win on its own merits. Bundling can improve distribution, but it should not conceal a weak value proposition. If a product cannot articulate and prove why its intended customer would choose it, sharpen the offer or stop expanding its GTM capacity.

    Key takeaways

    • Enterprise sales friction often reveals a readiness gap in architecture, security, governance, proof, implementation, or change management. Classify the gap before prescribing more sales activity.
    • Product-market fit proves customer value. Product-market-sales fit proves that your company can reproduce discovery, purchase, delivery, retention, and expansion.
    • Measure win rate by segment, stage-level cycle time, ramp to a first independent deal, multi-threading depth, net revenue retention, and expansion within two quarters.
    • Let the ICP govern qualification and roadmap trade-offs. A prestigious account is still a poor bet if winning it requires product changes that do not compound across the intended market.
    • Meet enterprise points of parity, then win with one testable differentiator that materially changes the customer’s decision.
    • Plan from productive capacity, qualified pipeline, observed conversion, territory intent density, and the time remaining in the buying cycle. Do not treat newly hired reps as instant capacity.
    • Hire a sales leader who can build the motion, maintain pipeline discipline, disqualify intelligently, and partner with product on where the company wins.

    Start with one enterprise segment and one recent opportunity cohort. Classify every win, loss, and stall across readiness, value, ICP, positioning, enablement, and execution. Pick the first shared constraint, assign one owner, and define the evidence you expect to change. Add sales capacity only when you can name the working motion it will reproduce.

    References

    • Shivam.Consulting Blog — Scaling 16 ‘Startups Within a Startup’: My Enterprise GTM, PMF, and Sales Hiring Playbook