Tag: product discovery

  • How I Build and Scale Winning Marketplaces: Demand, Supply, PMF, and Growth Loops

    How I Build and Scale Winning Marketplaces: Demand, Supply, PMF, and Growth Loops

    I’ve spent years building and scaling marketplaces and leading product teams through zero to one and one to many. Along the way, I’ve learned that winning marketplaces aren’t accidents—they’re engineered. In this first-person playbook, I break down what matters most, from the earliest choices that shape network effects to the growth loops that compound over time.

    When I start working on a new marketplace, I focus on a few non-negotiables: the atomic unit of value (what gets exchanged and why), the liquidity threshold (how much density is enough to trigger repeat use), and the trust model (policies, payments, and reputation that prevent disintermediation). Marketplaces rise or fall on liquidity, selection quality, price transparency, and reliability—get those right early and everything else scales more predictably.

    Marketplaces are different because they’re two-sided systems. They require careful sequencing of supply and demand, tight geographic or category focus to achieve density, and an operating model that remembers “the product is supply, not software.” I design the software to shape incentives and reduce friction, but I obsess over supply quality, responsiveness, and retention—because that’s what demand truly experiences.

    Finding product market fit is about measurable liquidity, not anecdotes. I track time to first transaction, percentage of new users who transact within their first session or week, repeat purchase rates by cohort, and supplier utilization. I use the “setup, aha, and habit” framework to design activation: great onboarding (setup), a fast, undeniable first success (aha), and a path to reliable repetition (habit). When those three lock in, network effects start to work for you.

    Scaling requires deliberate growth loops, not one-off channels. My go-to loops marry supply acquisition to demand creation: content/SEO loops (inventory generates pages that attract demand, which attracts more inventory), referral loops (happy suppliers bring peers, happy buyers bring friends), and performance loops (paid channels that are unit-economically profitable due to high LTV and rebuy rates). The goal is compounding, not dependency.

    There are 2 ways to acquire supply and demand in the early days: do things that don’t scale (hands-on supply curation, concierge onboarding, localized seeding) and build scalable systems (self-serve onboarding, programmatic SEO, performance marketing). I typically start manual to ensure quality and learning speed, then translate those learnings into self-serve flows and automation.

    What’s unique about building a marketplace is knowing when to shift focus between sides. I bias toward building great, retained supply first in narrow slices—one city, one category, one use case—then I layer demand once time-to-transaction is reliably short and fulfillment quality is high. As density rises, I rebalance: unlock more demand when supply is underutilized; throttle acquisition or expand geography/category when suppliers are at capacity.

    Hiring is another inflection point. Early on, I want scrappy generalists who can own a slice of the funnel end-to-end—supply ops, trust & safety, and growth-minded product managers. As we scale, I formalize teams around supply acquisition, supply success, demand growth, matching/relevance, and marketplace quality, with strong data science embedded throughout.

    Finding sticky customers depends on frequency and habit formation. In high-frequency categories, I relentlessly remove friction and drive reactivation. In low-frequency categories, I stay top of mind with utility features, content, and lifecycle nudges—because even “the best low-frequency marketplace” wins by owning the moments that matter before, during, and after the transaction.

    Category strategy requires patience. I generally prefer single-category focus until I’ve achieved strong liquidity and repeatability, then I consider adjacent expansion. I ask: does expansion improve marketplace health for existing users, or does it dilute density? “Single versus multi-category marketplaces” and “When to expand” aren’t philosophical questions; they’re math about liquidity, cross-sell, and operational complexity.

    Competitive strategy is instructive. “Uber versus Lyft” demonstrates how operational scale, category breadth, and geographic density compound advantages. “What Grubhub should’ve done” underscores the cost of missing durable loops and quality control. I also challenge provocative claims like “No value in car-sharing” by modeling unit economics, asset utilization, and multi-tenant demand patterns—use the data to decide what to believe.

    Looking ahead, I’m excited about “Emerging marketplaces in 2024,” especially vertical B2B, services with verified credentials, and embedded marketplaces inside workflow tools. As I scale any marketplace, I continually focus on “Improving supply and demand over time,” tightening SLAs, raising fulfillment quality, and reducing time-to-liquidity. I keep a running list of “Avoid these marketplace mistakes,” from subsidizing both sides for too long to expanding before density, and I revisit “One thing all marketplace founders should know”: compound advantages come from loops, not hacks.

    For inspiration and pattern-matching, I regularly study leaders in the space. Referenced: Airbnb: https://airbnb.com/

    Bill Gurley: https://www.linkedin.com/in/billgurley/

    Blue Apron: https://www.blueapron.com/

    Booking.com: https://www.booking.com/

    DoorDash: https://www.doordash.com/

    eBay: https://ebay.com/

    Eventbrite: https://www.eventbrite.com/

    Expedia: https://www.expedia.com/

    Faire: https://www.faire.com/

    Fermat Commerce: https://www.fermatcommerce.com/

    Grubhub: https://www.grubhub.com/

    Lyft: https://www.lyft.com/

    Pinterest: https://www.pinterest.com/

    Postmates: https://postmates.com/

    Shopify: https://www.shopify.com/

    Simon Rothman: https://www.linkedin.com/in/simonrothman/

    Square: https://squareup.com/

    Tony Xu: https://www.linkedin.com/in/xutony/

    Turo: https://turo.com/

    Uber: https://www.uber.com/

    Zillow: https://www.zillow.com/

    If you’re building a marketplace right now, pressure-test your model against these principles: define your atomic unit, get to liquidity fast, treat supply as the product, design growth loops that compound, and sequence expansion only after you’ve earned dense, repeatable usage. Do this well and you won’t just grow—you’ll build a marketplace with defensible moats and real staying power.


    Book a consult png image
  • Developing Technical Taste: My Playbook for Next‑Gen Engineers, AI Strategy, and 2024 Scaling

    Developing Technical Taste: My Playbook for Next‑Gen Engineers, AI Strategy, and 2024 Scaling

    When I think about the next generation of engineers and product creators, one capability consistently separates the great from the good: technical taste. It’s the intuition to choose the simplest viable path, the humility to iterate, and the courage to ask “what if” before everyone else. In this piece, I share how I frame technical taste, what it means for AI strategy, and how to scale software teams in 2024 without losing speed or product-market fit.

    Sam Schillace is the CVP and Deputy CTO at Microsoft. Before Microsoft, Sam held prominent engineering roles at Google and Box. He has also founded six startups, including Writely, which was acquired by Google and became Google Docs.

    In this deep dive, I explore themes like “Sam’s advice for future engineers,” “What’s next for AI,” “How to develop technical taste,” “The importance of asking ‘what if’ questions,” “Lessons on market timing,” and “Scaling a software company in 2024.” My lens is product management leadership at scale, with a bias toward clear decision-making, rapid learning, and compounding leverage.

    On market timing, my experience echoes the principle that momentum compounds only after you align product insight with the market’s inflection point. “The Innovator’s Dilemma” reminds us that the very systems designed to protect current value can block new value. The smartest move I’ve seen is to treat disruptive bets like venture portfolios inside the company—small, time-boxed, outcome-driven, and shielded from legacy KPIs. That’s how you preserve execution excellence while creating space for the next S-curve.

    Technical taste is developable. I look for three signals: first, engineers who reduce a problem to its essence and deliver a working slice quickly; second, product creators who anchor on outcomes vs output OKRs; third, teams who habitually ask “what if” questions to surface non-obvious constraints and new leverage. When this mindset meets strong product discovery, you get faster cycles, fewer dead ends, and clearer product-market fit lessons.

    “Building Google Docs” is a case study in choosing the web as the platform before it was fashionable—an act of taste under uncertainty. It’s also a reminder that what looks inevitable in hindsight was controversial in real time. Discussions about “The decline of Google apps” are less about any one company and more about the drift that occurs when focus fragments; taste is how you steer back to the core job-to-be-done.

    On “The Innovator’s Dilemma facing Microsoft” and “The differences between Google and Microsoft,” I’ve seen how culture shapes product motion. One optimizes for experimentation at massive consumer scale; the other, for enterprise trust and durability. The playbook to reconcile both: define two operating modes—explore and exploit—and make the seams explicit. Use forward deployed engineers to learn with customers, while platform teams industrialize the wins.

    “How to build a winning product” in 2024 is straightforward to say and hard to do: shorten the distance between insight and impact. I prioritize gen AI for product prototyping to test feasibility early, pair it with real-user loops from day one, and instrument everything to learn faster than competitors. Ruthlessly prune scope to ship a lovable slice, then iterate. That’s how you scale software in 2024 without bloating teams or code.

    On “Becoming an optimist,” I’ve learned optimism is a practice: assume better solutions exist, then run experiments to find them. “What makes a great engineer” and “One thing the best engineers do” often collapse into the same behavior—holding high standards while moving fast. The best engineers I know ask precise “what if” questions, surface edge cases early, and translate ambiguity into a plan the team can execute.

    “Sam’s prediction about AI,” “Capturing the value of AI,” and “How you should think about AI” all converge on a few product truths. Co-pilots and agents will become table stakes; differentiation will come from domain-specific data, workflow depth, and trust. Value accrues where AI is closest to the decision or outcome—embedded in the flow of work, not bolted on. For customer support AI strategy, the win isn’t a clever bot; it’s reducing time-to-resolution with explainability, guardrails, and continuous learning from real tickets.

    “Microsoft’s new leverage,” “Scaling software in 2024,” and “The future of AI across several sectors” point to a broader shift: platforms that combine distribution, identity, and compliance will set the rules of engagement. But even in that world, local excellence matters—tight loops with customers, forward deployed engineers, and outcome-centric roadmaps will out-execute feature factories. The teams that treat gen AI as a capability—not a feature—will capture durable advantage.

    Referenced:

    Amazon: https://amazon.com

    Box: https://www.box.com/

    Elon Musk: https://twitter.com/elonmusk

    Google Docs: https://docs.google.com

    Itzhak Perlman: https://itzhakperlman.com/

    Microsoft: https://www.microsoft.com

    Netflix: https://www.netflix.com

    Tesla: https://www.tesla.com/

    The Innovator’s Dilemma: https://www.amazon.com.au/Innovators-Dilemma-Clayton-M-Christensen/dp/0062060244

    TurboTax: https://turbotax.intuit.com/

    Uber: https://www.uber.com/

    Walmart: https://www.walmart.com/

    Workday: https://www.workday.com/

    Writely: https://techcrunch.com/2005/08/31/writely-process-words-with-your-browser/

    Where to find Sam Schillace:

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

    Newsletter: https://sundaylettersfromsam.substack.com/

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

    Timestamps:

    (00:00) Introduction

    (02:54) Lessons on market timing

    (07:30) Developing technical taste

    (09:51) Asking “what if” questions

    (14:03) Building Google Docs

    (19:32) The decline of Google apps

    (20:57) The Innovator’s Dilemma facing Microsoft

    (22:53) The differences between Google and Microsoft

    (24:42) How to build a winning product

    (27:46) Becoming an optimist

    (29:12) Why engineering teams aren’t smaller

    (32:00) Sam’s prediction about AI

    (34:11) Capturing the value of AI

    (37:43) How you should think about AI

    (45:33) Advice for future engineers

    (48:18) What makes a great engineer

    (49:45) One thing the best engineers do

    (51:37) Microsoft’s new leverage

    (56:01) Scaling software in 2024

    (59:50) The future of AI across several sectors

    (64:28) What Sam and a violinist have in common


    Book a consult png image
  • Inside Stripe, OpenAI, Retool: Hard‑Won Marketing Lessons on Brand, GTM, and Scale

    Inside Stripe, OpenAI, Retool: Hard‑Won Marketing Lessons on Brand, GTM, and Scale

    I spend a lot of time studying how the best product-led companies translate world-class product thinking into durable marketing systems. When I zoom out on OpenAI, Stripe, and Retool, I see a repeatable pattern: deep customer empathy, a narrative grounded in real product value, and an operational cadence that scales taste without diluting quality. In this piece, I share what’s worked for me as a product leader, and how I apply these lessons to build brand, accelerate go-to-market, and make smart resource allocation decisions.

    Here’s the roadmap for this deep dive: Marketing lessons from OpenAI, Stripe, and Retool. The 3 pillars of Stripe’s approach to brand. How to manage resource allocation as a marketer. Adapting marketing strategy to different business models. Advice for early marketing hires. I’ll keep the phrases and names intact where they are factual, and I’ll add my own practical commentary on how I use these ideas day to day.

    The 3 pillars of Stripe’s approach to brand is a useful way to think about brand systems in any technical company. Even without enumerating those pillars here, the underlying method is what matters: codify the few non-negotiables (the taste bar, the voice, the promise), make them visible to everyone, and hold the line in reviews. In my teams, we operationalize this by creating a short brand playbook that fits on a single page, pairing it with exemplar assets, and requiring every new program to declare how it advances at least one pillar. Clarity beats cleverness when you’re scaling.

    How to manage resource allocation as a marketer is a perennial challenge as products and teams grow. I’ve had success with a 70/20/10 model: 70% on proven programs with measurable ROI, 20% on emerging bets with leading indicators (pipeline quality, engagement from priority personas), and 10% on frontier ideas that can reset the curve. We anchor work to outcomes vs output OKRs—pipeline, activation, time-to-value, product-qualified leads—so we’re funding results, not activity. As context changes (new ICP, pricing shifts, platform launches), we rebalance quarterly rather than set-and-forget.

    As Stripe scaled taste, it demonstrated that high standards don’t have to mean bottlenecks. Rigorous reviews can empower teams when the criteria are explicit and teachable. Were Stripe reviews micromanaging? The lesson I apply: reviews should audit for narrative clarity, customer truth, and craft—not rewrite. We front-load narrative memos and storyboards, use pre-reads to keep live reviews crisp, and separate “taste feedback” from “blocking defects” to keep velocity high without compromising quality.

    Marketing under founders with strong marketing skills can be a superpower if you channel it. My playbook: align on the narrative spine early, invite dissent in draft form (not in launch week), and turn founder intuition into reusable artifacts—positioning docs, messaging matrices, and reference stories. The goal is to scale judgment across the org, not centralize it.

    Marketing at Retool vs Stripe and Marketing horizontal vs vertical products both highlight an important reality: default motions differ by product architecture and buyer psychology. For horizontal tools, the challenge is framing—teach the problem space, lead with canonical use cases, and invest in education (docs, templates, workshops) that unlock fast time-to-first-value. For vertical solutions, prioritize outcomes, credibility, and proof: ROI narratives, customer stories with industry-specific metrics, and targeted channel plays that map to where those buyers actually spend attention.

    Marketing to mid-market vs SMB vs enterprise requires instrumentation and patience tuned to each segment. For SMB, focus on self-serve journeys, clear pricing, and conversion velocity; for mid-market, emphasize solution fit, workflow integration, and multi-threaded nurture; for enterprise, lead with trust, compliance, partner ecosystem, and value engineering. I set segment-specific “north-star” outcomes (e.g., self-serve activation rate, opportunity-to-close rate, average deal cycle) and build program portfolios around those.

    Marketing programs that had an outsized impact often share a few traits: they’re product-adjacent, community-forward, and inherently educational. Two great examples from Stripe that I keep in my mental model are Stripe’s “Capture the Flag” campaign and Stripe Press—both programs build brand by creating genuine value for developers and builders instead of pushing features. They demonstrate how product-led marketing can compound over years.

    Lessons from OpenAI remind me that speed, clarity, and responsibility can coexist. The best teams tell a simple, credible story about how the tech helps people do meaningful work—then prove it in product. Inside OpenAI’s recent website relaunch, the big takeaways for me were reduction and focus: fewer pages, tighter flows, and a narrative that meets users where they are (from curious newcomers to advanced builders). That same discipline improves any product site: prioritize the jobs-to-be-done, reduce cognitive load, and surface the shortest path to value.

    How OpenAI’s marketers use OpenAI tooling is a model I bring into my teams daily. We use generative AI for content prototyping (outlines, angle exploration, voice calibration), for product discovery (summarizing interviews, clustering themes), and for campaign iteration (subject line tests, message variants, landing page microcopy). The bar is still human editorial judgment; AI accelerates the draft, we own the craft. Outside examples—like the Coca-Cola AI-generated wish card campaign—show how brand and AI can partner when creativity, data, and distribution align.

    Advice for early marketing hires is straightforward and hard-won. Be a product creator at heart: learn the product, sit with support, talk to customers weekly. Start with the shortest loops that drive real outcomes—docs that unlock activation, case studies that remove friction, templates that accelerate time-to-value. Build measurement into everything, but don’t let dashboards paralyze momentum. Above all, write clearly; strong writing is the highest-leverage GTM skill and a forcing function for clear thinking.

    When to start hiring marketers depends on signal. I look for repeatable demand patterns (consistent activation sources, emerging PQL signals), evidence of product-market fit lessons (clear ICP, pain–solution fit), and content debt (PMs and engineers over-producing GTM artifacts). For the first hire, I screen for full-stack utility, narrative instincts, and cross-functional leadership. How to screen early marketing hires: working sessions on positioning, a live critique of a landing page, and a writing exercise that reveals judgment under constraints.

    If you’re orchestrating a website relaunch, a segment shift, or a new product line, the throughline from these companies is simple: set a high taste bar, operationalize it with lightweight systems, and make the customer’s job-to-be-done the hero. Pair that with disciplined resource allocation, and you’ll earn brand, pipeline, and loyalty the hard way—by delivering real value.

    Referenced:

    Coca-Cola AI-generated wish card campaign: https://theprint.in/ani-press-releases/coca-cola-ignites-diwali-celebrations-with-unique-personalized-ai-generated-wish-cards/1840093/

    Cristina Cordova: https://www.linkedin.com/in/cristinajcordova/

    Gong: https://www.gong.io/

    Greg Brockman: https://www.linkedin.com/in/thegdb/

    Kenzo Fong: https://www.linkedin.com/in/kenzofong/

    Retool: https://retool.com/

    Stripe’s “Capture the Flag” campaign: https://techcrunch.com/2012/08/22/stripes-capture-the-flag-2-0-a-hands-on-contest-for-app-developers-to-test-their-security-know-how/

    Stripe Press: https://press.stripe.com/

    Stripe Sigma: https://stripe.com/us/sigma

    Tanya Khakbaz: https://www.linkedin.com/in/tanya-khakbaz-a725732/


    Book a consult png image
  • Inside Intercom’s Bold Reboot: Lessons in AI Strategy, Ruthless Focus, and Culture

    Inside Intercom’s Bold Reboot: Lessons in AI Strategy, Ruthless Focus, and Culture

    I’ve been reflecting on a remarkable comeback story that offers sharp lessons for product leaders navigating AI disruption. Eoghan McCabe is the CEO and cofounder at Intercom, an AI customer service platform. Intercom has raised over $240M, and was last valued at $1.3B in 2018. After spending 9 years building the company, Eoghan left Intercom in 2020, but he’s since returned, reshaping Intercom and pioneering its pivot to an AI-first service. That arc—departure, return, and reinvention—captures a founder’s willingness to defy orthodoxy and act from first principles.

    What stood out to me most was the unapologetic embrace of intuition. In high-variance environments like AI and customer support, best practices lag reality. Founder intuition vs. standard practice isn’t a cliché here; it’s a capability. I’ve seen teams overfit to playbooks and underweight the signals that matter—customer truth, product discovery signals, and outcomes vs output OKRs that force clarity on what actually moves the needle.

    McCabe’s reflections since leaving Intercom highlight the value of distance. Stepping away often exposes where complexity crept in and where focus was lost. On return, the immediate moves were decisive: refocus the strategy, simplify priorities, and set a higher bar for cadence and quality. Those changes were anchored by first-principles thinking and a willingness to question everything, including sacred cows.

    The productivity step-change is telling. How Eoghan increased Intercom’s productivity by 41% wasn’t magic—it was management. In my experience, that kind of shift comes from ruthless prioritization, removing low-leverage work, and consolidating teams around fewer, outcome-aligned bets. Tactically, think tighter operating rhythms, clearer decision rights, and forward deployed engineers who sit closer to customers to collapse feedback loops—especially critical in gen ai and customer support AI strategy.

    Strategy-wise, the pivot to AI-first wasn’t about feature-chasing; it was about category leadership. AI and category disruption demand conviction. Why you can’t make small improvements in big categories is simple: customers reward step changes in outcomes, not incrementalism. In customer service, that means rethinking workflows end-to-end, not just sprinkling gen ai for product prototyping on top of legacy processes.

    Hiring was another area where the guidance was crisp. Tactical advice on hiring top talent included raising the bar on slope (rate of learning) and ownership, biasing for product creators who thrive in ambiguity, and building an executive team that can scale the operating model, not just the org chart. I’ve found this is where product management leadership shows up most clearly—pushing beyond conventional resumes to find people who can compound execution and insight.

    Culture carried equal weight. Crafting a culture of ruthless honesty and transparency isn’t about being abrasive; it’s about creating a system where truth travels fast. In practice, that looks like instrumented business reviews tied to outcomes, written decision memos that capture tradeoffs, and a shared language for escalation. It’s uncomfortable at first, then liberating—because it accelerates learning.

    Brand came in for a reality check, too. Why software branding is in crisis resonates in an era where many products sound the same, look the same, and promise the same. The antidote is clarity: a point-of-view that’s inseparable from the product experience. How Intercom thinks about brand appears to lean into differentiated behavior—speed, quality, outcomes—rather than slogans. In crowded categories, that’s what earns attention and trust.

    Under the hood, this story is a masterclass in product-market fit lessons. It reaffirms that PMF isn’t a one-time event; it’s a moving target, especially when technology paradigms shift. The companies that navigate the shift are those that re-baseline their bets, measure what matters, and ship faster with higher standards. That’s the compounding loop I try to build: focused strategy, outcome-centric execution, and continuous product discovery.

    If you’re steering an AI transformation, a few prompts I use: Are we solving for an outcome that customers will feel in minutes, not months? Where are we making bold, non-incremental bets? Which processes can we kill to regain tempo? And do our leaders model transparency in a way that accelerates truth-telling across the org?

    For further context and inspiration, here are some of the references mentioned: 37signals: https://37signals.com, Basecamp: https://basecamp.com, Brian Halligan (HubSpot): https://www.linkedin.com/in/brianhalligan, David Heinemeier Hansson (37signals, Basecamp): https://www.linkedin.com/in/david-heinemeier-hansson-374b18221, Intercom: https://www.intercom.com, Jason Fried (37signals, Basecamp): https://www.linkedin.com/in/jason-fried, Salesforce: https://www.salesforce.com, Marc Benioff (Salesforce): https://www.linkedin.com/in/marcbenioff, Zendesk: https://www.zendesk.com.

    If you want to follow Eoghan directly: LinkedIn: https://www.linkedin.com/in/eoghanmccabe/ and Twitter/X: https://x.com/eoghan. I find it valuable to track leaders who are actively rewriting the playbook in real time.


    Book a consult png image
  • How I Find—and Keep—Product-Market Fit: Lessons on Conviction, Distribution, and Mergers

    How I Find—and Keep—Product-Market Fit: Lessons on Conviction, Distribution, and Mergers

    Product-market fit isn’t a finish line; it’s a dynamic state that needs to be earned repeatedly. In my work leading product strategy, I’ve learned that the most resilient companies combine ruthless intellectual honesty with repeatable discovery habits, movement-first distribution, and a bias toward decisive action when markets shift under their feet.

    One case study I return to often: Bob Moore is the co-founder and CEO at Crossbeam, a “LinkedIn for data” platform that helps companies find overlapping opportunities with their partners. Crossbeam has raised US$117M to date and recently acquired Reveal in 2024. Bob previously cofounded RJMetrics (now part of Adobe Commerce Cloud) and Stitch Data (acquired by Talend). He is also the author of Ecosystem-Led Growth. The arc of these companies offers a clear lens into finding founder-market fit, falling in and out of product-market fit, and rebuilding with conviction.

    When I evaluate ideas, I start with founder-market fit and falsification. I look for a lived pain, an unusual insight, and unfair access—then I try to disprove my thesis fast. I’ll line up dozens of target users and adjacent stakeholders, pressure-test the problem, and map evidence to The 4 Levels of PMF. The goal isn’t to “win” early interviews; it’s to surface the constraint that will eventually break the model: data availability, switching costs, procurement friction, or a distribution bottleneck.

    Market shifts can invalidate a great product overnight. The analytics stack reconfiguration around Amazon Redshift is a perfect reminder that timing, platform shifts, and ecosystem dependencies will bend your trajectory. I actively maintain a “watchlist” of platform moves (cloud data platforms, changes in ad networks, privacy policy shifts, AI infrastructure) and connect them to my product’s core assumptions. If a new platform absorbs the value we created, I’d rather be first to cannibalize our own roadmap than last to react.

    On distribution, I engineer sharing, reciprocity, and compounding usage directly into the product. That means designing collaboration surfaces, data assets, or partner workflows that make every new customer a new channel. Crossbeam’s model highlights how overlap mapping and partner ecosystems can turn integration nodes into growth nodes—an ethos that aligns with Ecosystem-Led Growth. Internally, I complement this with proactive outbound motions and the “joint jam” sales tactic: co-creating a live, high-signal artifact with the prospect that proves value with their data, not my slides.

    Falling out of PMF is a feature of reality, not a failure of leadership—provided you move with clarity. The RJMetrics journey illustrates how you can find market fit, then lose it as the stack modernizes. My safeguard is a portfolio of leading indicators: retention by job-to-be-done, time-to-first-value, expansion drivers, sales-assist ratio, and the support “tax” on core workflows. When those turn, I default to intellectual honesty: narrow the ICP, rebuild the wedge, or sunset the thing that’s stealing oxygen from the core.

    Building with conviction versus consensus is a critical cultural muscle. Consensus can smooth relationships, but it often averages out the insight. I anchor decisions in clear principles, write tight pre-mortems, and set owner-driven DRIs. We invite dissent early (red-team reviews, structured decision docs), then “disagree and commit” with a time-boxed checkpoint tied to specific, falsifiable milestones. This lets us move fast without romanticizing our own ideas.

    Creating scalable and durable startups requires architecture, not just ambition. I push for composability across data models, feature flags for safe exploration, and an experimentation fabric that lets us test distribution hypotheses at low cost. We sequence multi-product bets only when we see strong, repeated pull from the market—ideally where network effects are latent. Unlocking network effects in software isn’t magic; it’s the disciplined design of interactions where each participant makes the system more valuable for the next.

    Mergers are another lever for durability when executed with rigor. The Crossbeam/Reveal merger is a timely example of using consolidation to reduce fragmentation, standardize workflows, and accelerate network effects. Getting mergers right starts with strategic fit and cultural compatibility, but the real game is integration: aligning product architectures, pricing, packaging, and go-to-market motion within a 100-day plan that customers can feel in the product, not just read in a press release.

    If you’re pressure-testing your own path to product-market fit, here’s what I’ve found most reliable: obsess over founder-market fit first, use The 4 Levels of PMF to calibrate evidence, design distribution into the product from day one, watch platform shifts like a hawk, and choose conviction over consensus—with mechanisms that keep you honest. Do that consistently, and you won’t just find PMF—you’ll keep it.


    Book a consult png image
  • Mastering Altitude Shifts: Hard‑Won Product Leadership Lessons from Anneka Gupta’s Journey

    Mastering Altitude Shifts: Hard‑Won Product Leadership Lessons from Anneka Gupta’s Journey

    I’m endlessly fascinated by leaders who can operate at every altitude—zooming out on strategy one minute and diving into the weeds the next. That’s why Anneka Gupta’s journey resonated so strongly with me, because it crystallizes how multi-disciplinary leadership accelerates product outcomes and go-to-market execution.

    Anneka Gupta is the Chief Product Officer at Rubrik, a cloud management and data security company with a US$6B market cap. Before Rubrik, Anneka spent 11 years leading various teams at LiveRamp, including product, go-to-market, and operations.

    One proof point that leapt off the page for me: LiveRamp went from $30M to $200M ARR in 3 years. That kind of growth rarely comes from product alone—it’s the compounding effect of crisp customer segmentation, tight GTM alignment, and a culture that prioritizes outcomes over output. In my own teams, anchoring OKRs to business outcomes rather than feature counts has been the most reliable way to unlock this momentum.

    What I admire most is Anneka’s jack-of-all-trades career. Rotating through product, operations, and GTM builds a powerful intuition for how systems interact. I’ve seen the same benefit at scale: PMs who have shipped, sold, and supported the product make sharper tradeoffs because they integrate customer value, revenue mechanics, and operational feasibility in real time.

    There’s a counterintuitive hiring lesson here too—why specialist hires can backfire. When the product or market is still evolving, over-optimized specialists often struggle without mature processes and stable interfaces. Early on, I bias toward adaptable builders who can define the playbook, not just run it. Specialists shine once the motion is proven and repeatable.

    Altitude control matters. Knowing when leaders should get in the weeds is a differentiator. I’ve found three triggers: existential risk (security, reliability, or reputation), pivotal zero-to-one bets, and repeated cross-functional misalignment. Step in, diagnose at the system level, model the behavior you expect, and then step back out quickly so the team retains ownership.

    There’s also one area every PM can improve in: customer-facing fluency. I agree with the principle that PMs should undergo the same training as sales reps. Shadow discovery calls, rehearse objection handling, and learn to speak to value drivers by persona. When PMs can authentically sell the problem and the solution narrative, product discovery gets faster and win rates improve.

    Crafting products for different personas is another thread I pull on constantly. Buyers care about ROI, risk, and roadmap; users care about speed, clarity, and control. Great product discovery bridges the two by validating problem severity and adoption friction in parallel. That’s how you avoid building “the best product” that still loses because the buying committee can’t align on value.

    I’m also struck by how deftly LiveRamp navigated enterprise shifts like transitioning Acxiom’s customers to LiveRamp and the broader dynamics of why Acxiom chose to buy not build. These moves demand rigorous change management—backwards compatibility, data governance guarantees, and clear migration value propositions. When the incentives align for customers and field teams, integrations become accelerants rather than tax.

    Rubrik’s approach to building product underscores the same fundamentals: focus on critical customer outcomes, connect roadmap to go-to-market reality, and measure what matters. In practice, that means linking product bets to explicit revenue or retention hypotheses and setting guardrails so teams can run fast without creating long-term complexity debt.

    I also appreciate the humility in reflecting on mistakes and the outsized impact of mentors and peers. The best leaders I’ve worked with narrate their decision-making—what they knew, what they assumed, and what they’d do differently—which compounds organizational learning. It’s the difference between isolated wins and a repeatable operating system.

    If I distill my own playbook from these themes, it looks like this: hire for adaptability early, specialize later; anchor to outcomes vs output to avoid local maxima; keep PMs close to the sales and support edges of the system; and practice altitude shifting as a daily discipline. The result is a product organization that learns faster than the market changes—arguably the only durable advantage.


    Book a consult png image
  • From Prototype to the Pentagon: My Playbook for Winning DoD Customers and Mission Fit

    From Prototype to the Pentagon: My Playbook for Winning DoD Customers and Mission Fit

    I’ve spent years building dual-use products and partnering with teams navigating the Department of Defense. In this piece, I share how I move from prototype to program of record by aligning product strategy to real mission outcomes, building trust with end users, and translating commercial product rigor into the national security context. Commercial versus military market strategies require fundamentally different assumptions. In the private sector, we obsess over product-market fit and velocity; in defense, we obsess over “mission solution fit” and survivability in procurement. The buyer is a complex web—operators, program managers, contracting officers, and Program Executive Offices (PEOs)—and each needs a clear value story tied to mission impact, not just features or ARR. When I validate ideas for defense products, I start with deep discovery at the edge: talking with operators, understanding tactics, techniques, and procedures (TTPs), and quantifying what “better” looks like in their environment. The “Mission Model Canvas” helps me capture stakeholders, beneficiaries, and constraints that don’t exist in a typical SaaS motion. “Hacking for Defense” has been invaluable for structuring this discovery and ensuring we test assumptions against mission reality, not just market appetite. A practical guide to military sales and procurement starts by mapping decision pathways. I identify the PEOs, the Program Managers, and the acquisition timelines that govern transition. I treat each step like an enterprise sale with additional layers: requirements, testing, accreditation, and budgeting. I align demonstrations to mission milestones, ensure my roadmap accounts for integration and accreditation lead times, and keep decision-makers looped with concise, evidence-based updates. Rethinking go-to-market strategy for defense means planning for longer cycles and multi-level consensus. Instead of a simple funnel, I build a coalition: an operator champion for pilots, a program sponsor for funding continuity, and a contracting route that matches how the customer buys. The goal is to de-risk adoption across technical, operational, and procurement dimensions in parallel. Building a network in national security is a full-contact sport. I invest time in the field, put forward deployed engineers next to users, and show up at the training ranges and labs where problems are real. Trust accumulates when teams see you adapt quickly, respect constraints, and demonstrate an understanding of mission risk. That trust turns into access and, ultimately, into pull from the organization. The dual-use debate isn’t binary—it’s a portfolio decision. I’ve seen teams succeed by leading with a defense wedge when the problem is uniquely military, and others start commercially to prove traction then tailor for defense. The key is to avoid whiplash: design your architecture and compliance posture so you can serve both without fragmenting your roadmap. Behind the rise of a new generation of “defense founders” is a shift in ambition and capability. Teams are mission-driven, technically sophisticated, and comfortable operating in complex stakeholder environments. They’re building for hard problems and measuring success in operational outcomes, not just revenue milestones. “Mission solution fit” is my north star. I define it as measurable mission improvement with acceptable changes to TTPs, training, and integration. I seek evidence that units can and will use the solution under realistic constraints, that it interoperates with existing systems, and that program leadership can fund it at scale. When those signals align, transition becomes possible. Breaking new ground in military tech often means navigating institutional friction. The “The Frozen Middle” is real—layers that resist change even when leadership and operators are aligned. I plan for this by prototyping where adoption barriers are lowest, securing a senior sponsor, and demonstrating cost, schedule, and performance wins that the middle cannot ignore. The hidden challenges most startups miss tend to be non-technical. Security and accreditation aren’t documentation exercises; they’re product constraints that should shape architecture early. Interoperability isn’t a feature; it’s table stakes. And your ability to explain “why now” in the language of budget cycles can matter as much as a benchmark. Essential resources for any defense founder include “Hacking for Defense,” “The Hacking for Defense Manual,” the directory in “How to find your customer in the Dept of Defense,” the “Mission Model Canvas,” and lessons from “The lean launchpad at Stanford” and “The Secret History of Silicon Valley.” I also draw on the work of Alexander Osterwalder and Eric Ries to bridge discovery, iteration, and disciplined scale. What’s missing from Silicon Valley in this domain is patience paired with rigor. The best teams combine world-class product discovery with respect for acquisition realities. They instrument outcomes in the field, align roadmaps to funding gates, and bring forward deployed engineers to close the gap between prototype and operational capability. From prototype to the Pentagon is a repeatable path when we hold ourselves to mission outcomes, build coalitions across the acquisition chain, and design for constraints from day one. If you’re committed to national security, build with empathy for the operator, clarity for the buyer, and a roadmap that survives contact with procurement.
    Book a consult png image
  • Inside Figma’s Product Playbook: Taste, Simplicity, and Storytelling for Extraordinary PMs

    Inside Figma’s Product Playbook: Taste, Simplicity, and Storytelling for Extraordinary PMs

    I’ve long believed the best products come from a careful blend of taste, simplicity, and storytelling. Studying how Figma operationalizes these principles has sharpened my own playbook for building, launching, and scaling products. In this piece, I distill the patterns I use and teach: how to approach new products, how to prioritize without losing the plot, and how to use narrative as a force multiplier for teams and customers.

    At a high level, here’s the arc I focus on: approaching new products with a strong point of view, shaping product culture that balances craft with outcomes, understanding when to change course, tying business goals to product expansion, going multi‑product deliberately, recognizing the differences between “0 to 1” and “1 to 10” talent, and elevating storytelling from launch polish to a core build-time practice. Along the way, I’ll highlight why taste and simplicity aren’t luxuries—they’re strategy.

    When I explore how to build from zero, I start with a crisp customer promise and a single, testable magic moment. The early days demand ruthless focus: one job-to-be-done, one path to value, one reason to share. As teams expand scope, the risk is layering utility without coherence. The countermeasure is systematic simplicity—every addition must make the core value faster, clearer, or more extensible. If it doesn’t, it’s noise.

    Product culture is the scaffolding that makes this discipline stick. Speed and operational excellence drive the right kind of urgency; experimentation at scale validates hypotheses without cargo-culting metrics; and rigor in reviews ensures we’re prioritizing outcomes over output. The best cultures pair evidence with taste—data guides, but the bar for quality, narrative, and craft is set by humans with conviction.

    Knowing when to change things is both an art and a system. I look for signal in stubborn user friction, plateauing activation, a long tail of workarounds, and moments when a new platform or workflow unlocks 10x value. The framework I use: if a change can simplify the path to the promise, or unlock a whole new class of users without diluting the core, it deserves energy. Change the defaults before changing the philosophy.

    Business goals should sharpen, not overshadow, product expansion. Before adding surfaces or SKUs, I insist on clarity around the ICP, the premium moment worthy of pricing, the extensibility story for developers, and the narrative that unifies everything. Multi‑product strategy works best when each product is a chapter in the same book, not a pile of features. That’s why I appreciate how the ecosystem comes together across Figjam: https://www.figma.com/figjam/, Figma: https://www.figma.com/, Figma Dev Mode: https://www.figma.com/dev-mode/, and Figma Slides: https://www.figma.com/slides/—distinct entry points, shared language, and compounding value.

    For “0 to 1” product work, I hire for curiosity, taste, and velocity. I want builders who can reduce ambiguity quickly, prototype with whatever tools are at hand, and tell a clear story about why their version of the problem matters. My favorite interview signal is a non-obvious customer insight that changed their roadmap. Entrepreneurial talent shows up in the questions they ask about distribution, pricing, and adoption—not just the feature.

    I’m often asked why there aren’t more designer founders. My take: the gap is less about capability and more about exposure to distribution, pricing, and finance. Practical fixes help—give design leaders P&L ownership, put them on customer calls that include procurement, and pair them with GTM partners early. When designers are fluent in business mechanics, their advantage in taste and narrative becomes a superpower.

    New product launches work best when the story is built in from day one. I like to “slow-cook” with tight, cross-functional squads, private betas with power users, and an explicit before/after narrative that connects the dots across product, docs, community, and developer ecosystem. As teams scale, I match talent to stage: “0 to 1” thrives in uncertainty; “1 to 10” excels at repeatability, quality, and operational excellence. Both are essential; mixing them at the wrong time creates drag.

    Storytelling is not veneer—it’s how we align teams, earn stakeholder trust, and help users see themselves in the product. I anchor roadmaps to a one-sentence promise, show the painful “before,” demonstrate the “after,” and name the magic mechanic that makes it possible. Then I translate that story into prioritization. I stack-rank by value, confidence, and cost, and I’m explicit about what we won’t do. Strategy is as much the boundary as the plan.

    If you’re refining your product storytelling, a quick checklist helps: articulate the promise in plain language, show rather than tell with a demo that lands the magic moment in 30 seconds, connect to measurable outcomes, and make the first-run experience feel like the narrative come to life. Don’t bury the lead. If a user can’t explain your product to a teammate after one minute, the story isn’t ready.

    The difference between “good” and “extraordinary” product managers is simple to say and hard to do. Good PMs coordinate and ship on time. Extraordinary PMs set a higher bar for taste, simplify relentlessly, and move teams from consensus to conviction. They connect craft to outcomes, use narrative to create momentum, and make decisions that age well because the logic is legible.

    Simplicity is a growth strategy. It shortens time-to-value, reduces error surface, and raises retention by making products feel learnable and trustworthy. Tactics I lean on: one hard thing at a time, remove to improve, defaults are design, and compress choices until the right path is the easy path. Simplicity isn’t less—it’s the right less.

    Taste, in product and design, is not innate; it’s a practiced sensitivity to what feels inevitable. I cultivate it by collecting exemplars, writing and revisiting product principles, insisting on weekly critiques, and sweating the narrative as much as the pixel. The best teams hold two truths: quality you can feel and outcomes you can measure.

    If you want to explore the ecosystem I referenced, here are direct links: Figjam: https://www.figma.com/figjam/, Figma: https://www.figma.com/, Figma Dev Mode: https://www.figma.com/dev-mode/, Figma Slides: https://www.figma.com/slides/.

    Whether you’re building your first product or scaling a platform, the throughline remains: lead with taste, ship with simplicity, and align everyone with a story worth rallying around. That combination turns good teams into extraordinary ones—and products into movements.


    Book a consult png image
  • Inside dbt Labs’ $4.2B ascent: category creation, open source, and monetization playbook

    Inside dbt Labs’ $4.2B ascent: category creation, open source, and monetization playbook

    As a VP of Product Management, I’m fascinated by the rare mix of strategy, timing, and execution that turns a great idea into a durable category. The arc of dbt Labs is one of those definitive product stories: a cloud-based data management platform that has raised over $400M to date, and was last valued at $4.2B in 2022. What stands out to me first is the scale and velocity. Dbt Labs has grown from just three companies using its free tool in 2016 to an ecosystem of 30,000+ enterprise users. That journey captures the essence of category creation done right: lead with an opinionated product, cultivate a community around clear practices, and sequence monetization only after adoption becomes self-sustaining. When I look at Dbt’s explosive growth, I see a masterclass in product management leadership. The team focused on a precise, under-served problem in modern data workflows and built a tooling philosophy that aligned with how analysts and engineers actually work. That alignment turned a utility into a movement. The strategic pivot from consulting to a software company is a decision I’ve navigated myself, and it’s often misunderstood. Consulting’s hidden scalability and consultancy superpowers aren’t about headcount—they’re about tight customer feedback loops, paid discovery, and rapid learning cycles that directly shape product decisions. In this case, consulting engagements shaped the roadmap and helped validate the eventual product thesis with a clarity that pure software bets rarely achieve. Category creation is rarely a straight line. The team deployed unexpected strategies for building a tech category from scratch—most notably The anti-demo strategy. Rather than an overproduced wow moment, they optimized for real-life proof and repeatable value in the hands of practitioners. That put credibility ahead of theatrics. Community was the flywheel. Community hacking: the Slack group that changed everything wasn’t just a channel—it was a living spec for the product and the practices around it. Pair that with The open source philosophy and you have a compounding effect: trust, transparency, and contribution. When growth went exponential, it was because the community could see, shape, and advocate for the standard. Finding dbt Labs’ first customers mattered less than building a motion they could evangelize. How consulting engagements shaped the roadmap is a reminder that early revenue can be a learning instrument. Done well, it tightens product discovery and derisks foundational bets. Funding is another decision point I pay close attention to. The critical moment: Why and when dbt Labs sought venture funding came only after the system’s constraints were obvious. Fundraising only when “things started to break” signals operational discipline—capital as a force multiplier, not a crutch. On the commercial side, the sequencing was thoughtful. How to drive commercial adoption after open-sourcing is all about value layering: permissions, governance, collaboration, and scale—capabilities that enterprises will happily pay for. That dovetails into Key monetization strategies and the eventual Pivoting from consulting to software—a move that codifies services learnings into scalable product value. There are also powerful founder operating principles here. Becoming an “accidental founder” resonates with many of us who start by solving a concrete problem and wake up running a company. Why “begrudging” CEOs can be successful underscores that obsession with the customer often beats a desire to be a CEO. Advice for finding PMF: “It’s not a playbook” reflects the truth I’ve seen across teams: seek signals, not templates. Lowering your standards is a hack is a counterintuitive push toward shipping, learning, and iterating. Navigating emotional overwhelm and Every CEO needs a coach are signals of mature leadership—build inner capacity as deliberately as product capacity. Two things every founder CEO should do: set the cadence and protect the standards. If you want a quick guide to the narrative arc and key lessons, here’s how I map it to the journey: (00:00) Introduction; (02:56) The critical oversight in data analysis; (05:41) Becoming an “accidental founder”; (07:04) Inside the unique decision to start a consultancy; (08:17) The game-changing principle behind dbt Labs’ rapid growth; (11:20) Finding dbt Labs’ first customers; (15:52) Consulting’s hidden scalability; (17:25) How dbt Labs created a new category; (21:03) The anti-demo strategy; (23:59) Community hacking: the Slack group that changed everything; (26:00) The open source philosophy; (27:39) When growth went exponential; (28:49) How consulting engagements shaped the roadmap; (30:02) Fundraising only when “things started to break”; (32:40) Consultancy superpowers: the hidden advantages; (34:04) Pivoting from consulting to software; (40:00) Key monetization strategies; (48:56) Why “begrudging” CEOs can be successful; (51:02) Advice for finding PMF: “It’s not a playbook”; (51:59) Lowering your standards is a hack; (53:30) Navigating emotional overwhelm; (54:25) Every CEO needs a coach. Referenced: Amazon Redshift: https://aws.amazon.com/redshift/ Bob Moore: https://www.linkedin.com/in/robertjmoore/ Crossbeam: https://www.crossbeam.com/ dbt Labs: https://www.getdbt.com/ Drew Banin: https://www.linkedin.com/in/drewbanin/ Jerry Colonna: https://www.reboot.io/team/jerry-colonna/ RJMetrics: https://en.wikipedia.org/wiki/RJMetrics SeatGeek: https://seatgeek.com/ Steve Ritter: https://www.linkedin.com/in/steve-ritter-69495210/ Squarespace: https://www.squarespace.com/ Where to find Tristan: LinkedIn: https://www.linkedin.com/in/tristanhandy/ Twitter/X: https://x.com/jthandy
    Book a consult png image
  • Inside Clay’s $1.25B Playbook: Unconventional GTM, Pricing Strategy, and Enterprise Wins

    Clay’s path to a $1.25B valuation isn’t conventional—and that’s exactly why it’s instructive. Through the lens of product management and go-to-market strategy, I break down how unconventional tactics, rigorous pricing decisions, and a long game on brand combined to create real upmarket momentum. If you lead product, growth, or revenue, there’s a repeatable playbook here for blending product-led growth with enterprise sales without losing speed or signal. Varun Anand is the co-founder and Head of Operations at Clay, a GTM development environment that combines data and AI to help over 5000 companies power everything from CRM enrichment to highly targeted outreach campaigns. Clay recently announced their Series B expansion, raising $40M at a $1.25B valuation. Before Clay, Varun was the Director of Operations at Newfront and the Head of Expansion at Candid. Varun also spent four years working on Hillary Clinton’s presidential campaign. Turning traditional GTM on its head, Clay’s earliest traction didn’t come from glossy campaigns—it came from scrappy sales tactics: “WhatsApp groups, Reddit threads, and reverse demos.” I’ve seen this play repeatedly outperform paid channels early because it compounds social proof in the exact communities where power users congregate. When your ICP hangs out in niche threads, customer acquisition is a function of credibility, not CPM. On pricing, “credit-based pricing” was a pivotal decision. Equally important, the team “rejected the usage-based model.” For PLG plus enterprise, this matters: credits make value legible to buyers, reduce billing anxiety for ops and finance teams, and align with predictable, budgeted workflows. In my experience, credit models also create clearer upgrade paths when your product spans multiple use cases. Clay built a robust self-serve engine and then layered “enterprise customers on top of PLG.” This sequencing avoids the trap of hiring an enterprise team before the product is self-serve-proven. It also creates cleaner handoffs—self-serve for discovery and activation, sales for proof, procurement, and expansion. Content and brand weren’t afterthoughts. Clay made a “big bet on content” and “invested in brand from day-one.” That’s a contrarian move many teams delay, but content accelerates learning loops, reduces sales cycle time, and scales enablement far beyond headcount. In enterprise sales, a trusted brand is an asset class. Winning big accounts required creative proofs of value. “Reverse demos” flipped the script—show the customer’s data, in their workflow, with their outcomes. It’s one of the fastest routes to de-risking adoption and building trust with enterprise buyers. From there, they applied a pragmatic “land and expand model” that aligns with how large organizations actually buy. Clay highlights “3 changes that unlocked Clay’s upmarket motion.” While every company’s inflection points are unique, the meta-lesson is consistent: clarify the ICP, operationalize proof (reverse demos, ROI), and meet enterprise expectations on reliability, governance, and support—without sacrificing the PLG engine. Team construction was equally intentional. Hiring people who are “technical enough” and using a “hands-on interviewing process” raised the talent bar and reduced execution drag. I’ve found this mirrors the strength of forward-deployed mindsets: product, ops, and GTM talent who can prototype, troubleshoot, and translate customer complexity into scalable systems. Finally, Clay’s contrarian take on compensation signals a willingness to design incentives for the business they want to build, not the one the market expects. Compensation philosophies quietly shape culture, velocity, and who opts in. Referenced: Anthropic: https://www.anthropic.com/ Clay: https://www.clay.com/ Clay’s Series B expansion: https://www.clay.com/blog/series-b-expansion Eric Nowoslawski: https://www.linkedin.com/in/outboundphd/ Figma: https://www.figma.com/ Jesse Ouellette: https://www.linkedin.com/in/jesseoue/ Kareem Amin: https://www.linkedin.com/in/kareemamin/ Nick Merrill: https://www.linkedin.com/in/nick-merrill-64562310/ Notion: https://www.notion.com/ Oyster: https://www.oysterhr.com/ Pave: https://www.pave.com/ Rippling: https://www.rippling.com/ Snowflake: https://www.snowflake.com/ Verkada: https://www.verkada.com/ Webflow: https://webflow.com/ Yash Tekriwal: https://www.linkedin.com/in/yashtekriwal/ My takeaway: this is a modern GTM blueprint—prove value in the wild, price for clarity, build self-serve first, then industrialize trust for enterprise. Do that, and you can scale without losing the product signals that got you traction in the first place.
    Book a consult png image
  • Just Now Possible Preview: How Real Teams Ship AI—Workflows, RAG, Agents, Evaluation

    Just Now Possible Preview: How Real Teams Ship AI—Workflows, RAG, Agents, Evaluation

    I’m excited to share a preview of Just Now Possible, a show where I sit down with the builders who are shipping meaningful AI features in the real world. My goal is simple: pull back the curtain on how AI products actually get made—messy problems, rapid prototyping, and the leadership decisions that move teams from concept to customer value.

    Watch the preview on YouTube: https://www.youtube.com/embed/Kb2HbuPbfR8?feature=oembed. Prefer audio? Listen on Spotify: https://open.spotify.com/episode/5xM0pDnqR0JpKmW6aZ0pj6?ref=producttalk.org or Apple Podcasts: https://podcasts.apple.com/us/podcast/podcast-preview/id1838832993?i=1000725807029&ref=producttalk.org. Want a text version? Read the transcript ($): #full-transcript.

    How AI products come to life—straight from the builders themselves. In each episode, we dive deep into how teams spotted a customer problem, experimented with AI, prototyped solutions, and shipped real features. We dig into everything from workflows and agents to RAG and evaluation strategies, and explore how their products keep evolving. If you’re building with AI, these are the stories for you.

    From my own experience leading product teams, I’ve seen that the real unlocks come from disciplined product discovery, clear outcomes vs output OKRs, and smart use of gen ai for product prototyping. We’ll talk about the tradeoffs between speed and safety, when to bring in forward deployed engineers, and how to validate product-market fit lessons before scaling. Along the way, we’ll unpack practical patterns—like when to use RAG vs fine-tuning, how to evaluate agents in production workflows, and what great product management leadership looks like in AI-first environments.

    The first full episode drops on Thursday, September 18th. Don't miss it!

    Full transcripts are available to paid subscribers.


    Inspired by this post on Product Talk.


    Book a consult png image
  • Building AI Products That Work: My Playbook for LLM Strategy, Evals, and Orchestration

    Building AI Products That Work: My Playbook for LLM Strategy, Evals, and Orchestration

    AI features don’t succeed on clever prompts alone—they demand thoughtful product strategy, rigorous evaluation, and tight cross-functional collaboration. As a VP of Product Management and someone deeply immersed in building with Large language model (LLM) technology, I’m constantly refining how we turn generative capabilities into real customer value. This episode of All Things Product zeroes in on that challenge, and it captures many of the principles I rely on when shipping AI to production.

    The central question resonates with every product leader I know: How do product teams learn to build AI-powered products “beyond just dabbling with ChatGPT”? I appreciate how the conversation moves past novelty and into the disciplines that make AI reliable, safe, and outcome-oriented.

    One metaphor that always lands for me: building AI features is less like writing a single “killer prompt” and more like orchestrating a team of “interns.” You define roles, break down work, set guardrails, and continuously review outputs. That orchestration mindset, coupled with strong observability, evals, and ongoing maintenance practices, is what separates flashy demos from repeatable product value.

    Here’s how I frame the work. First, there’s a difference between an AI-powered product manager and an AI product manager. Many of us are becoming AI-powered—using tools to accelerate discovery, ideation, or execution. But when you own AI features end-to-end, you inherit new responsibilities: modeling risks, defining evaluation strategies for non-deterministic systems, and treating prompts and data pipelines as core product surfaces.

    Prompt engineering for a product is fundamentally different from prompting ChatGPT for personal use. In production, I rely on prompt decomposition and orchestration—explicitly breaking a task into steps, assigning each step to the right capability, and enforcing consistent formats. This reduces variance, improves debuggability, and enables targeted evals that catch regressions before customers do.

    System design and risk mitigation become front and center. I align early with engineering, legal, security, and support on failure modes, privacy expectations (including Personal information or personally identifiable information (PII)), and rollout plans. We log traces for every critical path, treat prompts as versioned assets, and use observability to connect inputs, intermediate states, and outputs. When something drifts, we need to see it fast, explain it, and fix it.

    Evaluating non-deterministic AI features is its own craft. “Thumbs up/thumbs down” isn’t enough. I design layered evals: unit-level checks for correctness and formatting, scenario-level evals for edge cases and risk behaviors, and longitudinal evals to monitor model and data drift over time. Clear acceptance thresholds and shadow deployments help us balance velocity with reliability.

    Deciding when AI is the right solution starts with the customer problem, not the model. I ask: Is the task ambiguous enough to benefit from generation? Can we bound the failure modes? Do we have affordable latency and cost envelopes? And what’s the graceful fallback if the model underperforms? If a deterministic algorithm or simple rules solve it better, we choose that—no heroics.

    The hidden cost of AI is maintenance. Prompts rot as upstream models change. New data skews behavior. Guardrails that worked yesterday might not hold tomorrow. That’s why ongoing evals, robust logging, and a change-management plan (for prompts, schemas, and policies) are non-negotiable. Treat AI features as living systems, not one-off launches.

    If you’re exploring gen ai for product prototyping, start small. Pick a narrow, high-value workflow, instrument everything, and ship with clear success metrics. Use your first release to build your team’s muscles around observability, evals, and cross-functional collaboration. The goal is not a perfect model; it’s a reliable product outcome.

    Want to go deeper? Listen to the full conversation here: Spotify | Apple Podcasts. Prefer video? Watch on YouTube: Building AI Products.

    What you’ll learn in this episode:

    – The difference between an AI-powered product manager and an AI product manager

    – Why prompt engineering for a product is different from prompting ChatGPT for personal use

    – The role of prompt decomposition and orchestration in building robust AI features

    – How to think about system design, risk mitigation, and cross-functional collaboration

    – Why observability and logging traces are critical for LLM products

    – The challenge of evaluating non-deterministic AI features (and why “thumbs up/thumbs down” isn’t enough)

    – How to decide when AI is the right solution for a customer problem

    – The hidden cost of ongoing maintenance for AI features

    Join the conversation: What practices have helped you ship reliable AI features? Drop your thoughts and questions in the comments—I’d love to learn from your experiences.


    Inspired by this post on Product Talk.


    Book a consult png image