When I push our organization to adopt the product operating model, I’m emphasizing a foundational shift—from “shipping roadmaps of features (output)” to solving real customer and business problems, measured by “business results (outcomes)”. That’s the difference between activity and impact, and it’s the only way to build durable value at scale.
This change inevitably reaches beyond the product organization. It reshapes how company stakeholders in Sales, Marketing, Customer Success, Finance, Legal, Security, and Operations engage with product teams, and it reframes what they expect from us. Instead of asking, “When will feature X ship?” they learn to ask, “How will we move the outcome that matters?”
In practice, the product operating model is a contract: product teams commit to outcomes, and stakeholders commit to partnership. That partnership means we co-own the problem, align on evidence, and share accountability for results. The reward is clarity—everyone sees how their work ladders to strategy and why the sequence of work makes sense.
Here’s how I align stakeholders around this model. First, I ground everything in outcomes vs output OKRs. We replace feature roadmaps with a clear strategy, prioritized problems, and measurable objectives. Our product roadmapping and sprint planning then serve the objectives—not the other way around—so capacity is allocated to the highest-leverage bets.
Second, I build empowered product teams around product trios (product, design, engineering). We practice continuous discovery with stakeholders: we share opportunity trees, test riskiest assumptions early, and bring partners into research when it informs go-to-market strategy, pricing, or enablement. This keeps us honest and avoids late-stage surprises.
Third, I establish operating rhythms that make outcomes visible. Monthly stakeholder reviews focus on progress toward objectives and what we’re learning—not status theater. Quarterly, we connect OKRs to business performance so leaders can see the throughline from discovery and delivery to pipeline, retention, or margin. If priorities shift, we renegotiate objectives explicitly.
Fourth, I define metrics that stakeholders trust. We use a balanced set of leading indicators (activation, engagement, cycle time) and lagging indicators (revenue, retention, unit economics). We socialize definitions early so no one debates the scoreboard mid-game. The result: faster decisions and less “data whiplash.”
Fifth, I invest in change management. Moving from outputs to outcomes can feel threatening if your success has historically been measured by launch volume or roadmap commitments. I address this head-on with training, transparent comms, and clear decision rights. The message is simple: outcomes create more autonomy for empowered product teams and more predictability for stakeholders.
At HighLevel, this approach has been especially powerful when cross-functional dependencies are high. For example, when we set an objective to improve user activation for a new CRM integration, we didn’t promise a bundle of features. We committed to a measurable lift in activation and a shorter time-to-value, co-owned with Customer Success and Marketing. That alignment unlocked smarter experiments, tighter enablement, and a more credible launch narrative.
The anti-patterns are predictable: treating OKRs as a renaming of the roadmap, equating discovery with indecision, or isolating product decisions from go-to-market strategy. The cure is equally consistent: bring stakeholders into discovery, attach every bet to an objective, and show progress with evidence—not just demos.
Ultimately, the product operating model is a leadership choice. It asks us to trade certainty theater for learning velocity, and feature checklists for business impact. When stakeholders see that shift pay off—in faster cycles, clearer priorities, and results that matter—support for the model moves from compliance to conviction.
I’ve spent years helping talented engineers explore what’s next when pure coding no longer feels like the only—or best—path. From hiring across cross-functional teams to mentoring career pivots, I’ve seen firsthand how engineering strengths translate into high-leverage roles that shape product, strategy, and growth.
Software engineers have alternative career options leveraging their skills in roles like product manager, data scientist, business analyst, and 22 more.
When an engineer moves into product management, they’re not starting from scratch—they’re redirecting problem-solving, systems thinking, and customer empathy toward outcomes. In practice, that means mastering product discovery, strengthening stakeholder management, and getting fluent in product roadmapping and sprint planning, so decisions are guided by impact rather than “outputs vs outcomes” confusion. I’ve watched this transition unlock empowered product teams and clearer prioritization across complex backlogs.
Data-oriented paths are equally compelling. If you enjoy experimentation and evidence-based decisions, roles in analytics or data science reward rigor. Think A/B testing, identifying the minimum detectable effect (MDE), and using tools like Amplitude analytics to translate behavioral signals into product bets. Pair that with retention analysis and you’ll become indispensable to growth conversations.
Business-facing roles such as business analyst or product marketing manager are ideal if you’re energized by customer problems and market narratives. Your engineering fluency sharpens value propositions, product positioning, and go-to-market strategy in a way that resonates with both buyers and builders. In my teams, the best bridges between product and revenue often came from former engineers who could articulate trade-offs with clarity.
If operational excellence is your edge, consider SRE, DevOps, or cybersecurity. The same instincts that push you toward clean CI/CD pipelines and resilient architectures translate well into incident management, threat detection and response, and privacy-by-design practices. These roles reward systems thinking and the ability to balance reliability with delivery speed.
For engineers who love community and storytelling, developer evangelism is a natural fit. You’ll translate complex concepts into actionable guidance, from in-app guides and product tours to UX writing and documentation. The best evangelists I’ve worked with turn feedback loops into product insight, strengthening activation and product-led growth without heavy sales pressure.
Customer-facing technical roles—solutions engineer, forward deployed engineer, or technical consultant—let you stay close to the product while solving real-world problems. You’ll drive onboarding quality, user activation, and adoption while surfacing insights that influence roadmaps. Done well, this work tightens the loop between customer outcomes and product decisions.
AI-centered roles are expanding rapidly. If you’re curious about AI Strategy, retrieval-first pipelines, or the practical use of LLMs for product managers, you can bring an engineer’s discernment to a noisy space. The most valuable contributors here pair pragmatic architecture choices with clear risk management and measurable business value, not hype.
Leadership tracks remain a strong option too. The IC to manager transition isn’t about title; it’s about raising the ceiling for others. You’ll coach empowered product teams, shape organizational development, and align initiatives to defensible metrics—think DORA metrics for flow, leading indicators for value, and OKRs that measure outcomes over output.
If you’re exploring a pivot, start small and intentional. Run “career A/B tests” by taking on cross-functional projects, shadowing adjacent roles, or shipping a lightweight portfolio that demonstrates the new muscle. Join a ProductCon session, practice conference networking, and refine a narrative that links your engineering foundation to the outcomes your target role owns.
Finally, map your personal unfair advantages—domain knowledge, systems thinking, customer empathy, or operational rigor—to the roles that value them most. With focus, you can reposition your engineering experience into a differentiated story that accelerates your next chapter. The breadth of options is real, and with a deliberate plan, you’ll turn curiosity into conviction—and conviction into impact.
You are probably not wondering whether UX matters. You are trying to decide whether to move closer to design, how to make that move without becoming a second designer, and what evidence will convince a hiring manager that you can own the work.
The answer is not another UX certificate or a more polished portfolio. You need proof that you can connect customer friction to a product decision, shape an experience with design and engineering, and measure whether the resulting behavior creates business value. This playbook shows you how to build that proof.
Decide whether you want the work, not just the title
A UX product manager owns the customer experience end to end while steering toward measurable outcomes. That does not mean producing every wireframe, conducting every research session, or making every interface decision. It means remaining accountable for the connection between a user’s problem, the experience the team ships, and the behavior that follows.
The distinction matters because the role sits in an overlap, not in a gap. A designer should not need a product manager to practice design. A product team does need someone who can turn customer evidence into a prioritized problem, make trade-offs explicit, and keep discovery connected to delivery.
Role emphasis
Primary question
Strong evidence
Product design
How should this experience work for the user?
Research synthesis, flows, interaction decisions, usability findings, and design-system judgment
Product management
Which problem should the team solve, for whom, and why now?
Prioritization, value proposition, outcome definition, trade-offs, and business impact
UX-oriented product management
Which experience change will help a defined user reach value, and how will the team know?
Customer evidence, experience strategy, cross-functional decisions, instrumentation, and behavioral outcomes
You are likely suited to the overlap if you want to do all of the following:
Investigate why users struggle before debating what the team should build.
Move comfortably between a journey-level problem and a specific piece of microcopy.
Accept accountability for an outcome even though design, engineering, marketing, support, and the user all affect it.
Use qualitative evidence to explain behavior and quantitative evidence to establish its scale.
Partner closely with a designer without treating collaboration as permission to direct every screen.
If those are not the decisions you want to own, do not force a title change. A product manager can deepen UX judgment without becoming a UX product manager, and a designer can develop product sense without leaving design. Choose the work you want to be accountable for.
Build the three capabilities around one real user problem
The fastest way to look shallow is to collect disconnected skills: a research course, an analytics dashboard, a prototype, and a prioritization framework that never touch the same decision. Build customer insight, product strategy, and experience design around one observable problem instead.
Onboarding is a useful practice field because it exposes the whole system. You must identify the user’s intended value, find where progress breaks, decide what not to explain yet, shape guidance, and measure whether people reach a meaningful action. If onboarding is not relevant to your product, choose a core workflow with a clear start, a meaningful completion event, and visible friction.
Customer insight: explain the friction before proposing a fix
Start with a defined segment and a job the user is trying to complete. Then combine behavioral evidence with direct customer evidence. Funnel data can show where people leave; interviews, support conversations, and usability observation can help explain why.
Create a compact evidence packet containing:
The target segment and the situation that brings the user into the experience.
The job the user believes they are completing, stated in the user’s terms.
The current critical path from entry to value.
Observed drop-off, delay, confusion, or repeated support demand.
Direct evidence behind the suspected cause, separated from your interpretation.
Assumptions that remain untested.
That last distinction is career evidence. A strong UX product manager can say, “Users leave at this step” as an observation, “They may not understand the permission request” as a hypothesis, and “Changing the explanation should improve completion” as a testable prediction. Blending those statements into one confident story makes weak discovery look stronger than it is.
Product strategy: turn the insight into a choice
Customer pain is not automatically a priority. Connect it to a value proposition and an outcome. A useful framing is: “For this segment, improve this meaningful behavior by removing this verified barrier, because the behavior is part of reaching product value.”
Now compare problem-level alternatives. The team might remove a step, change its sequence, defer a decision through progressive disclosure, clarify the value with UX writing, or provide contextual guidance. Do not jump from “users are confused” to “build a product tour.” A tour, an in-app guide, and a tooltip are interventions, not strategies. Each is appropriate only when it addresses the cause of the friction.
Record what you will not pursue and why. This is where prioritization becomes visible. A hiring manager learns more from a rejected alternative with a sound trade-off than from a long feature list with no decision logic.
Experience design: make the hypothesis concrete enough to test
Work with design and engineering to turn the chosen problem into a testable flow. Trace the happy path, but also inspect empty states, errors, permission requests, loading behavior, recovery paths, and the moment when the user must make a consequential choice.
Treat language as product behavior. A vague button label, an unexplained requirement, or a tooltip shown without context can create the same friction as a poor interaction. Good UX writing tells the user what will happen, why an input is needed, and how to recover when something goes wrong.
Your artifact does not need visual polish. It needs enough fidelity to expose assumptions. Annotate the flow with the user question each step must answer, the behavior you expect, and the event required to measure it. That turns a prototype into a decision instrument rather than a gallery piece.
Use activation as a diagnostic system, not a vanity metric
Activation is a strong practice area because it forces you to define what “reaching value” means. It can also mislead you. Account creation, a completed tour, or a clicked button is not necessarily activation. The event should represent meaningful progress toward the reason the user adopted the product.
Use this sequence for an activation project:
Choose the segment. Different users may enter with different jobs, permissions, data, or expectations. Do not let an overall average hide a segment-specific failure.
Define the value event. Name the behavior that indicates the user has experienced a meaningful part of the product’s promise. Explain why it matters rather than selecting the easiest event to count.
Map the critical path. Identify the necessary steps between entry and value. Separate required complexity from friction the product has introduced.
Locate the barrier. Combine funnel behavior with usability observation, customer language, and support evidence. A drop-off identifies a location, not a cause.
Write the hypothesis. State the segment, barrier, intervention, expected behavioral change, and reason the change should occur.
Define the read before launch. Specify the primary outcome, relevant guardrails, instrumentation, segments, and the decision you will make under each plausible result.
Your tooling might include Amplitude, Pendo, or Intercom for funnels, product behavior, experiments, and customer signals. The brand matters less than the discipline: events must represent the intended behavior, properties must support the relevant segmentation, and exposure to an experiment must be distinguishable from eligibility for it.
If you run an A/B test, set the minimum detectable effect before interpreting the result. Without an explicit MDE, an inconclusive read is easy to recast as success or failure after the fact. The purpose is not to make experimentation look scientific. It is to decide what size of change would matter and whether the test can detect it.
Read activation alongside time-to-value and adoption of the core capability. Then inspect retention rather than assuming an early lift created durable value. If activation improves while retention does not, you may have accelerated an action without improving the underlying experience. If usability feedback improves but the behavioral metric does not, the altered friction may not have been the limiting factor. Both outcomes are useful when they lead to a sharper next decision.
A practical experiment brief should answer these questions before delivery begins:
Which user segment is eligible?
What verified barrier are you addressing?
Which behavior should change, and why?
What is the smallest experience change that can test the causal assumption?
What is the primary outcome, and what must not degrade?
Which events and properties are required?
What MDE makes the test worthwhile?
What decision follows a positive, negative, mixed, or inconclusive result?
This is how you keep discovery attached to delivery. A sprint should carry a learning goal or an outcome, not merely a collection of screens to complete.
Build a portfolio that exposes your decisions
A UX product management portfolio is not a design portfolio with extra charts. Its job is to make your reasoning inspectable. A reviewer should be able to see what you knew, what you assumed, which choices were available, why you selected one, and how evidence changed the next decision.
Structure each case study as a decision journal:
Context: Identify the segment, user job, product state, business relevance, and constraints.
Problem evidence: Show the qualitative and quantitative signals. Distinguish observations from interpretations.
Outcome: Define the behavior the team intended to change. Explain why it represented customer and business value.
Alternatives: Present the credible options, including a smaller intervention and the option to do nothing.
Decision: Explain the trade-off, who contributed, and which uncertainty the team accepted.
Validation: Describe the prototype, usability work, production experiment, instrumentation, or retention analysis used.
Result and next move: Report what the evidence justified. If it was ambiguous, explain what remained unresolved and what you changed next.
Include screens only when they help the reader understand a decision. An annotated flow showing where a hypothesis enters the experience is more valuable than a polished sequence with no explanation. Likewise, a metric screenshot is not evidence of impact unless you define the segment, behavior, comparison, and decision attached to it.
If the work was exploratory or self-directed, label it clearly. Do not imply that a concept shipped, that users were interviewed, or that business impact occurred when it did not. You can still demonstrate strong judgment by showing how you would instrument the experience, which assumptions require validation, and what evidence would cause you to stop.
Your starting discipline determines which gaps the portfolio must close:
If you are a designer: make prioritization, value proposition, business trade-offs, outcome definition, and sequencing visible. Do not let the quality of the screens carry the case.
If you are a product manager: make the research plan, critical path, journey decisions, usability evidence, UX writing, and interaction trade-offs visible. Do not reduce UX to a feature requirement handed to design.
Prepare interview stories around consequential decisions, not project tours. Start with the tension. Name the alternatives. Explain the riskiest assumption and how you tested it. Then state what you decided and what the evidence changed. This gives the interviewer material to assess your judgment under uncertainty.
A strong resume bullet follows the same logic: “Changed [behavior] for [segment] through [experience decision], using [evidence or method], which informed [product or business decision].” Replace every bracket with facts you can defend. If you cannot name the behavior or the decision, the bullet is probably describing output.
Lead the product trio without taking over another craft
Your career will stall if UX fluency turns into design control. The useful version of the role creates a tighter product trio: product keeps the segment, problem, priority, and outcome visible; design leads the coherence and usability of the experience; engineering brings feasibility, system constraints, delivery insight, and instrumentation into the decision early. Important choices are shaped together.
Use a lightweight operating loop:
Before planning: align on the user problem, current evidence, target behavior, unresolved assumptions, and the next learning goal.
During discovery: pair customer evidence with prototypes and technical investigation. Involve engineering before the team commits to a flow whose cost or constraints are unknown.
During delivery: preserve the hypothesis in the acceptance criteria and instrumentation. Do not let the ticket retain the interface while losing the reason for it.
After release: review behavior and customer signals together. Decide whether to continue, adjust, investigate, or stop.
Tailor the decision narrative to the audience. Executives need the trade-off, business consequence, evidence strength, and decision required. Engineers need constraints, sequencing, edge cases, event definitions, and the reason behind the behavior. Designers need the user job, journey context, friction evidence, and experience assumptions. Other stakeholders need to know what changed, why it changed, how success will be judged, and which new evidence could alter the plan.
A reusable update can stay simple: “For [segment], we are trying to change [behavior] because [evidence] indicates [barrier]. We chose [intervention] over [alternative] because [trade-off]. We will judge it through [outcome and guardrail]. The next decision occurs when [evidence condition].” That format reduces status theater because it keeps the decision and its evidence in view.
Key takeaways
A UX product manager connects customer insight, experience decisions, and measurable product outcomes; the role is not a substitute for product design.
Build customer insight, product strategy, and experience design around the same real problem so your skills form a coherent body of evidence.
Use activation to diagnose the path to value, but verify downstream adoption and retention before claiming durable impact.
Define segments, events, guardrails, MDE, and decision rules before reading an experiment.
Make your portfolio a decision journal that includes constraints, alternatives, ambiguous evidence, and rejected ideas.
Demonstrate leadership by improving the product trio’s decisions, not by absorbing the responsibilities of design or engineering.
Choose one experience in your current product and build the full evidence chain: segment, problem, critical path, hypothesis, experience change, instrumentation, outcome, and next decision. When you can show that chain clearly, you are no longer asking a hiring manager to infer your UX product judgment. You are giving them proof.
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.
I hit play on Global Invoicing – All Things Product Podcast with Teresa Torres & Petra Wille and felt an immediate jolt of recognition. We’ve all launched a feature that looked solid—until a small, overlooked detail broke everything. Their stories about global invoicing and taxes echoed challenges I’ve faced leading product for international customers: if you don’t design for the last mile of compliance, you can accidentally block the very "moment of value creation" your product promises.
Listen to this episode on: Spotify | Apple Podcasts
The conversation starts as a candid rant about EU tax compliance and quickly becomes a precise product management lesson: when we fail to map the entire path to customer value—down to the tiniest regulatory requirement—we can ship something “done” that still doesn’t work in the real world. That gap between intention and outcome is where good product teams live or die.
In my experience, the nightmare of global invoicing for small online businesses is very real. Even big platforms (like Squarespace and Teachable) miss the mark on EU tax compliance, and when they do, customers feel it immediately. It’s the kind of edge case that doesn’t show up in a demo but absolutely shows up in revenue. Or as Teresa put it, “It’s not a little detail when your client won’t pay the invoice.” — Teresa Torres
I appreciated how the episode digs into the difference between passing a regulatory checklist and actually meeting customer needs. Put plainly: the product isn’t “done” when the ticket moves to Done; it’s done when the customer completes the job—receives an acceptable invoice, pays successfully, and can reconcile it without friction. That’s why I lean hard on story mapping for regulatory work; it exposes the invisible steps where value creation can silently fail.
Here’s how the episode resonates with my own playbook: the nightmare of global invoicing for small online businesses is a systems problem; why even big platforms (like Squarespace and Teachable) miss the mark on EU tax compliance is a prioritization and discovery problem; how Petra and Teresa navigated invoicing across borders with Ableify and LearnWorlds highlights pragmatic tool choices and trade-offs; the key difference between meeting regulations and meeting customer needs is an outcomes-over-output mindset; what product teams can learn from regulatory edge cases is how to find the seams where markets, laws, and workflows collide; how missing a single detail can block the "moment of value creation" is a reminder that value is defined by customers; and why story mapping is critical for finding gaps between "we shipped it" and "customers got value" is the method that connects all of the above.
Practically, that means I treat regulatory features like any other high-stakes product surface: do real product discovery with affected users; co-design the happy path and the ugly edge cases; write acceptance criteria that include jurisdictional and document-level specifics (e.g., VAT numbers, invoice formats, timing rules); align with finance and legal early; and instrument the journey from invoice issued to invoice paid so we can see where real customers get stuck. This is outcomes vs output OKRs in action, and it’s one of the fastest ways to earn trust with stakeholders.
Key takeaways worth bookmarking: Customers define value, not your compliance checklist. Regulatory work still requires discovery—you can’t skip understanding user needs. The path to value doesn’t end when your feature works; it ends when your customer succeeds. “Sweating the details” isn’t micromanagement—it’s good product management.
Memorable quotes to bring back to your team: “If you don’t sweat the details, people choose other platforms.” — Petra Wille. “It’s not a little detail when your client won’t pay the invoice.” — Teresa Torres.
Follow Teresa Torres: https://ProductTalk.org | Follow Petra Wille: https://Petra-Wille.com
Mentioned in the episode: Squarespace | Stripe | Product at Heart | Teachable | LearnWorlds | Ablefy | Become a Better Product Leader: A 52-Week Transformation Journey | Product Talk Academy
Have thoughts on this episode? Leave a comment below.
Full transcripts are only available for paid subscribers.
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/
You may already be doing the parts of engineering that sit closest to product management: questioning a requirement, clarifying the user problem, challenging an unnecessary feature, or helping design and product make a difficult trade-off. The uncertainty is whether those moments add up to PM readiness – and whether changing careers means discarding the technical credibility you worked hard to earn.
They don’t prove that you’re ready, but they give you a strong starting point. The safest path is to test the role before you depend on the title. Own a bounded customer problem, work through discovery and prioritization, ship a small bet, and make the resulting evidence visible. That gives you a transition plan based on demonstrated product judgment rather than potential alone.
Change the scoreboard from implementation to impact
Engineering and product management overlap, but they aren’t measured the same way. An engineer is expected to make a solution reliable, maintainable, secure, and feasible. A PM is expected to determine which problem deserves attention, why it matters now, what evidence supports the decision, and how the team will know whether its bet worked.
When you encounter a request such as “build bulk editing,” don’t start by turning it into tickets. Rewrite it as a product decision:
User and context: Which segment encounters the problem, and during which workflow?
Observed problem: What are people trying to accomplish, and where does the current experience fail them?
Current behavior: What workaround or alternative do they use now?
Desired outcome: Which user or business measure should change if the problem is solved?
Hypothesis: Why should this particular intervention change that measure?
Smallest useful test: What can you ship or simulate to reduce the most important uncertainty?
Decision rule: What evidence would make you continue, change direction, or stop?
This framing exposes weak roadmap items quickly. If you can’t identify the affected segment, current behavior, baseline signal, or decision rule, the team doesn’t yet have a product bet. It has a solution looking for justification.
Technical depth remains useful. You can detect hidden dependencies, challenge unrealistic scope, and understand where platform choices restrict future options. The trap is allowing feasibility to dominate desirability and business value. A solution can be technically elegant, delivered on time, and still leave the customer problem untouched.
Run a 90-day transition experiment in your current role
Choose a problem that matters but doesn’t require control of the entire roadmap. It should have an identifiable user, an observable pain point, a plausible measure of success, and enough room for a small intervention. Avoid a project whose scope is already fixed. Coordinating predetermined delivery may demonstrate execution, but it gives you little opportunity to show discovery, prioritization, or product judgment.
Phase
Work to own
Evidence to preserve
First 30 days
Map the users, workflow, current alternatives, relevant metrics, stakeholders, and decision process. Define the problem boundary and establish the baseline signal.
A one-page problem brief, workflow map, initial dashboard, interview plan, and written scope.
By day 60
Run focused discovery, combine interview patterns with quantitative signals, compare possible interventions, and build a hypothesis-led roadmap.
Discovery notes, customer language, an opportunity tree, rejected options, trade-offs, and a prioritized experiment.
By day 90
Deliver a thin slice, observe the result, follow up with affected users, and recommend whether to continue, revise, or stop.
A before-and-after dashboard, decision log, updated roadmap, outcome narrative, and lessons that change the next decision.
Set the operating agreement before the trial begins. Write down what you own, which decisions you can make, who remains accountable for the broader roadmap, and how much engineering work you will retain. A minimal engineering contribution can reduce the immediate staffing risk, but minimal must be explicit. Otherwise, you can end up carrying a full engineering workload while attempting a second full-time role.
Your weekly update should be short enough that leaders will read it and structured enough that they can intervene:
The outcome you are trying to influence.
What you learned from users or data.
Which assumption became stronger or weaker.
The decision made and the trade-off accepted.
The next uncertainty to reduce.
Any decision or support needed from the recipient.
This cadence does more than report activity. It demonstrates that you can turn incomplete information into a clear decision without hiding uncertainty. It also prevents the trial from becoming invisible work that everyone appreciates but nobody recognizes as product ownership.
Practice the three skills engineering may not have forced you to build
Technical competence can help you enter the conversation, but it won’t compensate for weak discovery, vague positioning, or poor stakeholder management. Those are the areas to practice deliberately during the transition.
Product discovery: investigate behavior before proposing a solution
Engineers are trained to solve well-defined problems. Product discovery tests whether the apparent problem is real, important, and worth solving for a particular segment. The distinction matters because confident solution design can make a weak assumption look mature.
Use interviews to reconstruct actual behavior rather than solicit approval for an idea. Useful prompts include:
Walk me through the last time you tried to complete this task.
What triggered the need?
Where did the workflow slow down or break?
What did you do next?
What workaround have you adopted?
What was the consequence of leaving the problem unresolved?
Avoid leading with a proposed feature or asking whether someone would use it. People can be polite, imaginative, and optimistic about hypothetical behavior. Recent examples, current workarounds, and actual consequences give you firmer evidence.
Don’t turn each interview into a roadmap vote. Look for repeated situations, motivations, obstacles, and alternatives. Then check those patterns against quantitative signals such as activation, conversion, retention behavior, or support volume. Qualitative evidence explains what may be happening; quantitative evidence helps you understand its reach and movement.
Product positioning: make the value segment-specific
A technically capable product can still fail to communicate why anyone should change behavior. Positioning forces you to choose whose problem matters and why your approach is preferable to the status quo.
Draft a simple statement: For [specific segment] struggling with [observable problem], this capability helps them achieve [meaningful outcome], unlike [current alternative], because [relevant distinction].
Each bracket requires evidence. If you describe the user as everyone, the segment is too broad. If the outcome is easier or better, it is too vague. If you can’t name the current alternative, you may not understand the real competition, which is often an established workaround rather than another product.
Stakeholder management: communicate decisions, not activity
A PM rarely controls every team needed to produce an outcome. You must create alignment through context, evidence, and explicit trade-offs. That is different from satisfying every stakeholder request. Stakeholder agreement can help delivery, but it does not prove customer value.
Build updates around the decision:
What decision is required?
Which outcome does it affect?
What evidence is relevant?
Which viable options were considered?
What does each option trade away?
What do you recommend, and why?
Who owns the next action?
Remove implementation jargon unless it materially changes the decision. Executives need the consequence of a dependency, not a tour of the dependency graph. Engineers need constraints and reasoning, not a priority handed down without context.
Practice these skills inside a product trio involving product, design, and engineering. The trio gives you access to different forms of judgment while preventing product discovery from becoming a solo PM exercise. Agree on decision rights and sponsorship at the start so you don’t become an unofficial PM with responsibility but no authority.
Turn the work into evidence that survives an interview
A long ticket history doesn’t demonstrate product judgment. Your portfolio has to show how you reduced uncertainty, made a choice under constraints, aligned the people needed to act, and learned from the result.
Build each case study around a decision rather than a feature:
Context: Who was the user, what were they trying to do, and why did the problem matter?
Uncertainty: What did the team not know at the beginning?
Evidence: Which customer and product signals changed your understanding?
Alternatives: What other options were credible, including doing nothing?
Choice: What did you prioritize, and what did you deliberately decline?
Delivery: How did you reduce scope while preserving a useful test?
Outcome: What changed in activation, conversion, support demand, or another relevant measure?
Learning: What did the result change about the next roadmap decision?
Attach the supporting artifacts only after the narrative is clear. Useful evidence includes a one-page problem brief, anonymized discovery notes, customer language, an opportunity solution tree, a hypothesis-led roadmap, an outcomes dashboard, and a before-and-after roadmap snapshot. The artifacts support your judgment; they shouldn’t force the interviewer to reconstruct it.
Be precise about causality. If several initiatives were running at once, say that your work influenced an outcome rather than claiming it caused the entire change. If the target metric didn’t move, don’t bury the result. Explain which assumption failed, what you stopped doing, and how the evidence improved the next decision. Honest learning is a stronger PM signal than a polished success story with implausibly clean attribution.
For an internal transfer
Package your trial as a proposal your manager and product leader can evaluate. Include the problem boundary, success measure, product trio, weekly update rhythm, retained engineering commitment, artifacts you will produce, and the decision to be made at the end of the 90 days. This turns a vague request for a chance into a controlled staffing and product experiment.
For an external search
Prepare two deep case studies: one centered on discovery and another on delivery. The discovery case should show how you challenged the initial framing and reduced uncertainty. The delivery case should show how you handled constraints, aligned stakeholders, protected the outcome while reducing scope, and shipped.
Expect follow-up questions about trade-offs: What did you say no to? Which assumption worried you most? Why was the thin slice sufficient? What evidence would have reversed your decision? What did you do when stakeholders disagreed? If your answer is only that the team completed the roadmap, you are still presenting yourself as a delivery coordinator. The stronger signal is that a decision changed because you understood the customer, business, and system more clearly.
Key takeaways
Your engineering background is an advantage, not proof of PM readiness. Use it to improve decisions, not to dominate the solution.
Replace feature completion as your scoreboard with a clearly defined user or business outcome.
Build experience before changing titles by owning one bounded problem through a 90-day internal trial.
Use a weekly update to expose evidence, assumptions, trade-offs, decisions, and requests for help.
Practice discovery, positioning, and stakeholder management deliberately; technical fluency won’t substitute for them.
Make your portfolio decision-centered, quantify the outcomes you influenced, and represent causality honestly.
Prepare one discovery-led case and one delivery-led case for external interviews.
Your next move isn’t rewriting your resume. Choose one user pain in a product you already understand. Write a one-page problem brief, identify the product and design partners you need, define the outcome you will track, and ask a sponsor to support a bounded trial. Let the title follow the evidence.
Heading to ProductCon San Francisco 2025? I approach conference travel the same way I approach product strategy: optimize for outcomes, reduce friction, and invest in high-signal experiences. Here’s the playbook I use to choose the right hotel, find memorable meals, and make the most of every hour in the city.
For lodging, I prioritize walkability, safety, and quiet rooms so I can focus during sessions and recover at night. If you want to be steps from most venues and meetups, SoMa and the Yerba Buena corridor are ideal. InterContinental San Francisco, W San Francisco, and The Clancy (Autograph Collection) are reliable, business-friendly picks with strong Wi‑Fi and ample lobby space for impromptu one‑on‑ones. If you prefer classic energy and transit access, Union Square hotels like Hotel Nikko and The Westin St. Francis work well. For waterfront views and a calmer vibe, Hyatt Regency Embarcadero puts you by the Ferry Building with easy BART and Muni access.
My booking checklist is simple: reserve early, target a high floor away from elevators, and request early check‑in or late checkout around your session schedule. Loyalty programs often unlock better rates and quiet‑room preferences. If you need heads‑down time between talks, ask about day‑use meeting rooms or find a corner of the lobby with stable bandwidth. I also pack a compact power strip and a long USB‑C cable—two small upgrades that routinely save a day.
Coffee is the fuel of great product conversations. Near SoMa, I rotate between Blue Bottle (Mint Plaza), Sightglass (7th Street), and Philz (Front Street) for pre‑session caffeine and quick stand‑ups. If I’m on the Embarcadero side, the Ferry Building’s roasters are perfect for early starts, and morning lines move faster than you’d expect if you arrive just after opening.
For efficient lunches, I favor fast‑casual spots that can handle volume without sacrificing quality. Mixt, Souvla, Sweetgreen, Super Duper Burgers, and The Grove are dependable within a short walk of most downtown venues. When I need a higher‑signal lunch with a partner or prospect, I book a table slightly off the main corridor to avoid the rush—think Mourad for elevated Moroccan in SoMa or Boulevard along the Embarcadero for a polished, quiet conversation.
Dinner is where the best networking often happens, so I plan for atmosphere, acoustics, and a menu that works for mixed dietary needs. Kokkari Estiatorio (FiDi) excels for executive dinners. Liholiho Yacht Club is a creative, memorable choice for cross‑functional teams. Waterbar or Angler near the waterfront pair great food with views that impress visiting colleagues. For something more casual but still conversation‑friendly, Nopa or Sorella deliver consistently.
When it’s time for drinks, I think in terms of groups and goals. For panoramic views and small group catch‑ups, The View Lounge (Marriott Marquis) is a classic. For wine‑forward conversations with a quiet ambiance, Press Club near Yerba Buena works well. If you’re hosting a more energetic crew, Charmaine’s (SF Proper Hotel), Dirty Habit (Hotel Zelos), or 25 Lusk offer space, good music, and reliable service. For craft cocktails, Pacific Cocktail Haven and ABV are standouts if you don’t mind a short ride.
Transit and timing matter. From SFO or OAK, BART is often the fastest, most predictable route downtown; rideshare is convenient late at night. I walk whenever possible, but I time routes along well‑lit, busier streets and avoid sprinting between neighborhoods tight on time. Microclimates are real—bring layers, comfortable shoes, and a compact umbrella. I schedule 15‑minute buffers around key sessions to handle inevitable friend‑of‑a‑friend introductions.
If you need a professional setting for a quick working session, many hotels will extend lobby seating to guests and their visitors. For dedicated space, day passes at coworking operators like Industrious, CANOPY, or Regus are worth it when you’ve got a client briefing or board prep. For a more casual backdrop, Sightglass and Blue Bottle locations typically have reliable Wi‑Fi and just enough outlets if you arrive off‑peak.
Finally, a word on intent: I set a simple goal for each day—one meaningful connection, one surprising insight, and one concrete action to bring back to my team. ProductCon San Francisco 2025 is a catalyst if you design your experience with the same rigor you apply to your roadmap. If you spot me in a session or at a nearby cafe, say hello—I’m always up for trading notes on product strategy, pricing experiments, and what’s working in the field right now.
Quick note: restaurants and hours can change quickly—make reservations where possible and double‑check opening times the week of the event.
Products without borders are exhilarating—and unforgiving. In my role leading product strategy, I’ve learned that “global” isn’t a launch plan; it’s a system. It’s the discipline of creating one product vision that flexes to many markets without breaking the core experience, the roadmap, or the business.
Here’s what a Global Product Manager does, key skills, tools, challenges, and how to grow into this high-impact role.
At its heart, the Global Product Manager role orchestrates product-market fit in multiple regions simultaneously. I translate a unified value proposition into localized realities—aligning product positioning, go-to-market strategy, pricing and packaging, and compliance—while keeping the platform cohesive. That means partnering closely with product trios, regional leaders, sales, customer success, and marketing to drive outcomes vs output OKRs that actually move the business.
Operationally, I start with deep product discovery across segments and geographies: what pains are universal, and where do we need regional nuance? From there, I map points of parity we must maintain globally and the differentiators we’ll localize—copy, workflows, payments, support models, and integrations. The art is delivering a consistent core with flexible edges so we can scale without fragmenting the codebase or the customer experience.
Trust is the non-negotiable. I build privacy-by-design into the product and roadmap, and I collaborate early with legal and security on data governance, data residency, and evolving regulations like GDPR. The right guardrails reduce rework later and enable faster regional launches—because compliance is a feature customers feel, even when they don’t see it.
On the commercial side, I partner on consumption SaaS pricing, product-led growth motions, and country-level market entry. Some markets need lighter onboarding and in-app guides; others demand concierge support or partner-led distribution. I use retention analysis to identify fit and inform sequencing, then adjust messaging and activation flows to shorten time-to-value and improve user activation by region.
My analytics and enablement stack is intentionally boring—and ruthlessly consistent. A unified analytics platform with Amplitude analytics gives us comparable funnels across countries. For experimentation, I run A/B testing with a clear minimum detectable effect (MDE) and disciplined rollout plans. Pendo powers product tours and in-app guides tailored by locale, while Intercom and CRM integration with HubSpot help me close the loop with GTM and support teams. The outcome is a learning system, not just a dashboard.
The hardest part isn’t translation—it’s alignment. Time zones, competing priorities, and matrixed ownership test even strong cultures. I rely on stakeholder management, crisp decision records, and product roadmapping and sprint planning rituals that respect regional input without derailing the global plan. When tension rises, I return to first principles decision making and the try do consider framework to make trade-offs transparent and repeatable.
If you’re growing into this role, start by owning a multi-region initiative end to end: lead localization for a critical workflow, run market-specific A/B testing with clear MDE, and publish a country launch plan that ties discovery insights to OKRs and resourcing. Build your credibility by shipping outcomes, not artifacts—then scale your impact by mentoring peers and creating shared templates for pricing, positioning, and experimentation. That’s how you shift from capable PM to trusted global operator.
Ultimately, a Global Product Manager is a force multiplier. We reduce complexity for the organization while increasing resonance for customers. If “products without borders” is your mandate, build the systems—analytics, governance, enablement, and decision-making—that make borderless execution reliable, repeatable, and fast.
If your roadmap looks aligned in the planning deck but every launch triggers fresh negotiation, your product teams are not short of collaboration. They are working inside an operating model that lets each function finish its task while no one owns the customer result. The visible cost is delay. The larger cost is mistaking a full backlog for progress.
A silo is not simply a function with specialized expertise. You need strong product, design, engineering, marketing, sales, support, and data disciplines. The problem begins when accountability stops at a functional boundary even though the customer outcome crosses it.
That distinction matters because the usual remedies target attitude: ask people to communicate more, schedule another sync, or encourage greater transparency. Those actions cannot repair unclear ownership. They often add coordination work while leaving the original decision structure untouched.
Diagnose the operating model by tracing one recent product bet from the customer problem to the result. Do not start with the org chart. Follow the actual work and ask:
Who first defined the customer problem, and what evidence did they use?
Who chose the solution, scope, success measure, and launch conditions?
Which decisions moved between functions because nobody had clear authority?
Which assumptions were discovered only after engineering, go-to-market, or support had committed work?
Where did two groups solve the same problem independently?
Who inspected the customer or business result after release?
The answers reveal different failure modes. Duplicate solutions usually point to overlapping ownership. A decision that repeatedly moves between leaders points to unclear decision rights. Roadmap arguments grounded in preference point to the absence of shared evidence. A release with no owner for activation, retention, or another intended result points to output accountability.
Launch surprises are another strong signal. If sales learns the positioning late, support sees a new workflow shortly before release, or data discovers that the success metric cannot be measured, the handoff did not fail at launch. Alignment began too late. The missing voices should have shaped the hypothesis and constraints before delivery.
Do not begin with a company-wide reorganization. Moving reporting lines can preserve the same ambiguity under new names. Start with the smallest unit that can own one meaningful outcome from problem definition through measurement.
Give a product trio an outcome, not a bundle of tickets
A product trio brings product management, design, and engineering into the core decision-making unit. Each discipline keeps its craft responsibilities, but the trio shares accountability for a customer outcome. It is not a committee that approves one another’s deliverables. It is the group responsible for turning evidence into a bet, testing that bet, and adapting when the evidence changes.
The wording of the assignment determines how the team behaves. Ship a redesigned setup flow is an output. Improve activation for customers entering setup is an outcome. The first statement commits the team to a solution before learning begins. The second gives the trio room to investigate the obstacle, compare options, run an experiment, narrow scope, or stop an idea that does not move the metric.
An outcome is not permission to work on anything. Give the trio a short bet brief that makes its boundaries explicit:
The customer behavior or problem that needs to change, with the evidence currently supporting it.
The customer outcome and its connection to a business result.
The baseline, leading indicators, lagging measure, and guardrail metrics.
The hypothesis about what is preventing the desired behavior.
The constraints the team must respect, including dependencies and launch conditions.
The experiment or discovery activity that can reduce the most important uncertainty.
The decisions already made, the decisions still open, and who resolves cross-portfolio trade-offs.
This brief should remain lightweight enough to change when learning changes. Its job is not to predict every feature. Its job is to stop different functions from carrying different versions of the problem.
Decision rights must be just as clear. The trio should be able to choose the solution, experiment sequence, and scope within the agreed outcome and constraints. Functional leaders should own craft standards, coaching, staffing quality, and reusable capabilities. Executives should allocate investment across outcomes and settle trade-offs that span teams. Go-to-market, support, legal, security, finance, and data should enter when their knowledge can change the decision, not merely when an approval is needed at the end.
Empowerment without boundaries creates fresh ambiguity. Coordination without local authority creates a committee. A useful test is simple: can the trio stop a planned feature because discovery showed that it would not improve the assigned outcome? If every scope change still requires a chain of functional approvals, the team owns delivery rather than the result.
Replace functional handoffs with a learning cadence
Breaking silos does not require more meetings. It requires changing what the existing meetings are for. Status reporting moves information upward. A learning cadence brings evidence, decisions, and dependencies into the open while the team can still act on them.
Use the following sequence from discovery through delivery:
Before committing scope, align the trio and relevant adjacent functions on the outcome, hypothesis, evidence, constraints, and unknowns. This is where you expose assumptions that would otherwise appear as launch surprises.
During discovery, review what the team learned and which uncertainty should be reduced next. A polished presentation is optional. Evidence and a decision are not.
During sprint planning, connect substantial work to the hypothesis or measure it supports. Label enabling work and dependencies honestly rather than pretending every ticket directly produces customer value.
In the weekly cross-functional review, inspect the outcome signal, new evidence, decisions needed, and blocked dependencies. Skip the round-robin recitation of completed tasks.
At launch, confirm instrumentation, go-to-market readiness, support readiness, ownership of guardrails, and the date of the result readout.
At the readout, compare the observed result with the baseline and experiment design, then decide whether to continue, change, scale, or stop.
Use OKRs to express the outcome commitment, not to disguise a feature list as key results. Use quarterly business reviews to inspect the portfolio: which outcomes are moving, where confidence has changed, and which investments should be increased, redirected, or stopped. Do not make a team wait for the quarterly review to respond to weekly learning.
A decision log keeps the cadence from becoming corporate memory theater. For each consequential decision, record the context, decision, owner, evidence, trade-off, and condition that would justify revisiting it. The goal is not permanent certainty. It is to prevent an unresolved question from being reopened by a different stakeholder with no new information.
Review your recurring meetings after the pilot. Keep a meeting if it produces a decision, resolves a dependency, or changes shared understanding. Merge or remove it if the same update already exists in the scorecard or decision log. This is how better collaboration can reduce coordination overhead instead of adding to it.
Create one evidence path from customer behavior to business result
Teams can share an outcome and still operate in silos if each function brings a different version of reality. Product may watch feature use, marketing may watch campaign conversion, support may watch conversation volume, and sales may watch CRM stages. None of those views is inherently wrong. The problem is that they are not connected into one explanation of what changed for the customer and the business.
Start with the decision, not the dashboard. For the chosen outcome, map the relevant customer journey and identify the events or state changes that show progress. Agree on definitions, identity rules, data owners, and the system of record for each measure. Then connect the measures into a scorecard the trio and stakeholders can inspect together.
A practical outcome scorecard contains:
The outcome metric, its baseline, and its current value.
The leading indicators expected to move before the final result.
Guardrail metrics that could reveal customer or business harm.
The current hypothesis and the evidence for or against it.
The active experiment, including its status and minimum detectable effect.
The latest decision and the next scheduled readout.
The minimum detectable effect, or MDE, is the smallest effect an experiment is designed to detect reliably under its statistical assumptions. Define it before interpreting an A/B test. Otherwise, a result that is too imprecise to support a decision can be presented as proof, while a potentially useful result can be dismissed simply because the test was not designed to detect it.
A unified analytics platform does not have to mean one vendor. If your operating stack includes Amplitude for behavioral analytics, Pendo for in-product behavior, Intercom for conversations, and HubSpot connected to the CRM, the important work is agreeing on identities, event definitions, funnel stages, and ownership across those systems. Buying another tool without resolving those definitions gives every silo a newer dashboard.
When numbers disagree, resolve the definition and lineage before debating the roadmap. Ask which population is included, when the event is recorded, which system owns the state, and whether the same customer can be counted differently across tools. Link the agreed dashboard directly from the bet brief so evidence does not become an optional attachment to planning.
Run one focused pilot before changing the whole organization
A broad transformation program can reproduce the same illusion of work you are trying to eliminate. A focused pilot gives you a real outcome, real dependencies, and real decisions against which to test the operating model.
Choose one customer outcome that currently suffers from conflicting priorities, repeated decisions, or unclear ownership. It must have a measurable leading indicator.
Form one product trio and name the executive sponsor responsible for removing cross-portfolio constraints.
Write the bet brief, establish the baseline, and connect the outcome to its business relevance.
Map decision rights and dependencies. Invite adjacent functions early where their knowledge can change the hypothesis, scope, measurement, or launch conditions.
Select one experiment, define its success criteria and MDE where A/B testing applies, and instrument the relevant part of the funnel.
Use a weekly review centered on the shared scorecard and decision log. Reuse an existing meeting if possible.
Hold a two-week readout. Decide what the team learned, which work or meeting can stop, and whether the bet should continue, change, or end.
A two-week readout does not guarantee that a lagging customer or business outcome will have matured. Use it to inspect the available leading signal, the quality and speed of decisions, unresolved measurement gaps, and whether the new model eliminated duplicated or low-value work. Continue observation when the outcome needs more time; do not manufacture certainty to satisfy the calendar.
Judge the pilot on both impact and operating behavior. Did the trio make a decision that previously would have bounced between functions? Did early involvement expose a dependency before delivery? Did shared evidence let the team cut scope or stop an unsupported idea? Those changes show that accountability is moving closer to the outcome, even before the final metric is available.
Key takeaways
Treat silos as an ownership and decision-design problem, not a request for people to communicate more.
Give a product trio one measurable customer outcome and explicit authority within defined constraints.
Align adjacent functions while the hypothesis can still change, not when the launch needs approval.
Turn planning and review rituals into a cadence for evidence, decisions, dependencies, and learning.
Connect behavioral, product, conversation, and CRM data through shared definitions before declaring a source of truth.
Prove the model with one outcome, one trio, one experiment, and a two-week readout before scaling it.
Start with one roadmap item that attracts recurring debate. Before discussing its feature scope again, ask the responsible people to agree on the customer outcome, baseline, decision owner, and next piece of evidence. If they cannot, you have located the silo. That is where the bridge needs to begin.
Your roadmap can look aligned while the teams behind it are solving different problems. Product is aiming for adoption, marketing is preparing a launch, engineering is controlling delivery risk, and data is still trying to establish what activation means. The mismatch appears late as rework, conflicting dashboards, launch friction, or an argument about whether the release succeeded.
The answer is not another status meeting. You need an operating system that gives people a shared outcome, common evidence, explicit decision rights, and a fast path from production signals to the next decision. When those elements are visible, cross-functional collaboration becomes part of delivery instead of an extra activity surrounding it.
Begin with the behavior you want to change
Output creates the appearance of agreement because it gives everyone a concrete noun: redesign, integration, campaign, dashboard, or launch. It does not prove that the team agrees on the customer problem or the result that would make the work worthwhile.
Consider the difference between these two statements:
Output: Launch guided onboarding.
Outcome: Help new accounts reach their first useful workflow and continue using it.
The output tells design and engineering what to build. The outcome gives product, design, engineering, marketing, and data a problem they can examine together. It also leaves room for the team to discover that a product tour, a clearer empty state, a setup checklist, better lifecycle messaging, or a change to the workflow is the more appropriate intervention.
I use a simple test for alignment: ask each function to explain, in its own words, whose behavior should change, why it is not changing now, and what evidence would show improvement. If the answers differ materially, the initiative is not ready for a scope discussion.
Capture the agreement in an outcome contract. This can be a one-page brief, but it should contain enough precision to govern later decisions:
Customer: The segment and situation you are addressing, not a label as broad as “all users.”
Problem: The obstacle or unmet need, supported by the evidence already available.
Behavior change: What customers should start, stop, complete, repeat, or understand differently.
Success measures: The signals that would indicate progress, including any guardrail that must not deteriorate.
Assumptions: What must be true about the customer, solution, channel, or underlying technology.
Non-goals: Adjacent problems that this initiative will not solve.
Decision owner: The person accountable for resolving tradeoffs when the functions disagree.
Revisit condition: The evidence or dependency change that would justify reopening the direction.
The contract is not a requirements document. It is a boundary around autonomous problem-solving. Teams can change the solution without asking for permission each time, provided the new approach still addresses the agreed problem, respects the constraints, and can be measured against the same outcome. That is the practical value of connecting customer problems, behavior change, and KPIs before delivery begins.
Watch for a problem statement that already contains the preferred feature. “Customers need an AI assistant” is a solution claim. “Customers abandon configuration because they cannot determine which settings apply to their workflow” is a problem the team can investigate. Ask whether you would still fund the initiative if the proposed feature disappeared. If the answer is no, you may be sponsoring an output without having established an outcome.
Separate contribution, consultation, and decision authority
Cross-functional does not mean that everyone decides everything. That interpretation produces large meetings, diluted accountability, and compromises that satisfy the room without serving the customer. Good collaboration expands the evidence going into a decision while keeping responsibility for the decision clear.
A product manager, designer, and technical lead can form the decision-making nucleus. The trio holds the customer, usability, business, and feasibility perspectives close enough to shape the work together. Marketing, data, support, customer success, security, legal, and other partners should enter while their knowledge can still change the approach, not after the solution is effectively frozen.
Contributor
Primary lens
Question to resolve early
Product manager
Customer and business outcome
Which problem deserves investment, and what result would justify continuing?
Designer
Behavior, comprehension, and workflow
Can the intended customer understand and use the proposed experience?
Technical lead
Feasibility, architecture, and delivery risk
Which constraints or unknowns could invalidate the approach?
Marketing
Audience, positioning, and demand
Which promise will make sense to the intended audience, and can the product fulfill it?
Data
Measurement and validity
Which observable signals distinguish real behavior change from activity?
Support and customer success
User language and operational failure modes
Where are customers already confused, blocked, or compensating with workarounds?
The table identifies perspectives, not departmental vetoes. For each material choice, name a directly responsible individual before the debate begins. Then use a consistent decision protocol:
Write the decision as a question. “Should the first release support every account type?” is easier to resolve than a vague discussion about scope.
List the viable options and constraints. Include the option to stop or defer when it is genuinely available.
Separate facts from assumptions. A technical limitation, a customer observation, and a forecast do not carry the same certainty.
Timebox the debate. Contributors provide evidence and consequences; the named owner resolves the remaining tradeoff.
Record the decision. Preserve the chosen option, the alternatives rejected, the reason, and the condition that would warrant reconsideration.
A useful decision record is short. It exists so the next contributor does not have to reconstruct context from messages and calendar invitations. It also prevents a settled choice from being reopened merely because someone new entered the conversation. New evidence is a reason to revisit a decision. A new attendee is not.
Evidence needs the same discipline as ownership. A shared analytics system cannot create agreement if teams use different populations, events, observation windows, or exclusions for the same metric. Create a metric contract for every KPI that can change a roadmap or release decision:
The metric name and plain-language meaning.
The eligible population and any exclusions.
The events and properties used in the calculation.
The observation period or qualifying window.
The owner responsible for definition changes.
The dashboard or query treated as the canonical implementation.
Known caveats and breaks in comparability.
“Activation” is not an operational definition. It is a label. Until the team agrees on who can activate, which behavior qualifies, and within what window, two dashboards can be internally correct while supporting opposite conclusions.
When metrics disagree, do not average the numbers or choose the more convenient chart. Compare the population, event trigger, properties, window, exclusions, and data freshness. Resolve the definition before using the metric to judge the product. This is why event hygiene, operational definitions, self-serve dashboards, and explicit decision ownership belong in the collaboration model rather than inside separate data and governance processes.
Connect discovery, planning, delivery, and learning
Many collaboration failures are timing failures. The right function participates after the decision it could have improved. Marketing sees the experience when messaging is due. Data reviews instrumentation when code is nearly complete. Support learns the workflow when customers begin asking questions. Engineering receives a polished concept before feasibility has shaped it.
Define what each phase must produce and which decision that artifact supports. The lifecycle can remain lightweight while still making participation intentional:
Phase
Shared artifact
Question the team must answer
Resulting decision
Problem discovery
Outcome contract and evidence summary
Is this problem real, important, and appropriate for this team?
Explore, defer, or stop
Concept discovery
Prototype and test findings
Does the approach appear understandable, useful, and feasible?
Refine, test another approach, or prepare delivery
Planning
Living roadmap and dependency map
Which bet best advances the objective under the current constraints?
Sequence the work and assign dependencies
Delivery
Working demonstration and instrumentation checklist
Can the product be released, observed, explained, and supported?
Release, narrow the scope, or resolve a blocking gap
Production learning
Behavior dashboard and feedback summary
Did the intended behavior change, and what remains uncertain?
Expand, modify, run another test, or retire the approach
Bring partner knowledge into discovery
Discovery is where collaboration has the greatest room to change the answer. Customer interviews can expose the problem and the language customers use. Concept tests can reveal confusion before implementation. An instrumented prototype can connect stated reactions with observable behavior. Existing support conversations and in-product feedback can show where the current experience fails.
Do not turn discovery into a series of presentations from one function to another. Give each partner a question that can alter the decision:
Ask marketing which audience assumption and value promise need validation.
Ask data which signals can distinguish the intended behavior from superficial activity.
Ask support and customer success which workarounds, vocabulary, and failure patterns already appear in customer interactions.
Ask engineering which unknowns need a technical exploration before the concept becomes a commitment.
Ask design which behavior can be observed in a prototype rather than inferred from preference.
Package each useful insight with its implication. A screenshot, quote fragment, event pattern, or test result without a decision connection becomes background material that few people revisit. State what was observed, what it may mean, what remains uncertain, and which open choice it affects.
Treat the roadmap as a traceable argument
A roadmap should show why the work belongs, not merely where it sits. Maintain a visible chain from objective to bet to epic to experiment. If the team cannot trace an epic to an outcome, it has probably inherited work without inheriting its rationale.
Invite stakeholders to shape the roadmap where they can reveal dependencies, constraints, risks, and opportunities. That does not make roadmap planning a vote. The product decision owner still has to rank the bets against strategy and evidence. Participation supplies context; it does not erase accountability.
For every meaningful dependency, record the owner, the condition you need satisfied, and what happens if it is not. “Waiting on platform” is status. “The identity team must expose the account permission before this workflow can serve multi-location users; without it, the first release is limited to a narrower account type” is planning information.
Keep the roadmap alive as discovery changes the evidence. A roadmap that cannot absorb a disproven assumption is a delivery calendar, not a product strategy tool. When priorities change, update the objective-to-work trace and the decision record so people can see the reason rather than invent one.
Design the release as a learning loop
A launch confirms that the team delivered something. It does not confirm customer value. The release plan therefore needs a learning path as concrete as the delivery path.
Feature flags and smaller release batches let the team control exposure while observing behavior. In-app guidance can explain a new interaction at the moment of use. Instrumentation connects that exposure to activation, engagement, conversion, or retention, depending on the outcome contract. These mechanisms turn production into a place to answer a question rather than merely distribute completed work.
Before releasing, confirm that the team has:
A named owner for the flag, rollout, and reversal decision.
Verified events and properties for the behaviors that matter.
A dashboard using the agreed metric definitions.
Customer guidance appropriate to the change.
Enough context for support and customer success to recognize expected questions and genuine defects.
A defined review point and a decision the resulting evidence will inform.
Do not collect every available signal. Measure the behavior named in the outcome contract and the guardrails that protect the wider experience. If the team cannot explain what it would do when the metric moves, stays flat, or becomes ambiguous, the dashboard is reporting activity rather than governing a decision. Small releases, feature flags, in-product guidance, and behavioral feedback are useful because they shorten the distance between a product choice and the evidence needed to improve it.
Make the collaboration system visible enough to inspect
Healthy collaboration is observable. You can find the current outcome, see who owns an open decision, inspect the metric definition, understand why a bet is on the roadmap, and locate what the team learned after release. If that context exists only in people’s memories, the operating model will weaken whenever the team grows, reorganizes, or adds a new partner.
Use rituals for specific transitions rather than filling the calendar with recurring status:
Initiative kickoff: Confirm the outcome contract, decision owner, contributors, and known assumptions.
Discovery review: Examine new evidence, identify which assumptions changed, and select the next question.
Decision checkpoint: Resolve a named tradeoff and publish the decision record.
Product demonstration: Inspect the experience in working form and expose gaps across usability, feasibility, messaging, measurement, and support.
Roadmap review: Re-rank bets when strategy, evidence, capacity, or dependencies change.
Learning review: Compare production evidence with the outcome contract and decide whether to expand, modify, test again, or stop.
Every ritual should produce a decision, new evidence, or an updated shared artifact. If it produces none of those, redesign it or remove it. A meeting whose only purpose is to transfer status is a sign that the underlying work is not visible enough.
Use the lightest communication form that preserves the decision context. A one-page brief works for a bounded initiative. A narrative memo is useful when the tradeoff needs more reasoning. A short demonstration video can show product behavior more clearly than written status. A decision record protects context. A shared dashboard gives each function access to the same behavioral evidence. Each artifact should have an owner, current state, and links to the work it governs.
Transparency matters most when the evidence is uncomfortable. Visible roadmaps, shared channels, accessible calendars, and open decision records reduce the temptation to manage disagreement through private escalation. The leader’s job is not to eliminate friction. It is to keep friction focused on the customer, the evidence, and the tradeoff while making it safe to expose a weak assumption early. Plain-language artifacts, transparent working spaces, and respectful disagreement make that behavior easier to sustain.
Run this diagnostic on one live initiative
You do not need an organization-wide maturity model to find the first weakness. Choose an initiative with visible coordination cost and answer these questions:
Can each function name the same customer, problem, intended behavior, and success measure?
Can a contributor find the operational definition of the primary metric without asking the data team?
Does every unresolved material decision have a named owner?
Did marketing, data, engineering, design, and customer-facing partners contribute before their relevant choices were fixed?
Can you trace each major item from an objective to a bet and from the bet to an experiment or release?
Does the release have verified instrumentation and a decision tied to the resulting evidence?
Can a new contributor discover why the team chose the current approach without reconstructing old meetings?
A “no” identifies a specific operating gap. Do not answer it by adding a broad collaboration initiative. Fix the missing contract, role, definition, artifact, or feedback loop inside the live work. That gives the team an immediate benefit and makes the new behavior easier to repeat.
Key takeaways
Define collaboration around a customer behavior and measurable outcome, not a shared list of deliverables.
Use a product trio as the decision nucleus, involve extended partners while they can still alter the approach, and name one owner for each material choice.
Give important metrics operational definitions. A common dashboard is not a common truth when populations, events, windows, and exclusions differ.
Connect discovery, roadmap planning, delivery, and production learning with small shared artifacts that support explicit decisions.
Treat every release as a test of the outcome contract, supported by controlled exposure, verified instrumentation, customer guidance, and a planned evidence review.
Make outcomes, decisions, roadmaps, metrics, and learning visible so collaboration survives beyond the people who attended the meeting.
Pick the live initiative creating the most coordination friction. Put its outcome contract, metric contract, decision owner, open choices, roadmap trace, and release learning plan on one linked page. At the next working session, resolve the first missing item before discussing more scope. You will make collaboration testable: not by whether people feel aligned, but by whether they can make a sound decision from shared context and learn from what reaches customers.
You can have a capable board, a thoughtful strategy, and employees who want the company to win, yet still lose trust when important decisions emerge from a black box. The risk is especially high for a founder learning the CEO role in public: advice multiplies, board conversations sit outside the company, and the calendar fills with escalations.
If you are trying to remain decisive without becoming opaque or consensus-bound, the answer is not simply to communicate more. You need a visible leadership operating system: a repeatable way to evaluate advice, use the board, explain consequential decisions, translate strategy into decision rights, and spend your own time.
Make your decision method visible before asking for trust
Employees do not need every decision to go their way. They do need to understand how decisions are made. When the method changes with the audience, the politics of the moment, or the founder’s mood, people stop relying on stated priorities and start reading informal signals.
The first distinction to make is whether you are solving an invention problem or an optimization problem.
Invention problems require first-principles reasoning. Product strategy, a new business model, and a consequential organizational design choice often belong here because the company’s constraints and opportunities may be unusual.
Optimization problems usually benefit from established playbooks. Operating cadences, execution rituals, and recurring reviews rarely need to be reinvented by the founder every cycle.
Using a playbook for an invention problem can conceal the most important assumption. Using first principles for every recurring process makes the founder a bottleneck. State which kind of problem you believe you are solving before debating the answer.
For a consequential decision, write a one-page decision brief with six fields:
Problem: What outcome or constraint requires a decision?
Why now: What changes if you wait?
Decision type: Is this invention or optimization?
Options: What credible alternatives were considered?
Recommendation: Which option do you support, and what trade-off are you accepting?
Revisit trigger: What evidence would cause you to reopen the decision?
What exact problem was this advice meant to solve?
Which conditions made it work in the adviser’s company?
Which of those conditions are also true here?
What is the downside if the advice is wrong?
What is the smallest evidence that would confirm or weaken it?
Triangulation is not voting. If three people recommend the same action for incompatible reasons, you do not have consensus; you have three hypotheses. Your job is to identify the invariant, expose the assumptions, and make the decision.
Run the board meeting as a decision system
A quarterly board meeting is too scarce to spend reading slides aloud. The board should receive enough context to challenge management’s reasoning, surface risks, and improve a small number of important decisions. Reporting is necessary, but it should prepare the discussion rather than consume it.
Label every agenda item before the meeting:
Update: Management is informing the board. No decision is requested.
Discussion: Management wants the board to challenge assumptions or add pattern recognition.
Decision: A formal decision or explicit alignment is required.
If an item has no label, the room will invent one. Directors may offer operating instructions when management wanted strategic feedback, or management may present a nearly final choice while pretending to seek input. Both patterns create frustration and muddy accountability.
A useful board packet has four layers:
Shared context: Current priorities, meaningful changes, and important surprises since the previous meeting.
Decision pages: One page for each consequential question, using the same decision-brief structure the executive team sees.
Risk pages: What could invalidate the plan, what leading signals management is watching, and who owns the response.
Commitments: Decisions made, open questions, owners, and the next point at which the board will see progress.
Send the material early enough for directors to react in writing. Use those reactions to identify disagreement before the meeting, then reserve live time for the assumptions and trade-offs that genuinely need discussion. Afterward, record what was decided, what was merely suggested, and who owns the next move. Board advice should inform the management system, not create a shadow reporting line into the company.
The exact boundary between board authority and management discretion depends on the company’s governing documents and applicable law. Treat that as a governance question for qualified counsel, not as an informal convention that can be resolved through meeting etiquette.
Share the board narrative without creating a transparency hazard
When employees hear one strategy from leadership while the board receives another, the gap eventually becomes visible through budget choices, hiring decisions, or sudden priority changes. That is when transparency becomes an organizational trust issue rather than a communication preference.
At Thumbtack, the CEO shared the board deck with the entire company. That is a strong form of openness, but it is not a rule to copy blindly. Board materials may contain individual compensation, private personnel matters, legal advice, security details, financing information, or material related to a pending transaction. Publishing those details can harm employees or create legal and commercial exposure.
Choose the highest safe level of disclosure rather than treating transparency as all or nothing:
Full internal deck: Appropriate when the material was designed for broad internal visibility and has been reviewed for confidential content.
Redacted deck: Preserve the strategic argument and operating data while removing restricted pages or fields.
Employee narrative: Publish the situation, priorities, decisions, trade-offs, and measures in a separate document when the board packet cannot safely circulate.
Manager cascade: Use only when details are highly sensitive, and give managers an exact narrative rather than asking each person to interpret the decision independently.
My rule is simple: protect people and legitimately confidential information, but do not use confidentiality as a blanket excuse to hide the logic of the business. Employees can usually be told what changed, which choices followed, what the company will stop doing, and how progress will be evaluated even when some underlying details must remain private.
Review sensitive disclosures with the appropriate legal, people, security, or finance leader before publishing them. The safe alternative to releasing a restricted board deck is a purpose-built employee version, not silence.
After a hard decision, explain what changes on Monday
Trust after a layoff, restructuring, missed plan, or major strategic reversal does not come from making the decision sound painless. It comes from making leadership’s reasoning and the new operating reality legible.
The leadership work following Thumbtack’s COVID-related layoff centered on consistent communication, explicit priorities, and a clear framework for what would happen next. Those elements matter because the people who remain are evaluating more than the explanation for the past. They are asking whether the new plan is credible and whether leadership will behave predictably under pressure.
A complete communication should answer six questions in this order:
What changed? Name the business condition or constraint directly. Avoid euphemisms that force employees to decode the message.
What decision was made? State the scope without burying it beneath context.
Why this decision? Explain the criteria and the alternatives that were rejected.
What changes now? Identify priorities that stop, start, or narrow. A smaller organization cannot credibly carry the same workload with fewer people.
What remains uncertain? Separate known facts from open questions. Do not manufacture confidence by turning assumptions into promises.
When will leadership update the company? Name the next operating forum or decision checkpoint, then use it even if the update is that uncertainty remains.
Managers also need direct answers to the questions employees will reasonably ask: Were the criteria applied consistently? Has the workload changed with the headcount? Which targets still stand? Who now owns interrupted work? Where can someone raise a concern privately?
Do not delegate this translation entirely to middle management. If each manager must invent the meaning of an executive decision, employees will experience several versions of reality. Give managers the same core facts, the same decision logic, and explicit permission to distinguish what is known from what is not.
Where employment law, individual circumstances, or contractual obligations are involved, have qualified legal and people professionals review what can be communicated. Transparency does not justify disclosing another person’s private information.
Convert the company narrative into local decision rights
A transparent strategy still fails if teams cannot use it to make trade-offs. People may understand the destination while continuing to escalate every route choice to the founder.
Your shared narrative needs five practical components:
Situation: What is true about the company, customer, and current constraint?
Priorities: Which outcomes matter most in this planning period?
Non-priorities: What attractive work will not receive attention now?
Measures: What evidence will show whether the choices are working?
Decision rights: Which choices belong to the board, founder, executive team, function leader, and product team?
Then translate that narrative through the operating system. Every material roadmap item should map to a declared priority. Sprint planning should expose work that does not. Outcome-based goals should measure the intended change rather than merely count completed projects. An escalation should identify the decision boundary that a team cannot cross, not simply announce that a problem feels important.
You can test whether the narrative is usable by asking several managers the same four questions independently:
What are the company’s most important outcomes right now?
What has leadership explicitly chosen not to prioritize?
Which trade-offs can your team make without executive approval?
What evidence would cause leadership to change direction?
If the answers vary materially, do not solve the problem with another broad town hall. Correct the shared artifact. Clarify the missing decision right, conflicting priority, or undefined measure, and use the revised version in the next roadmap, goal, and resource discussion.
Use the founder’s calendar as an accountability record
A founder’s calendar is where strategy becomes observable. If leadership declares that product quality, executive hiring, or a strategic transition is critical while the founder’s time remains dominated by recurring approvals and operational rescues, the organization will believe the calendar.
Run a weekly schedule audit using the following sequence:
Tag the completed week: Strategy, customers and product, talent, board and capital, operating reviews, or escalations.
Map each block to a stated priority: A meeting can be useful and still be unrelated to the company’s most important outcomes.
Mark founder-only work: Identify decisions, relationships, and messages that genuinely require your authority or context.
Inspect recurring rescues: Repeated intervention often points to unclear ownership, a missing capability, or a broken operating mechanism.
Change the next week: Delegate, cancel, shorten, or redesign work that does not justify founder attention, then reserve time for the priorities being crowded out.
Do not optimize for an aesthetically balanced calendar. Priorities are not equal, and some weeks will be shaped by a real incident or consequential decision. The purpose is to spot persistent contradiction: work that leadership repeatedly calls important but never schedules, and work that consumes executive attention without earning it.
Pair each major company outcome with a calendar commitment and an accountability partner, such as a board member, executive, or chief of staff. The question is not whether the founder was busy. It is whether founder-specific attention reached the constraints that mattered.
Key takeaways
Classify consequential decisions as invention or optimization before choosing between first principles and a playbook.
Give every board agenda item a clear purpose: update, discussion, or decision.
Share the strategic logic of board conversations at the highest level that is safe for employees.
After a hard decision, explain what stops, starts, remains uncertain, and happens next.
Audit the founder’s calendar weekly because repeated time allocation reveals the company’s real priorities and unresolved ownership gaps.
Start with one live decision before your next board cycle. Write the decision page, use it in the meeting, publish a safe version of the resulting narrative, and then inspect whether the following week’s calendar reflects the choice. Organizational trust grows when people can see the same logic move from the boardroom into priorities, decisions, and leadership behavior.
