Tag: outcomes vs output OKRs

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.

October 21, 2025
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.

October 21, 2025
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.

October 21, 2025
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.

October 21, 2025
How Retool Hit $2M ARR Pre‑Launch: My Playbook on Developer Focus, Product‑Market Fit, and GTM

I spend my days building and scaling B2B products, and Retool’s journey to $2M in ARR before launch is a masterclass in focus. It’s also a case study I revisit when coaching teams on developer evangelism and founder-led GTM.

Listening to David Hsu recount the early decisions made the strategy crisp: stay laser‑focused on developers, remove the boilerplate of internal tools, and earn trust with speed.

Retool, a low-code platform for developers building custom internal tools.

Today, Retool is valued at over $3 billion and has some of the biggest companies in the world building apps on its platform.

Early on, plenty of smart folks thought the idea for Retool would fail and that the product’s developer focus would sink the company. I’ve heard variations of this skepticism whenever a team doubles down on a specific persona—especially developers.

What struck me is the clarity around the target customer and the discipline to pursue language-market fit. When you get the words right for developers—their jobs-to-be-done, primitives, and constraints—you lower friction across product discovery, onboarding, and activation.

Equally instructive is how Retool nabbed its earliest customers (which includes Brex, DoorDash and a Fortune 500 BigCo) and the way the team prioritized creating incredibly tight feedback cycles with these early evangelists. That’s founder-led GTM at its best: sit with users, ship fast, instrument everything, and turn customer conversations into a roadmap.

On the surface, Retool’s path to product-market fit seems incredibly smooth. But as David tells it, there were plenty of bumps in the road — and he’s got tons of advice for early-stage founders that are finding their footing. I’ve lived those bumps, too; they’re signals to tighten the loop, not reasons to pivot away from your core user.

My takeaways for product leaders: start with developer empathy, not feature breadth. Use founder bandwidth to run high-frequency user sessions, shadow internal tool builds, and test copy until you hit language-market fit. Treat docs, templates, and examples as part of the product; they often outperform UI tweaks for time-to-value.

Operationally, stand up a lightweight, metrics-driven pipeline that connects discovery to delivery. I like a weekly cadence that pairs qualitative insights with activation, time-to-first-value, and expansion signals—classic product-market fit lessons that prevent local optimizations. When you see pull, lean into developer evangelism and zero to one B2B marketing, not paid acquisition.

If I were replicating this playbook today, I’d deploy a small, forward-deployed team to embed with design partners, capture real workflows, and ship improvements daily. Pair that with clear outcomes vs output OKRs so the team optimizes for customer outcomes, not just shipping velocity. That’s how you earn trust with developers and translate it into durable ARR.

Retool’s story reinforces a principle I teach often: conviction in the right user beats broad appeal every time. Focus wins, feedback compounds, and the market rewards teams that can turn skepticism into traction—especially when the users are developers.

October 21, 2025
Scale With Your Startup: Proven Lessons from Mike Boufford’s Decade at Greenhouse

Scaling a company is only half the battle; scaling your own career in lockstep is the harder, more enduring challenge. I’ve seen high-growth environments reward those who adapt early and often, which is why the arc of Mike Boufford’s journey resonates deeply with me as a product leader.

Mike Boufford, CTO of Greenhouse, an applicant tracking system and recruiting platform.

He wrote the first line of code at Greenhouse in May 2012, and he’s still there — over a decade later.

This isn’t the typical path of non-co-founding engineers, who usually get layered or leave to start their own ventures.

Drawing on his story, I zero in on how founders build an environment that makes early employees want to stay, and importantly, how leaders can build the career skills and self-awareness they need to succeed at a startup long-term. In my experience, that combination—healthy culture plus relentless personal development—is what keeps top talent growing rather than going.

How his own motivation changed over time and how he managed his relationship with the company’s co-founders. I’ve learned that motivations naturally evolve—from creation and ownership, to scale and stewardship, to legacy and leverage. Naming those shifts early helps you reset expectations with co-founders before friction builds. Practically, this means recurring check-ins on roles, decision rights, and the tradeoffs you’re willing to accept as the organization matures.

