Tag: product-market fit lessons

AI-Native Startup Execution: A Practical Operating System

Your startup can produce impressive demos every week and still learn slowly. If model behavior, customer evidence, and deployment feedback move through separate queues, faster shipping only creates more uncertainty.

If you are deciding how to run an AI-native startup, use one standard: how quickly can your team turn a real customer artifact into an evaluated product change and a measurable customer outcome? That standard should shape your wedge, ideal customer profile, team design, sales motion, and operating cadence.

Build the smallest closed learning loop

An AI-enabled company can add a model to an existing product process. An AI-native company has to organize the process around intelligence itself: the data entering the system, the judgment the model makes, the action produced, the evaluation of that action, and the feedback that improves the next decision.

That makes a long AI feature list the wrong starting point. Begin with the smallest end-to-end loop that proves the product’s central claim. In a security product, for example, the loop might start with suspicious activity, produce a risk judgment, stop or downgrade a threat, and capture enough evidence to assess whether the intervention was correct. A polished dashboard without that closed loop is packaging, not proof.

Use three gates before committing to a wedge:

The customer can quantify the problem. Ask for frequency, severity, operational burden, or another observable consequence in the customer’s own workflow. General concern about AI is not enough.
The wedge can create value within one buying cycle. If proving value requires a broad platform rollout, several integrations, and organizational change across multiple functions, you have probably selected a destination rather than an entry point.
Product use improves your data advantage. Determine what feedback the product will capture, whether you can legitimately use it, how quickly it arrives, and which evaluation or model decision it improves. Data volume alone does not create an advantage.

Failing any one of these gates weakens the loop. Urgent pain without accessible data leaves the model blind. Useful data without a near-term outcome produces an experiment that customers may admire but will not adopt. A fast result that teaches you nothing can become a services engagement disguised as software.

Your first version should feel narrower and less polished than the roadmap in your head. It may require manual review, a rough operator interface, or close founder involvement. That is acceptable when the roughness is visible and recoverable. It is not permission to hide model failure, skip evaluations, or make consequential actions impossible to inspect. Cut breadth before you cut control.

Define completion around the loop rather than the interface. You are done with the first proof when a target customer can supply the relevant input, receive the intended outcome, show whether it helped, and feed the result back into a repeatable evaluation. Everything else competes with learning speed.

Choose an ICP that maximizes learning density

The largest market is rarely the most useful starting market. Your early ideal customer profile should concentrate urgency, usable data, workflow access, and a reachable decision maker. Those conditions allow one customer interaction to improve both the product and the go-to-market motion.

Create a one-page ICP card with four evidence fields:

Urgency: What is happening now that makes the buyer act rather than merely agree that the problem matters?
Data pathway: Which alerts, cases, decisions, errors, or other operational artifacts can enter the product and its evaluation process?
Workflow position: Where will your output appear, who will act on it, and what existing step must change?
Success signal: What observable customer outcome would justify adoption, renewal, or expansion?

Rate each field as high, medium, or low, but require an evidence note beside the rating. A founder’s conviction is not evidence. A buyer who can describe the cost of the problem, provide representative artifacts, identify the operator who owns the workflow, and agree on a success signal gives you something testable.

Keep adjacent customer segments out of the first learning loop when they require different data, integrations, evaluation criteria, or buying logic. A larger pipeline can make progress look healthier while mixing incompatible requirements into the roadmap. The practical test is simple: if two prospects would judge the same model behavior by different definitions of success, they should not share an early product plan merely because they could buy from the same company.

Founder-market fit helps here, but it is a compression mechanism rather than proof of product-market fit. Deep domain experience can sharpen the problem statement, reduce translation with buyers, and establish credibility. It cannot substitute for evidence that customers will change a workflow around the product.

Founder-led sales should therefore operate as a structured discovery system. For every lost or stalled opportunity, record the exact objection, the stage at which it appeared, the evidence offered by the buyer, and the suspected root cause. Do not turn each objection into a feature request. Cluster the objections, identify the two most common root causes, and turn those into experiments within a sprint.

Look beyond compliments when judging early product-market fit. Stronger signals appear when customers escalate a problem to your team, volunteer data that can improve the system, or invite you into the workflow where decisions are made. None is conclusive alone, but each requires the customer to spend trust, attention, or organizational effort. That makes them more informative than enthusiasm during a demo.

Organize the team around evaluation and deployment

A conventional feature organization separates product definition, engineering delivery, model work, implementation, and customer support. That creates handoffs precisely where an AI-native startup needs rapid feedback. Organize durable units around a customer outcome, with the people who can inspect data, change the system, deploy it, and evaluate the result.

The exact titles can vary, but the unit needs four capabilities:

Product judgment: Choose the scenario, define the customer outcome, and decide which uncertainty deserves the next experiment.
Model and data judgment: Design evaluations, diagnose failure patterns, and understand whether a change improves one scenario while damaging another.
Product engineering: Turn model behavior into a reliable workflow with usable interfaces, permissions, integrations, and operational controls.
Frontline deployment: Work safely in live customer environments, resolve implementation friction, and return generalizable learning to the product.

Forward deployed engineers and solutions engineers are especially valuable when the product has to enter complicated workflows. They can shorten the distance between a live failure and a product decision. They can also become an unofficial custom-development queue. Prevent that by attaching three fields to every customer-specific change: the broader pattern it tests, the product owner responsible for reviewing the result, and the condition under which the work will be standardized, stopped, or kept outside the core product.

