Tag: first principles decision making

  • How Snapbar Turned Crisis Into an AI-Native Photo Experience Revolution

    How Snapbar Turned Crisis Into an AI-Native Photo Experience Revolution

    What does it take to reinvent a 14-year-old company, not once, but twice? I ask that question often when I look at mature product organizations, because the hardest transformations rarely start with a clean slate. They start with real customers, legacy expectations, operational muscle memory, and a market that suddenly refuses to behave the way it used to.

    Snapbar is a useful case study in that kind of transformation. The company began as a wedding photo booth side hustle, grew into a national events company, and then watched COVID wipe out the entire business overnight. As a product leader, I find that moment especially important because it separates teams that are attached to the current expression of their product from teams that understand the deeper customer need underneath it.

    The deeper need was never just a physical photo booth. It was identity, participation, memory, brand engagement, and a shareable experience that people could take with them. When in-person events disappeared, Snapbar went from physical photo booths to a cross-platform virtual product built on WebRTC in spring 2020. That was not a cosmetic pivot. It was a first-principles rebuild under pressure.

    I have seen many teams talk about innovation when conditions are favorable. Snapbar’s story is more interesting because the team had to innovate when the existing business model was unavailable. That kind of constraint can be clarifying. It forces product teams to ask: What job are we really doing for customers, and what parts of our current solution are merely historical artifacts?

    The next reinvention came from generative AI. Pushed by declining repeat business, Snapbar dove deep into Stable Diffusion, custom LoRA fine-tunes on H100/H200 GPUs, and eventually a reasoning-model-powered generative image and video pipeline. What stands out to me is not simply that the team adopted gen ai. It is that they connected AI capabilities to a domain they already understood deeply: photography, events, brand activations, and experiential marketing.

    This distinction matters. In product management, technology FOMO can lead teams to bolt AI onto workflows without a clear strategic advantage. Snapbar appears to have moved differently. They used 14 years of industry knowledge to identify where AI could change the experience itself, not just automate a back-office task or generate a novelty output.

    The product evolution is a strong example of applied AI. Snapbar integrated Stable Diffusion 1.5 as their first generative AI model and ran custom LoRA fine-tunes on H100/H200 GPUs to produce brand-quality outputs nobody else in their space could match. That level of execution shows the difference between experimenting with a model and building a differentiated product system around it.

    I also appreciate the way the team moved from negative prompts to reasoning model long-form prompts. In brand environments, creative control and safety control are not optional. A brand activation must feel imaginative, but it also has to remain on-message, inclusive, and predictable enough for a live event setting. Better prompt engineering becomes part of the product’s trust layer.

    One of the most important product details is the meta-prompting pre-processing pipeline designed to ensure user likenesses, including non-obvious details like disabilities, are accurately represented in generated images. That is not a minor implementation detail. It reflects a more mature view of AI risk management, representation, and customer experience.

    From my perspective, this is where product strategy and ethical technology intersect. Generative AI systems can easily flatten people into generic outputs. A thoughtful product team has to decide what fidelity means, what consent means, and how much control users and brands should have over the final artifact. Snapbar’s approach suggests that representation is not just a model-quality problem; it is a product-design problem.

    Podcast cover art for Just Now Possible with Teresa Torres, featuring bold white and yellow text on a navy background and Snapbar AI photo booth branding.
    Just Now Possible spotlights Snapbar’s journey from photo booths to AI-powered brand experiences, framing reinvention, creativity, and applied AI as the center of the conversation.

    The company’s experiential marketing platform lets brands “world build” at conferences, trade shows, and live events by bringing fans into branded creative worlds. That phrase matters because it reframes the photo booth from a capture device into a participatory brand system. The user is not merely photographed. The user becomes part of a designed world.

    I see this as a broader shift in product experience. Static brand impressions are giving way to co-created moments. Snapbar added participatory user inputs through Mad Lib-style prompts and prompt injection, turning photo experiences into co-creation moments between brands and their audiences. That is a more durable engagement loop than simply asking someone to pose in front of a branded backdrop.

    The operational story is just as relevant for product and engineering leaders. Snapbar used Claude Code and Codex to build and ship features rapidly as a small bootstrap team, and developed a four-pillar agent orchestration framework: context, tools, verification, and workflows. I like that framing because it treats AI-assisted development as a system of work, not a magic shortcut.

    In my own product leadership work, I keep coming back to the same lesson: AI workflows only become reliable when the team defines the surrounding operating model. Context determines whether the agent understands the problem. Tools determine what it can actually do. Verification determines whether the output is trustworthy. Workflows determine whether the capability compounds across the organization.

    Snapbar is now building customer-facing “vibe coding” using the Claude Agent SDK so brands can configure and create experiences themselves within Snapbar’s platform. That is a meaningful product move. It shifts creation closer to the customer while keeping the workflow inside a controlled product environment. For brand teams, that could reduce dependency on custom service work while still preserving creative flexibility.

    This is the kind of AI Strategy I find most compelling: not a generic claim that AI will transform everything, but a specific path from domain expertise to product capability to customer empowerment. Snapbar did not abandon its past. It converted years of event, photography, and brand knowledge into a new interface for generative AI.

    The core lesson for product teams is clear. Reinvention does not always mean discarding the original business. Sometimes it means identifying the durable customer need, rebuilding the delivery mechanism, and then using new technology to expand what the experience can become. Snapbar’s journey from wedding photo booths to virtual WebRTC experiences to AI world building shows how a team can preserve its market intuition while changing nearly everything about the product surface.

    For product leaders evaluating gen ai opportunities, I would take three practical lessons from this story. First, start with the customer experience, not the model. Second, treat brand safety, representation, and verification as product requirements from the beginning. Third, use agentic AI internally only when the team has a clear framework for context, tools, verification, and workflows.

    Snapbar’s story resonates because it is not about chasing a trend. It is about a team using necessity, curiosity-led self-education, and disciplined product thinking to build something that feels native to the generative AI era. That is the difference between adopting AI and becoming AI-native.

    Inspired by this post on Product Talk.

    Book a consult png image
  • Beyond Command and Control: How I Build Trust, Speed, and Autonomy in Product Teams

    Beyond Command and Control: How I Build Trust, Speed, and Autonomy in Product Teams

    When uncertainty spikes, I notice many organizations snap back to "Command and control." It feels fast, safe, and decisive—especially when the stakes are high. But in product management leadership, speed without shared context is often an illusion, and control without trust rarely scales. I’ve learned that what looks like strength from the top can quietly create bottlenecks, missed signals, and disengaged teams.

    Why do smart companies revert in tough times? Familiarity. Centralizing decisions can reduce short-term cognitive load and signal clarity. Yet the cost shows up quickly: leaders become single-threaded on context they cannot possibly hold, and teams spend cycles asking for permission rather than creating value. The result is slower learning and weaker product strategy just when continuous discovery and iteration matter most.

    Here’s the hard truth: no single leader can hold all the context required to make every decision in a modern, cross-functional environment. The hidden complexity of customer segments, technical debt, data signals, and go-to-market constraints outstrips any one person’s bandwidth. That’s why empowered product teams, staffed with domain experts, outperform command centers—provided they’re aligned on outcomes and guardrails.

    I like the burning house analogy: in a true emergency, crisp direction helps—"take the stairs, not the elevator"—because the problem is clear, the time horizon is short, and the action is obvious. But most product work is not a single burning house; it’s a city with evolving fire codes, shifting weather, and neighborhoods that look different block to block. In that environment, distributed action scales better than centralized control.

    Strong leadership is not the same as command-and-control. In practice, it means setting a compelling direction, defining guardrails, and running tight feedback loops. I aim for what I call the "Flotilla of kayaks": we’re all headed to the same lighthouse, but each kayak navigates its own currents based on local information. That’s aligned autonomy—fast, resilient, and deeply accountable.

    People often ask why some command-and-control companies still succeed. My view: beneath the surface, there’s usually more trust and unofficial autonomy than their org charts suggest. Teams earn freedom by shipping reliably, sharing decision rationales, and showing outcomes. Leaders tolerate—and even quietly endorse—those pockets of autonomy because they see the results.

    It’s a spectrum, not a binary. I flex my style based on risk, reversibility, and time horizon—what I’d call spectrum thinking. Early in a bet, or when risks are existential, I raise the altitude and tighten the cadence. As confidence builds, I widen autonomy and shift the team to outcomes over outputs. Beware "Founder mode" when it drifts from vision-setting into day-to-day decision vetoes; it’s intoxicating early and suffocating at scale.

    On decision-making, I prefer a simple principle: let the person with the most relevant expertise decide, while incorporating the right input. That’s "Consultative decision-making" in practice. In some regions, you’ll hear it called "Konsultativer Einzelentscheid." The point is to seek counsel without defaulting to consensus that bogs down speed. One person owns the call, and everyone commits to the decision once it’s made.

    Practically, here’s what works for my teams: we clarify decision rights up front, draft pre-reads with clear options and risks, involve the smallest set of stakeholders required, and document the decision and expected signals ahead of time. Product trios keep discovery tight with design and engineering, while stakeholder management focuses on context, not sign-offs. We track outcomes vs output OKRs and hold regular decision reviews so we can reverse or double down fast.

    My key takeaways are consistent: "Command and control" can feel efficient, but it doesn’t scale in complex environments. No leader can hold all the context. Strong leadership is about direction, guardrails, and feedback loops—not control. High-performing teams balance autonomy with alignment. Decision-making should sit with the person closest to the problem, supported by the right input and transparent reasoning. Trust is built and earned over time—and it changes how teams operate.

    Reflection prompts I use with my leads: Where does your team sit on the command-and-control ↔ autonomy spectrum? Are the highest-context people truly making the decisions? What would it take to increase trust and autonomy—better instrumentation, clearer guardrails, or tighter cadences? Which calls require consensus, and which deserve a decisive, single-threaded owner?

    If you’re wrestling with speed, alignment, and autonomy in your organization, start small: pilot "Consultative decision-making" on one consequential decision, set explicit guardrails, and measure the outcome. You may be surprised how quickly aligned autonomy compounds into better product discovery, sharper product strategy, and stronger execution.

    Inspired by this post on Product Talk.

    Book a consult png image
  • From Engineer to CEO: Hard-Won Lessons on GTM, Cloud-First Bets, and Must-Do Focus

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Book a consult png image
  • Inside Zipline’s Wild Pivot: My Take on Hiring Heat-Seekers and Scaling to 5,000 Hospitals

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

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

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

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

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

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

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

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

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

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

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

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

    Book a consult png image
  • Delegated Decision-Making: Build a System That Scales

    Delegated Decision-Making: Build a System That Scales

    Your calendar is full of approvals, but the problem probably isn’t that your team lacks initiative. The organization has learned that an important decision becomes safe only after you touch it.

    You don’t fix that by telling people to be more empowered. You fix it by making authority, context, constraints, evidence, and escalation explicit. The goal is not to remove yourself from every decision. It is to ensure that your involvement is triggered by risk or abnormal variance, not by habit.

    Delegation fails when you transfer work but retain judgment

    A leader says, "You own this," but still expects to approve the plan, resolve every cross-functional conflict, and make the final tradeoff. The team receives responsibility without authority. It can prepare options, but it cannot truly decide.

    The opposite failure is just as common. A leader transfers a decision with so little context that the owner must reconstruct the strategy, risk tolerance, and success criteria from scattered conversations. What looks like autonomy is actually abandonment.

    Effective delegation sits between those extremes. You retain accountability for the quality of the operating system while another leader gains authority over a defined class of decisions. That person should know what outcome matters, which constraints are real, what evidence to use, and when the decision must return to you.

    This is the transition many managers struggle with when they begin managing managers. Your value can no longer come primarily from supplying the best answer. It comes from installing mechanisms through which other leaders can repeatedly reach good answers.

    Key takeaways

    • Delegate a decision domain, not merely the tasks required to prepare a decision.
    • Give each recurring decision one clearly named owner with enough authority to act.
    • Define constraints and escalation triggers before the owner encounters pressure.
    • Teach the reasoning behind past decisions so people can handle cases you did not anticipate.
    • Review outcomes and assumptions without reopening every decision you would have made differently.
    • Increase authority when judgment is consistently sound; intervene when risk, ownership, or evidence breaks down.

    A useful test is to step away mentally and ask three questions: Would the priority remain intact? Would the relevant metrics continue to be watched? Would the team make approximately the same tradeoff without waiting for me? A no to any of them points to a missing mechanism, not automatically a weak employee.

    Build a minimum decision contract

    Before delegating a consequential decision, write a short decision contract. This is not a policy manual. It is the minimum context another capable leader needs in order to act without repeatedly requesting permission.

    The contract should answer the following questions:

    • What decision is being delegated? Name the decision class precisely. "Own onboarding" is vague. "Choose and sequence onboarding experiments within the agreed quarterly outcome" is actionable.
    • Who decides? Assign one decision owner. Other people may contribute expertise, execute the work, or challenge assumptions, but shared input should not create ambiguous ownership.
    • What outcome governs the tradeoff? Connect the decision to an outcome and its driver tree. Without that connection, the owner will optimize for the loudest stakeholder or the most visible output.
    • What is inside the owner’s authority? State the product area, customer segment, time horizon, resources, and dependencies covered by the delegation.
    • Which constraints are real? Separate non-negotiable boundaries from preferences. If every preference is presented as a constraint, authority remains fictional.
    • What evidence is expected? Identify the metrics, customer evidence, technical inputs, or operating assumptions that should inform the choice.
    • What requires escalation? Define the conditions that change the decision from local to executive. Use observable triggers where possible.
    • When will the result be reviewed? Set the review around the availability of meaningful evidence, not the leader’s desire for reassurance.

    Decision rights also need a verb. "Involved" is not a decision right. Use language such as recommend, decide, approve, execute, or advise. If two people both believe they approve, the real decision will drift upward when disagreement appears.

    For a recurring product decision, the contract might say that a product leader decides which discovery opportunities to pursue, design and engineering advise on feasibility, and the executive is informed through the normal review cadence. Escalation occurs only if the choice changes the agreed strategy, creates an existential risk, lacks a credible metric owner, or exposes a material contradiction between the operating narrative and the numbers.

    That final distinction matters. Notification is not permission. If a leader must wait for your reaction after every update, the supposed decision owner will learn to delay action until you respond.

    Use a one-page decision brief for consequential choices

    A decision brief makes judgment inspectable without forcing you into every working session. Keep it short enough to use under normal operating pressure:

    • Decision to make and why it must be made now
    • Owner and affected teams
    • Desired outcome and relevant driver-tree nodes
    • Options considered
    • Recommendation and rejected alternatives
    • Critical assumptions and evidence
    • Constraints and downstream consequences
    • Escalation triggers
    • Date or signal for reviewing the result

    The brief should expose reasoning, not reward document production. If the owner cannot state the governing outcome, the most fragile assumption, and the reason for rejecting the strongest alternative, more pages will not solve the problem.

    Teach judgment through driver trees and decision records

    Rules cover familiar situations. Judgment covers the cases no rule anticipated. If you want delegated decisions to survive ambiguity, you have to make your mental models visible.

    Start with the outcome. Decompose it into the controllable levers that could plausibly move it, instrument those levers, and assign each one a single-threaded owner. Document the assumptions that connect one level of the tree to the next. This forces a team to distinguish a desired result from the mechanism expected to produce it.

    Suppose the desired outcome is stronger customer expansion. A team might initially examine the eligible expansion base, adoption of additional capabilities, realized usage, retention, and the acceptance of relevant offers. That is a hypothesis about causality, not a permanent truth. The team should test whether those nodes actually explain movement in the outcome and revise the tree when the evidence disagrees.

    This changes the delegation conversation. Instead of asking, "Do I like this roadmap?" you can ask:

    • Which driver is the decision intended to move?
    • What evidence connects the proposed work to that driver?
    • Which assumption would invalidate the recommendation?
    • How quickly would the team detect that the assumption was wrong?
    • Who owns the metric after the decision is made?
    • What other driver might deteriorate as a result of this choice?

    Those questions teach a reusable method. Simply giving the answer teaches the team that your presence is the method.

    Record why the decision made sense at the time

    A lightweight decision record should preserve the recommendation, assumptions, evidence, expected effect, owner, and review trigger. Its purpose is not to create an audit trail for blame. It is to make organizational learning possible.

    Without the original assumptions, a later review is distorted by hindsight. A good outcome can hide poor reasoning, while a bad outcome can follow a sound decision made with incomplete information. Evaluate the process and the result separately.

    Decision records also reveal patterns that coaching conversations miss. You may discover that a leader consistently underweights second-order effects, treats weak signals as conclusive, escalates too late, or avoids choices that create short-term metric pressure. That is actionable feedback because it concerns a repeatable reasoning pattern rather than one disputed answer.

    Shared metric definitions matter here. If product, sales, marketing, and customer success use different meanings for activation, retention, or expansion, their decisions can appear aligned while optimizing different realities. Define the metric, its data source, its owner, and the assumptions beneath it. Shared language reduces the amount of executive translation required at every cross-functional seam.

    Review variance without taking the decision back

    A review cadence can scale judgment, or it can quietly recreate centralized approval. The difference lies in what the meeting is designed to do.

    Monthly business reviews and quarterly business reviews should connect narrative to numbers. They should reveal whether assumptions still hold, where performance has deviated, who owns the response, and whether the deviation crosses an agreed threshold. They should not become ceremonies in which every team waits for an executive to rewrite its plan.

    I use variance as the cue for changing altitude. A stable system with credible owners deserves space. An existential risk, an unowned metric, or a conflict between the explanation and the data warrants a deeper dive.

    SignalLeadership responseWhat to avoid
    Metrics remain within agreed control limits and the owner explains the drivers crediblyStay at the outcome level and let the owner actRe-litigating tactics because you have a different preference
    A leading indicator departs from its expected rangeAsk for a focused diagnostic, owner, and next decision pointChanging the entire strategy before identifying the affected driver
    The narrative and the numbers conflictInspect definitions, data sources, assumptions, and causal reasoningAccepting a persuasive story without resolving the contradiction
    A material metric has no credible ownerClarify ownership before debating solutionsBecoming the permanent owner by default
    The downside could threaten the businessEnter the decision directly and make the risk explicitPreserving the appearance of delegation at the expense of accountability
    The same class of mistake keeps recurringRepair the decision mechanism and coach the reasoning patternCorrecting each incident as though it were isolated

    When you dive deep, tell the team why. Otherwise, a risk-based intervention can be interpreted as a permanent withdrawal of authority. Say which trigger fired, what part of the decision you are entering, and what authority the owner still retains.

    When you step back, do that explicitly too. Silence is ambiguous. The owner needs to know whether you trust the decision, missed the update, or expect another approval request.

    Run post-decisions, not blame sessions

    After meaningful evidence arrives, compare the result with the original decision record. Ask what happened, which assumptions held, which failed, what signal appeared first, and how the decision mechanism should change.

    Do not use the review to prove that your preferred option would have worked. That teaches leaders to protect themselves through escalation and excessive consensus. The useful output is a better assumption, threshold, driver tree, or decision right that improves the next choice.

    Grow authority as leaders demonstrate judgment

    Delegation should expand with evidence. A leader may begin by developing options and making a recommendation. As the leader demonstrates sound framing, timely escalation, and consistent tradeoffs, the role can move toward deciding within guardrails and then owning the domain with routine visibility rather than prior approval.

    The progression should depend on decision quality, not confidence, tenure, or presentation skill. Look for observable behavior:

    • The leader frames the decision around an outcome rather than a preferred deliverable.
    • The strongest alternatives are represented fairly before being rejected.
    • Assumptions are made explicit and matched to evidence.
    • Short-term gains are weighed against longer-term consequences.
    • Cross-functional effects are surfaced before they become escalation points.
    • Bad news moves upward early enough to preserve options.
    • Results and learnings are documented without defensiveness.
    • The leader improves the mechanism after a miss instead of merely promising more effort.

    This is where demanding and supportive leadership must coexist. Set an unambiguous bar for reasoning and ownership. Then provide fast feedback, coaching, access to context, and the resources required to meet that bar. High expectations without mechanisms create anxiety. Support without a clear bar creates dependence.

    Ask leaders to bring a proposed path with the problem, but do not turn that expectation into a penalty for early escalation. The useful behavior is: "Here is what changed, here is my current diagnosis, here are the options, and here is where I need help." Requiring a polished solution before escalation delays the moment when executive context is most valuable.

    Repeated escalations are diagnostic data. If capable people keep returning the same decision to you, inspect the system before questioning their courage. The constraint may be a disputed metric, incompatible incentives, an absent owner, an unclear strategic boundary, or a consequence they lack the authority to absorb.

    You should also inspect your own behavior. If you routinely reverse reasonable decisions without explaining the mental model, demand visibility that functions as approval, or punish a well-reasoned miss, the organization will rationally centralize around you.

    Know when the system is working

    A delegated decision system is becoming durable when priorities survive your absence, tradeoffs remain legible across functions, and teams escalate exceptions instead of routine choices. Leaders can explain not only what they decided but why the decision fits the strategy, metrics, time horizon, and risk boundaries.

    Your calendar should change as a consequence. Less time goes to status translation and habitual approvals. More time goes to strategy, architecture, resourcing, talent, and the small number of deviations that genuinely need executive attention.

    Start with one recurring decision that currently waits for you. Name its owner, write the minimum decision contract, define the escalation triggers, and schedule a review around evidence. Then resist the urge to improve the decision by taking it back. Improve the system that produced it.

    References

    • Shivam.Consulting Blog — Mastering 30,000-Foot Vision and Ground-Level Execution: Systems That Decide Without You
  • Stop Groupthink in Hiring: Proven Product-Led Tactics to Make Faster, Fairer Decisions

    Stop Groupthink in Hiring: Proven Product-Led Tactics to Make Faster, Fairer Decisions

    Is hiring broken—or just badly designed? I’ve been sitting with that question after a recent conversation that crystallized what I see across product organizations: AI-fueled application overload, sprawling interview loops, and fuzzy criteria that invite groupthink at exactly the wrong moments. If you’ve ever watched a promising candidate stall out late in the process, you’re not alone. Listen to this episode on: Spotify | Apple Podcasts.

    Here’s the reality I’m observing in the market: Layoffs and hiring freezes have flooded the funnel, while AI tools make it trivial to submit hundreds of applications. Companies are overwhelmed, so they respond by adding more interviews and more stakeholders, hoping more touchpoints equal better signal. In practice, that complexity often dilutes accountability and increases noise—especially for product management leadership roles where clarity, not consensus theater, determines success.

    I’ve seen too many offers derailed by “one last step.” A candidate clears every structured interview, then a casual lunch or unframed panel suddenly becomes the deciding factor. The team isn’t briefed on what to evaluate, one lukewarm comment lands, and group dynamics cascade into a no-hire. That’s not rigor—it’s randomness masked as prudence.

    Groupthink ≠ good hiring decisions. When everyone has veto power, risk-averse no-decisions become the default. Focus-group-style interviews create bias, not signal, and “culture fit” often becomes a proxy for stereotyping or personal preference. As product leaders, we’d never ship a feature based on vibes; we shouldn’t make high-stakes hiring calls that way either.

    There’s a better way—and it mirrors how we run great product discovery. Define who you’re hiring before writing the job description. Set clear success metrics for the role. Assign each interviewer specific criteria to evaluate. Treat hiring like product discovery: intentional, structured, and evidence-based. In my teams, that looks like tight scorecards, interviewer calibration, and a decision owner who synthesizes evidence—not a popularity contest where the loudest voice wins.

    Chemistry checks still matter, but only when we define what collaboration actually means for the role. Introversion, debate style, or lunch-table small talk are not performance indicators. I look for behaviors we value in empowered product teams—clarity of thinking, healthy dissent, co-creation under constraints—often via a real working session with the future product trio. Diverse teams outperform homogenous ones, even if not everyone “vibes,” so I optimize for complementary strengths over sameness.

    If you’re a candidate, remember: When a process feels broken, it’s often not about you. Ask how you’re being evaluated to gauge process maturity; a thoughtful team will happily walk you through their rubric and what great looks like. For structure and support, I’ve seen “Who: The A Method for Hiring” help leaders clarify requirements; “Never Search Alone” and joining a Job Search Council (JSC) can give you peer accountability and sharper narratives. For current openings, I regularly point PMs to Scott Baldwin’s PM job postings on LinkedIn.

    My challenge to fellow product leaders: Audit your hiring process the way you’d audit your roadmap. Where are decisions getting stuck? Where are you over-indexing on consensus and under-indexing on evidence? Tighten the criteria, streamline stakeholders, and instrument the funnel so you can learn and improve. The payoff is faster, fairer, more confident decisions—and teams that reflect the rigor we expect in product strategy and stakeholder management.

    What’s one change you can make this week—reworking the scorecard, calibrating interviewers, or replacing an unstructured lunch with a real collaboration exercise? Small improvements compound. Let’s build hiring systems that are worthy of the talent we’re trying to attract.

    Inspired by this post on Product Talk.

    Book a consult png image
  • Year-End Reflection for Product Leaders: Values, Themes, and the 100‑Wishes Reset

    Year-End Reflection for Product Leaders: Values, Themes, and the 100‑Wishes Reset

    I’ve been closing the year with a deliberate reflection ritual for more than a decade, and this season I found fresh energy for it after listening to an insightful conversation with Teresa Torres and Petra Wille on All Things Product. Their approaches mirror the evolution many product leaders experience: moving from rigid annual goal-setting to values-led themes, longer time horizons, and a healthier respect for spaciousness. In my own practice, that shift has created better focus, less pressure, and far more meaningful outcomes.

    Prefer to listen? You can find this episode here: Spotify | Apple Podcasts. I took notes with my team in mind and translated the discussion into a simple, values-driven framework that any product organization can adopt.

    Why does annual reflection matter for product people? Because our work lives at the intersection of ambiguity, trade-offs, and time. If we only measure ourselves by shipped output or quarterly OKRs, we overlook the compounding value of learning, relationships, and judgement. I treat this ritual as a strategic reset: a chance to surface patterns, adjust expectations, and recommit to outcomes over output.

    My own reflection habit started scrappy—paper notebooks, messy timelines, and even artful visualizations inspired by Dear Data by Giorgia Lupi & Stefanie Posavec. Like Petra, I’ve found that tactile, analog artifacts unlock insights I miss in a spreadsheet. Over time, I’ve kept the spirit and simplified the mechanics: a “what went well” review, a short list of hard lessons, and a handful of decisions that paid off—or didn’t.

    The biggest evolution for me has been moving from rigid annual goals to values and themes. I still run OKRs, but I use them to track progress, not identity. The lens of process vs. outcome goals—reinforced by ideas from Atomic Habits—helped me set fewer, better commitments. For example, instead of “launch X by Y,” I’ll emphasize the cadence of customer discovery, the health of the product trio, and the quality of decisions made along the way.

    One exercise that changed my practice is the “100 wishes” list. It’s powerful—and surprisingly difficult. Pushing past 30 or 40 wishes forces me to name latent interests and long-range intentions I rarely say out loud. Combined with decade-level themes, the list helps me balance ambition with patience. I don’t try to do it all next year; I use it to spotlight direction, not deadlines.

    I also review patterns across years: Where did over-scheduling create hidden costs? When did I protect focus time and what did that unlock? Paul Graham’s Maker’s Schedule, Manager’s Schedule remains a useful calibration tool here. And when I feel the pull toward constant throughput, I revisit Stefan Sagmeister’s The Power of Time Off (TED Talk) to remind myself why strategically creating space often yields the most valuable ideas.

    Of course, not every year follows plan—and that’s normal. Reflection helps me spot unrealistic expectations early and let them go. When setbacks hit, I’ll rewatch Dealing with Setbacks and re-ground in continuous discovery. The question isn’t “Did we do everything?” but “Did we learn fast, protect customer value, and make trade-offs aligned with our values?” That’s how empowered product teams compound impact.

    My sharing philosophy has become more nuanced over time. Some reflections are public to invite dialogue and accountability; others stay private so I can process honestly. I’ve found it helpful to publish what I’m saying no to, capture a theme for the year ahead, and keep the rest for myself and my team. This balance preserves motivation while still contributing to the broader product management leadership community.

    If you’re designing your own ritual, consider this lightweight flow: review wins and tough calls, write your “100 wishes,” extract a few values-based themes, then translate those into process goals for Q1. Revisit monthly, not just annually. If you like structured prompts, Chris Guillebeau’s How to Conduct Your Own Annual Review from The Art of Nonconformity offers a practical template you can adapt to your context.

    For deeper dives and complementary ideas, I bookmarked these as part of my year-end reset: What I’m Saying No to This Year—And Why, Ask Teresa: My Leaders Still Want Roadmaps with Timelines—What Should I Do?, Scaling Impact: A Look at the Year Ahead (2022), Let’s Connect in 2025: A Look at the Year Ahead, The Interview Coach, and Petra’s own year-ahead reflections (here and her 2026 version). I also recommend revisiting the prior conversation on leadership and change: Role of Leadership in Transformations.

    I’d love to hear how you approach your end-of-year reflection. What questions bring you the most clarity? Which practices help you set an intentional, values-driven path for the next year? Share your process—I’m always looking to learn from other product creators and leaders.

    Inspired by this post on Product Talk.

    Book a consult png image
  • Long-Horizon Company Building: How to Operate for Decades

    Long-Horizon Company Building: How to Operate for Decades

    You are looking at a roadmap full of credible near-term work, yet none of it seems likely to change your company’s position. The team is busy, customers are asking for improvements, and every investment has a reasonable explanation. What is missing is a clear connection between today’s choices and the company you want to become.

    Long-horizon company building solves that problem only when it changes how you allocate capital, sequence capabilities, learn from customers, and stop work. A 25-year ambition is not permission to wait longer for results. It is a decision filter that helps you distinguish compounding investments from activity that merely fills the next planning cycle.

    Choose a problem that becomes more defensible with time

    Not every company should play a decades-long game. Time does not rescue weak demand, an undifferentiated product, or a market whose underlying problem is disappearing. A long horizon is useful when the work required to serve customers creates assets that become more valuable as they accumulate.

    Before you commit to a long-horizon strategy, test the problem against a few concrete conditions:

    • The pain is structural. Customers are constrained by an enduring workflow, infrastructure dependency, procurement model, or service failure. The opportunity does not depend entirely on a temporary technology cycle.
    • Frustration and switching costs are both high. Switching costs alone protect incumbents. Frustration alone can produce shallow demand for a convenient feature. When customers are dissatisfied but cannot change easily, a substantially better end-to-end experience can open a durable market.
    • The solution requires cumulative capability. Reliability knowledge, operational data, installation expertise, distribution, hardware, service operations, or customer trust should improve with continued use. If a new entrant can reproduce your advantage quickly, waiting longer will not make the business stronger.
    • The first product creates credible adjacencies. Expansion should follow the same customer, capability base, or service promise. A list of unrelated markets is not a platform strategy.
    • The customer outcome can support the business model. The way you charge should reinforce the result customers buy, rather than reward complexity they would prefer to avoid.

    The sharpest test is simple: explain why the company should be structurally better after years of serving customers. Your answer must identify a mechanism. More telemetry may improve diagnosis. More deployments may reduce installation risk. Deeper workflow integration may increase the value of adjacent services. Trust may lower the friction of adopting the next product. Merely having more customers or more features is not enough.

    A useful thesis takes this shape: for a specific customer, a costly problem will persist because of a structural constraint; repeatedly building a named capability will improve a defensible advantage; controlling certain interfaces is necessary to deliver the promise; and observable evidence will tell you when the thesis is weakening.

    If you cannot complete that logic without relying on market size, ambition, or executive conviction, you do not yet have a long-horizon strategy. You have a long-range hope.

    Convert a 25-year belief into present-day decisions

    A decades-long horizon should not produce a decades-long roadmap. The farther out you look, the less credible feature-level precision becomes. Preserve the direction while making the route explicitly revisable.

    Separate your strategy into three layers:

    • Enduring commitments: the customer you serve, the problem you believe will remain important, the experience you intend to make possible, and the principles you will not trade away casually.
    • Revisable hypotheses: the product architecture, distribution motion, ownership boundary, pricing model, and capability sequence that currently appear most likely to deliver the promise.
    • Disposable work: features, prototypes, internal systems, campaigns, and implementation choices. These deserve no protection beyond the evidence they produce.

    This separation prevents two common errors. The first is strategic thrashing: changing the destination whenever a current bet disappoints. The second is strategic stubbornness: defending a failed implementation because it has been wrapped in the language of mission.

    Meter provides a useful example of the distinction. The company maintained its commitment to a full-stack networking service while spending more than four years in early research and development. It also discarded about a year of operating-system work. The durable thesis survived; a costly implementation did not. That is what conviction looks like when it remains accountable to learning.

    At each planning cycle, require every major initiative to answer four questions: Which lasting capability will this build? What customer evidence should it produce? What finding would cause you to reshape or stop it? What are you deliberately declining so the investment receives enough attention?

    The stop condition matters most. Without one, patient capital quietly becomes protected capital. Teams learn to explain delays instead of testing assumptions. Write the condition while enthusiasm is high, before sunk costs and personal identity enter the decision.

    Key takeaways

    • Use a long horizon to define durable commitments, not detailed forecasts.
    • Fund work that compounds a named capability or reduces a consequential uncertainty.
    • Protect the customer problem and company promise, not the current implementation.
    • Give every major bet observable evidence and an explicit stop condition.
    • Treat abandoned work as a valid strategic outcome when it prevents a larger misallocation.

    Own only the stack required to keep the promise

    Vertical integration is neither inherently bold nor inherently wasteful. It is justified when a layer you do not control repeatedly prevents you from delivering the outcome customers believe they purchased.

    Start with the promise, not the architecture. Map the complete path from customer intent to customer outcome:

    • How the customer evaluates and buys the product
    • How the product is installed, configured, and activated
    • Which interfaces determine performance and reliability
    • What telemetry reveals failure before or after the customer notices
    • How support diagnoses and resolves a problem
    • Which service commitment makes the outcome commercially credible

    Mark every point where an external dependency can break the promise. Then ask whether tighter integration would materially improve the experience and whether the capability will compound across customers or future products. Own a layer when both answers are strong. Keep partnering when the dependency is replaceable, the layer is genuinely commodity-like, or internal ownership would add cost without improving the customer outcome.

    This prevents full-stack ambition from turning into organizational vanity. Building hardware, software, installation operations, support tooling, and service delivery at once creates many ways to fail. The burden of proof belongs with the added ownership. Each new layer should remove a specific failure mode, improve a measurable part of the promise, or unlock a strategically important product that would otherwise remain impossible.

    Physical-product teams should also treat geography as part of the operating design. When design, manufacturing, and iteration depend on one another, physical proximity can compress feedback loops. Meter used Shenzhen in this way during its development. The general lesson is not that every hardware company needs the same location. It is that organizational geography should follow the bottleneck: put the people making interdependent decisions close enough to learn at the speed the product requires.

    The business model belongs in the same analysis. If customers want an outcome but must assemble vendors, equipment, installation, and support themselves, packaging the complete experience as a service can reduce complexity and clarify accountability. Service commitments then become part of the product, not language added after the product is built. The company earns recurring revenue by continuing to deliver the outcome, which aligns incentives more closely than a transaction that ends when equipment changes hands.

    Distribution should reinforce learning during the early stages. A direct sales motion gives product and commercial leaders access to the buyer’s language, objections, procurement constraints, implementation concerns, and definition of value. That access is especially important when you are trying to establish seller-market fit: the ability to identify the right buyer, explain the value consistently, navigate the buying process, and deliver what was sold.

    Before adding channel distance, verify that target buyers recognize the same problem, objections fall into understandable patterns, sales commitments survive the implementation handoff, and the economics support the promised service. A channel can scale a repeatable motion. It cannot repair one that the company does not yet understand.

    Replace planning theater with a customer-learning system

    Removing OKRs does not create focus. It removes one alignment mechanism. If you do not replace it with a visible decision system, priorities will depend on executive proximity, persuasive storytelling, and whichever escalation arrived most recently.

    A lightweight operating system still needs a few explicit artifacts:

    • A strategic narrative: the customer problem, the long-horizon thesis, the current constraint, and the choices the company is making because of them.
    • A primary customer-value measure: evidence that the promised outcome is actually occurring, not merely that work shipped.
    • Guardrails: reliability, service, economics, or trust conditions that must not deteriorate while the primary outcome improves.
    • An unhappy-customer ledger: a shared record of broken promises, stuck use cases, escalations, and gaps between what was sold and what was delivered.
    • A decision log: the assumption behind each consequential choice, the evidence available at the time, the owner, and the condition for revisiting it.

    The unhappy-customer ledger is often more useful than another aggregate dashboard. A satisfaction score compresses many experiences into one number. An escalation exposes the precise boundary where your product, service, sales process, or ownership model failed.

    For every serious case, capture the customer’s intended outcome, the point at which progress stopped, the expectation that was violated, the immediate resolution, and the systemic change required. Classify that change as product, operations, sales, support, or ownership-boundary work. Then look for recurring failure modes across cases.

    Do not let this become a larger support queue. Closing the individual ticket is necessary, but the strategic value comes from removing the class of failure. If customers repeatedly struggle during installation, the answer may be a better workflow, different telemetry, a narrower promise, or ownership of an interface that has been treated as someone else’s problem.

    This system also clarifies empowerment. A product team should know the outcome it owns, the constraints it must respect, the decisions it can make independently, and the conditions that require escalation. Empowerment without a clear outcome produces local optimization. Authority without proximity to customer evidence produces slow, brittle decisions.

    The same clarity applies to performance problems. A company cannot preserve a long horizon while allowing unresolved role or behavior gaps to consume the team’s attention. Define the gap, the expected standard, the support available, the decision owner, and the process for reaching a fair conclusion. Move quickly toward clarity, while still following the appropriate people process. Delayed ambiguity is not patience.

    Make patience accountable in your next strategy review

    Long-horizon work will contain periods when visible output understates real progress. Research, infrastructure, reliability, manufacturing, and operational design may need to mature before customers see the complete benefit. The leadership challenge is to distinguish that legitimate incubation from drift.

    Patience is working when the core customer thesis remains supported, important uncertainties are being resolved, a reusable capability is getting stronger, and customer failures are becoming better understood or less frequent. The dates may move, but the quality of evidence improves.

    Drift looks different. Milestones move without producing new knowledge. Teams defend work by describing its difficulty or the effort already invested. The same customer failures return without a systemic response. Adjacent products receive attention before the original promise is dependable. Leadership keeps adding resources because it has not defined what would justify stopping.

    Review the portfolio by decision, not by project status. Continue work that compounds a necessary capability. Reshape work when the thesis remains sound but the current method is failing. Stop work whose original assumption no longer holds. Keep adjacent opportunities separate until the core business has earned the capacity to pursue them.

    You can run the review with the following sequence:

    1. Write the customer promise in language a buyer would recognize.
    2. Name the structural reason the problem should remain worth solving.
    3. Identify the capability that should become more valuable as the company learns.
    4. Map the interfaces, operations, and commercial dependencies that can break the promise.
    5. Examine recent unhappy-customer cases for repeated failure modes.
    6. For every major investment, write the evidence expected and the condition that would cause a change of course.
    7. Remove work that neither improves the current promise nor builds a required future capability.
    8. Assign the next consequential decision to a named owner with access to the relevant customer evidence.

    Do not leave that review with a more elaborate long-range deck. Leave with fewer bets, clearer ownership, explicit learning goals, and at least one piece of work you are prepared to stop.

    At your next planning meeting, ask which current investment will make the company structurally better at solving its chosen problem. If nobody can name the capability, the evidence, and the customer promise it serves, pause the work before time turns activity into strategy by accident.

    References

    • Shivam.Consulting Blog — Playing the 25-Year Game: Rethinking Networking, Ditching OKRs, and Owning the Full Stack
  • From KPIs to Comebacks: How I Lead Through Setbacks with Curiosity, Care, and Discovery

    From KPIs to Comebacks: How I Lead Through Setbacks with Curiosity, Care, and Discovery

    Setbacks are the tax we pay for doing meaningful product work. As a VP of Product Management, I’ve learned that what separates resilient teams from the rest isn’t a lack of failures—it’s how we metabolize them. This episode of All Things Product with Teresa Torres and Petra Wille is a powerful reminder that recovery, reflection, and rigorous product discovery are as essential as speed and execution.

    Listen to this episode on: Spotify https://open.spotify.com/episode/10LYRya7boYJBHTYBnE79E?ref=producttalk.org | Apple Podcasts https://podcasts.apple.com/kh/podcast/dealing-with-setbacks/id1794203808?i=1000737190520&ref=producttalk.org

    What struck me most is how Teresa shares a deeply personal story about her long recovery from an injury—and how that journey mirrors the nonlinear reality of product development. In product, just like in healing, progress is rarely a straight line. We have surges, stalls, and moments that feel like reversals. Yet with the right mindset and rituals, we still move forward.

    Professionally, we all face moments when your product fails to move a single KPI, when a launch falls flat, or when you just feel stuck. I’ve been there—in quarterly reviews, post-launch standups, and board prep. The instinct is to sprint straight into solutions. The wiser move is to respond with curiosity, emotional honesty, and resilience, then re-engage our discovery habits with intention.

    If you’re a PM, designer, or researcher, consider this an invitation to rebalance. Recovery and reflection are just as important as velocity and success. That’s not soft talk—it’s how empowered product teams build durable performance without burning out.

    On the emotional reality of setbacks, I’ve learned to normalize naming the loss. We put immense pressure on ourselves, and it’s okay (and necessary) to grieve product failures. When we acknowledge the disappointment, we regain the ability to observe clearly—and to learn.

    Leaders play a crucial role here. I create space for teams to recover before jumping into post-mortems. We don’t whiteboard over feelings; we schedule time for decompression, then conduct a crisp, blameless review. That sequencing transforms the quality of insights and strengthens psychological safety.

    Another lesson that resonates is the danger of tying performance too tightly to outcomes. Outcomes matter, but they are lagging indicators influenced by many externalities. I evaluate performance on behaviors: clarity of problem framing, rigor in discovery, quality of decision-making, and stakeholder alignment. This aligns with outcomes vs output OKRs and keeps us focused on controllable excellence.

    How do we build resilience? Continuous discovery builds resilience by normalizing failure. When we test assumptions routinely with customers and data, we turn large, risky bets into a series of small, learnable steps. Teams recover faster because failure becomes feedback—frequent, cheap, and informative.

    For perspective, I often use the 10–10–10 framework (from Decisive by Chip & Dan Heath). I ask: How will this setback feel in 10 minutes, 10 months, and 10 years? The answers de-escalate urgency, expand our time horizon, and produce better, calmer decisions.

    Here are the key takeaways I’m carrying forward. Setbacks are not just inevitable—they’re part of doing meaningful product work. Giving teams time and space to process failure builds long-term resilience. Mourning losses is just as important as celebrating wins.

    Healthy discovery cultures embrace reflection, psychological safety, and emotional honesty. And most importantly, staying consistent with discovery habits helps teams recover faster and learn more deeply.

    Notable moments that stood out for me include: [00:02:00] Teresa shares the story of her injury and what it’s taught her about patience and setbacks. The parallel to product cadence is both humbling and motivating.

    [00:10:00] Petra talks about a team whose carefully planned launch didn’t move a single KPI. I’ve led similar debriefs; when we anchor on customer insight gaps rather than blame, the next iteration improves dramatically.

    [00:20:00] Discussion on allowing space for grief and frustration after failure. In my teams, we time-box “emotional processing” before we enter analysis mode—it humanizes the work and sharpens the learning.

    [00:30:00] Why organizations must decouple performance reviews from short-term outcomes. I align evaluations to strategy execution quality, hypothesis discipline, and cross-functional collaboration.

    [00:40:00] How continuous discovery can help teams normalize—and even learn to appreciate—setbacks. When discovery is weekly, momentum becomes self-healing.

    If you want to dig deeper, here are useful links from the episode. Follow Teresa Torres: https://ProductTalk.org

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

    Mentioned in the episode: Decisive by Chip & Dan Heath — The 10–10–10 framework for perspective in decision-making https://heathbrothers.com/books/decisive/?ref=producttalk.org

    Teresa Torres’ Continuous Discovery Habits — Building resilience through ongoing discovery practices. https://www.amazon.com/Continuous-Discovery-Habits-Discover-Products/dp/1736633309?dchild=1&keywords=continuous+discovery+habits&qid=1621385051&sr=8-2&linkCode=sl1&tag=teresatorres-20&linkId=34bc439ac78da06e1398f7bf069b219e&language=en_US&ref_=as_li_ss_tl&ref=producttalk.org

    Join the Conversation: Have thoughts on this episode? Leave a comment below. I’d love to hear how you create space for recovery while sustaining product velocity.

    Full Transcript: Full transcripts are only available for paid subscribers.

    Inspired by this post on Product Talk.

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

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

    I’ve spent my career building products and teams that I intend to steward for the long haul, and I’m drawn to founders who treat company-building as a craft you can practice forever. In this analysis, I break down a journey that crystallizes what it takes: going from a teenage wholesale hustle to an API-first healthcare clearinghouse, and in the process, learning why execution isn’t a moat, why venture capital is “going pro,” and how “eating glass” can become a durable advantage.

    Here’s the arc that anchored my thinking: a founder who, at 16, turned $2,500 into a wholesale empire; later bootstrapped a wildly profitable auto-parts business; then sold it to tackle “the most complicated problem” he’d ever encountered: business-to-business transaction exchange. He spent years building EDI infrastructure, threw away the entire codebase eight times, and found extraordinary traction in healthcare. The company recently raised a $70M Series B co-led by Stripe and Addition. The throughline is a consistent, high-agency approach to product management and go-to-market strategy, guided by first principles decision making.

    The first customer is often the trickiest—not because demand doesn’t exist, but because the product’s value proposition, points of parity, and competitive differentiation are still coalescing. I push teams to do founder-led GTM early, speak in the user’s language, and orchestrate high-signal conversations that expose real switching costs. That’s how we avoid mistaking polite interest for product-market fit.

    Bootstrapping forces rigor, but it also means being “constrained by capital.” There’s a ceiling to the speed at which you can iterate, validate, and scale. Venture capital, in the right context, is like “going pro”: you trade a bit of optionality for time, talent density, and a faster feedback loop. I often see confusion between ownership vs. control; structurally, you can design for alignment while still moving with the urgency a competitive market demands.

    One theme I return to with my own teams: execution is never actually a moat. Processes can be copied. Culture can be mimicked superficially. What can’t be easily replicated is the willingness to do the unglamorous, compounding work—what the founder here called “eating glass.” It’s the daily discipline of simplifying the system, instrumenting the edge cases, and standing up operational excellence that compounds into true competitive differentiation.

    When product-market fit hits in enterprise infrastructure, it can feel like “the snake swallowing a deer.” Capacity, process, and architecture are stretched to their limits all at once. I’ve experienced the same pattern: everything slows down so the organization can re-architect for scale. The trick is to make those constraints visible—measure service levels, queuing, and error budgets like you would in a production system—so you’re not flying blind.

    Some of the strongest product-management instincts I’ve seen borrow from discount retail and Toyota. From discount retail, we learn to obsess over unit economics, operational throughput, and ruthless simplification. From the Toyota production system, we adopt Kanban / TPS (Toyota), continuous improvement, and respect for constraints. In software terms, this becomes fast deployment frequency, small batch sizes, and defect prevention at the source—because “All software is a cascade of miracles.”

    Scaling decision-making is where most teams stall. I favor clear ownership, lightweight written narratives, and a bias for first principles decision making over committee compromise. That structure lets high-agency individuals move quickly while keeping cross-functional stakeholders aligned on outcomes vs output OKRs. It’s how you build empowered product teams without sacrificing focus.

    Hiring is where philosophy becomes practice. I resonate with the onboarding mantra “everything’s your fault now”—not as blame, but as an invitation to own outcomes end to end. I look for high-agency people who demonstrate systems thinking and the capacity to simplify. Manager hiring should lag role clarity; bring in managers when coordination overhead is the limiting factor, not when it merely feels uncomfortable.

    Longevity comes from founder-approach fit as much as product-market fit. Build a company you don’t want to leave by aligning operating cadence, decision rights, and cultural norms with how you actually work best. Maintain conviction in unconventional practice when the evidence supports it, while remembering that “Reality has a surprising amount of detail.” The more I zoom in on the real work—interfaces, edge cases, workflows—the more the right design emerges.

    In healthcare EDI, that realism matters. HIPAA overview (HHS) sets the compliance baseline. Payer integrations with Aetna, Blue Cross Blue Shield, and Cigna demand reliability and deep domain fidelity. Cloud and back-office ecosystems—from AWS and NetSuite to Slack, Microsoft Teams, Zapier, and Clay—shape the surrounding workflow. Lessons from Amazon, Target, Walmart, and Costco inform operational rigor; supply chain analogies from Ford Motor Company and GM clarify interface contracts. Porter’s five forces helps frame market structure; perspectives from Jeff Bezos and Peter Thiel sharpen strategic posture.

    If you’re building for the long run, here’s the blueprint I use with product leaders: validate painfully specific jobs-to-be-done before you scale; prefer founder-led GTM until messaging closes the intent-to-adoption gap; instrument throughput and quality like a production system; invest in people who treat ambiguity as a chance to lead; and don’t confuse speed with hurry. When the “snake swallowing a deer” moment arrives, re-architect deliberately, protect your margins, and let operational excellence carry you from product discovery to durable product-led growth.

    References and resources: Aetna: https://www.aetna.com/, Amazon: https://www.amazon.com/, AWS: https://aws.amazon.com/, Blue Cross Blue Shield: https://www.bcbs.com/, Change Healthcare: https://www.changehealthcare.com/, Cigna: https://www.cigna.com/, Clay: https://www.clay.com/, Costco: https://www.costco.com/, Ford Motor Company: https://www.ford.com/, GM: https://www.gm.com/, HIPAA overview (HHS): https://www.hhs.gov/hipaa/index.html, Jeff Bezos: https://x.com/JeffBezos, Kanban / TPS (Toyota): https://global.toyota/en/company/vision-and-philosophy/production-system, Microsoft Teams: https://www.microsoft.com/microsoft-teams, NetSuite: https://www.netsuite.com/, O’Reilly Auto Parts: https://www.oreillyauto.com/, Peter Thiel: https://x.com/peterthiel, Porter’s five forces: https://www.isc.hbs.edu/strategy/pages/the-five-forces.aspx, “Reality has a surprising amount of detail”: https://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail, Slack: https://slack.com/, Stedi: https://www.stedi.com/, Summit Racing: https://www.summitracing.com/, Target: https://www.target.com/, Walmart: https://www.walmart.com/, Zapier: https://zapier.com/

    Book a consult png image
  • From Walls to Bridges: How I Unite Siloed Teams and Eliminate the Illusion of Work

    From Walls to Bridges: How I Unite Siloed Teams and Eliminate the Illusion of Work

    I’ve seen what happens when talented teams drift into silos: priorities splinter, timelines slip, and what looks like progress turns out to be motion without momentum. My job is to turn those walls into bridges—aligning product, engineering, design, and go-to-market around outcomes that matter to customers and the business.

    For siloed teams, walls go up, and unnecessary work gets done. Learn the signs, the damage, and the way to break free from the illusion of work.

    The signs show up early if you know where to look: duplicated efforts across squads, decision-making that bounces between functions, roadmap debates grounded in opinions rather than data, and “busy” sprints that ship outputs without measurable outcomes. These are classic stakeholder management breakdowns, often masked by perfect decks and full calendars.

    The damage is real. Customers feel friction and inconsistency, product-market fit signals get missed, and we over-invest in features that don’t drive user activation or retention. Morale takes a hit as teams lose the thread of purpose. That’s the “illusion of work” in action—activity that crowds out impact.

    Here’s how I build bridges. First, I organize around empowered product teams and product trios (product, design, engineering) who own customer outcomes, not just velocity. We practice first principles decision making, write decisions down, and align early with adjacent functions so there are no surprises when we move from product discovery to delivery.

    Second, I anchor planning in outcomes vs output OKRs. We commit to a small set of measurable outcomes, then use QBRs vs OKRs cadences to inspect progress, cut scope that doesn’t move the needle, and recalibrate with clarity. This shifts the conversation from “What did we ship?” to “What changed for customers and the business?”

    Third, I make impact measurable and visible. We instrument the funnel end to end, define a minimum detectable effect (MDE) for experiments, and use A/B testing to de-risk bets before we scale them. A unified analytics platform—with Amplitude analytics, Pendo, Intercom, and HubSpot tied back to our CRM integration—keeps everyone looking at the same truth so we can diagnose what’s working and what’s noise.

    Fourth, I bring collaboration into the core rituals: transparent product roadmapping and sprint planning, weekly cross-functional reviews, and fast, lightweight artifacts that clarify hypotheses, success metrics, and trade-offs. By the time we launch, stakeholders already understand the why, the how, and the expected impact.

    If parts of your organization feel stuck, start small: pick one shared outcome, form a cross-functional trio, define your leading indicators, and run one experiment with clear MDE and a two-week readout. The momentum you create will turn walls into bridges—and busywork into business results.

    Inspired by this post on Product School.

    Book a consult png image
  • How I Decode Founder Advice: Lessons from Thumbtack CEO Marco Zappacosta on Boards, Time, and Trust

    How I Decode Founder Advice: Lessons from Thumbtack CEO Marco Zappacosta on Boards, Time, and Trust

    I recently dug into a conversation with Marco Zappacosta, co-founder and CEO of Thumbtack, who has spent the last 13 years building the company into a billion-dollar business — and it’s his first and only job after graduating college. As someone who lives at the intersection of product management leadership and company-building, I was struck by how deliberately he navigates the deluge of advice that comes with being a first-time founder.

    What resonated most was the way he differentiates between moments that demand a return to first principles and those that benefit from a tested playbook. In my own practice, I’ve found that product strategy and organizational design often require first-principles thinking, while operational cadence and execution rituals tend to scale best with proven patterns. The key is recognizing which game you’re playing — invention versus optimization — and applying the right mental models to filter input without losing velocity.

    Marco’s approach to parsing counsel as a first-time CEO is refreshingly pragmatic. Rather than treating advice as binary, he triangulates from multiple data points, looks for invariants, and pressure-tests assumptions against the company’s unique context. I use a similar lens: anchor on the problem, map potential solutions to risk/return, and calibrate decisions with base rates where possible. It’s a disciplined way to turn a mountain of opinion into actionable signal — especially when stakes are high.

    He also connects this discipline to stakeholder management, particularly in how he runs Thumbtack’s board so quarterly meetings become a critical resource, not just a time suck — and why he shares the board deck with the entire company. I’ve found this level of transparency to be a force multiplier: it aligns teams on priorities, elevates product roadmapping and sprint planning, and empowers leaders to make trade-offs with clarity. When the narrative is shared, accountability scales.

    Marco candidly reflects on Thumbtack’s COVID-related layoff last year, and what he specifically did as CEO to ensure the folks who remained still had confidence in the company and his leadership moving forward. In hard moments like these, consistent communication, explicit prioritization, and a clear framework for decision-making matter more than ever. Trust is built by showing your work — why choices were made, what changes now, and how success will be measured.

    Finally, he opens up his playbook for choosing what to spend his time on as a busy CEO with only so many hours in the day — and perhaps more importantly, how he stays accountable for these priorities. I’ve learned to pair outcome-oriented OKRs with a ruthless weekly schedule audit: if the calendar doesn’t reflect the strategy, the strategy won’t happen. This discipline creates focus, accelerates learning loops, and keeps leaders from becoming the bottleneck.

    For builders at any growth stage, there’s a powerful takeaway here: cultivate a repeatable way to distill advice, clarify when to use first principles versus a playbook, operationalize board relationships as strategic assets, and turn time into your sharpest instrument. The result is a more resilient company — and a leadership practice that compounds.

    Inspired by this post on First Round.

    Book a consult png image