The techniques he used to prepare himself for every next phase of growth and how his role would have to change in 18-24 months. I encourage leaders to keep a running “future job description” and refresh it quarterly. Ask: What will break at our next order of magnitude? Which systems, skills, and successors must I develop now so that I’m qualified for the job I’ll have in two years? This future-back planning keeps you ahead of the curve as the startup compounds.

Why he read two books on every other executive’s area of the business when he joined the leadership team. That habit builds cross-functional fluency fast. In my teams, this kind of immersion reduces friction with peers, sharpens strategy, and anchors debates in shared constraints—exactly what product and engineering leaders need to operate credibly at the executive level.

For a nuanced perspective on retention and healthy team evolution, I recommend reading: Why This Engineering Leader Thinks You Shouldn’t Aim for Zero Regrettable Attrition. Embracing the right amount of change—especially at senior levels—can unlock growth for both the organization and the individual.

If you’re navigating startup leadership, product management leadership, or the IC to manager transition, take this playbook to heart: anticipate the next phase, invest in cross-functional competence, and renegotiate your role before the org structure forces it. That’s how you scale with your startup, not in spite of it.

Inspired by this post on First Round.

October 21, 2025
Build Culture Like a Product: Anna Binder’s Asana Playbook for High-Performing Teams

I’ve long believed that culture deserves the same rigor we bring to product management. That view crystallized in a recent deep dive with Anna Binder, Head of People at Asana, where we explored what it truly means to build culture like a product — with clear goals, tight feedback loops, and iterative learning.

We revisited the earliest days when she first took on the role, zeroing in on how she prioritized the initial things to tackle as a new People exec and combed through a slew of opinions that bubbled up from other folks at the company. What stood out to me is how much this mirrors product discovery: define the problem precisely, gather qualitative signals, and validate with small, high-leverage experiments before scaling.

Translating that into my own operating system, I treat cultural work like a roadmap. I write crisp problem statements, hypothesize the behavioral change we seek, run lightweight pilots, and measure adoption and sentiment. I anchor success on outcomes vs output OKRs so we avoid mistaking activity for impact. This mindset not only accelerates learning, it also builds trust because leaders can explain the why behind each cultural bet.

Anna shared her tactical playbook for creating a culture of feedback for not just low-performers, but high-performers, too. That nuance matters. High performers often get praise but little developmental tension; I’ve seen careers plateau when strengths go unsharpened. My practice: institutionalize upward feedback, time-box “bright spots and blind spots” in 1:1s, and ensure managers are trained to ask for evidence and examples, not just opinions. It’s an essential step in the IC to manager transition as well, where modeling curiosity sets the tone for the entire team.

She also unpacked her methodology of conscious leadership, and how the best leaders always interrogate how the opposite might be true. I’ve adopted that as a mental circuit breaker when I feel certain: I write the opposite hypothesis and list evidence for it. This habit reduces ego, surfaces hidden risks, and leads to more durable decisions — a hallmark of product management leadership.

From working on Asana’s executive team for nearly 7 years, Anna emphasized building habits that keep the exec team a healthy nucleus at the center of the company. I’ve seen the same: meeting hygiene (clear intents, pre-reads, decision logs), decision-making cadences that separate debate from decide, and transparent communication that closes loops with the broader org. Treating the exec group as a high-trust product squad prevents thrash and models the behaviors we want everywhere else.

We ended with a rapid-fire exchange that maps cleanly to everyday leadership. On onboarding: design a 30-60-90 plan with explicit outcomes, shadowing for context, and early relationship-building across functions. On all-hands meetings: prioritize clarity over spectacle, celebrate learning (not just wins), and reserve time for unscripted Q&A to keep the dialogue authentic. On mentors: build a personal board of advisors with complementary strengths — operators for execution, coaches for reflection, and domain experts for sharp edges.

If you’re looking to uplevel your culture, start small and think like a product creator: define outcomes, run thoughtful experiments, and iterate in the open. The compound interest from these practices shows up in engagement, execution velocity, and ultimately, sustainable performance.

Inspired by this post on First Round.

October 21, 2025
Inside Stripe’s Culture: Powerful Documentation Rituals from Kickoffs to Retros and Slack