AI fluency should also change your hiring process. Model vocabulary on a resume tells you little about how someone will reason under uncertainty. Give candidates a work sample built around a realistic failure: model performance changes across scenarios, the data distribution is moving, and customer trust is at risk.

Ask the candidate to define the evaluation, explain the consequences of false positives and false negatives, diagnose a precision-recall tradeoff, and translate the technical result into a product decision. The strongest response will not jump straight to a model change. It will clarify the scenario, inspect the evidence, identify what the current evaluation misses, and explain the tradeoff in terms an operator or buyer can use.

Use the same discipline for founder and leadership disagreement. Write down the principle in dispute, the evidence each side is using, the decision owner, the time box, and the condition that will trigger a review. Debate the principle rather than multiplying competing implementation plans. Once the decision is made, commit until the agreed review point. This preserves speed without pretending that an uncertain decision has become permanently correct.

Run model and business evidence on the same cadence

An AI-native startup needs two connected scoreboards. One shows whether the system is becoming more reliable. The other shows whether customers are receiving enough value to adopt, retain, and expand. Reviewing them separately makes it easy to celebrate a model improvement that does not change customer behavior, or a short-term commercial win built on fragile product performance.

Evidence layer	Question	Measures to inspect	Decision it should inform
Scenario quality	Does the system make the right judgment in each important situation?	Precision and recall by scenario; recurring misclassification patterns	Evaluation coverage, data work, model changes, and acceptable operating thresholds
Change detection	Does the system recognize when its environment is moving?	Drift, data freshness, and time to first signal for an emerging pattern	Refresh cadence, investigation priority, and new evaluation cases
Operational experience	Can the customer use the output without creating a new burden?	Alert-fatigue reduction and latency under load	Workflow design, prioritization, and deployment constraints
Business value	Is reliable behavior turning into durable adoption?	Activation, expansion, and Net Recurring Revenue	ICP focus, onboarding, positioning, and roadmap investment

Do not collapse these measures into one composite score. Aggregation hides the failure mode you need to fix. A model can improve overall precision while degrading a high-consequence scenario. Activation can remain flat even when evaluation results improve because the output arrives too late, lacks an escalation path, or does not fit the operator’s workflow. The broken link between the two scoreboards is often the most valuable finding in the review.

Make the weekly customer debrief evidence-based. Bring actual alerts, misclassifications, escalations, and deployment failures rather than a verbal account of how the customer feels. For each material artifact, record the hypothesis it challenges, the evaluation that can reproduce it, the next bet, and the owner. That written log becomes organizational memory when priorities change quickly.

Use an evaluation gate for every consequential release:

Run the relevant scenario-level evaluations, not only an aggregate benchmark.
Inspect newly introduced failure modes as well as improvements to the target case.
Check latency and operational behavior under the conditions the customer will actually use.
Name the owner of monitoring, escalation, and rollback before deployment.

This is not process for its own sake. In an AI product, observability is the control center for trust. It tells your team whether the model still deserves the authority the workflow gives it. Demo speed cannot compensate for an inability to see, explain, and correct failure in production.

Key takeaways for your next operating cycle

Define the product as a closed loop from customer signal to verified outcome, not as a list of AI capabilities.
Commit to a wedge only when the problem is quantified, value can appear within one buying cycle, and legitimate product use improves the data advantage.
Select the first ICP for urgency, data access, workflow access, and a clear success signal. Keep adjacent segments separate when they require different definitions of success.
Turn founder-led sales into a discovery system by logging every rejection, clustering root causes, and testing the two most common causes within a sprint.
Build durable customer-facing units that combine product, model, engineering, and deployment judgment.
Review scenario-level model evidence and business outcomes together, then investigate the link whenever one improves without the other.

For your next planning cycle, choose one ICP, one end-to-end loop, one scenario-based evaluation set, and one customer outcome. Give a single owner responsibility for showing the connection between them. If the team cannot trace that chain with production evidence, the roadmap is still too broad. Narrow it before adding another feature, segment, or model.

References

Shivam.Consulting Blog – Inside Artemis’ AI vs AI Security War: Hiring at Speed, PMF Signals, and Founder-Led Sales

April 21, 2026

From Engineer to CEO: Hard-Won Lessons on GTM, Cloud-First Bets, and Must-Do Focus

Making the leap from engineer to CEO demands an almost entirely new skillset. I’ve felt that jolt firsthand: the tools that serve you as an IC or even a product leader—system design, crisp PRDs, elegant roadmaps—only get you about 20% of the way. The rest is learning to orchestrate go-to-market strategy, finance, hiring, culture, and product positioning with just enough depth to make sound, fast decisions while empowering true experts to execute.

My operating heuristic is the 80% rule. As CEO or GM, I don’t need to be the best marketer, seller, or finance leader; I need to understand 80% of each function well enough to set a compelling product strategy, ask the right questions, and catch the second-order effects. That breadth unlocks speed, quality of judgment, and the conviction to say no when the organization is tempted by what it can do rather than what it must do.

The clearest illustration comes from the journey that turned Apache Kafka—originally built at LinkedIn—into Confluent, a publicly traded enterprise software company. The technical insight was powerful, but the real lift came from translating that insight into a repeatable go-to-market engine. That required building new muscles: founder-led GTM, enterprise sales orchestration, and open source monetization without alienating the community that fueled adoption.

