AI search is quickly becoming the new homepage for startups. When a buyer asks a model for the best tools, they often take the short list at face value. I treat this moment as a product surface I can influence with strategy, content, structure, and distribution—much like any other go-to-market channel.
Early on, I set a simple objective for my team and me: "Learn how LLMs like ChatGPT and Perplexity decide which startups to recommend and what signals help a brand get discovered in AI search." That sentence became our north star for experiments, instrumentation, and content architecture.
Here is the mental model that consistently holds up in practice. Large language models synthesize answers from a knowledge graph built from crawled content, citations, and high-signal sources. They weight consensus, clarity, recency, authority, and machine-readability. I don’t pretend to know the internals, but across hundreds of tests, the same patterns correlate with being surfaced and cited.
First, I make our entity unambiguous. I standardize the company name, product names, and leadership bios across the site and external profiles. I implement Organization and Product markup with schema.org and link out with sameAs to authoritative profiles like LinkedIn, Crunchbase, GitHub, and key directory listings. The goal is to collapse ambiguity so AI search knows exactly who we are and which claims are attributable to us.
Next, I publish definitive, answer-first pages. For every core query—what we do, who it’s for, outcomes, differentiators, pricing, comparisons, and integrations—I ship a page that leads with a crisp summary, then supports it with evidence, examples, and plain language. I include Q&A sections, realistic use cases, and named case studies so models can quote and ground responses in verifiable facts.
I then make the site maximally machine-readable. I add schema.org for SoftwareApplication, Product, FAQPage, and HowTo where relevant. I keep titles, H1/H2 structure, internal links, and metadata descriptive and consistent. I expose last-modified dates, maintain an XML sitemap, and keep a visible changelog and release notes. Freshness matters—Perplexity, in particular, tends to privilege recent, well-cited material when answering time-sensitive questions.
Citations are non-negotiable. I earn credible mentions on third-party properties, analyst lists, comparison pages, and customer reviews. I prioritize authoritative placements over volume, then make sure our site references those sources to reinforce the signal. When Perplexity cites our page alongside a respected third-party review, our inclusion rate in answers rises noticeably.
I also design for developers, buyers, and machines at once. That means clean docs, integration pages, and transparent security and trust content. Clear API references, integration guides, and reliability notes give models concrete artifacts to summarize. Pricing, privacy, and support policies reduce uncertainty and increase the likelihood that an answer will include us.
Measurement turns this from a hunch into a system. I run controlled content experiments, track minimum detectable effect on discovery and mentions, and instrument referral patterns from AI assistants when citations appear. I monitor which prompts surface our brand, which sources are cited, and which pages are repeatedly used as references. When we move a KPI, we codify the pattern into our playbook and scale it.
Trust is the compounding advantage. I maintain a transparent trust center, privacy-by-design posture, and clear data governance practices. I remove vague claims, back up benefits with evidence, and keep all performance or security statements auditable. Models tend to lift brands that feel low-risk, well-documented, and widely corroborated.
If you want a fast start, here’s the checklist I rely on. Standardize your entity and ship schema.org. Publish answer-first pages for core jobs-to-be-done, comparisons, and integrations. Earn authoritative third-party citations and reference them. Keep release notes, changelogs, and dates current. Instrument AI discovery and iterate based on what gets cited. Do this consistently, and your startup earns a fair shot at being recommended when buyers ask AI for the best options.
Inspired by this post on Amplitude – Best Practices.
I’ve spent my career building products and teams that I intend to steward for the long haul, and I’m drawn to founders who treat company-building as a craft you can practice forever. In this analysis, I break down a journey that crystallizes what it takes: going from a teenage wholesale hustle to an API-first healthcare clearinghouse, and in the process, learning why execution isn’t a moat, why venture capital is “going pro,” and how “eating glass” can become a durable advantage.
Here’s the arc that anchored my thinking: a founder who, at 16, turned $2,500 into a wholesale empire; later bootstrapped a wildly profitable auto-parts business; then sold it to tackle “the most complicated problem” he’d ever encountered: business-to-business transaction exchange. He spent years building EDI infrastructure, threw away the entire codebase eight times, and found extraordinary traction in healthcare. The company recently raised a $70M Series B co-led by Stripe and Addition. The throughline is a consistent, high-agency approach to product management and go-to-market strategy, guided by first principles decision making.
The first customer is often the trickiest—not because demand doesn’t exist, but because the product’s value proposition, points of parity, and competitive differentiation are still coalescing. I push teams to do founder-led GTM early, speak in the user’s language, and orchestrate high-signal conversations that expose real switching costs. That’s how we avoid mistaking polite interest for product-market fit.
Bootstrapping forces rigor, but it also means being “constrained by capital.” There’s a ceiling to the speed at which you can iterate, validate, and scale. Venture capital, in the right context, is like “going pro”: you trade a bit of optionality for time, talent density, and a faster feedback loop. I often see confusion between ownership vs. control; structurally, you can design for alignment while still moving with the urgency a competitive market demands.
One theme I return to with my own teams: execution is never actually a moat. Processes can be copied. Culture can be mimicked superficially. What can’t be easily replicated is the willingness to do the unglamorous, compounding work—what the founder here called “eating glass.” It’s the daily discipline of simplifying the system, instrumenting the edge cases, and standing up operational excellence that compounds into true competitive differentiation.
When product-market fit hits in enterprise infrastructure, it can feel like “the snake swallowing a deer.” Capacity, process, and architecture are stretched to their limits all at once. I’ve experienced the same pattern: everything slows down so the organization can re-architect for scale. The trick is to make those constraints visible—measure service levels, queuing, and error budgets like you would in a production system—so you’re not flying blind.
Some of the strongest product-management instincts I’ve seen borrow from discount retail and Toyota. From discount retail, we learn to obsess over unit economics, operational throughput, and ruthless simplification. From the Toyota production system, we adopt Kanban / TPS (Toyota), continuous improvement, and respect for constraints. In software terms, this becomes fast deployment frequency, small batch sizes, and defect prevention at the source—because “All software is a cascade of miracles.”
Scaling decision-making is where most teams stall. I favor clear ownership, lightweight written narratives, and a bias for first principles decision making over committee compromise. That structure lets high-agency individuals move quickly while keeping cross-functional stakeholders aligned on outcomes vs output OKRs. It’s how you build empowered product teams without sacrificing focus.
Hiring is where philosophy becomes practice. I resonate with the onboarding mantra “everything’s your fault now”—not as blame, but as an invitation to own outcomes end to end. I look for high-agency people who demonstrate systems thinking and the capacity to simplify. Manager hiring should lag role clarity; bring in managers when coordination overhead is the limiting factor, not when it merely feels uncomfortable.
Longevity comes from founder-approach fit as much as product-market fit. Build a company you don’t want to leave by aligning operating cadence, decision rights, and cultural norms with how you actually work best. Maintain conviction in unconventional practice when the evidence supports it, while remembering that “Reality has a surprising amount of detail.” The more I zoom in on the real work—interfaces, edge cases, workflows—the more the right design emerges.
In healthcare EDI, that realism matters. HIPAA overview (HHS) sets the compliance baseline. Payer integrations with Aetna, Blue Cross Blue Shield, and Cigna demand reliability and deep domain fidelity. Cloud and back-office ecosystems—from AWS and NetSuite to Slack, Microsoft Teams, Zapier, and Clay—shape the surrounding workflow. Lessons from Amazon, Target, Walmart, and Costco inform operational rigor; supply chain analogies from Ford Motor Company and GM clarify interface contracts. Porter’s five forces helps frame market structure; perspectives from Jeff Bezos and Peter Thiel sharpen strategic posture.
If you’re building for the long run, here’s the blueprint I use with product leaders: validate painfully specific jobs-to-be-done before you scale; prefer founder-led GTM until messaging closes the intent-to-adoption gap; instrument throughput and quality like a production system; invest in people who treat ambiguity as a chance to lead; and don’t confuse speed with hurry. When the “snake swallowing a deer” moment arrives, re-architect deliberately, protect your margins, and let operational excellence carry you from product discovery to durable product-led growth.
References and resources: Aetna: https://www.aetna.com/, Amazon: https://www.amazon.com/, AWS: https://aws.amazon.com/, Blue Cross Blue Shield: https://www.bcbs.com/, Change Healthcare: https://www.changehealthcare.com/, Cigna: https://www.cigna.com/, Clay: https://www.clay.com/, Costco: https://www.costco.com/, Ford Motor Company: https://www.ford.com/, GM: https://www.gm.com/, HIPAA overview (HHS): https://www.hhs.gov/hipaa/index.html, Jeff Bezos: https://x.com/JeffBezos, Kanban / TPS (Toyota): https://global.toyota/en/company/vision-and-philosophy/production-system, Microsoft Teams: https://www.microsoft.com/microsoft-teams, NetSuite: https://www.netsuite.com/, O’Reilly Auto Parts: https://www.oreillyauto.com/, Peter Thiel: https://x.com/peterthiel, Porter’s five forces: https://www.isc.hbs.edu/strategy/pages/the-five-forces.aspx, “Reality has a surprising amount of detail”: https://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail, Slack: https://slack.com/, Stedi: https://www.stedi.com/, Summit Racing: https://www.summitracing.com/, Target: https://www.target.com/, Walmart: https://www.walmart.com/, Zapier: https://zapier.com/
"Can you critique the landing page for my new Story-Based Customer Interviews course?" That simple ask used to kick off hours of back-and-forth where I fed an AI the same context over and over—only to get generic feedback that wouldn’t land with my audience or fit my products. As a product leader, that inefficiency was unacceptable; as a writer, it was just plain frustrating.
Not anymore. Today, Claude not only critiques my work, it helps me produce it. It generates marketing copy—in my voice. It helps me write blog posts. It knows what search terms are relevant to my business and helps me optimize my articles for SEO and now AEO. It helps me with competitive research, academic research, and discovery research. And it does all of this with little prompting from me.
I don’t upload files to a web-based project. I don’t manage elaborate prompt libraries. I don’t repeat myself. I ask for help and Claude knows exactly what to do. The shift happened when I learned how to give Claude Code a memory. Claude now knows who my target customer is, the key value propositions I focus on, the specific opportunities each product addresses, my revenue model, my marketing channels, and so much more.
A dark-themed strategy slide for the post Stop Repeating Yourself: Give Claude Code a Memory, showing how to lead with a CLAUDE.md glossary page, write clearly for nontechnical readers, and link glossary and article to boost discovery and engagement.
With that memory, I consistently get high-quality output tailored to my audience and aligned to my products and services. I don’t retype the same context; Claude just remembers. In this article, I’ll show you exactly how I set up that memory. It relies on Claude Code (which requires a Pro subscription), and it’s worth it. If you’re new to Claude Code, start with "Claude Code: What It Is, How It’s Different, and Why Non-Technical People Should Use It."
Here’s the underlying problem: with large language models, every conversation starts from scratch. Yes, ChatGPT can remember some things and Claude can search past conversations, but practically speaking each new thread wipes the slate clean. If I were working on a new landing page, I’d normally need to upload target customer context, product details, primary and secondary value propositions, FAQ questions and answers, plus testimonials and logos for social proof—every single time.
Start fast with Claude’s home screen: Sonnet 4.5 is ready, and quick actions for writing, learning, and coding sit beneath a clean prompt box—ideal for showing how memory cuts repetition and streamlines daily development.
Projects in web-based tools help a bit, but they introduce a new dilemma. When I move to the next landing page targeting the same customer but a different product and value proposition, do I start a new Project (tedious) or keep expanding the old one (which muddies the context window and degrades output quality)? The good news: Claude Code solves this by giving the model a precise, durable memory without overloading any single conversation.
Claude Code can read files on my local machine, which is an understated superpower. I use those files to create a persistent, reusable memory that works across all chats and Projects. Files can be mixed and matched, so I give Claude exactly what it needs for the task at hand—and nothing more. For a first landing page, I reference the target customer and the relevant product; for the second, I reuse the same target customer file and point to the new product file.
Dark-mode Notes screenshot captures Claude Code in action: it fetches producttalk.org, reads context files, and delivers a concise homepage evaluation—showing how memory streamlines repeated analysis tasks.
When you give an LLM the exact right context, output quality jumps. More context only helps if it’s the right context. For a landing page, Claude needs to know about the current product and perhaps related products for differentiation—but it doesn’t need to know about unrelated offerings. Structure your memory so Claude gets precisely what’s required.
Once I did this, Claude shifted from “intern who needs handholding” to trusted advisor and capable teammate. It doesn’t guess at my value propositions—I’ve already told it. It writes in my voice because it has my writing guide and samples. It knows who owns which course and which use cases map to which features. The setup takes a bit of upfront work, but it compounds: update a file when something changes and you’re done. Most of this information already lives in your system; the trick is making it easy for Claude to use.
See how Claude Code stops repetition: global and project CLAUDE.md files, plus custom reference docs, flow into the editor so the assistant remembers your preferences and context while you code and run commands.
Because the files live on my machine, I own the system. No vendor or device lock-in. I decide when and who to share with. I can work with Claude on one project and ChatGPT on another—both can rely on the same file-based memory strategy. It’s an AI strategy that scales with product discovery, accelerates go-to-market content, sharpens competitive differentiation, and supports product-led growth.
Here’s how I design the memory: I use three layers. Claude Code already encourages global preferences and Project-specific instructions, but the third layer—reference context—is where the real power lives.
Peek inside a markdown playbook for Claude Code: concise rules for writing, multi-level planning, and clear feedback that turn repeated reminders into reusable memory and smoother, faster coding sessions.
Layer 1: Global Preferences (Always on). The first time I launched Claude Code, I created a CLAUDE.md file at ~/.claude/CLAUDE.md. This is where I keep the cross-project rules of engagement—how I like to work with Claude. Mine includes: Always create a plan for me to review before you start any work; Give me direct feedback (no hedging, no gentle suggestions); Use bullet points for summaries; Ask clarifying questions one at a time so I can give complete answers; No emojis unless I explicitly ask for them. Claude Code automatically loads this file at the start of every session, so I never restate my preferences.
Layer 2: Project-Specific Instructions. Different projects have different rules. In my writing workspace, the Project CLAUDE.md sets the roles (I’m the primary writer; Claude is my thought partner and editor), defines a multi-round review flow (content → structure → accuracy → typos), prioritizes human readability over SEO, and points to my writing style guide. In my task management system, I include how my Trello integration works, file naming conventions for tasks, and how to process research papers into summaries. In my code projects, I specify the technology stack (Node.js vs. Python), testing framework (Jest for Node.js, pytest for Python), code style and conventions, project architecture and directory structure, and which dependencies and libraries to use. Each project directory has its own CLAUDE.md, and Claude automatically loads the relevant file when I’m working there.
Peek inside a markdown playbook for collaborating with Claude—covering session setup, roles, editorial standards, and research steps—to show how saved instructions create consistent results without repeating yourself.
Layer 3: Reference Context (Pull as Needed)—the real power. LLMs have a context window—a limit to how much they can process at once. Even within that limit, loading too much degrades performance due to “context rot.” The remedy is ruthless context management: small, targeted files that load only when needed. Keep CLAUDE.md files concise and focused on rules and workflows. For detailed knowledge, create separate reference files and list them in your CLAUDE.md so Claude knows they exist and when to fetch them. When I ask for help creating a landing page, Claude knows to use my business profile, the product file, and my target customers context.
Here’s what most people miss: you don’t cram everything into global or Project files. You maintain small, reusable reference files that Claude only loads on demand. In my walkthrough, I share exactly which context files I created and why; how I got Claude Code to help me create them; how I break them into small, reusable components so Claude gets precisely what it needs; how I keep everything up to date; and step-by-step instructions so you can set up a similar memory system.
Three project notes funnel into Claude Code, turning reusable context into working output. This visual shows how saving key docs as memory lets the AI pick up where you left off and skip repetitive prompting across tasks.
Your homepage promises an all-in-one platform. The sales deck leads with automation. The product demo focuses on analytics. Each claim may be true, but together they force the buyer to work out what you are, whom you serve, and why you matter. That is a positioning failure, not a copy problem.
The way out is to separate the strategic choice from its expression. First decide which customer and buying situation you intend to win. Then build a messaging system that carries that decision from the first impression through sales, onboarding, and product use. The method below gives you the artifacts, tests, and operating rules to do both.
Separate the strategic decision from the words
Positioning, messaging, and copy are related, but they solve different problems:
Positioning decides the target segment, urgent customer job, category, primary alternative, promised outcome, meaningful difference, and proof.
Messaging decides which parts of that position to emphasize, in what order, for each audience and stage of the buying journey.
Copy turns the message into a headline, sales talk track, pricing-page explanation, onboarding prompt, or product-tour step.
This distinction tells you where to intervene. If leaders disagree about the customer or alternative, a headline workshop will only conceal the disagreement. If the position is clear but buyers do not understand it, the messaging hierarchy needs work. If the hierarchy is sound but one page underperforms, you may have a copy or execution problem.
I use a simple diagnostic: ask the product, marketing, sales, and customer-success owners to complete the following prompts independently. Do not let them discuss wording first.
The customer I most want to win is…
They look for a solution when…
The progress they need is…
They would otherwise use, assemble, or tolerate…
They should choose this product because…
The evidence that makes that claim credible is…
Compare the nouns and decisions in the answers, not their polish. If one person names agencies, another names sales teams, and another says any growing business, you do not have a shared target. If the alternatives range from a direct competitor to spreadsheets and doing nothing, the team is framing different buying decisions. Resolve those differences before approving new copy.
The output of this diagnosis should be a short list of strategic questions, each with an owner and an evidence gap. That is far more useful than a document full of compromise language.
Build the position from evidence, not ambition
Choose a segment that behaves like a good customer
A broad market description is not a target segment. Modern teams, small businesses, and enterprises are labels, not choices. A usable segment combines a buyer or user, an operating context, a trigger, and a need that is unusually important in that context.
Start with behavioral evidence from activation, retention, and expansion. Look for cohorts that reach meaningful value, continue using the product, and deepen their commitment. Then investigate why. A large cohort that requires heavy persuasion and struggles to retain may be a less attractive positioning target than a smaller cohort that recognizes the problem immediately.
Write a segment brief with four fields:
Who: the buying role, user, or accountable leader.
Context: the company type, workflow, maturity, or constraint that changes the value of the product.
Trigger: the event that turns a background inconvenience into a priority.
Exclusion: a plausible customer for whom the product is not the best fit.
The exclusion is important. If you cannot say who should not buy, the segment is probably still too broad. Specificity does not make the total market disappear. It gives your message a place to land.
Name the progress, not the product output
Customers do not wake up wanting a dashboard, an AI assistant, or another system of record. They want to make a decision sooner, remove a risky handoff, create predictable pipeline, reduce manual work, or gain control over an outcome they already own.
Complete this sentence using the customer’s language: After adopting this product, the customer can do what they could not do reliably before? The answer should describe progress in the customer’s world. A capability belongs in the explanation of how the result happens, not in the result itself.
Tie the promise to a business result the customer already tracks, but do not add a number merely to make the claim sound concrete. A quantified promise requires evidence that supports the same segment, use case, and conditions. Until you have that evidence, state the direction of value plainly and use verified proof lower in the message.
Define the category, alternative, difference, and proof
The buyer needs a familiar frame before your differentiation can matter. A category tells them what kind of decision they are making. Points of parity tell them you meet the minimum conditions for consideration. Differentiation tells them why you should win after you qualify.
Decision
Question to answer
Common failure
Category
What familiar kind of solution is this?
Inventing a label the buyer must decode before understanding the product.
Points of parity
What must be true for the product to make the shortlist?
Leading with table stakes as if they were differentiation.
Alternative
What would the customer use, assemble, or tolerate without this product?
Assuming the only alternative is a named competitor.
Differentiation
Which valuable outcome or mechanism is meaningfully better?
Using adjectives that any competitor could copy.
Proof
What evidence supports the exact claim?
Offering confidence, popularity, or technical detail that does not prove the promise.
The primary alternative may be a competitor, a generic platform, a manual workflow, a collection of tools, or the decision to do nothing. Name the one that appears in the buying situation you are targeting. Your differentiation is meaningful only in relation to that alternative.
Proof can take several forms: measured customer outcomes, time-to-value evidence, product behavior, implementation evidence, data-governance controls, privacy-by-design, or cybersecurity commitments. Match the proof to the anxiety created by the claim. If you promise speed, prove speed. If you promise control, prove governance. A list of impressive but unrelated facts will not close the credibility gap.
For [specific customer in a defined context] who needs [urgent progress], [product] is a [familiar category] that delivers [customer outcome]. Compared with [primary alternative], it [meaningful difference], supported by [relevant proof].
Positioning statement template
Treat every bracket as a decision, not a place for the most flattering phrase. Mark each clause as evidence, assumption, or aspiration. Evidence can enter the approved statement. An assumption becomes a test. An aspiration belongs in product strategy until the product and proof can support it.
Before moving on, apply six checks:
Does the segment exclude anyone you could plausibly sell to?
Would the target customer recognize the triggering problem?
Does the category reduce the explanation burden?
Is the alternative one customers actually consider?
Would the difference still matter if a competitor copied the wording?
Does the proof establish the claim rather than merely decorate it?
If a competitor can paste your statement onto its homepage without changing the meaning, you have described the market, not your position.
Turn one position into a messaging system
A positioning statement is an internal decision tool. It is rarely the exact sentence that should appear on every customer-facing surface. Buyers need the same strategic story expressed at different levels of depth.
Build the message in this order:
Category cue: help the buyer place the product on a familiar mental shelf.
Core outcome: state the progress that makes the product worth considering.
Mechanism: explain how the product creates that outcome differently from the alternative.
Proof: supply evidence for the claim and mechanism.
Objection response: address the trade-off, risk, or missing parity point most likely to stop the decision.
Next step: ask for an action that fits the buyer’s current level of intent.
This order prevents two common errors. Leading with features makes the buyer infer the value. Leading with a grand outcome and no mechanism makes the claim sound ungrounded. The combination of outcome, mechanism, and proof gives the message both relevance and credibility.
For an intent-data product, a message unit could work like this:
Claim: Act on buying intent while it is still useful.
Mechanism: Translate live product-usage signals into prioritized opportunities and the appropriate next action.
Proof: Insert only verified evidence, such as observed time to value, measured conversion results, documented governance, or customer validation.
The example does not need faster, smarter, seamless, or revolutionary. Those words add no information unless a mechanism and evidence give them a precise meaning.
Next, create a message map for each audience that participates in the decision. Use the same position, but change emphasis:
Economic buyer: business consequence, strategic fit, financial logic, and adoption risk.
Operational user: workflow improvement, usability, time to value, and what changes in the working day.
Technical or trust evaluator: integration, data handling, governance, privacy, security, and operational control.
For each audience, record the trigger, desired outcome, current alternative, core claim, supporting mechanism, accepted proof, likely objection, and appropriate call to action. That becomes the brief for a landing page, demo, campaign, or onboarding flow.
Do not create a new position for every persona. If an executive hears an efficiency story, an operator hears a feature story, and a technical evaluator hears an infrastructure story with no common outcome, the account receives three products. Keep the strategic claim stable and translate the consequence, mechanism, and proof for the listener.
Consistency does not mean identical copy. It means every message helps the customer reach the same conclusion about whom the product is for, what it changes, and why it is the better choice.
Test for customer movement, not internal applause
A message that wins a leadership vote has passed a preference test. It has not passed a market test. Validation should show whether the intended customer understands the position, believes it, and takes a more valuable next step.
Write the hypothesis before changing the asset:
For [target segment] at [journey stage], emphasizing [message decision] instead of [current framing] will improve [customer behavior] because [expected change in understanding or motivation].
Messaging experiment hypothesis
Then run the test with the following controls:
Capture the current baseline and the audience definition.
Change one meaningful message decision, not the message, design, offer, and traffic source at the same time.
Choose a primary metric that reflects progress at that stage of the journey.
Add guardrails for downstream quality, retention, or unwanted customer mix.
Set the decision rule before reviewing the result.
Record what changed, what happened, for whom it happened, and what the result does not establish.
The metric must match the surface:
Acquisition page: qualified conversion is more useful than raw visits or attention.
Sales conversation: look for clearer problem recognition, fewer category misunderstandings, relevant objections, and progression to the agreed next step.
Onboarding: measure activation and completion of the behavior tied to the promised value.
In-product message: measure the meaningful action after the prompt, not merely a tooltip click.
Expansion motion: look for adoption and commercial movement in the segment the message was intended to reach.
A higher click-through rate with weaker qualified conversion is not a positioning win. It may mean the new wording creates curiosity but attracts the wrong expectation. Follow the behavior far enough to see whether the message improves customer fit rather than only top-of-funnel volume.
If traffic is too limited for a reliable A/B test, use customer interviews, comprehension checks, sales-call analysis, and structured message reviews to learn why language works or fails. Treat that evidence as directional. Interview feedback can reveal confusion, relevance, and objection mechanisms, but it should not be relabeled as causal conversion lift.
Keep a decision log. For every experiment, store the segment, surface, control, variant, hypothesis, primary metric, guardrails, result, interpretation, and next decision. Without that record, teams repeatedly test synonyms while forgetting the strategic assumption underneath them.
Read results diagnostically. A message that improves acquisition but not activation may be setting an expectation the product does not fulfill. A message that works for one retained cohort but fails for another may reveal that the target segment is too broad. A claim that repeatedly requires explanation may indicate a poor category choice. The purpose of testing is not to defend the original language; it is to improve the decision system.
Make positioning part of the product operating system
Positioning decays when it lives only in a launch deck. Sales adapts the story to objections, marketing optimizes individual campaigns, product ships capabilities, and onboarding inherits old promises. Each local choice can seem reasonable while the overall narrative drifts.
Create one canonical positioning brief with:
An accountable owner, version, approval date, and current validation status.
The target segment, trigger, and explicit exclusions.
The urgent job and customer outcome.
The category and required points of parity.
The primary alternative and competitive difference.
Approved proof for each claim, including any conditions or limits.
The message hierarchy and audience-specific message maps.
Known objections, prohibited unsupported claims, and open assumptions.
Links to experiment results and the decisions they changed.
The brief should govern product decisions as well as communication. When reviewing roadmap work, ask whether the item strengthens the promised outcome, closes a parity gap that blocks consideration, compounds the reason to choose the product, or creates proof for a claim customers already value. Work that does none of these may still be necessary, but it needs a different strategic justification.
This prevents differentiation from becoming a slogan unsupported by investment. If the product claims a uniquely fast path to value while roadmap decisions add setup complexity, the market will eventually believe the experience rather than the headline.
Roll the position through the connected customer journey. Update the homepage, pricing explanation, sales discovery, demo narrative, onboarding, product tours, in-app guidance, customer-success materials, and nurture sequences that rely on the old framing. Prioritize the surfaces where the intended segment makes or validates its decision. A new promise on the homepage paired with an old demo and unrelated onboarding creates more confusion than a controlled, coherent rollout.
Give one owner authority to maintain the canonical brief, while making product, marketing, sales, and customer success responsible for contributing evidence. Version meaningful changes. A headline iteration does not require a new strategic version; changing the target segment, category, alternative, outcome, or differentiation does.
Review the position when evidence changes, not merely because the calendar says it is time. Useful triggers include a major product launch, entry into a new segment, a shift in the alternative customers choose, a parity gap that changes shortlist eligibility, new proof that strengthens the promise, or a persistent mismatch between acquisition, activation, retention, and expansion.
Do not rewrite the position after every losing copy test. A failed expression and a failed strategic premise are different diagnoses. Change the position only when the evidence shows that the customer, problem, category, alternative, promise, or reason to believe has changed.
Key takeaways
Resolve disagreements about the customer, buying trigger, category, and alternative before debating headlines.
Choose a segment using activation, retention, and expansion behavior, then document whom the position excludes.
Build every major message from an outcome, a distinctive mechanism, and proof that supports the exact claim.
Test messaging against meaningful customer behavior and downstream quality, not internal preference or clicks alone.
Use the approved position to guide roadmap trade-offs, go-to-market assets, onboarding, and future experiments.
Take your current positioning statement and label every clause as evidence, assumption, or aspiration. Pick the assumption that would most change the strategy if it proved false, and design the next customer or behavioral test around it. Validate the decision before rewriting every surface. Once it holds, carry the same position all the way into the product experience.
Go hard early is more than a mantra—it’s a product strategy. When I study the most durable enterprise companies, I see the same pattern: you win by shipping fast, obsessing over the customer’s day-to-day pains, and delivering consumer-quality experiences to business buyers. That lens is exactly why Serval’s recent momentum caught my attention and why the lessons behind it matter for every product and IT leader building in AI.
Jake is the founder and CEO of Serval, an AI-driven IT automation and service management platform that just raised $47M in Series A funding this week. Before founding Serval, Jake spent over five years at Verkada, where he led multiple products from 0-1 and helped scale the company across hardware and software. His years at Verkada taught him that winning in enterprise means delivering consumer-quality experiences to business buyers — a lesson that shapes how Serval turns complex IT automation into something that feels magical.
From my vantage point, the most counterintuitive lesson here is the power of building “in existing categories.” Rather than inventing a new market, the better move can be to redefine expectations inside a known one—where buyers, budgets, and success criteria already exist. That’s how you compress sales cycles, build trust rapidly, and create a wedge for product-led growth without boiling the ocean.
Another playbook thread I admire: turning “hard mode” into a moat. The teams that lean into gnarly integrations, real workflow depth, and enterprise-grade reliability end up compounding an advantage that’s very hard for fast followers to copy. That mindset shows up in Serval’s platform strategy and, more importantly, in how they translate complex IT work into something that feels intuitive on day one and powerful on day 100.
Customer intimacy sits at the center of that strategy. The customer interview question that unlocked the IT buyer’s hidden pain points is the kind of move I try to operationalize across product trios and forward-deployed teams. When you ask not just, “What do you do?” but, “What do you do when everything breaks?” you surface the real constraints: shadow runbooks, brittle scripts, brittle processes, and the political friction that slows down response times. That’s where durable value—and competitive differentiation—lives.
How Serval’s automation builder uses AI to generate code-based workflows is a particularly smart architectural choice. Code-first doesn’t mean hard-to-use; it means source-controlled, interoperable, and shareable across teams—exactly what IT leaders want when automation moves from side project to system of record. Tie that to agentic orchestration and you get reliable automations with clear observability, safety rails, and the ability to scale without collapsing under edge cases.
I’m also a believer in redefining engineering and PM roles with forward-deployed engineers. When engineers partner directly with customers, discovery accelerates, prioritization sharpens, and product bet quality improves. You avoid ping-ponging requirements through layers, and you raise the hiring bar for true product creators who can think in outcomes, not just output.
Keeping the hiring bar high in an AI-native startup isn’t optional—it’s existential. The best teams screen for candidates who can reason from first principles, ship quickly with taste, and articulate the value proposition in plain language. The ultimate hiring litmus test is whether someone can improve the product on day one by clarifying a user journey, simplifying a workflow, or tightening a metric that actually matters.
There’s also Why there’s a “land grab” moment right now in enterprise AI. Incumbents are strong on breadth but often slow to re-architect for AI-native workflows. New entrants that show up with opinionated defaults, pragmatic security, and crisp buyer narratives can establish points of parity quickly while extending into true points of differentiation. That’s the window to seize—especially when building for mid-market and enterprise.
Here are the core themes I took away and how I translate them into practice across product roadmapping and sprint planning, product discovery, and go-to-market strategy.
Why building “in existing categories” can be more powerful than creating new ones. Use the market’s mental models, measure against known alternatives, and win by delivering a meaningfully better experience—not by forcing buyers to invent new procurement paths.
The lessons from Verkada that shaped Serval’s platform strategy. Treat UX polish as a strategic asset, make setup effortless, and let power users go deep without friction. Consumer-grade quality is not a veneer; it’s a trust accelerator in enterprise.
The customer interview question that unlocked the IT buyer’s hidden pain points. Go beyond happy-path discovery. Ask about the 3 a.m. moments, the panic buttons, and the messy handoffs—then design for those first.
How Serval’s automation builder uses AI to generate code-based workflows. Pair AI generation with reviewability, versioning, and safe rollbacks. Make it easy to see, test, and share what the agent is doing under the hood.
Redefining engineering and PM roles with forward-deployed engineers. Collapse feedback loops by putting builders where the problems are. It’s the fastest path to product-market fit lessons and real-world reliability.
Keeping the hiring bar high in an AI-native startup. Look for taste, speed, and ownership. Optimize for people who can both prototype with gen ai and ship production-hardened systems.
Why there’s a “land grab” moment right now in enterprise AI. Move quickly, but anchor on outcomes. Land with a wedge use case, expand with measurable value, and maintain clear points of parity while you deepen differentiation.
If you want to follow or explore the companies and leaders referenced, these links are a useful starting point.
This podcast on all platforms: https://review.firstround.com/podcast
References:
Alex McLeod: https://www.linkedin.com/in/alexmcleodio/
Clay: https://www.clay.com
Cloudflare: https://www.cloudflare.com
Cursor: https://cursor.sh
Filip Kaliszan: https://www.linkedin.com/in/kaliszan/
Hans Robertson: https://www.linkedin.com/in/hansrobertson
Linear: https://linear.app
Okta: https://www.okta.com
Rippling: https://www.rippling.com
Serval: https://www.serval.com/
ServiceNow: https://www.servicenow.com
Verkada: https://www.verkada.com
Workday: https://www.workday.com
Timestamps and topic highlights for easy navigation and deeper study:
(02:25) Lessons from holding different product roles
(07:29) Turning “hard mode” into a moat
(10:49) The early days of Serval
(12:59) Scratching the founder itch
(14:57) Unconventional interview techniques
(17:47) Solving core interview challenges
(21:10) Planning the early product roadmap
(23:03) The surprising power of patience
(26:12) Serval’s impressive technical advantage
(27:35) Disrupting legacy incumbents
(31:13) Building for mid-market and enterprise
(33:35) Serval’s enduring roadmap
(36:08) How to sell to an existing market
(39:16) The evolving role software plays
(43:55) Building for AI that didn’t exist yet
(49:49) Serval’s forward-deployed engineers
(58:31) The hybrid PM-GM
(1:00:27) “You can over-prioritize”
(1:02:48) The unexpected value of panic buttons
(1:04:50) What Serval looks for in new talent
(1:07:01) The ultimate hiring litmus test
(1:13:59) Building out Serval’s go-to-market function
(1:16:31) The evolving IT market in 2025
My bottom line: build where budgets already live, ship with uncompromising UX, embed engineers with customers, and hold the line on talent. Do that, and you won’t just keep up with the enterprise AI “land grab”—you’ll define the standard others have to meet.
I’m fascinated by how the most credible legal-tech platforms operationalize AI in the enterprise, where risk tolerance is near zero and trust is the product. When I evaluate solutions in this space, I look for rigor in model design, governance, and go-to-market execution—not just raw model performance.
Discover how Luminance CEO Eleanor Lightbody builds Legal-Grade™ AI for enterprise. See how their specialized, agentic AI models lawyers trust at scale.
That framing resonates with me. “Legal-Grade™” isn’t a slogan; it’s a product requirement that implies auditable decisions, explainable outputs, robust data governance, and demonstrable accuracy under real-world legal workflows. “Agentic AI” adds another layer: autonomous orchestration of tasks with explicit guardrails, role definitions, and escalation paths to humans-in-the-loop.
From a product management perspective, I start with outcomes. For legal teams, the jobs-to-be-done are concrete: contract analysis and redlining, due diligence, compliance reviews, investigations, and eDiscovery. The success criteria are equally concrete: precision and recall on domain-specific clauses, latency under load, traceability of sources, and the ability to scale across matter types, jurisdictions, and languages without degrading trust.
Building that foundation requires deliberate AI strategy. I look for domain-specialized models, retrieval-augmented generation tuned to legal corpora, evaluation harnesses with gold-standard datasets, and continuous red-teaming. Just as important are deployment choices—on-prem or VPC isolation, encryption in transit and at rest, strict PII handling, and granular access controls—to satisfy the security posture of enterprise legal and compliance teams.
Governance is where “legal-grade” is won or lost. Robust audit trails, versioned prompts and policies, model cards, clear data lineage, and event logs that support defensibility are table stakes. Human review workflows, explainability tooling, and remediation paths ensure the system remains trustworthy when edge cases arise.
On product process, I favor empowered product teams and forward-deployed engineers partnering directly with attorneys and legal ops. Co-designing workflows with subject-matter experts surfaces the right constraints early: how redlines are presented, what confidence thresholds trigger review, and where to anchor the user experience in familiar legal tools and document structures.
Competitive differentiation and product positioning hinge on clarity: what specific legal outcomes are delivered faster, safer, or more accurately than alternatives? I prioritize transparent benchmarking against baselines, proof-of-value pilots that mirror production data conditions, and pricing that aligns to measurable outcomes (e.g., time-to-first-draft, review throughput, or risk reduction) rather than abstract usage metrics.
Go-to-market strategy in enterprise legal is a discipline in itself. Expect rigorous InfoSec reviews, stakeholder alignment across legal, IT, and procurement, and the need for customer references that demonstrate “trust at scale.” Clear messaging around value proposition, safety posture, and operational readiness shortens cycles and builds confidence among risk-averse buyers.
The big takeaway for product leaders: Legal-Grade™ AI isn’t about novel models; it’s about orchestrating specialization, safeguards, and enterprise-grade delivery into a coherent system that lawyers can rely on daily. When agentic AI is harnessed with the right guardrails and domain depth, it becomes a force multiplier for legal teams—accelerating work without compromising standards.
Inspired by this post on Amplitude – Perspectives.
Early in any market, I obsess over one thing before splashy features or clever messaging: are we meeting the table stakes that buyers expect? Points of parity (POPs) are the baseline capabilities that put us on a buyer’s shortlist and establish the credibility to compete. Without them, even the best differentiators won’t land.
Understand how points of parity are crucial to getting your foot in the door. Explore different strategies to make POPs work for your SaaS business.
Here’s how I define POPs in practice: they’re the “no-regrets” features, assurances, and experiences that customers assume you have because your competitors already do. In SaaS, that often includes security certifications (e.g., SOC 2), SSO, predictable performance (SLAs/Uptime), clear pricing, responsive support, and integrations with the rest of the customer’s stack.
POPs differ from points of difference (PODs). PODs are what make you unique; POPs are what make you viable. I’ve seen teams try to lead with innovation before building credibility, only to stall in procurement. You earn the right to showcase differentiation after you meet parity.
For SaaS, POPs frequently map to procurement checklists. Think InfoSec reviews, role-based access controls, audit logs, encryption standards, user management, and integrations with systems like Salesforce, HubSpot, or Slack. These aren’t glamorous, but they remove friction, reduce perceived risk, and accelerate time-to-value—cornerstones of product-led growth and a healthy go-to-market motion.
To identify the right POPs, I triangulate across four inputs: customer interviews focused on buying criteria, win/loss analysis to understand disqualifiers, competitor teardowns to benchmark table stakes, and support data to spot recurring gaps eroding trust. Collectively, these inputs reveal the minimum viable promises we must keep.
Prioritization matters. I translate POPs into outcomes (not output) and align them with our roadmapping and sprint planning. For example, instead of “Ship SSO,” I set an objective like “Reduce enterprise security objections by 60%” and measure RFP pass rates, security review cycle time, and sales stage conversion. This keeps us anchored to impact, not just checkboxes.
Execution should be pragmatic. With POPs, “good enough” is often the right bar—reliable, discoverable, and well-documented. Over-engineering POPs slows you down and diverts resources from differentiation. I focus on stable defaults, clear UX patterns, great docs, and in-app guides that help users activate parity features without friction.
Measuring POP health is straightforward if you wire it into your system. I monitor activation rates for parity features (e.g., SSO enabled), support volume tied to trust blockers (security, performance, billing), and the presence of POP gaps in win/loss notes. Retention and expansion are the ultimate validators: when POPs are solid, renewal conversations shift from risk mitigation to value creation.
Consider two tangible examples. For a messaging platform, POPs may include 99.9% uptime, message deliverability guarantees, two-factor authentication, and role-based permissions. For a product analytics tool, POPs could include granular event tracking, user privacy controls, standard dashboards, and self-serve onboarding. None differentiate you alone, but missing any one of them can disqualify you.
Common pitfalls I warn teams about: over-indexing on shiny features while losing deals on basics; inconsistent messaging that promises parity you can’t operationalize; ignoring pricing and packaging parity (buyers expect clear tiers and predictable billing); and underinvesting in enablement, leaving sales to “sell around” missing POPs.
Communicating POPs is as important as building them. I make sure parity shows up on our pricing page, security and reliability pages, and in crisp one-pagers for buying committees. In the product, I highlight parity features during onboarding with checklists and tooltips so customers experience trust quickly. For founder-led GTM, a tight narrative—“Yes, we meet the table stakes; here’s where we go beyond”—keeps discovery calls focused on outcomes.
My playbook is simple: meet parity fast, prove reliability visibly, and then pour fuel on your differentiators. When POPs are nailed, sales cycles shorten, support debt drops, and your unique value finally gets the stage time it deserves.
Inspired by this post on Amplitude – Best Practices.