Culture is a company’s operating system, and documentation is the code that keeps it performant. As I lead product teams, I’ve learned that great cultures don’t just happen—they’re intentionally designed, scaled, and maintained. When founders and operators ask me which organizations model this best, Stripe reliably tops the list.
I recently sat down with Brie Wolfson to compare notes on how documentation, rituals, and communication norms shape high-velocity teams.
Brie spent nearly 5 years at Stripe, where she worked on bizops and launched Stripe Press, followed by a stint at Figma where she worked on education. She then started her consultancy, named The Kool-Aid Factory, to share her lessons on building team cultures. And now she’s operating as a first-time founder building Constellate, a new productivity and communications tool for teams.
In our conversation, we zeroed in on company culture—what it looks like when it’s working, how to codify it early, and how to scale it without diluting what makes it special. A decade ago, many teams tried to emulate the playbooks of companies like Google and Amazon. Today, a newer guard has emerged, and Stripe is often the culture benchmark that startups aim to emulate.
Brie peels back the layers into not just the cultural pillars that drove Stripe’s meteoric rise, but also how these showed up in day-to-day work.
We also zoom out beyond Stripe to talk about her work teaming up with companies with The Kool-Aid Factory, seeing culture and company-building up close. Brie shares advice on codifying your operating principles, establishing meaningful rituals, and growing this kernel of culture as the company scales.
Here’s what resonated most for me—and what I’ve seen pay dividends in product management leadership. First, treat kickoffs as the contract between intent and execution. A strong kickoff doc aligns on the problem statement, the “why now,” the DRI and decision log, risks and non-goals, and success measures tied to outcomes vs output OKRs. This single artifact becomes the source of truth for product discovery, scope decisions, and stakeholder communication.
Second, close the loop with retros that are structured and searchable. Think of retro docs as compounding assets: what worked, what didn’t, what we’ll change, and where decisions deviated from the kickoff. Over time, these narratives accelerate onboarding, reduce repeated mistakes, and strengthen operating principles.
Third, make Slack channels work like living documentation. Clarify a channel’s purpose, pin an index post, standardize naming conventions, and link to the latest kickoff and retro. When Slack is curated—not chaotic—it becomes a lightweight knowledge system that complements your docs rather than competing with them.
Finally, remember that rituals are the scaffolding for culture. Whether it’s weekly written updates, decision memos, or quarterly operating principle reviews, the goal is to make writing a team sport. Writing sharpens thinking, scales context, and reduces the cost of coordination as headcount grows.
Read the full essay Brie recommended during the interview: Reality has a surprising amount of detail and the article she penned for First Round Review: Ditch Your To-Do List and Use These Docs to Make More Impact.
You can follow Brie on Twitter @zebriez
If you’re building a product organization—or evolving from IC to manager—this playbook helps you replace ambiguity with clarity, reactive busyness with intentional outcomes, and scattered updates with a coherent, documented operating rhythm. Start with one ritual, write it down, and let the practice compound.

October 21, 2025
What I Learned from Don Faul on Leading with Radical Transparency in Hard Times