Early on, the product was “embarrassing” by enterprise standards—thin features, sharp edges, and a long tail of operational gaps. Shipping anyway was the point. A thin vertical slice into the market created learning loops with real customers, not hypotheticals. That uncomfortable speed became a superpower, especially when the company decided to push toward a cloud-first business in the face of widespread opposition.

The messaging challenge was just as hard as the technical one. Most marketing fails because it starts with what we built, not what customers must achieve. A simple product marketing pyramid—vision at the top, category framing and points of parity in the middle, crisp value props and proof at the base—helped explain Kafka to the world in customer language. When the narrative snaps into place, adoption accelerates. In Kafka’s case, one well-timed blog post clarified the “why now” and unlocked a step-change in community and enterprise pull.

There’s a pivotal distinction leaders underestimate: the gap between what a company can do and what it must do. I use a must-do filter before every planning cycle: What moves are non-discretionary for durable product-market fit? For Kafka and Confluent, that meant ruthless prioritization on managed cloud services, reliability, and platform scalability—even when it jeopardized short-term revenue or required retooling how engineering, sales, and support worked.

Fundraising strategy mirrored this clarity. Planning to raise before building the full product wasn’t about hype; it was about matching capital to the physics of the problem. If your category requires enterprise credibility, global infrastructure, and 24/7 SRE, you finance those table stakes early. That’s first principles decision making: instrument the constraints, then design the sequence that gets you to scale with the fewest irreversible mistakes.

In the early years, every product decision felt like a trade between polish and learning. The team essentially bludgeoned its way into a cloud-first posture—less because the initial product was ready, and more because the market’s must-do was obvious. That’s the essence of founder-led GTM: get into the field, close lighthouse customers, and use their arcs to shape the roadmap. It’s also where open source monetization matures from downloads into durable, enterprise value.

As the organization scales, excellence often erodes—the Chipotle problem. Process hardens; quality blurs; the magic decays. The antidotes are simple but hard: a few non-negotiable product quality bars, a short set of product-market fit metrics that everyone can recite, and empowered product teams who own outcomes over output. This is where organizational development matters as much as code: design clear interfaces between product, sales, and success, and you’ll keep velocity without losing standards.

Contrary to popular lore, founder optimism is overrated. Constructive realism wins. I try to model “probabilistic optimism”: assume we will win, but instrument the journey like an SRE runs an incident. Set leading indicators, rehearse failure modes, and make pre-commitments to the must-do path so you’re not swayed by the latest anecdote. It keeps the team out of a failure mindset while making room for rigorous course correction.

Giving up the right things at the right time is a CEO superpower. As complexity grows, I hand off decisions that benefit from specialization and keep only those tied to company narrative, must-do prioritization, and talent bar. CEO time management becomes a portfolio problem: ensure each week contains deep product time, frontline customer exposure, and one compounding systems fix (hiring loop, pricing rubric, or GTM enablement) that pays back for quarters.

If you’re moving from IC or PM into a GM/CEO role, here’s a practical playbook: build your product marketing pyramid; write the one-page must-do memo for the next six quarters; ship a narrow, managed cloud slice early; pick three product-market fit metrics (usage, time-to-value, retention) and publish them company-wide; and architect an enablement engine that turns field learnings into roadmap changes within one quarter. That’s how you transform technical advantage into a category-defining business.

The Kafka-to-Confluent arc reminds me that technology can open a door—but clarity of narrative, sequencing, and must-do focus determines whether you walk through it. When in doubt, bias toward shipping, talking to customers, and tightening the loop between what you learn and what you build. That’s the work of product management leadership at scale.

March 26, 2026
Inside Zipline’s Wild Pivot: My Take on Hiring Heat-Seekers and Scaling to 5,000 Hospitals

I’m consistently drawn to stories where product strategy and operational grit collide to change real lives. Zipline, the world’s largest commercial autonomous delivery system, is one of those rare cases. Serving 5,000 hospitals across multiple countries and saving an estimated 17,000 lives per year, it embodies the kind of mission-driven execution I try to model in product management. The arc—from a near-dead home robot startup to a scrappy bet on drone blood delivery in Rwanda, to 135 million autonomous miles flown—offers some of the clearest lessons I’ve seen on hiring, leadership, and product-market fit under extreme constraints.

One principle that immediately resonated with me: why Zipline doesn’t hire for experience. The idea behind “Why Zipline hires teenagers over PhDs” isn’t a dismissal of expertise; it’s a commitment to learning velocity, ownership, and unteachable hunger. The best startup employees, as described here, are “heat-seeking missiles for pain”—people who chase the hardest problems, not the shiniest projects. In my org, I look for the same signal: candidates who can move from ambiguity to action, who find the bottleneck without being asked, and who care more about outcomes than optics.

I also appreciated the unapologetic stance that “blind references are a non-negotiable.” In high-stakes builds—especially in regulated or safety-critical categories—the cost of a mis-hire compounds. I routinely validate for two traits during references: intellectual humility and accountability. “Can candidates admit when they screwed up?” is a powerful filter. If someone can’t name a hard mistake and how they specifically changed as a result, they’re unlikely to scale with the organization.

Equally important is clarity about who not to hire. The employees Zipline doesn’t want are those who optimize for status, process theater, or low-friction work. In practice, that means pressure-testing for problem-finding, not just problem-solving. I often design interviews around messy, cross-functional constraints (regulatory, operational, and financial) to see who can integrate tradeoffs, not just ideate features. That’s how we build empowered product teams that ship consequential outcomes, not outputs.

