Month: October 2025

  • From PM to VP: Proven Tactics to Accelerate Your Product Career and Lead with Confidence

    From PM to VP: Proven Tactics to Accelerate Your Product Career and Lead with Confidence

    I’ve spent my career growing product teams and coaching product managers, and I’m continually drawn to leaders whose playbooks translate across company stages. One standout is Jiaona Zhang (she goes by JZ), whose journey offers an especially clear roadmap for moving from individual contributor to executive product leadership.

    JZ is the VP of Product at Webflow. Before that, she was the Senior Director of Product Management at WeWork, a Product Lead at Airbnb, and a PM at Dropbox and at Pocket Gems. She teaches product at Stanford and mentors rising product leaders. You may also know her for the widely shared article, “Don’t Serve Burnt Pizza (And Other Lessons in Building Minimum Lovable Products).”

    What resonates most with me is her framing of the product career path. Instead of a linear ladder, think of three distinct phases: contributing as a PM, managing PMs, and leading the function. I’ve used a similar model to guide my own teams, and I’ll walk through how I apply this framework in practice.

    Phase 1 — The PM role: When you’re breaking into product, focus on environments that will compound your learning. I look for signs of strong product discovery, clear ownership of product roadmapping and sprint planning, and a culture that values outcomes vs output. In interviews, I ask how success is measured (OKRs, customer outcomes, adoption) and how PMs partner with engineering and design. Early mistakes are common: trying to own decisions without owning the problem, shipping features without a minimum lovable product mindset, and confusing velocity with value. To avoid these traps, anchor your work in customer problems, link every roadmap item to measurable outcomes, and practice crisp storytelling that connects strategy to execution.

    Phase 2 — The managing phase: The IC to manager transition is a shift from doing the work to building the system that does the work. As you become more senior, zoom out from features to portfolios, from experiments to strategy. When hiring, I look for complementary archetypes across the team — the product creator who thrives in zero-to-one, the operator who scales repeatable playbooks, the analyst who brings rigor to prioritization, and the evangelist who aligns stakeholders. For first-time managers, my advice is to establish clear decision rights, define the bar for product quality, and coach toward autonomy. Balance mentoring with mechanisms: weekly product reviews, outcomes-driven OKRs, and lightweight rituals that reinforce clarity without micromanaging.

    Phase 3 — The executive phase: At this stage, I treat the product organization itself as a product. Define a vision, clarify the customer (your CEO, exec peers, board, and of course end users), and build feedback loops. With the CEO, align on the narrative, business model bets, and the handful of company-level outcomes that matter most. With peers on the exec team, drive cross-functional planning so GTM, finance, and product are synchronized around impact, not just output. With the board, translate strategy into measurable progress and risk mitigation. The goal is to ship strategy: clear choices, intentional sequencing, and a portfolio that advances product-market fit and durable growth.

    Whether you’re trying to break into product, grow into management, or step into the executive arena, this three-phase arc is a reliable compass. Invest in product discovery, tie work to outcomes, and develop the operating cadence that turns intent into impact. That’s how you accelerate from PM to VP — and lead with confidence at every step.


    Inspired by this post on First Round.


    Book a consult png image
  • Why the COO Role Is the C-Suite’s Most Fluid: Archetypes, No-Blame Culture, and CEO Guidance

    Why the COO Role Is the C-Suite’s Most Fluid: Archetypes, No-Blame Culture, and CEO Guidance

    I’ve long believed the COO seat is the most fluid role in the executive suite, and my perspective has been sharpened by learning from operating leaders who’ve scaled iconic companies. One conversation that stands out centers on Sara Clemens, most recently COO of Twitch and former COO of Pandora.

    In this interview, we explore the nuances of the COO role, which can vary drastically across different companies. We cover:

    The three main COO archetypes and which sorts of folks are best suited for those roles.

    The tactical elements of being a COO, including Sara’s advice for what good strategy actually looks like, and how to truly create a no-blame culture.

    Sara’s lessons on keeping pace as a company doubles in size, including her tips on sketching out “decision rights.”

    Guidance for CEOs considering bringing on a COO to the executive suite.

    From my vantage point in product management leadership, the variability of the COO mandate is a feature, not a bug. Great COOs adapt to the business model, stage, and CEO superpowers. The best partnerships I’ve seen start with explicit clarity: What outcomes matter most in the next 12–18 months? Which constraints are real? Where will product, operations, and go-to-market intersect—and who owns what?

    On archetypes, I map product’s needs to the operator’s strengths. If we’re pursuing step-function growth, I look for a COO who is comfortable orchestrating ambiguous, cross-functional bets. When the priority is scaling reliability and margins, I align with a process- and systems-oriented operator. When the goal is organizational transformation, I look for a builder who can reset norms while protecting momentum. Getting this fit right improves execution, reduces decision latency, and clarifies how we measure progress.

    On the tactical elements of being a COO and what good strategy looks like, I anchor on a few principles that have never failed me: strategy is a coherent set of choices, not a list of initiatives; it prioritizes outcomes over output and forces trade-offs. We translate those choices into a focused operating cadence—clear goals, crisp leading indicators, and reviews that separate signal from noise. In practice, that means elevating outcomes vs output OKRs, pressure-testing assumptions early, and linking roadmaps to measurable value creation.

    Creating a no-blame culture isn’t soft—it’s operationally essential. Blame keeps teams defensive; learning keeps them fast. I’ve had success institutionalizing blameless postmortems, pre-mortems for high-risk launches, and a norm of writing down hypotheses before we run experiments. We fix the process, not the person. Over time, this builds psychological safety and enables the honest retrospectives that high-velocity product and operations teams depend on.

    As companies double in size, complexity compounds. This is where “decision rights” become a force multiplier. I recommend codifying who is the decision-maker, who must be consulted, and who needs to be informed before work begins. Whether you prefer RACI, DACI, or RAPID, choose one, teach it, and use it consistently. Pair decision rights with single-threaded ownership for critical initiatives and you’ll reduce escalation churn, speed handoffs, and preserve accountability as headcount grows.

    Keeping pace during hypergrowth also demands an operating rhythm that scales. I align quarterly planning with a lightweight monthly business review, ensure product roadmapping and sprint planning tie directly to company-level outcomes, and maintain a disciplined change-management channel so emergent priorities don’t derail committed work. When the cadence is consistent and the artifacts are simple, leaders can move fast without breaking trust.

    For CEOs considering bringing on a COO to the executive suite, my guidance is straightforward: define the mandate in terms of outcomes, not tasks; be explicit about the seams between CEO, COO, and product; and decide how you’ll make decisions together before the first decision. Align on metrics, communication rhythms, and escalation paths. Hiring a great COO is not about finding a clone—it’s about designing a complementary partnership that compounds your strengths and closes your gaps.

    The through line across all of this is clarity—of strategy, of responsibilities, and of learning. Get those right, and the natural fluidity of the COO role becomes your organizational advantage.


    Book a consult png image
  • Go Totally Asynchronous: Inside Sidharth Kakkar’s Remote, Autonomous Culture That Scales

    Go Totally Asynchronous: Inside Sidharth Kakkar’s Remote, Autonomous Culture That Scales

    I’ve spent years leading product teams across global B2B SaaS, and few topics spark more debate than building a remote team that operates totally asynchronously. Recently, I revisited the playbook of Sidharth Kakkar, founder and CEO of Subscript, a subscription intelligence platform that empowers B2B SaaS leaders to better understand their revenue. (Read more about the company in this Techcrunch article.)

    Previously, he was the founder, CEO of Freckle, an education platform that grew to serve 10 million students and was acquired by Renaissance Learning in 2019. As a repeat founder, Sidharth picked up a ton of valuable lessons, particularly when it comes to company culture and management.

    Right from the start, he knew he wanted to build Subscript to be global, distributed, and asynchronous. That’s why there are no internal company meetings. Everyone also operates autonomously, deciding what to work on for themselves.

    In this analysis, I dive into both the philosophy behind this unique approach and the nitty gritty details of how exactly it works in practice. I’ll unpack how to share company updates asynchronously every week; advice on how to approach goal-setting and performance feedback while minimizing micromanagement; tips for improving transparency and documentation, plus details on Subscript’s running product/market fit journal; thoughts on how to assess asynchronous communication skills when hiring; and how this culture impacts a founder’s role and schedule.

    On weekly updates, asynchronous communication shines when it is consistent, structured, and outcomes-focused. I recommend a lightweight cadence that combines a written executive summary, links to artifacts (roadmaps, PRDs, dashboards), and optional short Looms for rich context. Tie each update to outcomes vs output OKRs so teams self-calibrate without meetings, and make updates searchable so new hires can ramp themselves with a clear trail of decisions and tradeoffs.

    For goal-setting and performance feedback, autonomy and clarity must coexist. Define clear success metrics upfront, timebox discovery, and use product roadmapping and sprint planning rituals that emphasize measurable customer outcomes over task completion. Replace micromanagement with transparent expectation docs, written performance narratives, and asynchronous 360 feedback—so individuals know what good looks like and can course-correct without waiting for a meeting.

    Transparency and documentation are the backbone of a remote, autonomous culture. Centralize decisions in a single source of truth, standardize decision records, and maintain a living discovery log alongside Subscript’s running product/market fit journal. This practice compresses feedback loops, preserves institutional memory, and accelerates product discovery by making assumptions, experiments, and results easy to consume across time zones.

    When hiring, I prioritize asynchronous communication skills as first-class selection criteria. Use written work samples, time-boxed take-home prompts, and collaborative docs to evaluate clarity, rigor, and empathy in writing. Look for signal such as strong structuring, crisp problem statements, thoughtful tradeoffs, and proactive documentation of risks and unknowns—capabilities that predict success on distributed teams.

    This culture fundamentally reshapes a founder’s role and schedule. With deep work protected and status noise automated, leaders can spend more time on strategy, customer conversations, and coaching. Decision latency drops because context is captured in writing, and the organization scales through principles rather than approvals—exactly what you want in a high-trust, high-leverage product operating system.

    There’s tons of food for thought in here, whether you’re a founder thinking about shaping your company culture, or a manager looking for some fresh ideas.


    Inspired by this post on First Round.


    Book a consult png image
  • Operations vs Algorithms: How I Scale Startups with Data Science, Team Design, and Pre-Mortems

    Operations vs Algorithms: How I Scale Startups with Data Science, Team Design, and Pre-Mortems

    I recently revisited one of the most practical conversations I’ve had about scaling: insights from Ian Wong, co-founder and CTO of Opendoor. Before founding Opendoor, Ian was Square’s first data scientist, where he developed machine learning models and infrastructure for fraud detection. That trajectory—building from operational muscle to algorithmic advantage—maps closely to how I’ve led product and data investments in fast-growing environments.

    As Ian puts it, in the early innings it might make sense for your startup to be operations heavy. But as you start to scale, data science becomes a critical component for running a business with longevity in mind. This mirrors my experience: hands-on operations create the learning loops you need early, while data science turns those learnings into scalable systems, better forecasts, and tighter risk controls.

    We dive into how both Square and Opendoor approached this transition. The progression is instructive—start with pragmatic operational workflows to validate demand and unit economics, then shift toward machine learning and automation once the process is stable, the data pipeline is trustworthy, and the cost of manual work begins to drag margins and responsiveness.

    Along those lines, we discuss some of the early considerations for your fledgling data science team, including the type of folks to hire for the early team, like whether to look for generalists or specialists, and how to set up your interview loops. In my playbook, I bias toward T-shaped generalists first—people who can partner with product, analytics, and engineering—then layer in specialists (ML ops, causal inference, experimentation) as complexity grows. For interview loops, I ensure we evaluate for problem framing, data intuition, model-to-product translation, and stakeholder communication—not just model accuracy.

    Ian also dives into his lessons on structuring the data science function so that it’s deeply integrated with the rest of the technical org. I’ve found embedded pods work best early—data scientists sit with product teams to accelerate discovery, instrumentation, and iteration—paired with a light central platform group to standardize data quality, experimentation frameworks, and model deployment practices.

    Next, we dive into some of his biggest lessons as a first-time founder and CTO, including his practice with Opendoor’s leadership team of doing pre-mortems to predict why something might not work. He also encourages founders to run through a bi-yearly exercise of re-writing their job rec. I’ve seen both rituals raise the bar: pre-mortems surface hidden risks before launch, and re-writing the job rec forces leaders to shed responsibilities, prevent role drift, and keep the org structured for the next stage—not the last one.

    Practically, my guidance to founders and product leaders is straightforward: define the decisions data science will improve (pricing, risk, routing, personalization), instrument for leading indicators, and ruthlessly prioritize the smallest models that deliver outsized business value. Avoid premature optimization—let operations teach you where the algorithm belongs. Use clear success metrics to track outcomes, not just output, and revisit them as your market and product expand.

    Finally, remember that the goal isn’t to replace operations—it’s to make operations smarter. Pair human judgment with machine learning in the workflows that matter most, invest in trustworthy data foundations, and build hiring and interview loops that reward interdisciplinary problem solvers. That’s how you turn early operational grit into durable, data-driven advantage.


    Book a consult png image
  • Airtable’s Journey to Product-Market Fit: Hard-Won Lessons on Building Horizontal Products

    Airtable’s Journey to Product-Market Fit: Hard-Won Lessons on Building Horizontal Products

    I recently dove deep with Andrew Ofstad, co-founder of Airtable, to unpack Airtable’s path to product-market fit and the realities of building a truly horizontal product. As a product leader, I’m always looking for patterns that translate across teams and stages — and this conversation offered a wealth of practical insights for founders and product managers alike.

    We started with first principles: how the founders came together, their vision for the product, and what the initial prototypes looked like. That early narrative matters — it anchors positioning, keeps scope disciplined, and ensures your earliest builds reflect the core value proposition rather than a laundry list of features.

    From there, we stepped through Airtable’s alpha, beta, and launch timelines, as well as their early traction. I pay close attention to these milestones because they reveal the learning cadence: how quickly teams validated hypotheses, which signals they treated as leading indicators, and how they balanced qualitative pull with quantitative adoption during product discovery.

    We also explored the challenges of creating a horizontal product that can do many things, including identifying initial use cases and figuring out how to describe what they were building. In my experience, the key is to land a small set of canonical use cases, articulate crisp jobs-to-be-done, and build narrative clarity around the “why now.” Without this, even great products struggle to convert curiosity into active usage.

    On commercialization, we dug into how to approach pricing and competition, as well as their early go-to-market strategy. For products with broad applicability, I’ve found that founder-led GTM is essential early on — it shortens the learning loop and informs SaaS pricing and packaging. Start with simple, customer-aligned tiers, validate willingness to pay against clear outcomes, and keep positioning focused on value, not feature parity.

    We then looked ahead to what the next 3 years will look like for Airtable, and how they’ve navigated scaling while staying true to their vision. Scaling a horizontal product requires tight product roadmapping and sprint planning, strong messaging discipline, and an unwavering commitment to the core value — all while layering ecosystem leverage, templates, and community to accelerate adoption without diluting the product’s identity.

    Whether you’re a founder validating your own idea, or a product leader looking for growth advice, there are tons of tactics here that go much deeper than the typical founding stories you hear. My takeaway: great horizontal products find product-market fit by starting narrow in use case, obsessing over teachability, and letting customer outcomes pull the roadmap forward.


    Inspired by this post on First Round.


    Book a consult png image
  • Inside Figma’s 5-Phase Community-Led Growth Playbook to Ignite Organic GTM

    Inside Figma’s 5-Phase Community-Led Growth Playbook to Ignite Organic GTM

    When I study companies that turn product-market fit into durable, compounding momentum, Figma stands out. In this breakdown, I walk through Figma’s five phases of community-led growth and share how I’d apply each step to build an organic growth engine. My lens is product management leadership paired with pragmatic GTM thinking, so the emphasis is on what to do, when to do it, and why it works.

    Phase 1 centers on the lessons from years in stealth mode — specifically, how to start planting the seeds for a community when you don’t have a fully-formed product. I focus on the inflection point to emerge from stealth, what signals matter, and how to use early feedback loops for product discovery without over-rotating on feature requests. Quietly building is necessary; quietly engaging is essential.

    In this early phase, my playbook prioritizes rigorous product discovery, crisp problem narratives, and a cadence that makes learning visible. I invest in relationship-building with credible early adopters, share prototypes thoughtfully, and shape outcomes over output through disciplined product roadmapping and sprint planning. The goal is to design a community that feels invited into the creative process while preserving the integrity of your vision.

    Phase 2 is all about the launch playbook — from taking over design Twitter, to marketing to folks who tend to bristle at traditional SaaS marketing. Here, founder-led GTM matters. I pair zero to one B2B marketing with specific audience rituals, leaning into channels where the product can be experienced, not just described. The message avoids enterprise jargon and instead showcases feel, speed, and collaboration, so the community can instantly “get it.”

    Phase 3 shifts the focus to activation via community gravity. The goal is to get folks to try the product, even if they weren’t going to switch over right away to designing in Figma full-time. This is where I formalize an evangelist strategy — spotlighting workflows, templates, and stories that reduce the cost of the first session. I think about developer evangelism patterns applied to designers: celebrate makers, distribute small wins widely, and build momentum with authentic, peer-to-peer proof.

    The final two phases connect passionate individual users to an enterprise strategy. They didn’t layer in a sales team until four years after the product launched, and didn’t add a paid product tier until another two years after that. Those choices underscore a disciplined sequencing of PLG with a sales overlay — land with love, expand with proof, monetize with timing.

    In practice, this means evolving from bottoms-up adoption to clear value narratives for team and enterprise tiers, while tuning SaaS pricing and packaging to customer maturity. I optimize the handoff from product-led signals to sales motions, align success metrics to outcomes (not just usage), and enable procurement-friendly paths without dulling what made the product magical. That’s the GTM trade-off: protect the community engine while scaling into enterprise.

    If you’re building your own community-led growth engine, these phases offer a durable blueprint: learn in stealth, launch where your audience lives, activate with authentic evangelism, and scale with a thoughtful enterprise bridge. Done well, this approach compounds — it strengthens product-market fit, accelerates zero to one B2B marketing, and sets the stage for sustainable growth without overreliance on paid channels.


    Book a consult png image
  • From Roadmaps to Sprints: Proven Tactics to Ship Software at Scale Without Chaos

    From Roadmaps to Sprints: Proven Tactics to Ship Software at Scale Without Chaos

    I recently sat down with Snir Kodesh, Head of Engineering at Retool, a development platform for building custom business tools. Before joining Retool, he spent six years as a Senior Director of Engineering at Lyft. Coming from my vantage point leading product at HighLevel, I was eager to compare notes on what it really takes to ship software at scale without losing clarity, customer focus, or team morale.

    We dug into the biggest differences between leading engineering teams for a consumer product versus an enterprise platform — and the patterns that hold true across both. Consumer surfaces demand rapid iteration loops and relentless UX polish; enterprise platforms demand configurability, security, reliability, and stakeholder alignment across buyers and users. In my experience, the constant across both worlds is crisp product management leadership: clear problem definition, tight feedback loops, and unambiguous ownership.

    We pulled back the curtain on the software development cycle, starting with setting the product roadmap while balancing a diverse set of customer needs. On roadmapping, I ensure we explicitly identify who’s in the room to represent product, engineering and design, as well as customer-facing teams like support and solutions. The most effective sessions make trade-offs visible: we quantify impact, risk, and effort; we surface dependencies; and we align on outcomes before timelines. The result is not just a list of features, but a sequenced narrative that earns the right to build.

    From there, we discussed how engineering takes that product roadmap and turns it into a concrete plan of action using the “try, do, consider” framework. I’ve found this framing incredibly practical: “try” creates space for low-risk experiments, “do” commits to high-confidence work, and “consider” tracks explorations that need more discovery. When sprint planning inherits this taxonomy, teams retain momentum without overcommitting — and leaders get a transparent view into where learning versus delivery is happening.

    He makes the case for leaning on QBRs instead of OKRs. I agree that quarterly business reviews calibrate teams on real outcomes, not vanity metrics, and they naturally force prioritization around customer value. When we do use OKRs, we emphasize outcomes vs output OKRs so teams aren’t incentivized to ship volume over impact. In practice, QBRs keep us honest: what shipped, what moved the needle, and what needs to change next quarter.

    We also tackled why scope creep gets a bad rap. In my experience, what’s labeled as “scope creep” is often legitimate learning uncovered through product discovery. The key is disciplined change management: time-box discovery, explicitly re-baseline when new information emerges, and separate must-haves from nice-to-haves. When done well, this turns surprises into strategic clarity rather than delivery risk.

    On estimation, we shared practical tactics for getting better at estimating how long a feature will actually take to complete. I lean on reference-class forecasting (compare to similar past work), risk burndown charts, explicit buffers for integration and QA, and a habit of capturing deltas between estimate and actuals. Over time, this creates a trustworthy velocity signal and sharpens intuition across both product and engineering.

    Translating the roadmap to sprint planning is where execution quality shows. We align on definitions of ready and done, maintain code review SLAs, budget a percentage for tech debt, and instrument everything so we can spot drift early. The “try, do, consider” framework maps cleanly to backlog hygiene, keeping discovery visible without derailing delivery. This is how we sustain speed and quality at scale.

    Finally, we zoomed out to essential advice for engineering leaders — especially folks scaling quickly from leading a small team to a much bigger one. Shift from direct control to leverage: clarify decision rights, invest in Staff+ ICs, and scale communication through operating cadences, decision logs, and crisp narratives. Pair autonomy with accountability using QBRs, and keep product discovery tight to preserve customer empathy as you add layers. The goal is the same at ten people or a thousand: ship valuable software predictably, learn fast, and keep the team energized.

    If you’re navigating the leap from product roadmapping to sprint planning, these patterns are battle-tested. Anchor on outcomes, use the “try, do, consider” lens to manage ambiguity, and treat scope as a living artifact informed by discovery. With the right rituals and metrics, you can ship software at scale — without chaos.


    Book a consult png image
  • My Playbook for the First 10 Hires: Lessons from Steven Bartel on Gem & Dropbox

    My Playbook for the First 10 Hires: Lessons from Steven Bartel on Gem & Dropbox

    I sat down with Steven Bartel, co-founder and CEO of Gem, to go deep on what really works when you’re making the very first critical hires in a startup. As a builder and operator, I know how much early talent decisions determine product velocity, culture, and ultimately whether the team can execute founder-led GTM with confidence.

    Before building the talent acquisition platform, Steven was an early engineer at Dropbox, where he spent 5 years working on analytics, Dropbox Paper, and hiring as the company grew from 25 to 1500 people.

    This experience from Dropbox, combined with his lessons from building out Gem’s own team and talking to his customer base of recruiters makes Steven the perfect person to talk to about early-stage recruiting.

    In our conversation we focus on how to make those fourth, fifth, or tenth hires — those really early days when your startup has zero brand recognition or recruiting help. Here’s a preview of his tactical advice, paired with my product leadership lens on what to actually do next.

    A trick for sourcing second-degree network connections. I’ve used this same approach to turn lukewarm interest into warm intros by mapping mutual connectors across former teammates, investors, advisors, and early customers. The goal is to engineer serendipity: stack-rank warm paths, ask for specific intros, and close the loop quickly with crisp role requirements and a two-sentence value proposition.

    The power of sending a “break-up” message in your candidate outreach. When a candidate goes quiet, a polite, time-bounded note that gives them an easy out often re-engages the conversation. It respects their time, signals high standards, and creates a natural moment for them to opt back in—very similar to enterprise follow-ups in founder-led sales.

    How Gem brought candidates on to work with them in very structured trial periods before making a full-time offer. I’ve found structured trials invaluable for de-risking early hires: define a scoped project, align on success criteria, and ensure tight feedback loops. This mirrors a product discovery sprint—short, measurable, and collaborative—while giving both sides a realistic preview of working together.

    Advice for working on your recruiting pitch and nurturing passive talent. Your pitch should evolve like your product narrative: lead with the mission, the unique wedge, and the precise problems a candidate will own in the next 90 days. For passive talent, sequence lightweight touchpoints (demo the product, share a customer story, invite a technical deep dive) to build trust long before you ask for a decision.

    The similarities between early-stage hiring and founder-led sales. Both require targeted prospecting, tight messaging, and rigorous follow-through. The best founders and product leaders treat recruiting pipelines like revenue pipelines—measure response rates, iterate on messaging, and run structured, time-boxed cycles to convert high-signal candidates.

    If you’re navigating your first hiring wave, these principles will help you build a repeatable recruiting engine: amplify second-degree networks, use respectful “break-up” nudges, validate fit with structured trials, sharpen your pitch for passive talent, and apply founder-led sales discipline to every stage of the funnel. Do this well, and your early team becomes a durable competitive advantage.


    Inspired by this post on First Round.


    Book a consult png image
  • Founder-Led Customer Success: My Proven Playbook for NRR, Feedback Loops, and First CS Hires

    Founder-Led Customer Success: My Proven Playbook for NRR, Feedback Loops, and First CS Hires

    I’m constantly looking for battle-tested ways to operationalize founder-led customer success in B2B SaaS. In that spirit, I recently dug deep into the patterns that have powered Sydney Strader, VP of Customer Success at Catalyst. Prior to joining Catalyst, Sydney was the VP of Customer Success at InVision.

    Founder-led customer success is one of the most overlooked levers in early company building, yet it’s often the fastest path to durable retention, sharper product-market fit, and a more effective founder-led GTM. When I roll up my sleeves with founders, I focus on building tight feedback loops, defining accountability for net revenue retention, and sequencing the first customer success hire with intention.

    How to structure early customer check-ins, plus a framework to help surface more specific feedback. In practice, I run these as short, recurring sessions for the first 60–90 days, anchored on outcomes, not features. I use a simple cadence and agenda: confirm the customer’s jobs-to-be-done and success criteria, inspect friction along the critical path, quantify value moments, and close with two commitments (one for us, one for the customer). To elicit specificity, I lean on prompts like: “Walk me through the last time you used this,” “What almost made you stop?” and “What has to be true to consider this indispensable in 90 days?”

    The most impactful questions that founders and customer success managers should ask all their customers. My shortlist includes: What outcome did you hire us to achieve, and how will you measure it? What’s the single biggest blocker between you and that outcome right now? Which part of our product experience feels surprisingly valuable—and which feels like work? If this tool disappeared tomorrow, what would you do instead? What needs to happen for you to expand usage with confidence in the next quarter? These questions turn qualitative check-ins into quantifiable insight that sharpens product discovery and reduces churn risk.

    Why everyone at the company owns the net revenue retention metric — not just the customer success function. I treat NRR as a company-wide operating metric, not a department KPI. Product owns value creation and time-to-value; Sales owns expansion hygiene and deal quality; Marketing owns ideal customer profile clarity and expectation setting; Finance and RevOps instrument leading indicators like activation rate, feature adoption, and health scores. When we wire NRR into planning and OKRs across teams, we translate customer signals into roadmap priorities and revenue outcomes without handoffs getting lost.

    How to make your first customer success hire, from the ideal profile to structuring the interview process and setting comp. The ideal early CS leader is a builder-operator: consultative, technically fluent, comfortable in ambiguity, and obsessed with outcomes. I design interviews around live exercises—diagnose a customer scenario, map a 90-day success plan, and instrument a health score with leading and lagging indicators. For compensation, I favor a base/variable split with a meaningful portion tied to net revenue retention and adoption milestones, plus early equity to align with long-term value creation. This profile accelerates learning loops between customers, product, and go-to-market.

    The throughline across all of this is simple: founders who lead from the front on customer success compress the learning cycle that drives retention and efficient growth. By formalizing early check-ins, asking high-signal questions, making NRR a company sport, and hiring a builder for that first CS role, we turn customer conversations into a strategic engine for product management leadership and sustainable expansion.


    Inspired by this post on First Round.


    Book a consult png image
  • Scaling Your Co-Founder Relationship: Rituals, Decision Rights, and Trust Lessons from Labelbox

    Scaling Your Co-Founder Relationship: Rituals, Decision Rights, and Trust Lessons from Labelbox

    I’ve learned that a startup’s trajectory often mirrors the strength of its co-founder relationship. With that lens, I sat down to unpack how to scale trust, decision-making, and speed between co-founders as the company itself scales. Our guests are Manu Sharma and Brian Rieger, co-founders of Labelbox. In this interview, I take a microscope to their co-founder DNA, exploring the ins and outs of how they’ve made the relationship work over the years. We traced how Manu and Brian came together as co-founders and landed on the idea for Labelbox. That origin story matters: it reveals the early signals of shared conviction, complementary experience, and a clear problem thesis—foundations I look for when evaluating co-founder fit in any startup. Before writing a line of code, they intentionally aligned their skillsets, values and responsibilities. I emphasize this step in my own product management leadership practice: make the invisible explicit. Define roles, boundaries, and how decisions get made while the stakes are low, so you can move fast when the stakes are high. As the company grows, their rituals for spending valuable time together keep the relationship durable. They use thought-starter questions for deep discussions and even benefit from sharing an executive coach. I’ve seen this playbook consistently reduce friction: structured prompts surface misalignments early, while an external coach creates a safe container to reset, recommit, and keep momentum. We also dug into how they run the executive team at scale and sketch out decision rights. Clear decision rights accelerate execution, prevent rework, and protect the co-founders’ relationship from getting pulled into every operational knot. In my experience, codifying who decides, who contributes, and how dissent is handled is one of the fastest ways to boost operating cadence without sacrificing trust. Manu and Brian both offer practical advice to other founders—whether you’re in the early stages of looking for a co-founder or aiming to add a little magic to an existing partnership. If you’re building, apply their lessons: align on values early, institutionalize rituals, use an executive coach, and be explicit about decision rights. These are the simple, scalable mechanisms that preserve focus, speed, and resilience as you pursue product-market fit and scale your executive team. You can follow Manu at @manuaero and Brian at @RiegerB on Twitter.
    Book a consult png image
  • Rethinking Quitting: Annie Duke’s Decision Science for Smarter Product Strategy

    Rethinking Quitting: Annie Duke’s Decision Science for Smarter Product Strategy

    I recently sat down with Annie Duke, a retired pro poker player and First Round’s Special Partner focused on Decision Science. She’s also the author of the bestselling book, “Thinking in Bets.” Her latest work, “Quit: The Power of Knowing When to Walk Away,” offers a provocative lens on one of the most misunderstood skills in product management and startup leadership: the decision to stop.

    In our world, quitting is often dismissed as failure. We celebrate grit, persistence, and the legendary founders who “just kept going.” But in my experience leading product strategy, I’ve learned that knowing when to walk away is frequently the hallmark of great judgment. Annie’s perspective reframes quitting as a strategic move that preserves focus, accelerates learning, and ultimately improves outcomes.

    What struck me most is how our psychology conspires against sound walk-away decisions. We’re vulnerable to sunk cost fallacy, status quo bias, and identity-driven attachment to our bets. As product teams, that shows up as clinging to features that don’t move the needle, extending pilots that never convert, or chasing a go-to-market motion that looked good in a deck but stalls in reality.

    “Quit: The Power of Knowing When to Walk Away” argues that quitting, done right, is not capitulation—it’s optimization. I see that play out in product discovery and portfolio management. The teams that outperform define clear kill criteria up front, tie decisions to leading indicators rather than vanity metrics, and treat each initiative as a reversible bet until product-market fit evidence says otherwise.

    Practically, I’ve found a few tactics echo Annie’s approach: set timeboxed experiments with explicit stop-loss rules; pre-commit to thresholds that trigger a review; and separate decision rights so the person advocating for a project isn’t the sole decider on its continuation. Decision logs, red-team reviews, and base-rate comparisons help strip away narrative bias and keep us grounded in outcomes vs output OKRs.

    Annie also offers guidance for advice-givers—those moments when you need to nudge a teammate or founder to change course. Lead with curiosity, not combat. Ask, “If we were starting from zero today, would we choose this strategy?” Frame quitting as a path to the original goal, not a retreat from it. And when necessary, be gentle, yet firm—clarity is kind.

    For product leaders, the real unlock is weaving quitting into the operating system. Stage funding for initiatives, escalate the evidence bar as you invest more, and normalize regular “stop, pivot, or double-down” checkpoints. This keeps resources flowing to the highest-leverage bets and reduces the emotional tax on hard calls.

    If you’re rethinking your roadmap, pipeline, or GTM motions, this is the moment to institutionalize better walk-away decisions. Align quit criteria to business outcomes, define decision cadence, and coach teams to see quitting as learning in action. It’s how you create velocity toward product-market fit while minimizing opportunity cost.

    If this resonates, add “Quit: The Power of Knowing When to Walk Away” to your reading list. And if you want to keep up with the ideas behind decision science and strategic quitting, you can follow Annie on Twitter at @AnnieDuke.

    Quitting isn’t the opposite of perseverance—it’s how we preserve our best bets. When we treat walking away as a disciplined product management capability, we build stronger strategies, ship better products, and protect the most precious asset we have: time.


    Inspired by this post on First Round.


    Book a consult png image
  • Finding Product-Market Fit Twice: Alma’s bold pivot and tactics to stay close to customers

    Finding Product-Market Fit Twice: Alma’s bold pivot and tactics to stay close to customers

    Finding product-market fit is hard enough once; doing it twice is the rare pressure test that separates resilient product teams from the rest. As a product leader, I’m obsessed with how teams navigate pivots without losing sight of their users — and Alma’s journey is a masterclass in staying customer-obsessed while scaling.

    In a recent conversation with Harry Ritter, I dug into how disciplined product discovery, clear decision-making, and founder-led GTM can accelerate learning cycles. Harry Ritter, founder of Alma, a membership-based network that helps independent mental health care providers accept insurance and build thriving private practices.

    What stands out to me is that the Alma team essentially had to find product-market fit twice as they went from physical, co-working office spaces pre-pandemic, to quickly building out their virtual care capabilities. That’s an enormous shift in operating model, unit economics, provider experience, and buyer expectations — yet the throughline was a relentless focus on customer needs and outcomes.

    Team building matters even more during moments like these. Approaching team building as a solo founder means deliberately constructing complementary skills around the founder’s strengths and gaps. I look for three early anchors: an execution-first product partner, a zero-to-one GTM lead who can validate demand with founder energy, and a metrics-driven operator to keep the system healthy as complexity scales. Values, operating cadence, and decision rights must be explicit, or a pivot will expose the cracks.

    Refining the idea and getting more insights from your customers through structured interviews, using the technique doctors are trained on is a powerful way to de-bias signal. I’ve used this clinical-style approach — open-ended history, precise symptom probing, differential hypotheses, and a closing summary for confirmation — to improve customer interview quality. It transforms conversations from anecdote collection into consistent, comparable product data you can act on.

    When the ground shifts, rallying your team through a pivot depends on clarity and cadence. I anchor on a simple narrative: why the environment changed, what we’ve learned from customers, where we’re going, and how we’ll measure progress. Staying competitor aware — not competitor obsessed keeps speed and focus on the user, while avoiding reactive roadmaps. And it’s crucial to internalize The difference between building a marketplace versus a platform. Marketplaces require liquidity, trust, and incentive design; platforms demand extensibility, APIs, and ecosystem health. Confusing the two leads to misaligned KPIs and misallocated resources.

    My practical playbook for a “second PMF” includes: weekly founder-led customer calls until patterns converge; a structured interview template and central repository; a pivot memo with explicit kill criteria and success metrics; a liquidity or engagement model depending on whether you’re a marketplace or platform; and a tight KPI set (retention, activation, and quality-of-service indicators) to validate product-market fit beyond growth vanity metrics.

    Whether you’re in the early stages of starting a company or going through a tough pivot, there are tons of helpful tactics here. The Alma story reinforces a timeless truth: proximity to customers is the ultimate unfair advantage — in discovery, in execution, and especially in moments of change.

    You can follow Harry on Twitter at @harryritter1.


    Inspired by this post on First Round.


    Book a consult png image