Leading teams through volatility demands more than strategy decks—it demands conviction and clarity. That’s why I was eager to learn from Don Faul, CEO of CrossFit, whose leadership journey spans a combat zone and a corporate board room. He spent 8 years as a platoon commander in the U.S. Marine Corps, then took on roles at Google, Facebook and Pinterest, the latter of which he served as the Head of Operations. Few leaders have stress-tested their principles across cultures this different, and that perspective is invaluable for product management leadership. One theme we explored head-on: whether micromanagement is always a bad thing. In my experience, it isn’t binary. In moments of genuine risk—customer incidents, safety-critical launches, or brand-defining bets—short, explicit periods of hands-on leadership can help a team move faster and learn safely. The key is to set clear exit criteria, communicate the why, and anchor on outcomes vs output OKRs so the team understands what success looks like—and when autonomy returns. We also dove into what it takes to build a long-term company vision that actually energizes people. A credible vision marries a bold, emotionally resonant narrative with a concrete path of near-term milestones. In my role leading product management at HighLevel, we anchor that narrative in the customer’s pain, make the outcomes measurable, and translate the vision into crisp, sequenced bets. When teams can see how this quarter’s work ladders to a multi-year north star, execution energy skyrockets. All-hands meetings are another place where leadership either compounds trust—or depletes it. The most common mistakes I see: status-report theater, a sea of vanity metrics, and avoiding the hard questions everyone is already whispering about. My playbook is simple: lead with what’s hard, be explicit about trade-offs, highlight real customer stories, and tie priorities back to outcomes vs output OKRs. Then make space for unfiltered Q&A and follow up with written decisions so the operating system stays transparent. We also discussed what it takes to lead when things feel like they’re going off the rails, which plenty of startup folks are feeling right now. In uncertain markets, I default to over-communication: weekly updates on goals, financial runway and scenario plans; decision logs that explain what changed and why; and repeated clarity on the next three most important priorities. When the path gets rocky, transparency isn’t a virtue signal—it’s an operating mechanism that preserves momentum and dignity. Don unpacked lessons on embracing transparency when things aren’t going well, and also shared his experience having to wind down a company. My own approach in that situation is to move quickly and humanely: communicate early, share the specific criteria behind the decision, offer as much support as possible, and be crystal clear on timelines and logistics. People can handle tough news; what erodes trust is ambiguity and delay. For anyone navigating the IC to manager transition, there’s a powerful throughline in these lessons: leadership is context-aware. Your job shifts from owning tasks to designing systems—communication cadence, decision frameworks, and coaching—so that outcomes persist without your constant presence. The earlier you learn to set vision, define outcomes, and create feedback loops, the sooner your team compounds value. If you’re building in this market, remember: radical transparency is not just about sharing everything; it’s about sharing the right things at the right altitude, at the right time. Clarity on vision, grounded metrics, honest all-hands, and humane leadership in adversity—these are the habits that keep teams inspired and resilient. You can follow Don on Twitter @donfaul

October 21, 2025
Hypergrowth Leadership: My Takeaways from Claire Hughes Johnson on “learning organisms”

I’ve been reflecting on what it really takes to scale a product organization through hypergrowth, and I keep coming back to the discipline and mindset modeled by Claire Hughes Johnson. Her approach to operating at scale, executive hiring, and leadership development aligns closely with the highest standards of product management leadership.

Claire joined Stripe as its COO back in 2014 and, over the course of her nearly seven years in the company’s executive suite, she oversaw rapid growth as Stripe scaled from under 200 employees to over 7,000. Prior to Stripe, she spent 10 years at Google leading various high-impact business teams. That arc of operating experience sets the context for her new book, “Scaling People: Tactics for Management and Company Building.”

One story that particularly resonates with me is the inside look at her lengthy, no-stone-unturned interview process with the Collison brothers for the COO role. I’ve learned that this level of rigor is not just about due diligence; it’s a signal of shared standards and cultural alignment. When I hire for critical roles, I mirror this depth: clarify the mandate, pressure-test values, and evaluate for the long arc of decision quality—not merely short-term execution.

Hiring exceptional talent demands systems thinking. Claire’s emphasis on doing reference checks the right way—structured, targeted, and focused on observed behaviors—maps to my own playbook. I’ve found executive hiring is hard because the signals are noisy, the roles are often ambiguous, and it’s tempting to over-index on brand or storytelling. The antidote is to define success as outcomes, not activities, and then assess candidates against those outcomes. This is where outcomes vs output OKRs become indispensable for preventing mis-hiring and aligning expectations.

Her personal backstory also underscores a foundational leadership trait: curiosity. The way her parents instilled deep curiosity and fierce independence at a very young age is more than biography—it’s a blueprint. In practice, it translates to cultivating an owner’s mindset across the org, which is crucial for anyone navigating an IC to manager transition and for leaders who must empower teams without micromanaging.

I also appreciate her belief that all high-performers are “learning organisms.” I’ve seen the best product leaders systematize learning with deliberate feedback loops, postmortems, and explicit mechanisms to turn insight into action. In product discovery, this shows up as rapid cycles of hypothesis, experiment, and synthesis—creating a culture where learning velocity compounds just as reliably as revenue can.

This is why I recommend “Scaling People: Tactics for Management and Company Building” to operators who want pragmatic tools, not just abstractions. For complementary perspective, the book she recommended from Fred Kofman titled “Conscious Business” pairs well with these themes of ownership, integrity, and clear commitments—essentials for leaders who manage complexity at scale.