There’s a reference to “Zipline’s secret leadership playbook,” and while the specifics remain private, the spirit is unmistakable: first principles decision making, ruthless focus, and a culture that rewards radical responsibility. Translating that to my product organization, I emphasize five behaviors: orient to the mission under uncertainty, run fast but close the loop with data, communicate constraints early and often, own the long tail of consequences (especially in safety and reliability), and scale judgment by teaching the why, not just the what. That blend of clarity and autonomy is the backbone of product management leadership at any growth stage.

On the other side of the culture coin is “Why you should always fire quickly” and “The brutal firing advice that shaped Keller’s leadership.” I’ve learned (sometimes the hard way) that slow decisions erode trust and team velocity. Moving quickly doesn’t mean being harsh; it means being fair, explicit, and humane—tight feedback loops, role clarity, and decisive action when the gap persists. If your bar is clear and your coaching is consistent, acting fast protects both the mission and the team’s energy.

Strategically, the origin story reads like a masterclass in choosing the right problem. The team moved “from toy robots to drone delivery: Zipline’s pivot,” then partnered deeply with Rwanda, where “How Rwanda’s health minister changed everything” is a pivotal moment. It wasn’t a linear climb—”How Zipline almost died – twice” and “Why Zipline’s launch was a ‘complete disaster’” underline a tough truth: breakthrough products rarely arrive fully formed. What matters is the operating cadence that turns early chaos into repeatable reliability—especially when the stakes are measured in minutes and lives.

Scaling from 1 hospital to 5000 required more than product brilliance; it demanded systems thinking across logistics, compliance, safety, and community trust. That’s stakeholder management at its highest level. The product lessons are durable: anchor on outcomes, not artifacts; build reliability as a feature; and practice founder-led GTM where your credibility is on the line with customers and regulators. This is where first principles decision making beats benchmarking—particularly in novel categories where there are no playbooks to copy.

There’s also a hard-nosed operational takeaway in “The 10x hardware cost rule every founder should know.” My read: assume total cost of ownership will balloon once you account for manufacturing variability, support, redundancy, maintenance, and compliance. In product strategy, I treat those multipliers as design inputs, not afterthoughts. If the unit economics can’t survive these realities, the idea isn’t ready—no matter how elegant the prototype looks in a lab.

Across all of this, a few product management patterns stand out for me: build teams around outcomes vs output OKRs; hire for slope, not just intercept; make continuous discovery routine with real users (in this case, clinicians and health systems); and treat operational excellence as a product surface. When a mission is this consequential, culture becomes a safety system—and every leadership decision compounds into either speed with quality or speed with regret.

For leaders building in complex domains, this journey is a blueprint: pick problems that matter, hire “heat-seeking missiles for pain,” keep blind references non-negotiable, lead with first principles, and scale with responsibility. Do that well and even a “complete disaster” launch can become the inflection point of a category-defining company that flies 135 million autonomous miles and saves 17,000 lives per year.

March 12, 2026
Kill Your Darlings: Why I Sunset ‘Successful’ Products to Fuel Real Portfolio Growth

There’s a moment in every product leader’s career when the bravest decision isn’t to build—it’s to stop. That’s why the “Kill Your Darlings” theme resonated so strongly with me. In this episode of All Things Product, Teresa Torres and Petra Wille dig into the courage and craft it takes to sunset products that look successful on the surface yet quietly block your path to meaningful growth. As someone accountable for portfolio outcomes, I’ve learned that disciplined endings are often the catalyst for exceptional beginnings.

Listen to this episode on: Spotify | Apple Podcasts

The heart of the conversation is that uncomfortable middle ground between obvious failure and runaway success: products that are profitable, loved by customers, but fundamentally flatlining. Teresa shares candid stories from her own business, including a decision to cut 40% of revenue on purpose. I’ve been there—choosing to retire a “working… kind of” product to free up discovery capacity felt risky in the moment, but it created the focus we needed for durable growth.

Here’s the trap: some traction can be more dangerous than no traction at all. Early fans are not the same as durable product–market fit, and “stable but not growing” can lull leaders into maintaining instead of learning. Every hour of design, engineering, and go-to-market attention that props up a flatlining product is an hour not invested in the next breakthrough—an opportunity cost that rarely shows up on a dashboard, yet compounds month after month.

From a portfolio perspective, this is continuous discovery in action. If we want empowered product teams to tackle meaningful outcomes, we have to protect their capacity from zombie work. That means setting clear thresholds for when we double down, shift strategies, or sunset—before attachment and inertia take over. When I’ve institutionalized this discipline, our throughput of high-quality bets increased, and our confidence in what not to do became a strategic advantage.

Organization design can make sunsetting harder than it needs to be. Dedicated, long-lived teams are fantastic for compounding capability, but they also create emotional and structural ties to specific products. Petra’s point lands: leaders need explicit sunsetting conversations and a portfolio decision-making cadence that sits one level above teams. In my org, we treat sunsetting as a strategic reallocation—not a verdict on a team’s talent—so people are celebrated for learning, not punished for outcomes outside their control.

Killing profitable products can be the right strategic move when the growth ceiling is clear and the opportunity cost is high. I’ve chosen to “burn the ships (on purpose)” more than once—retiring add-ons that generated reliable revenue but diluted our value proposition and spread discovery thin. Yes, it stings in the quarter you do it. But it’s astonishing how quickly focus restores momentum when you create intentional space for what’s next.

