Month: October 2025
-
How Radical Simplification Drove Vercel’s Product-Market Fit: Lessons for PMs and Founders
When I study category-defining products, I look for the decisive moment where simplification unlocks scale. Few stories illustrate this better. Guillermo Rauch is the CEO of Vercel, a frontend-as-a-service product that was valued at $2.5b in 2021. That headline number matters, but the underlying playbook matters more: simplify the developer path to value, create a default that feels inevitable, and let adoption compound. Vercel serves customers like Uber, Notion and Zapier, and their React framework – Next.js – is used by over 500,000 developers and designers worldwide. For a product creator, those are the signatures of extreme product-market fit: an obvious customer set, a loveable default framework, and a platform that scales with developer ambition. From a product management leadership lens, this is a masterclass in developer evangelism and founder-led GTM, not just technology. Guillermo started his first company at age 11 in Buenos Aires and moved to San Francisco at age 18. In 2013, he sold his company Cloudup to Automattic (the company behind WordPress), and in 2015 he founded Vercel. I read this arc as a sequence of product discovery moments: start with a sharp user problem, ship the smallest credible solution, and iterate where the usage is loudest. The throughline is obsession with experience—reducing friction until the product’s default path feels like magic. Reflecting on the Cloudup era, I see a blueprint for outcomes vs output OKRs. Shipping features is easy; aligning them to a few hard outcomes is what prepares a company for scale or acquisition. That discipline shows up later in Vercel’s sequencing: tight technical scope, clear constraints, and relentless measurement of time-to-first-value. On origin and early validation, the insight was deceptively simple: give frontend teams a zero-config way to build, preview, and ship. The V1 product wasn’t a kitchen sink—it was a clean, repeatable flow from commit to deploy. The early skeptics (and there are always skeptics) helped refine the edges; real usage pressure-tested the defaults. The paradox of developers is alive here: we demand power without complexity. The genius is delivering depth without exposing every knob on day one—Next.js did exactly that. My advice on finding product-market fit mirrors this path: collapse the distance between intent and impact. Design the onboarding so one successful path feels pre-ordained. Put forward deployed engineers beside the customer, and treat their feedback as your fastest route to truth. Keep founder-led GTM longer than you think; it’s the most direct signal path you’ll ever have. An open source business becomes successful when adoption is the front door and the cloud is the living room. Open source monetization works when you resist taxing the developer and instead charge for the operational guarantees that companies need at scale: performance, security, governance, and global reliability. Next.js as a community engine and Vercel as a managed “frontend-as-a-service” is a textbook pairing. The trend toward a “Front-end Cloud” is structural. As teams modularize on services like AWS and adopt modern stacks with Next.js, React Native, and headless partners such as Contentful or Shopify, the frontend becomes the primary assembly layer. That’s why people now pay so much attention to the front-end: it’s where the brand lives, the iteration cycles are fastest, and the performance budget is now a business KPI. Positioning and category creation here relied on clarity over cleverness. Name the job-to-be-done, anchor on speed and reliability, and make the default workflow visibly better than the DIY alternative. When the default wins, you earn the right to go multi-product. The key is sequencing: expand from core strengths and ship adjacent capabilities that shorten time-to-value across the same journey. On AI, I’m seeing gen ai shift from novelty to necessity. The immediate wins are in gen ai for product prototyping (faster ideation, copy, and component scaffolding) and in developer experience (test generation, refactors, and safe migrations). The long arc over 10–20 years points to engineering where we curate constraints and verify outcomes, while machines propose implementations. That raises the bar for PM rigor: better problem statements, tighter acceptance criteria, and sharper product discovery. My enduring heuristics for building better product experiences are simple. Eliminate decisions the user shouldn’t have to make. Make the fastest path the default path. Optimize for the preview moment because that’s where confidence is built. And measure success by how little the user has to think to achieve a powerful result. If you apply that mindset—plus disciplined developer evangelism and thoughtful open source monetization—you give your product a real shot at extreme product-market fit.
-
Goal-Setting for AI Products: How I Plan, Prioritize, and Confidently Ship in a Nonlinear GenAI World
I build and ship AI products in an environment where the frontier changes weekly, so my planning system has to be adaptive, evidence-driven, and unapologetically outcome-focused. In this piece, I share the frameworks I use to set goals for generative AI, balance research with product execution, and scale responsibly — drawing sharp lessons from one of the most influential applied AI companies operating today.
Consider Runway, an applied AI research company shaping the next era of art, entertainment, and human creativity. Runway has raised $237m and was one of Time Magazine’s “100 most influential companies” in 2023. Runway has been a persistent viral sensation in recent years, and is behind many of the most famous AI demos online.
The earliest stages of an AI company often begin with research breakthroughs, scrappy prototypes, and clever distribution. In practice, that means leveraging containerization (https://aws.amazon.com/what-is/containerization/) and Docker (https://www.docker.com/) to package models reproducibly, showcasing work where practitioners already gather — Hugging Face (https://huggingface.co/), Hugging Face Spaces (https://huggingface.co/spaces), and Hugging Face Model Hub (https://huggingface.co/docs/hub/models-the-hub) — and tapping infrastructure like Replicate (https://replicate.com/) to get demos into people’s hands. Early, magical use cases — like the Green screen tool by Runway (https://runwayml.com/green-screen/) — teach us which problems are both technically feasible and viscerally valuable.
I’ve learned to be cautious about “The limitations of being “customer-driven” when building in AI”. Traditional product discovery assumes needs are legible and solutions are relatively deterministic. In generative AI, user desire often follows model capability, not the other way around. The job is to triangulate: run tight user loops to validate perceived value, instrument objective model quality, and explore novel interaction patterns that customers can’t yet articulate. I treat this as a portfolio of discovery bets — some customer-led, some capability-led, all evaluated against clear outcome thresholds.
Balancing research development with product development requires organizational design that prevents context-switching tax while preserving velocity. I pair research pods with product pods, supported by forward deployed engineers and domain PMs who translate evaluation metrics into user-visible milestones. Safety and content moderation sit on the critical path, not as afterthoughts — think policy definition, classifier tooling, abuse red teaming, and clear escalation playbooks. This balance is how you move from a great demo to a dependable product without losing momentum.
Goal-setting amidst constant change in AI starts with outcomes vs output OKRs. I write OKRs in terms of user impact and model performance thresholds — for example, target ranges for latency, quality scores against a golden dataset, or creator retention — then let teams choose the highest-leverage outputs (data pipelines, fine-tuning, UX improvements) to get there. Why I don’t plan very far ahead: I treat the annual view as a vision and bet map, the quarterly view as a constrained slate of outcomes, and the 6–8 week cycle as the execution heartbeat. AI roadmaps are hypotheses; evaluation harnesses and launch gates are the truth.
Community is a force multiplier. Forming a vocal community and fostering community requires real access and real listening: early release cohorts, office hours, and transparent changelogs. How they picked users for early release matters — diversity of use cases, sophistication of workflows, and willingness to give crisp feedback. Expanding past the first 100 users of Gen-2 demands readiness: evaluation parity across modalities, scalable infra, and safety coverage. Done well, this motion compounds learning while building authentic advocacy.
For founders, my advice echoes the core lessons above. Start with a narrow, high-intent wedge and prove durable value fast; let founder-led GTM compress the feedback loop; instrument everything from day one; and resist the urge to over-plan features before you’ve nailed outcomes. Product-market fit lessons in AI often arrive via small, fast experiments — not grand, long-range plans. Ship thin slices that demonstrate unmistakable value, then iterate toward a system, not a single feature. When in doubt, shorten the loop and improve the evaluation harness.
People often ask: Will AI replace video editors? My view is that AI will replace zero editors who master these tools — and many who don’t. The winners blend taste, storytelling, and generative leverage. The products we build should honor this reality: design for control, iteration, and co-creation, not just automation.
If you’re mapping the progression of tech and use-cases, a few public references are instructive: Runway Gen-1 (https://research.runwayml.com/gen1) and Runway Gen-2 (https://research.runwayml.com/gen2) show how capability unlocks new workflows and demand. Runway’s 30 AI Magic Tools (https://runwayml.com/ai-magic-tools/) illustrates portfolio thinking — a suite of composable powers rather than a monolith.
For builders focused on gen ai for product prototyping through production: keep your demo muscle strong, your evaluation stronger, and your outcomes strongest. Invest in community, treat safety as a feature, and let your OKRs steer what ships — not the other way around.
-
Engineering Leadership That Scales: Strategy, Velocity, and Org Design from Carta, Stripe, Uber, Calm
I’m often asked how I translate lessons from hypergrowth engineering organizations into practical playbooks for product and platform teams. In this piece, I unpack the patterns I’ve seen repeatedly work—anchored by what I admire about Will Larson’s approaches at Carta, Calm, Stripe, and Uber—and how I apply them to build resilient, high-velocity orgs. Will Larson is a case study in modern engineering leadership. As CTO at Carta—an ownership and equity management platform—he helped guide the company after it raised at a $7.4b valuation in 2021. Before that, he was CTO at Calm, founded Stripe’s Foundation Engineering org, and led Uber’s Platform Engineering people and strategy. He’s also the author of Staff Engineer and An Elegant Puzzle, both essential reads for leaders leveling up from line management to org design. When I craft an engineering strategy, I start by writing down a small set of clear principles. This isn’t performative; it’s an alignment mechanism. Principles reduce decision thrash, make trade-offs explicit, and help teams navigate ambiguity without constant escalation. I’ve found the discipline of writing them down upfront pays off 10x in execution quality later. For the strategy document itself, I structure it so anyone can understand the why, what, and how in one sitting. A useful pattern: a sharp problem definition, a few guiding policies, and a concise set of coherent actions. That scaffolding keeps the strategy legible and actionable across functions—especially as it ladders into product roadmaps, platform investments, and talent plans. Every engineering strategy has two parts. First, compounding capabilities: the platform, tooling, and architecture that unlock future velocity. Second, targeted bets: focused initiatives that advance near-term outcomes. Neglect either and you either stall out later (too many quick wins, no compounding) or fail to ship value now (all compounding, no customer impact). Turning strategy into action requires ruthless translation. I map each guiding policy to a small number of initiatives with owners, milestones, and outcome metrics—not output. This is where outcomes vs output OKRs matter: measure the user or business result, not just the deliverable. It’s also where you surface dependencies early and avoid the Hidden Variable Problem that quietly derails timelines. I’m particularly intrigued by Carta’s unique “navigator” model, which blends technical leadership with cross-functional guidance to accelerate execution while preserving autonomy. In my experience, similar patterns work when leaders are explicitly accountable for both system health and product outcomes—reducing the gap between platform decisions and customer value. Engineering velocity is explainable, measurable, and optimizable. I anchor on DORA and the research from Accelerate (book), and I complement it with the SPACE (framework) to account for satisfaction and collaboration, not just delivery. The story I tell executives is simple: pick a few canonical measures, instrument them consistently, and then drive the feedback loops—branching strategy, CI/CD hygiene, change size, and operational excellence. Choosing the right metrics for an engineering org matters as much as the metrics themselves. I use a balanced set: delivery (lead time for changes, deployment frequency), quality (change failure rate, availability), and flow (work in progress, batch size). Then I pair these with narrative context so the numbers inform decisions rather than become a game to win. On policy, nuance beats orthodoxy. Great leaders define clear, default rules while acknowledging real-world exceptions. I’ve learned to document the policy, define who can grant exceptions, and track exception volume to spot design flaws. The goal isn’t rigidity—it’s predictable operations with a safe on-ramp for edge cases. Micromanagement is a symptom, not a root cause. Telling someone “don’t micromanage” is often counterproductive. Instead, I focus on what’s missing—trust, clarity, or visibility. If leaders can see the plan, the risks, the checkpoints, and the demo cadence, they don’t need to hover. If they still do, fix incentives and accountability, not just behavior. I avoid management anti-patterns by watching for early signals: policies without principles, roadmaps without strategy, meetings without decisions, or dashboards without actions. The best engineering executives pair systems thinking with crisp communication. They’re close enough to the details to ask sharp questions, yet disciplined enough to scale through managers and staff engineers. Executive communication is an asymmetric game. I tailor the message to the decision horizon: one slide for the ask, one for the trade-offs, one for the plan and risks. The Minto Pyramid (framework) helps—lead with the answer, then support it. In meetings, the fastest way to derail progress is to lack a clear owner, a time box, or pre-reads. Fix those and you reclaim hours every week. For presentation feedback, I’ve found a cadence that works: clarify the objective, highlight the single biggest risk, and eliminate anything that doesn’t move the decision forward. A bad sign with direct reports is when updates are status-only and insight-light; I coach toward “what changed, why it changed, and what you need.” For early-career engineers, the most durable advantage is compounding learning: pick hard problems, write more than you think you should, and seek out leaders who invest in your growth. For team development, I borrow a simple model: staff your keystones, instrument your systems, and build a culture where the best ideas win, not the loudest voices. If you want to explore the foundations behind these practices, start here. Accelerate (book): https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339 Good Strategy, Bad Strategy (book): https://www.amazon.com/Good-Strategy-Bad-Difference-Matters/dp/0307886239 DORA: https://dora.dev/ SPACE (framework): https://queue.acm.org/detail.cfm Minto Pyramid (framework): https://untools.co/minto-pyramid Carta: https://www.carta.com/ Calm: https://www.calm.com/ Stripe: https://www.stripe.com/ JavaScript: https://www.javascript.com/ KAFKA: https://kafka.apache.org/ Ruby on Rails: https://rubyonrails.org/ To go deeper on Will’s writing and perspective, these are great starting points. Twitter/X: https://twitter.com/lethain LinkedIn: https://www.linkedin.com/in/will-larson-a44b543/ Personal website/blog: https://lethain.com/ An Elegant Puzzle (book): https://www.amazon.com/Elegant-Puzzle-Systems-Engineering-Management/dp/1732265186 Staff Engineer (book): https://staffeng.com/book
-
Inside Bard’s Playbook: How to Ship AI Fast, Build Ethically, and Outlearn Competitors
I spend a lot of time helping teams reconcile two pressures that define modern product management: ship fast enough to learn and compete, but slow enough to be safe, ethical, and useful. Studying Bard offers a crisp blueprint for navigating that tension and leveling up how we build with Generative AI. Jack Krawczyk is a Senior Director of Product at Google, building Bard. Bard is Google’s collaborative, conversational, and experimental AI tool that’s bridging the gap between humans and bots, while addressing ethical considerations around AI. After joining the project in 2020, Jack helped ship Bard in less than four years. Bard sources information directly from the web, and now enables users to inquire about and summarize YouTube videos. From a product management lens, the most valuable takeaway is the sequencing: problem definition → principled constraints → rapid public learning with clear guardrails. I’ve seen this order de-risk speed. When we anchor teams on a tight product thesis and ethical framework, we unlock faster iteration without drifting into feature theater. Shipping early—especially with a Large Language Model (LLM)—can feel risky. Yet the decision to open Bard to the public quickly reflects a disciplined bias toward learning velocity. In my experience, the longer we delay real-world feedback with LLMs, the more our internal assumptions calcify. Early exposure surfaces edge cases, calibrates safety systems, and drives better prioritization than any lab-only evaluation can. Ethics in AI is not a separate workstream; it’s a product requirement. I anchor cross-functional reviews on harm modeling, transparency, and user agency. Bard’s framing makes this explicit: collaborative, conversational, experimental—language that signals co-creation and responsible exploration rather than unfettered automation. That positioning matters for trust and sets expectations for both quality and limitations. Differentiation in AI assistants increasingly hinges on live context and modality. Bard sources information directly from the web, and now enables users to inquire about and summarize YouTube videos. In practice, this moves Bard beyond static Q&A toward dynamic sensemaking. I advise teams to ask: what fresh, authoritative context can our system responsibly ingest to reduce hallucinations and increase actionability? On development speed, I look for a culture that marries ambition with measurable risk reduction. That means small, end-to-end vertical slices; evaluation harnesses aligned to user outcomes, not model vanity metrics; and weekly red-teaming that actually changes the roadmap. Outcomes vs output OKRs are critical here—optimize for quality-adjusted learning per unit time, not just feature count. Early user research should be embedded, not episodic. I’m a proponent of forward deployed engineers paired with product and research to observe failure modes in the wild and close the loop quickly. With LLM-based experiences, qualitative signals (confusion, trust breaks, cognitive load) often precede quantitative ones; instrument both and let them inform each other. Deciding when to ship comes down to clear thresholds. I pressure-test launch criteria with two prompts: what would change my mind tomorrow, and what could break if we’re right but too early? For AI features, I also require recovery paths—explanations, undo, source attribution—so that small misses don’t become trust-ending moments. As for the competitive landscape—Bard versus ChatGPT, and others—users ultimately reward utility, reliability, and workflow fit. I encourage teams to pick a sharp use case, lean into their unique distribution or data advantage, and prove value in minutes, not weeks. “Generative AI” is table stakes; reliable outcomes in a real job-to-be-done is differentiation. Zooming out, I see three fronts shaping the future of LLM, Generative AI, and AGI: model capability, grounding and retrieval quality, and product ergonomics. Most teams overinvest in capability and underinvest in grounding and UX. The fastest wins often come from better retrieval, tighter prompts, and clearer affordances—not just a larger model. For aspiring AI developers, start narrow and instrument deeply. Pick a workflow with painful status quo, ship a thin slice, measure correctness and confidence, and iterate with real users. For non-LLM companies, the mandate is different: augment your core product where AI reduces friction or unlocks frequency—don’t bolt on a chatbot because everyone else did. For product leaders, AI changes the craft in two ways. First, prototyping is faster—use this to expand the option space early. Second, evaluation requires new muscles—build an experimentation and safety stack that blends qualitative red-teaming with quantitative reliability and cost controls. The leaders who thrive will combine taste with statistical rigor. If you want to go deeper, these references are useful: Bard: https://bard.google.com/; ChatGPT: https://chat.openai.com/; Duet AI: https://cloud.google.com/duet-ai; Free courses on machine learning by Andrew Ng: https://www.andrewng.org/courses/; Google Assistant: https://assistant.google.com/; Introducing Google Assistant to Bard: https://blog.google/products/assistant/google-assistant-bard-generative-ai/; Large Language Model (LLM): https://en.wikipedia.org/wiki/Large_language_model; Meena: https://blog.research.google/2020/01/towards-conversational-agent-that-can.html. In sum, the Bard blueprint reinforces a simple truth: ship with a thesis, learn in public with care, and let principled constraints accelerate—not slow—your path to product-market fit. That’s how we create value fast, build ethically, and stay ahead in the next era of AI.
-
Winning with Open Source and SaaS: My GTM Playbook, Monetization Tactics, and Founder Fit
I’m often asked how to win when your product strategy spans both open source and closed source. My short answer: treat community, product, and go-to-market as one system, then sequence each move with ruthless clarity. Reflecting on Neha Narkhede’s journey helped crystallize a practical playbook for building, monetizing, and scaling category-defining platforms.
Neha Narkhede is a co-founder at Confluent, a data streaming software that raised at a $9.1b valuation in 2021. Neha later co-founded Oscilar, a no-code platform that helps companies detect and manage fraud. Before building these two companies, Neha was a Principal Software Engineer at LinkedIn where she co-created Apache Kafka. Neha is ranked #50 on Forbes’ list of “America’s Richest Self-Made Women 2023” with an estimated net worth of $520m.
Here’s what stood out to me as a product leader: the origin of Apache Kafka inside LinkedIn wasn’t just a technical breakthrough—it was an obsessive response to a clearly defined, acute infrastructure pain. Open sourcing it wasn’t a marketing move; it was a distribution masterstroke that built trust, accelerated adoption, and seeded a future enterprise business.
On company-building, the “Zero to One” at Confluent was uniquely disciplined: build for a specific customer early on, earn credibility with developers through education and evangelism, and simultaneously position as an enterprise-grade solution. I’ve seen this duality—developer-first credibility with enterprise posture—unlock velocity in complex platform markets.
Monetizing open source product works when you’re intentional about what to license and what to open source. Commercial value clusters around enterprise security, governance, scalability, observability, and reliability features—plus SLAs customers can’t get from the community. That’s how you can run two businesses within one company: a software business and a SaaS business that remove operational burden and expand the addressable market.
Confluent’s approach to SaaS versus software is instructive. Confluent Cloud delivers a consumption SaaS model where pricing aligns to value realized, not just time elapsed. Subscription SaaS versus consumption SaaS requires different GTM motions, different product telemetry, and different revenue operations. I’ve found success by matching pricing units to customer mental models and by instrumenting usage early to drive product-led expansion.
Developer evangelism played a pivotal role in category creation. It’s not merely about talks and tutorials—it’s a systematic way to collapse time-to-value, reduce perceived risk, and compress a buyer’s learning curve. When you blend education with hands-on pathways—demos, sandboxes, quickstarts—you transform top-of-funnel curiosity into bottom-of-funnel conviction.
Founder-led GTM was another powerful theme. Early on, I prioritize direct customer conversations, hands-on discovery, and live deal support. The order of operations matters: validate the ICP, close lighthouse customers, codify the repeatable sales narrative, then operationalize outbound once the signal-to-noise ratio is high. That sequence prevents premature scaling and preserves momentum.
For second-time founders, the takeaway is focus and speed. Build differently the second time by compressing cycles from speculation to product realization. Neha’s “proactive research sprint” resonates with my own practice: pressure-test the problem, define must-have requirements with real users, and ensure you’re solving problems people are actually willing to pay for—before building full-stack.
Oscilar exemplifies this clarity. A no-code platform to detect and manage fraud aligns to an urgent, quantifiable pain with measurable ROI. That’s founder-market fit: where your experience, the market’s urgency, and the product’s capabilities directly reinforce one another.
If you’re navigating open source and SaaS together, here’s the practical synthesis I use: define your ICP early; decide what to open source versus license based on enterprise risk and operational burden; invest in developer experience and evangelism to power category creation; choose pricing that mirrors value realization (consumption when possible); and keep founder-led sales at the forefront until the narrative is truly repeatable. Done well, you can run two businesses inside one company without diluting focus.
Apache Kafka: https://kafka.apache.org/
Confluent: https://www.confluent.io/
Confluent Cloud: https://www.confluent.io/confluent-cloud/
Jay Kreps, co-founder at Confluent: https://www.linkedin.com/in/jaykreps/
Jun Rao, co-founder at Confluent: https://www.linkedin.com/in/junrao/
MongoDB: https://www.mongodb.com/
Oscilar: https://oscilar.com/
Where to find Neha:
LinkedIn: https://www.linkedin.com/in/nehanarkhede/
Twitter/X: https://twitter.com/nehanarkhede
Website: https://www.nehanarkhede.com/
-
Master Modern Entrepreneurship: Build Lean, Start Young, and Obsess Over Customers
Modern entrepreneurship demands speed, clarity, and relentless customer focus. In my role leading product management and shipping category-defining features, I’ve learned that the fastest way to build enduring companies is to build lean, start young in our experiments, and study customers with scientific rigor. This is not about heroics; it’s about disciplined learning and making the market the ultimate arbiter of truth.
The foundational playbooks still guide my day-to-day: the Lean Startup approach and the timeless lessons from The Four Steps to the Epiphany and The Startup Owner’s Manual. Even in 2025, these ideas remain remarkably relevant because they center on one principle we can’t automate away—deep, direct customer understanding.
Why aren’t there more successful startups? Most teams conflate building with learning. They fall in love with solutions, optimize for output over outcomes, and skip the uncomfortable parts of customer discovery. Another pattern I see: teams ignore market type. The tactics for entering an existing market versus creating a new one are fundamentally different; using the wrong go-to-market playbook can erase months of runway.
Improving entrepreneurship in the USA starts with how we teach it. We should normalize hypothesis-driven product discovery in high schools and universities, pair students with real customers, and fund lightweight experiments instead of polished business plans. Programs modeled after The lean launchpad at Stanford demonstrate that when we combine mentorship, evidence, and speed, we create founders who learn faster than the market changes.
Lean Startup is also widely misunderstood. An MVP is not an excuse for low quality; it’s a vehicle for validated learning. The goal is to reduce uncertainty—not craftsmanship. The best teams run a cadence of testable hypotheses, instrument the product to capture evidence, and tie their roadmap to outcomes vs output OKRs so effort maps directly to measurable customer and business value.
Curiosity is the meta-skill. The founders who win are addicted to understanding “why” customers behave the way they do. Instincts matter, but instincts sharpen with reps. I treat instincts as hypotheses: hold them lightly, test them aggressively, and let the data upgrade your intuition.
Outlier founders often share similar traits: an early comfort with ambiguity, an almost irrational attachment to a future state, and a bias for action. That “irrational” conviction is a feature, not a bug—so long as it’s paired with a willingness to invalidate one’s own beliefs when the evidence contradicts them.
Becoming a great founder CEO requires a personal pivot from maker to multiplier. Early on, be the chief learner and chief seller. As traction builds, invest in systems—hiring bar, decision frameworks, and operating rhythms—that scale beyond your own heroics. I’ve found that clear product strategy, crisp decision rights, and outcomes vs output OKRs create the scaffolding for autonomy without chaos.
Why do some second-time founders fail? They overfit to their previous win, underestimate how much luck and timing played a role, or import a playbook that doesn’t match the new market type. The antidote is humility and fresh customer discovery—treat your new company like your first, and earn product-market fit again.
Building in existing versus new markets demands different muscles. In an existing market, your edge is focus, speed, and a sharp wedge that exploits a neglected segment or workflow. In a new market, your job is category education, sequencing use cases to reduce friction, and architecting distribution while the value narrative is still forming.
When I evaluate what makes a startup successful, I look for a learning velocity advantage: a team that runs more meaningful experiments per unit time than peers, converts insights into product changes quickly, and compounds those lessons into differentiation. Execution quality matters, but the compounding engine is the ability to discover truth faster.
On leadership, I often point to Satya Nadella’s transformation at Microsoft as a case study in rewriting culture through a growth mindset and customer-centric innovation. It’s a reminder that the “founder mentality” can be cultivated at scale when leaders change incentives, narratives, and mechanisms in concert.
The Four Steps to the Epiphany in 2023 (and beyond) still hold: Customer Discovery, Customer Validation, Customer Creation, and Company Building. I treat them as a continuous loop rather than a one-time sequence. Discovery never stops; validation is ongoing; creation evolves with channels and pricing; company building is the operating system that sustains the pace of learning.
If you’re building today, start smaller, learn faster, and get closer to the customer than your competition thinks is necessary. The compounding effect of disciplined product discovery, evidence-based roadmapping, and founder-led storytelling remains the closest thing we have to an unfair advantage.
-
The New PLG Playbook: Avoid the Trap, Win Enterprise, and Break the $10B Ceiling
Product-led growth is powerful, but it can stall when teams mistake bottom-up activation for durable enterprise value. I’ve seen high-velocity self-serve engines hit a ceiling and wondered why the graphs flatten just shy of breakout scale. This is my updated playbook for avoiding the stall, winning enterprise adoption, and compounding into category leadership.
At the core, the differences between PLG and enterprise companies come down to how rigorously we translate user value into company value. Bottom-up adoption, time-to-value, and collaboration loops are essential — but without verified ROI tied to executive priorities, the engine sputters. That’s the “PLG trap”: a product everybody loves but a business that struggles to justify top-down investment.
I often use the contrast between user value versus company value to explain this gap. It’s why brilliant collaboration tools can go viral yet struggle to close budgeted deals. One stark lesson: “Dropbox had almost no company value.” When you dig into “Why Dropbox is worth $10b, not $50b,” you see the cost of not turning bottom-up enthusiasm into executive-aligned outcomes, integrations, and measurable impact on the business.
Transitioning to enterprise can feel like building two companies at once — and in many ways, it is. You must preserve the product-led engine while layering enterprise-grade capabilities, packaging, and proof. Think of it as “The playbook for transitioning into enterprise”: enterprise security and admin, deployment support, integrations into systems of record, and verifiable ROI. On top of that, you need a narrative that elevates from individual productivity to organizational outcomes.
That’s where the relationship between OKRs and executive champions becomes pivotal. Enterprise buyers don’t purchase features — they purchase progress against objectives. I align our value narrative directly to executive OKRs, then instrument the product and the sales process to quantify that movement. Executive champions emerge when we reliably help them hit their goals and make them look like heroes in their orgs.
On message, I’ve found the most effective positioning is deceptively simple: “selling clarity.” When you help leaders reduce chaos, align teams, and ship outcomes with less friction, your product stops being a tool and starts being an operating system for work. The shift from activity to clarity is what elevates company value.
“How and when to build an enterprise sales team” depends on traction signals. I look for repeatable proof of company value (multi-team adoption, enterprise-grade requirements appearing in deals, measurable impact on OKRs) before hiring a small, senior team of sellers, solutions engineers, and post-sales partners who can navigate complex orgs. Early on, I keep this team tight and highly analytical, obsessing over learning velocity rather than coverage.
To accelerate pipeline and expansion, I map power and influence using the champion tree framework. This forces clarity on the relationships between users, managers, and executive sponsors — and how value flows across that network. In parallel, a unique customer success team focused on activation, habit-building, and executive reporting turns early landings into durable, budgeted expansions.
For GTM, I operationalize the seed, land, and expand framework. Seed with irresistible self-serve value; land with a clear enterprise package that meets security, governance, and integration needs; expand with measurable outcomes, executive dashboards, and a cadence that ties adoption to business results. This is how you respect the PLG motion while building enterprise muscles.
There are strategies PLG companies should avoid. The most common mistakes include building horizontally too early, optimizing solely for signups instead of revenue-qualified usage, and treating enterprise as just another pricing tier. “Building horizontally may be a mistake” if it dilutes the wedge that wins executive mindshare. Depth beats breadth until the wedge reliably translates into company value.
So, “How PLG companies can break $10 billion market cap”? Earn the right to expand. Nail one or two high-value enterprise use cases, prove ROI against OKRs, and turn that proof into a repeatable playbook across segments and industries. Then widen the surface area — compliance, data controls, workflow integration, cross-functional analytics — and sequence multi-product expansion as an outcome of credibility, not a substitute for it.
Finally, “Why it’s difficult to emulate Atlassian, Slack or Salesforce.” Their eras, audiences, categories, and ecosystems were uniquely favorable to their playbooks. Emulation without context leads to cargo cults. Instead, adopt the principles: reduce time-to-value, monetize company value, build ecosystems intentionally, and design your GTM so self-serve fuels — not fights — the enterprise motion.
If you’re a founder or product leader, my guidance is simple: define the smallest wedge that connects user value to executive value; measure it obsessively; and build a lightweight, senior enterprise motion the moment you see repeatability. From there, keep “selling clarity,” nurture executive champions, and let seed, land, and expand do the compounding.
Referenced resources:
Airtable: https://www.airtable.com/
Asana: https://asana.com/
Atlassian: https://www.atlassian.com/
Bitbucket: https://bitbucket.org/product/
Confluent: https://www.confluent.io/
Daniel Shapero: https://www.linkedin.com/in/dshapero/
Datadog: https://www.datadoghq.com/
Dennis Woodside: https://www.linkedin.com/in/dennis-woodside-341302/
Dropbox: https://www.dropbox.com/
Dustin Moskovitz: https://www.linkedin.com/in/dmoskov/
Jay Simons: https://www.linkedin.com/in/jaysimons/
Jira: https://www.atlassian.com/software/jira
Justin Rosenstein: https://www.linkedin.com/in/justinrosenstein/
Kim Scott: https://www.linkedin.com/in/kimm4/
Salesforce: https://www.salesforce.com/
Slack: https://slack.com/
The PLG Trap: https://www.linkedin.com/pulse/plg-trap-oliver-jay/
The seed, land, and expand framework: https://www.endgame.io/blog/seed-land-expand-framework
Zendesk: https://www.zendesk.com/
-
From Zero to One: My Playbook for Building a World‑Class Sales Org (Lessons from Figma)
When I think about building a world-class sales organization from scratch, I look for playbooks forged in the hardest part of the journey: zero to one. Kyle Parrish, Figma’s first sales hire, built the company’s zero-to-one sales engine from scratch. Figma now has more than 3 million monthly users. Prior to Figma, Kyle spent 5 years at Dropbox in various sales roles. At Dropbox, Kyle successfully launched and scaled the Austin office to 100+ people, and then led the enterprise sales function in San Francisco and New York. Those facts anchor a set of timeless lessons I’ve applied in product management leadership and in partnering with sales to drive product-market fit and revenue.
The right time to build a sales function is when founder-led sales start to constrain learning speed and repeatability. Before hiring, I pressure-test three inputs: a clear ideal customer profile, a crisp value hypothesis supported by real usage, and a repeatable early sales motion that I can document. If I can’t capture the core narrative, top three proof points, and the qualification rubric on one page, I’m not ready to scale. That discipline protects runway and focuses product discovery on what truly moves the needle.
Who to hire first matters even more than when. I look for a builder-athlete—someone who thrives in ambiguity, writes their own talk tracks, and views every customer interaction as a product feedback loop. This person should be comfortable with founder-level context switching: discovery in the morning, enablement at lunch, and early pipeline surgery in the afternoon. I prioritize curiosity, writing clarity, and a history of winning in imperfect environments over shiny logos or rigid playbook adherence.
Integrating your first sales hire is as critical as selecting them. I embed them with product and support in the first 30 days, pair them with a designer or PM on weekly customer sessions, and give them a public Notion or doc to codify objections, narrative experiments, and qualification notes. The goal isn’t velocity at all costs—it’s precision learning at speed. That early collaboration helps us transition cleanly away from founder-led sales while preserving the product’s authentic voice.
Early sales motion should be simple, specific, and measurable. I start with a tight segment, insist on consistent discovery questions, and run weekly film reviews on calls to refine our narrative. If customers force me to constantly re-explain what we are, I treat that as a sign to evolve the story. It’s common to change the customer narrative as you learn which use cases actually land and expand. The best motions translate product magic into business outcomes without diluting what makes the product beloved.
On hiring and scaling, I favor a bar-raiser approach. The ideal experience sales candidates should have is less about title and more about evidence of building: writing the first playbook, proving repeatability, and showing that they can recruit talent better than themselves. Common traits of successful salespeople at this stage include intellectual humility, a builder’s bias, and an almost editorial standard for customer communication. I’ve seen unique hiring processes—live role plays with real customer objections, writing-based exercises, and cross-functional panels—consistently reveal signal that traditional interviews miss.
Outbound strategy should start narrow and be relentlessly measured. A small number of well-defined hypotheses, clean data, and tight messaging loops beat high-volume outreach every time. I’ve also seen segmented pricing and no discounts create the right incentives for clarity and value alignment. While discounting can appear to accelerate wins, it often erodes positioning and invites endless custom deals that break the product roadmap.
World-class sales culture is product-centric, rigorous, and kind. It prizes candor without ego, craftsmanship in discovery, and a respect for time—customers’ and teammates’. In practice, that looks like crisp deal reviews, transparent pipeline hygiene, and shared ownership of learning with product and engineering. Navigating the founder/Head of Sales relationship is easier when you align on definitions of a qualified opportunity, the ladder of proof for a narrative, and the weekly operating rhythm.
For ambitious salespeople, I offer straightforward advice: choose products you genuinely admire, ask better questions than everyone else, and write your learnings in public within the company. Your career compounds fastest when you become the teammate product and design proactively loop in. For early leaders, the most underrated skill is scaling yourself—documenting decisions, building systems that outlast you, and coaching your team to be better than you were at the same stage.
I’m often asked what differentiates exceptional founding leaders and early go-to-market operators. The secret to Dylan Field’s success is frequently framed around vision and product taste, but I also see a remarkable capacity to listen deeply and operationalize feedback without losing the soul of the product. Similarly, I’ve seen leaders like Oliver Jay model crisp execution and high-velocity learning—reminders that culture and cadence are strategic assets, not afterthoughts.
If you’re about to hire your first salesperson, simplify the brief: clarify who you serve, why you win, and what great looks like in the first 90 days. Start with a small, high-talent nucleus united by a passion for the product, then layer process only where it accelerates learning. Do a few important things exceptionally well, and let the results pull you toward scale rather than trying to push your way there prematurely.
-
From Vertical Focus to Power Users: My Playbook for Product-Market Fit and Founder Mindset
I’ve learned that the fastest route to product-market fit blends ruthless focus, a tight-knit community of power users, and a clear-eyed understanding of founder psychology. As a VP of Product, I’ve seen how aligning strategy and self-awareness creates compounding advantages—especially when you commit to a vertical, build with your most advanced users, and make decisions faster than your market shifts.
Start narrow. Building for a specific customer forces clarity: one ICP, one core job to be done, one measurable outcome. That single-threaded focus removes ambiguity from product discovery, sharpens prioritization, and accelerates iteration. Only after unmistakable pull—retention, compounding usage, and customer-led expansion—do I widen the aperture to a broader customer base.
Clay is a lead-generation software that uses AI to scrape 50+ databases and help companies scale their outbound campaigns. When I evaluate products like this, I look for a crisp vertical wedge (for example, outbound sales teams or growth marketers), a clear “time-to-first-value” path, and strong affordances for advanced workflows. Winning a vertical creates a reliable beachhead for expansion without diluting the core value proposition.
Power users are the engine of product evolution. I actively identify and convene them—by analyzing power-law usage patterns, high-complexity workflows, and frequent integration touches—then invite them into hands-on feedback loops. I’ve found small, recurring sessions where we co-design in Figma and document patterns in Notion to be especially effective. These users don’t just validate; they reveal emergent use cases, inspire templates, and shape the roadmap. The result is a community that evangelizes organically and sets a high bar for everyone else.
Speed is a strategy. I front-load decisions with clear success criteria, kill-switch thresholds, and a cadence of two-to-four-week sprints. The discipline isn’t just “moving fast”—it’s committing to bounded bets, reducing work-in-progress, and measuring outcomes over output. Focus is often misunderstood as doing less; in practice, it’s doing the essential few things completely and letting the data make the hard calls. This mindset unlocks faster iteration cycles and cleaner OKRs that reflect real customer value.
My principles for product-market fit are simple but demanding: undeniable engagement (habitual use without prompts), concentrated love from a specific customer archetype, willingness to endure friction for core value, expansion motions that begin with usage not discounts, and a backlog shaped by customer pull rather than internal aspiration. When these signals converge, you don’t ask, “Do we have PMF?”—you ask, “How do we scale responsibly?”
Founder psychology shapes the product more than most admit. A company is the reflection of its founder’s personality, from appetite for risk to tolerance for ambiguity. I align my own psychology with the business through honest self-inventory, explicit constraints, and a cadence of reflection. I’ve found the life spiral framework helpful to contextualize growth phases, and techniques from Internal Family Systems to reduce reactive decision-making. The outcome is a calmer operating system that scales with the company rather than against it.
Translating this into a customer journey, I design for a sharp “aha” moment within minutes, a guided path to first successful workflow, and a clear unlock that turns a single task into a repeatable motion. From there, I build leverage: templates, automations, and integrations that accelerate outcomes for advanced users while remaining accessible to newcomers. This is how individual success becomes team adoption—and team adoption becomes the basis for expansion.
To ground strategy in practice, I often pair discovery and build cycles with tools that meet teams where they already work: Airtable: https://www.airtable.com/, Clay: https://www.clay.com/, Figma: https://www.figma.com/, Internal Family Systems: https://ifs-institute.com/, NetSuite: https://www.netsuite.com/, Notion: https://www.notion.com, Sailthru: https://www.sailthru.com/. The stack matters less than the behaviors it enables: rapid prototyping, transparent collaboration, and decision trails that survive scale.
If you’re moving from first-time to second-time founder (or leading product through that evolution), the mindset shift is profound: less attachment to ideas, more attachment to evidence; fewer bets, bigger conviction; and a deeper respect for focus as an accelerant. Lean into vertical excellence, invest in your power users, and do the inner work. That’s how you achieve product-market fit—and keep it.
-
The Human Side of Engineering Leadership: Practical Plays to Build Creative, High-Performing Teams
Engineering leadership is a human sport first and a technical sport second. The longer I lead product and engineering teams, the more convinced I am that world-class execution comes from clarity, trust, and an environment designed for deep work — not just clever architectures or more process. In my role leading product, I see the biggest unlocks happen when we combine operational excellence with empathy and purpose.
My “utopia” — where engineers have time to create and invent — starts with sacred focus time. I protect no-meeting blocks, design sprints that include exploration, and carve out recurring capacity for prototypes and technical debt. When builders know they have sanctioned space to think, we get more product discovery, better ideas, and fewer last-minute heroics.
Shipping software at scale is difficult, and it’s harder to ship today than ever before. Complexity from microservices, compliance, security, platform fragmentation, and AI-driven surface area expands every quarter. The counter is operational hygiene: clear ownership, ruthless scope, a predictable release cadence, excellent tooling, and a culture that values outcomes over activity.
What makes a startup operationally sound is surprisingly simple to describe and hard to do consistently. Define decision rights, keep teams small and mission-aligned, instrument everything, and ship on a reliable train. Feature flags, dark launches, automated testing, and crisp rollbacks turn risk into routine. Most importantly, we write things down — intents, constraints, and success metrics — so execution scales beyond any single leader.
Product managers can dramatically improve engineering culture. The fastest way is through precision: sharp problem statements, explicit success metrics, clear acceptance criteria, and honest trade-offs. I hold our team to “outcomes vs output OKRs,” framing goals by customer and business value rather than task volume. PMs should also shield makers from thrash, resolve ambiguity quickly, and bring real users into the room early and often.
From an engineer’s perspective, good product management sounds like respect for the craft. We acknowledge performance budgets, technical constraints, and the hidden cost of complexity. We ask for estimates responsibly, show our work in decision docs, and make room for forward deployed engineers to close the loop with customers. When PMs consistently do these things, trust grows — so does velocity.
The role of product compared to design and engineering is easy to state and easy to forget: product owns the why and what, design owns how it feels, engineering owns how it works, and all three own the outcome. I treat the PM job as system optimization across functions — removing friction, sequencing bets, and maximizing learning per unit of time. When incentives are aligned to shared outcomes, handoffs turn into collaboration.
Micromanagement kills creativity. Declarative versus prescriptive leadership is the antidote: set the intent, define the constraints, agree on the measures of success — then get out of the way. I replace step-by-step tickets with a one-page brief and a weekly demo cadence. Guardrails create safety; autonomy creates ownership; together they create better software.
I foster a debate culture by making disagreement safe and productive. We write RFCs, invite dissent, time-box decisions, and “disagree and commit” when the window closes. Good debates chew on assumptions, not people. The payoff is compounding judgment and a team that can argue well without leaving scars.
Three leadership ideas I practice every week: first, default to clarity — ambiguity is the silent killer of execution. Second, manage energy, not just time — sustain the team’s battery with realistic pacing and visible wins. Third, train judgment — distinguish one-way doors from two-way doors and match decision speed to reversibility.
Understanding employee motivation is a superpower. People move for different reasons — mastery, autonomy, purpose, progression, compensation, recognition. I map motivations explicitly in 1:1s and shape work accordingly. When someone’s day-to-day aligns with what they value most, performance and retention both rise.
My advice on discovering what motivates people is straightforward: ask better questions and observe the work. I love asking, “What feels like play to you but looks like work to others?” I rotate responsibilities to run small experiments, then codify what sticks in growth plans. Motivation is dynamic; treat it like a product you’re constantly rediscovering.
On org design, I review team topology every six months. Strategy changes and customer needs evolve; our organization should, too. I favor lightweight reorgs — adjusting missions and interfaces rather than wholesale reshuffles — and I use rotations to refresh learning without destabilizing roadmaps. The aim is responsiveness without chaos.
One habit I see in successful leaders is relentless focus on outcomes. We inspect impact, not activity, using transparent scorecards, weekly business reviews, and OKR hygiene that spotlights real progress. When outcomes are the north star, prioritization becomes sane and teams feel meaning in their work.
Sound judgment is crucial for decision-making. I separate reversible from irreversible choices, run pre-mortems, and keep a decision log so we can learn at the portfolio level. Informed speed beats perfect slow, and fast follow-ups are a feature, not a bug.
Crystallized lessons from large-scale software environments keep proving true: cadence beats heroics, observability pays for itself, and investment in developer experience is the highest-ROI platform bet you can make. Also, write it down — clear artifacts are how complex systems learn together.
I stay wary of becoming irrelevant. The antidote is shipping, curiosity, and deliberate learning — talking to customers weekly, pairing with engineers, and letting junior talent teach me new tools and patterns. Relevance is earned every quarter.
If I had to pick one leadership lesson, it’s this: people remember how you made them feel. Trust, candor, and consistency create the conditions for excellence. The best strategy in the world won’t move if people don’t feel seen, safe, and challenged.
I’ve changed my mind on a few big things: more documentation beats more meetings, hybrid can outperform in-office with the right rituals, and smaller, more frequent reorganizations are better than large, rare ones. I used to think speed and quality were a trade-off; now I think clarity gives you both.
My growth has been shaped by thoughtful operators, designers, and engineers who taught me to balance ambition with stewardship. Their fingerprints are on these practices, and my teams’ results are better for it. The human side of engineering leadership isn’t soft — it’s the hard edge that makes everything else work.
-
Customer Success Masterclass: How I Design, Build, and Scale a World‑Class CS Org
Customer success is not a department I bolt on after product-market fit — it’s a strategic engine I design in parallel with product, sales, and support. In my role as VP of Product Management at HighLevel, I’ve learned that the fastest way to accelerate growth is to operationalize value delivery, from onboarding to renewal. In this masterclass-style breakdown, I share how I formalize customer success in early-stage companies, the hiring and compensation tactics that actually work, and the metrics and rituals that keep teams focused on outcomes.
When I formalize customer success at a startup, I start small and intentional. The goal of v1 isn’t scale — it’s clarity. I define the core moments that matter (onboarding, time-to-first-value, activation, expansion), codify the handoffs with sales and product, and set outcomes vs output OKRs so the team is measured on customer impact, not activity. Only once I can consistently predict value delivery do I introduce more specialization and automation.
Early hiring order matters. I typically hire ICs before building out a full CSM layer. Think implementation managers, solutions consultants, and forward-deployed problem solvers who can translate ambiguous customer needs into product-anchored outcomes. These folks create the playbooks and close the “last mile” between product capabilities and customer workflows — a prerequisite to scaling a durable CS org.
My tactics for hiring standout talent are simple and disciplined. I source for learning athletes who show a bias for action and executive presence, not just a customer-facing resume. I run structured interviews and working sessions that simulate real problems. Three questions anchor my evaluation: 1) Tell me about a customer who was at risk — how did you quantify the risk and what did you do? 2) Describe a time when you influenced product direction using customer evidence — what changed? 3) Walk me through a renewal or expansion you orchestrated — what was your strategy, and how did you align incentives across sales, product, and CS?
Fail-case patterns are consistent across stages. The most common are: reactive firefighting instead of proactive planning, weak business acumen (can’t tie product usage to business value), and poor cross-functional muscle (inability to influence product, marketing, and sales). I avoid these by probing for data fluency, systems thinking, and evidence of repeatable playbooks — not one-off heroics.
I actively consider candidates with non-traditional backgrounds. Teachers, analysts, management consultants, and product-adjacent operators often outperform because they are structured thinkers, exceptional communicators, and relentless about outcomes. I assess them through scenario work and mentorship plans that accelerate domain onboarding.
I index hard toward a bias for action. In interviews and trial projects, I look for people who quickly form hypotheses, validate with customers, and ship iterative solutions. The best CS operators don’t wait for perfect data — they create momentum while instrumenting the learning loops that improve precision over time.
Here’s what v1 of customer success looks like in my playbook: a crisp onboarding journey with defined exit criteria, a success plan that ties product capabilities to business goals, a lightweight QBR rhythm focused on outcomes, and a clear escalation path for risk. I keep the tooling lean and favor a living playbook over ornate process — speed and clarity beat bureaucracy.
Key early-stage customer success metrics include adoption and depth of feature usage, time-to-first-value, product-qualified accounts, renewal intent, gross and net revenue retention, and engagement signals from executives and power users. I complement the numbers with disciplined rituals: weekly risk reviews, a win/loss “value realization” debrief, and a Voice of Customer readout that feeds directly into product discovery.
Should customer success or sales own renewals? My answer: align ownership to your business model. If your product is value-expansive with complex deployments, CS should co-own or own renewals to manage risk and value realization. If your motion is highly transactional or heavily quota-driven, sales can own the paper while CS owns the health and expansion signals. What matters most is a single, unambiguous source of truth for renewal accountability.
Where customer success fits into the org depends on stage and strategy. Early on, I advocate for a direct line of sight to the executive team and tight integration with product and sales. As the company scales, I ensure comp plans, OKRs, and planning cadences keep incentives aligned across functions. Misalignment between CS and sales (especially on expansion vs retention) is one of the fastest ways to erode customer trust.
To distinguish a product problem from a customer success one, I ask: is the failure one-to-many and reproducible (product), or one-to-few and context-specific (CS and onboarding)? If multiple segments show the same friction, I escalate to product with evidence: cohort analysis, user journeys, and a prioritized hypothesis backlog. If the issue is account-specific, I focus on enablement, configuration, and stakeholder alignment.
There’s a simple way to reduce churn: make value realization explicit and measurable from day one. Define what “success” means with the customer, instrument usage and outcomes, review progress in standing rituals, and intervene early when leading indicators fall. A proactive executive sponsor program — including direct outreach from product leadership on at-risk accounts — can be a force multiplier.
To get honest feedback, I decouple discovery from renewal cycles, use third-party or product-led surveys, and create safe, structured avenues for critique (e.g., advisory councils with clear rules of engagement). I also return the favor: close the loop on what we learned, what we shipped, and what we’re shelving — customers reward transparency with candor.
When customer success and product teams collaborate well, the whole system accelerates. Product discovery gets sharper, roadmaps reflect real-world value drivers, and launch readiness improves because CS has co-authored the enablement and rollout plan. I treat CS as a core input to product discovery, not just a downstream implementer.
Structuring an early CS team is about coverage and clarity. I start with a player-coach leader and a few high-caliber ICs, define segmentation and ratios (e.g., enterprise vs scaled), and standardize handoffs with sales and support. As signals stabilize, I layer in specialization: implementations, technical success, renewals management, and scaled programs for long-tail accounts.
For compensation packages, I align variable pay to controllable, outcome-centric metrics: gross retention for core CSMs, net retention for expansion-focused roles, implementation milestones for onboarding teams, and shared targets with sales when collaboration is essential. I avoid activity-based comp and use tiered accelerators to reward durable, high-quality results.
Aligning customer success with the business model is non-negotiable. In a low-touch, product-led motion, I invest in scaled programs, education, and in-product guidance. In complex B2B software, I prioritize executive alignment, value engineering, and strategic QBRs that map product adoption to business outcomes. The throughline is the same: prove ROI, relentlessly.
In B2B software, the role of customer success is to operationalize value realization. That means orchestrating people, product, and process so customers achieve their outcomes faster, renew with confidence, and expand because the value is undeniable. When done right, CS transforms from “post-sales support” into a revenue-creating, product-sharpening discipline.
Common customer success mistakes I see repeatedly include spinning up process before purpose, underinvesting in onboarding, confusing relationship management with executive influence, burying CS under misaligned incentives, and measuring output instead of outcomes. Avoid these, and you’ll build a world-class customer success org that scales with conviction.
Referenced: Aaron Levie: https://www.linkedin.com/in/boxaaron/, Box: https://www.box.com/, David Love: https://www.linkedin.com/in/david-s-love/, Gainsight: https://www.gainsight.com/, Jon Herstein: https://www.linkedin.com/in/jonherstein/, Jonathan Lister: https://www.linkedin.com/in/jonathanlister/, Ken Fine: https://www.linkedin.com/in/kmfine/, Medallia: https://www.medallia.com/, Nick Mehta: https://www.linkedin.com/in/nickmehta/, Opower: https://www.oracle.com/utilities/opower-energy-efficiency/
-
How to Find Your Product Wedge: Battle‑Tested SMB SaaS Lessons from Square, Gusto, and My Playbook
Every enduring platform I admire started with a sharp product wedge—an unmistakably form‑fitting solution to a painful, persistent problem. In my own work leading product teams, I’ve seen how a great wedge unlocks momentum, trust, and distribution long before you earn the right to build horizontally. In this piece, I break down what I’ve learned from studying companies like Square and Gusto, and share the practical playbooks I use to find wedges, scale them, and turn them into platforms.
SMBs require unique software solutions because their constraints are different: time is scarce, tasks are juggled by a small team, and workflows span both the front of house and the back office. What wins is software that collapses steps, automates compliance, and delivers clear ROI in hours—not quarters. If you can’t demonstrate immediate utility and reduce cognitive load, you won’t earn a second week of usage, let alone loyalty.
The level of specificity required when building for SMBs is higher than many expect. “Form‑fitting” isn’t just a metaphor—it’s the difference between adoption and abandonment. In practice, that means obsessing over the exact moments of friction: where data gets retyped, where the cash drawer doesn’t reconcile, where payroll rules create anxiety. The fastest way to a wedge is to remove a choke point so completely that your product becomes the default way of working.
Building vertical versus horizontal SaaS is a strategic fork in the road. Verticals can win by encoding industry nuance (menus, wage rules, inventory, tip pooling), which drives faster adoption but narrows TAM and increases service intensity. Horizontal suites maximize TAM but risk feeling generic until they’ve earned trust. The play is often sequential: tight wedge first, then carefully adjacent expansions that preserve the original fit while compounding value.
Inside strong product orgs, decision‑making frameworks make that sequencing explicit. I lean on outcomes vs output OKRs to clarify what must improve for customers, not just what we plan to ship. I pair that with crisp guardrails—who we are building for, what problems we solve end‑to‑end, and what we intentionally ignore—for speed and focus. When everyone knows the game we’re playing, we can move faster with fewer meetings.
How to build horizontally from a wedge product: start by mapping the “jobs” that cluster around your wedge and identify which are triggered before, during, or after your core workflow. Expand into the nearest job that either (1) eliminates a costly handoff, (2) compounds your data advantage, or (3) increases switching costs without increasing complexity. Sequence matters; stitch together two workflows perfectly before you add a third.
I use The Three Horizons Model to balance the portfolio. Horizon 1 protects and grows the wedge with relentless quality and speed. Horizon 2 extends into adjacencies that deepen customer value and LTV. Horizon 3 explores new bets with asymmetric upside. The discipline is to time‑box and stage‑gate Horizon 3, so you develop options without starving the core or confusing the narrative.
Crafting a compelling vision for products means painting a clear picture of the world customers want—and the shortest believable path to get there. The vision should connect the wedge to a future platform, but every waypoint must feel pragmatic. When assessing Horizon 3 bets, I look for early signs of inevitability (regulatory tailwinds, data scale effects, platform shifts) and a credible edge we uniquely possess.
To give product teams the freedom to try things, I design for speed with safety: small, API‑first modules, toggled rollouts, and success metrics agreed upon upfront. Creating a risk‑taking culture isn’t about celebrating risk; it’s about celebrating validated learning. Make it cheap to run thoughtful experiments and easy to kill what doesn’t work.
Developing good product sense and intuition takes deliberate practice. I treat it like athletic ability: you can’t outsource reps. The fastest builders I know run weekly customer conversations, share raw call notes, and practice “storyboarding” real workflows until they can spot friction on sight. Five signs of great product sense: you predict failure modes before launch, you simplify scope without losing the magic, you can articulate the must‑have moment, you measure what matters, and you know when to say “not yet.”
Shipping faster without increasing headcount comes from better constraints, not heroics. I favor fewer, larger bets; pre‑wired cross‑functional pods; ruthless de‑scoping to the must‑have moment; and a zero‑tolerance policy for work that doesn’t move a core metric. Shorten the distance from insight to production, and speed shows up everywhere.
Generative AI is reshaping product discovery and prototyping. Tools like Copilot are accelerating content generation, scaffolding, and testable flows, which lets teams validate value propositions earlier and with more fidelity. I use gen AI for product prototyping to pressure‑test onboarding copy, simulate edge cases, and explore variations that would have taken weeks to mock by hand.
If you’re building for SMBs today, choose a wedge you can dominate, prove undeniable value fast, and then expand deliberately—one adjacent workflow at a time. The companies we admire didn’t skip steps; they sequenced them with conviction.
References and resources worth exploring:
Alyssa Henry: https://www.linkedin.com/in/alyssa-henry-0905692/
Copilot: https://copilot.microsoft.com/
Gokul Rajaram: https://www.linkedin.com/in/gokulrajaram1/
Gusto: https://gusto.com/
High Output Management: https://amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884
Marty Cagan: https://www.linkedin.com/in/cagan/
Opendoor: https://www.opendoor.com/
Silicon Valley Product Group: https://www.svpg.com/
Square: https://squareup.com/
The Three Horizons Model: https://www.mckinsey.com/enduring-ideas-the-three-horizons-of-growth
Toast: https://pos.toasttab.com/