If you’re looking to stay close to her work, you can follow Claire on Twitter at @chughesjohnson. I’ve found her ongoing reflections a useful calibration point for raising the bar on leadership systems, executive hiring, and operating rigor.

My key takeaway is simple but powerful: scale rewards clarity, discipline, and humility. Hiring is a product in itself. Culture is a system, not a slogan. And the leaders who keep compounding are the ones who choose to be “learning organisms,” building teams that do the same.

October 21, 2025
From IC to Manager: Proven Strategies to Avoid Pitfalls and Lead High-Impact Teams

The leap from individual contributor to manager looks straightforward on paper, yet it’s one of the trickiest transitions I’ve seen in high-growth environments. In my role at HighLevel, I’ve watched brilliant engineers stumble when the job changes from building the product to building the people who build the product. The difference isn’t incremental—it’s a complete shift in identity, incentives, and daily habits.

Most startups get it wrong because they promote for technical excellence and throughput, then keep the new manager doing their old job with “a little people stuff on the side.” That’s a recipe for burnout and underperformance. The first principle is simple: management is a different job. Success is no longer measured by your code, but by your team’s clarity, velocity, and outcomes.

Set expectations and goals with precision on day one. I establish a clear role charter, spell out decision rights, and align to outcomes vs output OKRs so the new manager understands what “great” looks like. We define a 30/60/90 plan that includes team health metrics, delivery goals, and collaboration routines with product and design. The aim isn’t to ship more tickets—it’s to reliably ship the right outcomes.

To turbocharge a team’s effectiveness, I focus on operating cadence and flow. That means crisp intake, visible priorities, lean WIP, tight feedback loops, and regular retros that drive real change. I remove systemic blockers, protect focus time, and make psychological safety a non-negotiable. When people feel safe, they surface risks early, challenge assumptions, and accelerate learning.

High-impact feedback is fast, frequent, kind, and specific. I coach managers to use situation–behavior–impact, to separate people from problems, and to balance reinforcing and redirecting feedback. Written summaries after key conversations prevent drift, while short feedback cycles create compounding growth. Recognition is not an afterthought—it’s a performance tool.

Going from peer to manager requires an explicit reset. I encourage managers to communicate the new expectations, re-establish boundaries, and commit to fairness over familiarity. This includes confidential 1:1s, transparent decision-making, and a clear stance on performance bars. Trust grows when people experience consistency, not when they hear platitudes.

Delaying action on low performance is one of the most costly leadership mistakes. It silently taxes your top performers, normalizes mediocrity, and corrodes culture. Diagnose if the issue is skill or will, offer targeted support with time-bound milestones, and be decisive. Managing someone out can be both humane and necessary—clarity and dignity can coexist.

For first-time managers, I use a simple playbook. In the first 30 days, run a listening tour and baseline the team’s delivery, quality, and morale. By day 60, implement the new operating cadence, align on outcomes vs output OKRs, and tighten cross-functional rituals. By day 90, complete career conversations, calibrate performance, and publish a team charter that codifies how you plan, build, and learn.

The throughline in all of this is ownership: own the outcomes, the culture, and the system. When you make the mindset shift from doing the work to enabling the work, you’ll find that the manager role is not a detour from impact—it’s a force multiplier. With clear expectations, disciplined execution, and courageous feedback, you’ll transform a promotion into a platform for sustained, compounding results.

October 21, 2025
Scale Beyond One Product: Battle‑Tested Tactics for Ideas, Teams, and Product Reviews

Expanding from a single hero product to a resilient multi‑product portfolio is one of the most consequential moves a SaaS company can make. I’ve navigated this shift firsthand and studied how leaders approached it at companies like Stripe and Watershed. What follows is the playbook I use to assess new product ideas, structure teams for 0‑1 execution, and run rigorous product reviews without losing momentum on the core business.

I start by clarifying the type of multi‑product strategy we’re pursuing. Are we building adjacent features that deepen adoption, launching true net‑new products for new buyers, extending a platform with new primitives, or assembling a bundle that compounds customer value? That choice dictates everything else—resource allocation, hiring profiles, team topology, and the shape of our product discovery.