Practically speaking, I make sunsetting easier and less traumatic by operationalizing it: Regular portfolio reviews focused on outcomes and opportunity cost; a visible “sunsetting” column so everyone sees what’s on the table; the Horizon (H1 / H2 / H3) model to balance core, adjacent, and transformational bets; and making portfolio decisions one level above teams to avoid local optimizations. Add explicit exit criteria and success metrics for endings, the same way we set entry criteria for new bets.

Another theme I appreciated is designing for the right customers. Teresa highlights intentionally limiting access and pricing to work with customers who show agency and commitment. I’ve applied the same principle: when we’re clear about who we serve and who we don’t, our product–market signal sharpens, churn narratives simplify, and roadmaps get crisper. Focus is a growth strategy.

If you’re leading a product portfolio, running discovery, or wrestling with a product that “works… kind of,” this conversation is permission to act. Product–market fit isn’t binary, and mediocre success can be the most dangerous place to stay. Sunsetting is a portfolio decision, not a team failure; teams shouldn’t be punished for reaching the end of a product’s natural lifecycle. If experimentation isn’t in your DNA, killing products will always feel traumatic—so make space for it intentionally, not passively.

Key moments and themes worth bookmarking: 00:00 – Why “kill your darlings” matters; 04:30 – The dangerous middle ground; 09:30 – The opportunity cost of “okay” products; 14:30 – Sunsetting in product organizations; 19:00 – Real examples of killing revenue streams; 28:00 – Designing for the right customers; 33:30 – Burn the ships (on purpose); 38:00 – Making sunsetting easier with Regular portfolio reviews, a visible “sunsetting” column, the Horizon (H1 / H2 / H3) model, and making portfolio decisions one level above teams; 46:00 – Normalizing product lifecycles.

Resources & Links:

Follow Teresa Torres: https://ProductTalk.org

Follow Petra Wille: https://Petra-Wille.com

Mentioned in this episode:

Ways to Work with Petra Wille

Product at Heart

CDH Membership by Teresa Torres

Product Talk by Teresa

Product Talk Academy by Teresa

Enduring Ideas: The three horizons of growth

Join the Conversation:

Have thoughts on this episode? Leave a comment below.

Full Transcript

Full transcripts are only available for paid subscribers.

Inspired by this post on Product Talk.

March 10, 2026
From Concierge to AI Marketing Engine: Inside Mowie’s Document Hierarchy Playbook

I’m constantly asked by SMB owners: What if your small business could have a full marketing team—automated content calendars, customer segmentation, and channel-specific posts—without the headcount? That question is no longer hypothetical; it’s precisely the promise behind Mowie, and the way they got there is a masterclass in practical AI product development.

I recently listened to Chris O'Connor (CEO) and Jessica Valenzuela (Co-Founder) of Mowie, an AI marketing platform built for small and medium-sized businesses in restaurants, retail, and e-commerce. Their story starts with a concierge marketing service—doing the work by hand for overwhelmed owners—and evolves into a fully automated AI product.

They walk through their "document hierarchy" approach: how Mowie crawls the web to build a "dossier" about each business, infers customer segments and marketing pillars, and generates quarterly content calendars with channel-specific posts. As a product leader, this is the kind of retrieval-first pipeline that consistently outperforms naive prompt chaining because it builds durable context before generation.

They also unpack the technical challenges of structuring unstructured data and the evolution from rigid schemas to loosely structured markdown. In my experience with LLMs for product managers, markdown becomes a flexible intermediate representation that’s easy to diff, trace, and feed back into models without brittle parsing.

Equally important, they use customer feedback—from calendar approvals to regeneration requests—as their primary evaluation signal. That’s eval-driven development in practice: close the loop with lightweight evals that reflect genuine user intent, not proxy metrics.

The planning model is elegant: the three mini-calendars—public events, business-specific events, and recommended campaigns—roll up into a coherent plan that eliminates the blank-page problem and enables steady, predictable execution.

Crucially, they’re building traceability so customers can see which context documents influenced their content. This kind of transparency increases trust, accelerates edits, and supports governance in regulated categories where auditability matters.

Onboarding and data collection stay pragmatic: let the system crawl first, ask humans only for deltas, and progressively profile over time. It’s a pattern I advocate in continuous discovery and AI workflows—keep humans in the loop without overwhelming them, and make the right action the easy action.

Early on, they used Simon Sinek's Golden Circle framework to validate demand and sharpen messaging. Framing the "why" before the "what" helps teams maintain a crisp value proposition and tighten their go-to-market strategy.

Performance measurement goes beyond vanity metrics by connecting marketing performance back to point-of-sale data for attribution. The ability to tie campaigns to revenue events is the bridge from clever content to accountable outcomes.

What’s next is equally compelling: deeper attribution, omnichannel expansion, and digital out-of-home displays. For SMBs, that points to a unified analytics platform spanning email, social, and in-store touchpoints—exactly where modern marketing is headed.

My takeaways for builders: invest in a retrieval-first pipeline with a resilient document hierarchy; prefer loosely structured markdown over rigid JSON when dealing with messy inputs; design human-in-the-loop controls that double as evals; and always connect activity to business outcomes. That’s how you turn an idea into a repeatable system that scales.

If you want to explore further, start here: Mowie AI — AI marketing platform for SMBs. For early validation and storytelling, revisit Simon Sinek's Golden Circle.

Inspired by this post on Product Talk.

December 11, 2025
How We Built an AI Sleep Coach: CBTI, Voice AI, and a Product Playbook for Better Rest

What if your morning started with a helpful check-in from a voice AI that actually improves your sleep—using the same core principles that typically cost thousands of dollars and come with year-and-a-half waitlists? That idea energizes me as a product leader, because it blends clinical-grade outcomes with consumer-grade accessibility. Recently, I dug into how the team at Rest built an AI sleep coach inspired by Cognitive Behavioral Therapy for Insomnia (CBTI), and why their method offers a repeatable blueprint for complex, personal AI products.

The origin story is a classic product discovery moment. Rest’s team noticed that a meaningful slice of users in their podcast app were using audio to fall asleep. Although it represented only about 10% of users, that group showed a high willingness to pay. That signal pushed them to explore a dedicated sleep solution, moving from a general audio app to a targeted sleep experience—and eventually toward an AI-powered coach as LLMs matured.

Through jobs-to-be-done research, they identified a clear, underserved segment: “DIY sleep hackers.” These are motivated users who want agency, structure, and results without navigating clinical systems. Choosing CBTI (a clinically proven approach with 80% efficacy) gave the product a strong evidence-based foundation while remaining accessible as a wellness tool. It’s the kind of strategic choice I look for: credible, measurable, and aligned with user motivation.

The product evolution moved in smart, incremental steps. Rest started with a basic text chatbot before graduating to a voice-first experience—using Vapi for voice and OpenAI for reasoning. Voice changed the relationship dynamic: it increased intimacy, lowered friction for daily check-ins, and made behavioral coaching feel human without pretending to be. The team built a memory system that tracks context (like traveling or having a dog) with time-based relevance, which keeps conversations fresh, respectful, and genuinely personalized.

Daily engagement is driven by dynamic agendas that adapt based on sleep data, the user’s stage in the program, and their recent compliance. I love this mechanic: it operationalizes behavior change by sequencing the right intervention at the right time. In parallel, they developed text via OpenAI Assistants while building voice with Vapi, which let them ship value while learning in two modes. They also moved from massive system prompts to RAG for general sleep knowledge, keeping personal user context in the prompt—reducing brittleness while improving scalability.

Because sleep sits close to healthcare, the team drew a firm line between wellness and medical positioning. They implemented clear guardrails: no diagnosis, no medication advice, and strong boundaries on scope. Weekly error analyses with domain experts (sleep therapists) tightened quality and tone, and they adopted LLM-powered evals to enforce safety boundaries. For observability and evaluations, they leveraged Langfuse, and they experimented with Hamming for voice testing to refine the experience end-to-end.

Under the hood, this is a great example of “one bite of the apple at a time” product building in AI. Start with a simple interface, anchor on an evidence-based method, layer personalization with memory, formalize program structure with dynamic agendas, and shift to RAG when general knowledge outgrows prompt engineering. As a product leader, I see strong echoes of agentic patterns here—goal-oriented orchestration, stateful memory, and adaptive planning—shipped in pragmatic increments rather than as a monolithic platform rewrite.

A few takeaways I’m applying with my teams: First, segment deeply and pick a high-intent niche (those “DIY sleep hackers” were the right beachhead). Second, let modality fit the job—voice is not a gimmick when it boosts compliance and empathy. Third, design safety and scope from day one if you’re anywhere near health. Finally, invest early in evals and observability so you can improve with confidence, not hope.

If you want to explore the full conversation and product decisions, you can listen here: Spotify | Apple Podcasts.

Resources & Links:

Rest – AI sleep coach app

Vapi – Voice agent platform Rest uses

Langfuse – Observability and evals platform

Hamming – Voice testing platform

AI Evals Maven Course by Hamel Husain and Shreya Shankar

Bottom line: Rest demonstrates how to take a clinically grounded method like CBTI, translate it into a daily voice-first experience, and ship it with rigor. If you’re building in AI, this is a model worth studying—practical, safe, and deeply user-centered.

Inspired by this post on Product Talk.

November 20, 2025

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 observe	Likely constraint to investigate	What to do next
Qualified opportunities repeatedly stop during security, governance, or legal review	Enterprise product readiness	Turn 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 decision	Business proof, stakeholder alignment, or change management	Define the decision criteria, economic outcome, buyer group, rollout plan, and procurement path before the pilot begins.
Deal quality and cycle length vary sharply by rep	Qualification, positioning, or enablement	Standardize the ICP, discovery questions, proof package, objection handling, and stage-exit criteria.
Customers close but do not retain or expand as expected	Product value, customer fit, or adoption	Review retention and expansion by segment, then inspect whether the promised outcome was achieved after implementation.
One prestigious account requires a large, account-specific roadmap detour	ICP discipline and exception governance	Measure 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:

Define the ICP, use case, required outcome, buying group, and disqualifying conditions.
Choose a cohort of opportunities that entered the motion under comparable qualification rules.
Review win rate, stage duration, multi-threading, rep ramp, retention, and two-quarter expansion without blending other segments into the result.
Inspect representative wins, losses, and stalled deals to explain the pattern behind the metrics.
Classify the primary constraint as product value, enterprise readiness, positioning, enablement, segmentation, or execution.
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:

Enterprise foundation: Is this a baseline capability, such as governance, auditability, reliability, or access control, that the target market broadly requires?
Native ICP need: Does it strengthen the core outcome for many customers you deliberately want to serve?
Reusable extension: Can it be handled through configuration, extensibility, or a shared platform capability without distorting the core product?
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