Stories from Stripe’s multi‑product success reinforce a principle I believe deeply: launch with small, high‑trust teams and a brutally clear problem statement, then iterate fast with real customers. When adding products like Stripe Billing and Stripe Treasury, the work required not only great execution but also adapting to new buyer profiles and purchasing motions. The lesson I apply is simple—don’t assume the new buyer is just a variant of the old one.

Resource allocation is where strategy meets courage. I protect the core product’s roadmap while ring‑fencing a few exceptional builders to pursue secondary bets. These squads operate with clear, outcome‑based goals and tight feedback loops, not sprawling OKR spreadsheets. The aim is to make small, reversible bets at first, then scale conviction with evidence—market pull, repeatable use cases, and early revenue signals.

Team structure matters even more than headcount. I form new‑product squads that behave like a startup within the company—full‑stack ownership, minimal dependencies, and direct access to customers. The early team must combine product discovery instincts with the ability to ship. Great early‑stage product thinkers show crisp problem framing, a bias for learning, and the humility to change course. One common fail‑case I watch for is hiring purely for potential over demonstrated ability to drive ambiguous work from zero to one.

Hiring the right people for 0‑1 work is its own craft. I look for signals of self‑direction, obsession with customer outcomes, and the ability to reason from first principles under uncertainty. I use five interview questions to unearth hidden talent among product candidates, all designed to reveal how they validate problems, reduce scope intelligently, earn trust with engineers, and handle the uncomfortable middle of product discovery.

Even the best teams stumble when product, packaging, and go‑to‑market are misaligned. I’ve seen what happens when an organization assumes the existing buyer will adopt the new product in the same way—pricing misses the mark, activation drops, and sales enablement lags. The fix is to revisit the buyer, refine the value proposition, and rebuild the path to value so the first‑run experience matches the new buying journey.

To keep new bets honest, I treat them with “definite optimism”—a clear, written view of what success looks like and a pragmatic path to get there. I focus on the sequence of proof: problem validation, consistent user pull, and evidence of repeatable adoption. In a new or early market, I combine a methodical approach (milestones, stages of validation) with analytical rigor (leading indicators, customer expansion patterns) to decide which products to prioritize and when to scale.

Goal‑setting for new products must be measurable yet forgiving of discovery. I favor outcome‑centric checkpoints over vanity metrics, and I evaluate bets by expected learning speed and cost of delay. This keeps us moving fast without confusing activity for progress.

My product reviews are anchored by 12 questions that force clarity on problem, user, value, and risk. I often share these questions as a pre‑read so teams can self‑diagnose and come in focused on decisions rather than updates. “The Enterprise Rent‑A‑Car Story” is a helpful reminder for me that distribution and execution are as decisive as the product idea itself. When building for net‑new‑customers, I re‑focus the questions on buyer change, activation friction, and early‑life cycle signals.

User feedback is the lifeblood of 0‑1. I collect inputs across interviews, product analytics, and support tickets, but I interpret them through the lens of the problem statement rather than raw feature requests. Product development must start with problem validation; otherwise, speed becomes a liability and discovery masquerades as delivery.

For ongoing inspiration and sharp thinking in product management leadership and product discovery, I regularly revisit a few resources. First Round Capital’s Newsletter: https://review.firstround.com/newsletter. The ‘Wins Above Replacement’ metaphor: https://en.as.com/mlb/wins-above-replacement-war-baseball-statistic-explained-n/. Zero to One by Peter Thiel & Blake Masters: https://www.amazon.com.au/Zero-One-Notes-Startups-Future/dp/0804139296.

When I look across the ecosystem—Atlassian: https://www.atlassian.com/, Cash App: https://cash.app/, Figma: https://www.figma.com/, First Round Capital: https://firstround.com/, Lattice: https://lattice.com/, Notion: https://www.notion.so/, Paypal: https://www.paypal.com/, Stripe: https://stripe.com/, Watershed: https://watershed.com/—I see variations of the same pattern: disciplined product discovery, sharp resource allocation, and product review rituals that reward learning over laddered status updates.

I also learn from builders who think in systems and act with urgency. Jack Dorsey: https://twitter.com/jack. Patrick Collison: https://twitter.com/patrickc. Shreyas Doshi: https://twitter.com/shreyas. Their public writing on product strategy, execution, and outcomes vs output informs how I evaluate talent, decide what not to build, and keep teams aligned as we scale beyond one product.

October 21, 2025