November 19, 2025

Build a Company You’ll Run Forever: Bootstrapping vs VC, PMF, and the Art of ‘Eating Glass’

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/

November 6, 2025
My Product Positioning Playbook: Craft Unforgettable Messaging That Wins Markets and Endures

Every market-winning product I’ve helped build started with a positioning statement that was clear, defensible, and memorable. When I lead new initiatives at HighLevel, Inc., I treat positioning as a product decision—because it sets the guardrails for what we prioritize, how we execute, and how we tell the story across the entire go-to-market engine.

Your product positioning statement decides if you stand the test of time. Learn how other expert products do it and how to write one that sticks.

At its core, a positioning statement is the sharpest articulation of who we serve, the problem we solve, the category we compete in, the value proposition we deliver, and why we win. It is not a tagline or a pitch deck sentence; it’s the decision calculus that aligns product, marketing, sales, and customer success so we can move fast in one direction.

Here’s the simple template I use and coach teams on: For [target customer/segment] who [urgent need or job-to-be-done], [product name] is a [category or frame of reference] that [core value proposition]. Unlike [primary alternative or status quo], it [competitive differentiation and reasons to believe]. When this fits, everything from roadmaps to demos becomes easier—and conversions tend to follow.

Start with the target segment. Be precise about who you are for. I triangulate with retention analysis and behavioral data (e.g., Amplitude analytics) to find the cohorts that activate quickly, retain well, and expand. If you cannot name the segment in one line, you’ll struggle to land positioning anywhere else.

Next, define the customer outcome. Tie the promise to measurable “outcomes vs output OKRs.” Customers buy progress, not features. State the job-to-be-done in their language and anchor it to a business result they already track.

Choose your category and points of parity. Category is a cognitive shortcut; it tells buyers where you sit on their mental map. Points of parity are table stakes you must match to be considered. If you skip parity, you look incomplete; if you skip category, you look confusing.

Then sharpen your competitive differentiation and value proposition. What do you do uniquely well that competitors can’t easily copy? Back it up with reasons to believe—proof points like speed-to-value, measurable ROI, data governance, or privacy-by-design and cybersecurity commitments. Credibility turns claims into confidence.

Validate the statement through rigorous A/B testing. I pressure-test the language across landing pages, onboarding flows, in-app guides, sales call talk tracks, and nurture sequences. Tools like Pendo, Intercom, and HubSpot make it easy to instrument message experiments and see what actually moves activation, conversion, and expansion.

Operationalize the winning statement across go-to-market strategy and product-led growth motions. Bake it into onboarding, product tours, pricing pages, and demo narratives. A strong positioning statement should shape prioritization in the roadmap as much as it shapes the headline on your website.

Beware common pitfalls. Don’t confuse vibe marketing for positioning. Avoid vague superlatives that any competitor could claim. Don’t aim for universal appeal; specificity sells. And never let the statement drift—revisit it after major launches, new segments, or shifts in competitive dynamics.

Here’s an example using the template: For revenue teams at mid-market SaaS companies who need faster, more predictable pipeline creation, SignalFlow is a unified analytics platform that turns product usage signals into qualified opportunities. Unlike generic CRMs and static lead scoring, it surfaces intent in real time and automates outreach, improving conversion by 22% within 30 days.

If your team debates features more than outcomes, it’s time to revisit your positioning. In my experience, one crisp sentence can unlock alignment, accelerate execution, and make your message stick. Write it, test it, and make it the north star for every decision you ship.

Inspired by this post on Product School.

November 5, 2025
From Code to Roadmaps: My Proven Playbook for Engineers Becoming Product Managers

"From code commits to boardrooms. Here are real stories of software engineers who swapped bugs for roadmaps on the road to product manager." I’ve made that leap myself and helped many engineers do the same. In this piece, I share the playbook I use to guide high-potential ICs into impactful product management roles—without losing the engineering rigor that makes them special.

Engineers make exceptional product managers because we’re trained to decompose complex systems, debug ambiguity, and reason from first principles. The transition isn’t about abandoning code; it’s about expanding your scope from implementation details to customer outcomes, market context, and business impact.

The first shift is mental: move from shipping outputs to driving outcomes. Features are a means; value is the end. I anchor this change with outcomes vs output OKRs, ensuring every roadmap item ties to a measurable user or business result rather than a checklist of tickets.

Next, upskill deliberately in three areas: product discovery, product positioning, and stakeholder management. Learn to design unbiased customer interviews, synthesize patterns from qualitative and quantitative signals, and craft crisp value propositions that resonate with real segments. Then practice executive-ready communication—clear decisions, concise narratives, and no jargon crutches.

Here’s the practical, low-risk way to get PM experience without changing your title: form a product trios working group (design, engineering, product) around a real problem. Lead discovery with a weekly cadence, run lightweight experiments, and translate insights into a draft product roadmapping and sprint planning artifact. Ship small, learn fast, and narrate the learning.

Build a simple portfolio that proves product judgment. Include one-page problem briefs, discovery notes, customer quotes, prioritized opportunity trees, and a before/after roadmap snapshot. For each artifact, quantify the impact: activation lift, support ticket reduction, conversion improvement—whatever outcome your work influenced.

If you want to pivot internally, propose a 90-day experiment. Volunteer to own a well-bounded problem, commit to an outcomes dashboard, and set a weekly stakeholder update. Keep a minimal engineering contribution during the trial to de-risk the transition for your team while you demonstrate PM leverage across the squad.

If you’re interviewing externally, prepare two deep case studies: one discovery-led (how you reduced uncertainty) and one delivery-led (how you aligned stakeholders and shipped). Be explicit about trade-offs, risks you retired, metrics you moved, and lessons learned. The best signals of product sense are clarity under constraints and an ability to say “no” for good reasons.

Once you land the role, use a 30-60-90 plan. In the first 30 days, map users, workflows, metrics, and decision rhythms; in 60, run a focused discovery sprint and align on your hypothesis-led roadmap; by 90, deliver a thin slice that proves value and establishes credibility with empowered product teams. Keep your communication tight, your dashboards honest, and your customers close.

Common pitfalls: translating directly from solution space to roadmap without validating problems; equating stakeholder satisfaction with customer value; and mistaking velocity for progress. Avoid them by running small tests early, revisiting segment-specific value propositions, and anchoring trade-offs to product-market fit lessons.

If you’re standing at the edge of this transition, start where you are: choose one user pain, one measurable outcome, and one small bet. Treat it like a product: define success, experiment thoughtfully, and learn in public. The road from engineer to product manager isn’t a title change—it’s a shift in how you create value.

Inspired by this post on Product School.

November 3, 2025
10 Customer Acquisition Metrics I Obsess Over to Predict Growth (and Kill Vanity KPIs)

Stop chasing the wrong numbers! Learn which customer acquisition metrics actually point the way to growth and which to leave behind.

In my role leading product and growth, I’ve learned that sustainable acquisition comes from a disciplined focus on a few decisive signals. I run a tight scorecard that blends product-led growth inputs with sales-assisted outputs, stitched together in a unified analytics platform and grounded in our CRM integration. Tools like Amplitude analytics, HubSpot, Pendo, and Intercom help me see the entire journey—from first touch to user activation and revenue—without getting lost in dashboard noise.

ICP-qualified lead rate (MQL-to-SQL conversion) is my first gate. If qualified interest isn’t turning into sales conversations, I know our targeting, messaging, or handoff is off. This metric forces alignment between marketing and sales on the actual Ideal Customer Profile and disqualifies the “traffic for traffic’s sake” mindset.

Lead Velocity Rate (LVR) tells me whether next quarter’s growth is compounding. I track the month-over-month growth of qualified leads and opportunities, not raw leads. When LVR dips, I revisit go-to-market strategy and pipeline sources before the lagging revenue number shows trouble.

Activation rate is the heartbeat of product-led growth. I define a clear “first value” action and measure what percentage of new signups reach it within a set time window. Strong activation signals that our onboarding and value proposition are resonating; weak activation pushes me to refine in-app guides, product tours, and tooltip design.

Time-to-Value (TTV) measures how quickly new users experience the core benefit. Shorter TTV correlates with higher conversion, better retention, and lower support costs. I routinely A/B test onboarding steps, copy, and default settings to shave minutes off TTV without sacrificing comprehension.

Customer Acquisition Cost (CAC) by channel keeps us honest. I break out CAC for paid, organic, partner, and sales-led motions, then double-click into cohort performance. Channel-level CAC, tied back to revenue quality, helps me reallocate budget and resist the allure of cheap but low-intent clicks.

CAC payback period is my sanity check on efficiency. I want to know how many months of gross margin it takes to recover CAC—across each motion. When payback creeps up, we revisit pricing, packaging, onboarding friction, and top-of-funnel quality simultaneously.

LTV:CAC ratio shows whether we’re buying durable revenue. I pair it with retention analysis to avoid overestimating Lifetime Value. A healthy ratio without healthy retention is an illusion; I’d rather fix the product and activation leaks than pour more dollars into acquisition.

Win rate is the truth serum for positioning. If we’re losing qualified deals, I look for gaps in our points of parity, competitive differentiation, and proof points. Improving win rate often requires sharper product positioning and fewer—but stronger—value propositions.

Sales cycle length closes the loop between interest and impact. I segment cycle time by ICP, channel, and deal size to expose bottlenecks. Tightening cycle time compounds growth by accelerating cash and freeing capacity for more pipeline.

Organic acquisition share protects us from paid dependency. I aim for a rising share of signups from organic search, referrals, and product-led loops. Healthy organic signals resonance—a clear message-market fit that compounds over time.

To operate this system, I keep experiments rigorous. We set a minimum detectable effect (MDE) up front for key A/B tests so we don’t declare fake wins. Weekly cross-functional reviews keep us focused on outcomes vs output, and we only scale what demonstrably moves these ten metrics.

If you align your team around these signals and instrument the full journey end-to-end, you’ll make better bets faster. More importantly, you’ll stop celebrating vanity spikes and start compounding real, defensible growth.

Inspired by this post on Product School.

November 3, 2025
Go Hard Early: Enterprise AI Lessons That Built Serval’s Magical IT Automation Agents

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.

LinkedIn: https://www.linkedin.com/in/jakestauch/

Twitter/X: https://x.com/jakeserval

LinkedIn: https://www.linkedin.com/in/brett-berson-9986094/

Twitter/X: https://twitter.com/brettberson

Website: https://firstround.com/

First Round Review: https://review.firstround.com/

Twitter/X: https://twitter.com/firstround

YouTube: https://www.youtube.com/@FirstRoundCapital

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.

October 25, 2025