I’ve been closing the year with a deliberate reflection ritual for more than a decade, and this season I found fresh energy for it after listening to an insightful conversation with Teresa Torres and Petra Wille on All Things Product. Their approaches mirror the evolution many product leaders experience: moving from rigid annual goal-setting to values-led themes, longer time horizons, and a healthier respect for spaciousness. In my own practice, that shift has created better focus, less pressure, and far more meaningful outcomes.
Prefer to listen? You can find this episode here: Spotify | Apple Podcasts. I took notes with my team in mind and translated the discussion into a simple, values-driven framework that any product organization can adopt.
Why does annual reflection matter for product people? Because our work lives at the intersection of ambiguity, trade-offs, and time. If we only measure ourselves by shipped output or quarterly OKRs, we overlook the compounding value of learning, relationships, and judgement. I treat this ritual as a strategic reset: a chance to surface patterns, adjust expectations, and recommit to outcomes over output.
My own reflection habit started scrappy—paper notebooks, messy timelines, and even artful visualizations inspired by Dear Data by Giorgia Lupi & Stefanie Posavec. Like Petra, I’ve found that tactile, analog artifacts unlock insights I miss in a spreadsheet. Over time, I’ve kept the spirit and simplified the mechanics: a “what went well” review, a short list of hard lessons, and a handful of decisions that paid off—or didn’t.
The biggest evolution for me has been moving from rigid annual goals to values and themes. I still run OKRs, but I use them to track progress, not identity. The lens of process vs. outcome goals—reinforced by ideas from Atomic Habits—helped me set fewer, better commitments. For example, instead of “launch X by Y,” I’ll emphasize the cadence of customer discovery, the health of the product trio, and the quality of decisions made along the way.
One exercise that changed my practice is the “100 wishes” list. It’s powerful—and surprisingly difficult. Pushing past 30 or 40 wishes forces me to name latent interests and long-range intentions I rarely say out loud. Combined with decade-level themes, the list helps me balance ambition with patience. I don’t try to do it all next year; I use it to spotlight direction, not deadlines.
I also review patterns across years: Where did over-scheduling create hidden costs? When did I protect focus time and what did that unlock? Paul Graham’s Maker’s Schedule, Manager’s Schedule remains a useful calibration tool here. And when I feel the pull toward constant throughput, I revisit Stefan Sagmeister’s The Power of Time Off (TED Talk) to remind myself why strategically creating space often yields the most valuable ideas.
Of course, not every year follows plan—and that’s normal. Reflection helps me spot unrealistic expectations early and let them go. When setbacks hit, I’ll rewatch Dealing with Setbacks and re-ground in continuous discovery. The question isn’t “Did we do everything?” but “Did we learn fast, protect customer value, and make trade-offs aligned with our values?” That’s how empowered product teams compound impact.
My sharing philosophy has become more nuanced over time. Some reflections are public to invite dialogue and accountability; others stay private so I can process honestly. I’ve found it helpful to publish what I’m saying no to, capture a theme for the year ahead, and keep the rest for myself and my team. This balance preserves motivation while still contributing to the broader product management leadership community.
If you’re designing your own ritual, consider this lightweight flow: review wins and tough calls, write your “100 wishes,” extract a few values-based themes, then translate those into process goals for Q1. Revisit monthly, not just annually. If you like structured prompts, Chris Guillebeau’s How to Conduct Your Own Annual Review from The Art of Nonconformity offers a practical template you can adapt to your context.
For deeper dives and complementary ideas, I bookmarked these as part of my year-end reset: What I’m Saying No to This Year—And Why, Ask Teresa: My Leaders Still Want Roadmaps with Timelines—What Should I Do?, Scaling Impact: A Look at the Year Ahead (2022), Let’s Connect in 2025: A Look at the Year Ahead, The Interview Coach, and Petra’s own year-ahead reflections (here and her 2026 version). I also recommend revisiting the prior conversation on leadership and change: Role of Leadership in Transformations.
I’d love to hear how you approach your end-of-year reflection. What questions bring you the most clarity? Which practices help you set an intentional, values-driven path for the next year? Share your process—I’m always looking to learn from other product creators and leaders.
You are looking at a roadmap full of credible near-term work, yet none of it seems likely to change your company’s position. The team is busy, customers are asking for improvements, and every investment has a reasonable explanation. What is missing is a clear connection between today’s choices and the company you want to become.
Long-horizon company building solves that problem only when it changes how you allocate capital, sequence capabilities, learn from customers, and stop work. A 25-year ambition is not permission to wait longer for results. It is a decision filter that helps you distinguish compounding investments from activity that merely fills the next planning cycle.
Choose a problem that becomes more defensible with time
Not every company should play a decades-long game. Time does not rescue weak demand, an undifferentiated product, or a market whose underlying problem is disappearing. A long horizon is useful when the work required to serve customers creates assets that become more valuable as they accumulate.
Before you commit to a long-horizon strategy, test the problem against a few concrete conditions:
The pain is structural. Customers are constrained by an enduring workflow, infrastructure dependency, procurement model, or service failure. The opportunity does not depend entirely on a temporary technology cycle.
Frustration and switching costs are both high. Switching costs alone protect incumbents. Frustration alone can produce shallow demand for a convenient feature. When customers are dissatisfied but cannot change easily, a substantially better end-to-end experience can open a durable market.
The solution requires cumulative capability. Reliability knowledge, operational data, installation expertise, distribution, hardware, service operations, or customer trust should improve with continued use. If a new entrant can reproduce your advantage quickly, waiting longer will not make the business stronger.
The first product creates credible adjacencies. Expansion should follow the same customer, capability base, or service promise. A list of unrelated markets is not a platform strategy.
The customer outcome can support the business model. The way you charge should reinforce the result customers buy, rather than reward complexity they would prefer to avoid.
The sharpest test is simple: explain why the company should be structurally better after years of serving customers. Your answer must identify a mechanism. More telemetry may improve diagnosis. More deployments may reduce installation risk. Deeper workflow integration may increase the value of adjacent services. Trust may lower the friction of adopting the next product. Merely having more customers or more features is not enough.
A useful thesis takes this shape: for a specific customer, a costly problem will persist because of a structural constraint; repeatedly building a named capability will improve a defensible advantage; controlling certain interfaces is necessary to deliver the promise; and observable evidence will tell you when the thesis is weakening.
If you cannot complete that logic without relying on market size, ambition, or executive conviction, you do not yet have a long-horizon strategy. You have a long-range hope.
Convert a 25-year belief into present-day decisions
A decades-long horizon should not produce a decades-long roadmap. The farther out you look, the less credible feature-level precision becomes. Preserve the direction while making the route explicitly revisable.
Separate your strategy into three layers:
Enduring commitments: the customer you serve, the problem you believe will remain important, the experience you intend to make possible, and the principles you will not trade away casually.
Revisable hypotheses: the product architecture, distribution motion, ownership boundary, pricing model, and capability sequence that currently appear most likely to deliver the promise.
Disposable work: features, prototypes, internal systems, campaigns, and implementation choices. These deserve no protection beyond the evidence they produce.
This separation prevents two common errors. The first is strategic thrashing: changing the destination whenever a current bet disappoints. The second is strategic stubbornness: defending a failed implementation because it has been wrapped in the language of mission.
Meter provides a useful example of the distinction. The company maintained its commitment to a full-stack networking service while spending more than four years in early research and development. It also discarded about a year of operating-system work. The durable thesis survived; a costly implementation did not. That is what conviction looks like when it remains accountable to learning.
At each planning cycle, require every major initiative to answer four questions: Which lasting capability will this build? What customer evidence should it produce? What finding would cause you to reshape or stop it? What are you deliberately declining so the investment receives enough attention?
The stop condition matters most. Without one, patient capital quietly becomes protected capital. Teams learn to explain delays instead of testing assumptions. Write the condition while enthusiasm is high, before sunk costs and personal identity enter the decision.
Key takeaways
Use a long horizon to define durable commitments, not detailed forecasts.
Fund work that compounds a named capability or reduces a consequential uncertainty.
Protect the customer problem and company promise, not the current implementation.
Give every major bet observable evidence and an explicit stop condition.
Treat abandoned work as a valid strategic outcome when it prevents a larger misallocation.
Own only the stack required to keep the promise
Vertical integration is neither inherently bold nor inherently wasteful. It is justified when a layer you do not control repeatedly prevents you from delivering the outcome customers believe they purchased.
Start with the promise, not the architecture. Map the complete path from customer intent to customer outcome:
How the customer evaluates and buys the product
How the product is installed, configured, and activated
Which interfaces determine performance and reliability
What telemetry reveals failure before or after the customer notices
How support diagnoses and resolves a problem
Which service commitment makes the outcome commercially credible
Mark every point where an external dependency can break the promise. Then ask whether tighter integration would materially improve the experience and whether the capability will compound across customers or future products. Own a layer when both answers are strong. Keep partnering when the dependency is replaceable, the layer is genuinely commodity-like, or internal ownership would add cost without improving the customer outcome.
This prevents full-stack ambition from turning into organizational vanity. Building hardware, software, installation operations, support tooling, and service delivery at once creates many ways to fail. The burden of proof belongs with the added ownership. Each new layer should remove a specific failure mode, improve a measurable part of the promise, or unlock a strategically important product that would otherwise remain impossible.
Physical-product teams should also treat geography as part of the operating design. When design, manufacturing, and iteration depend on one another, physical proximity can compress feedback loops. Meter used Shenzhen in this way during its development. The general lesson is not that every hardware company needs the same location. It is that organizational geography should follow the bottleneck: put the people making interdependent decisions close enough to learn at the speed the product requires.
The business model belongs in the same analysis. If customers want an outcome but must assemble vendors, equipment, installation, and support themselves, packaging the complete experience as a service can reduce complexity and clarify accountability. Service commitments then become part of the product, not language added after the product is built. The company earns recurring revenue by continuing to deliver the outcome, which aligns incentives more closely than a transaction that ends when equipment changes hands.
Distribution should reinforce learning during the early stages. A direct sales motion gives product and commercial leaders access to the buyer’s language, objections, procurement constraints, implementation concerns, and definition of value. That access is especially important when you are trying to establish seller-market fit: the ability to identify the right buyer, explain the value consistently, navigate the buying process, and deliver what was sold.
Before adding channel distance, verify that target buyers recognize the same problem, objections fall into understandable patterns, sales commitments survive the implementation handoff, and the economics support the promised service. A channel can scale a repeatable motion. It cannot repair one that the company does not yet understand.
Replace planning theater with a customer-learning system
Removing OKRs does not create focus. It removes one alignment mechanism. If you do not replace it with a visible decision system, priorities will depend on executive proximity, persuasive storytelling, and whichever escalation arrived most recently.
A lightweight operating system still needs a few explicit artifacts:
A strategic narrative: the customer problem, the long-horizon thesis, the current constraint, and the choices the company is making because of them.
A primary customer-value measure: evidence that the promised outcome is actually occurring, not merely that work shipped.
Guardrails: reliability, service, economics, or trust conditions that must not deteriorate while the primary outcome improves.
An unhappy-customer ledger: a shared record of broken promises, stuck use cases, escalations, and gaps between what was sold and what was delivered.
A decision log: the assumption behind each consequential choice, the evidence available at the time, the owner, and the condition for revisiting it.
The unhappy-customer ledger is often more useful than another aggregate dashboard. A satisfaction score compresses many experiences into one number. An escalation exposes the precise boundary where your product, service, sales process, or ownership model failed.
For every serious case, capture the customer’s intended outcome, the point at which progress stopped, the expectation that was violated, the immediate resolution, and the systemic change required. Classify that change as product, operations, sales, support, or ownership-boundary work. Then look for recurring failure modes across cases.
Do not let this become a larger support queue. Closing the individual ticket is necessary, but the strategic value comes from removing the class of failure. If customers repeatedly struggle during installation, the answer may be a better workflow, different telemetry, a narrower promise, or ownership of an interface that has been treated as someone else’s problem.
This system also clarifies empowerment. A product team should know the outcome it owns, the constraints it must respect, the decisions it can make independently, and the conditions that require escalation. Empowerment without a clear outcome produces local optimization. Authority without proximity to customer evidence produces slow, brittle decisions.
The same clarity applies to performance problems. A company cannot preserve a long horizon while allowing unresolved role or behavior gaps to consume the team’s attention. Define the gap, the expected standard, the support available, the decision owner, and the process for reaching a fair conclusion. Move quickly toward clarity, while still following the appropriate people process. Delayed ambiguity is not patience.
Make patience accountable in your next strategy review
Long-horizon work will contain periods when visible output understates real progress. Research, infrastructure, reliability, manufacturing, and operational design may need to mature before customers see the complete benefit. The leadership challenge is to distinguish that legitimate incubation from drift.
Patience is working when the core customer thesis remains supported, important uncertainties are being resolved, a reusable capability is getting stronger, and customer failures are becoming better understood or less frequent. The dates may move, but the quality of evidence improves.
Drift looks different. Milestones move without producing new knowledge. Teams defend work by describing its difficulty or the effort already invested. The same customer failures return without a systemic response. Adjacent products receive attention before the original promise is dependable. Leadership keeps adding resources because it has not defined what would justify stopping.
Review the portfolio by decision, not by project status. Continue work that compounds a necessary capability. Reshape work when the thesis remains sound but the current method is failing. Stop work whose original assumption no longer holds. Keep adjacent opportunities separate until the core business has earned the capacity to pursue them.
You can run the review with the following sequence:
Write the customer promise in language a buyer would recognize.
Name the structural reason the problem should remain worth solving.
Identify the capability that should become more valuable as the company learns.
Map the interfaces, operations, and commercial dependencies that can break the promise.
Examine recent unhappy-customer cases for repeated failure modes.
For every major investment, write the evidence expected and the condition that would cause a change of course.
Remove work that neither improves the current promise nor builds a required future capability.
Assign the next consequential decision to a named owner with access to the relevant customer evidence.
Do not leave that review with a more elaborate long-range deck. Leave with fewer bets, clearer ownership, explicit learning goals, and at least one piece of work you are prepared to stop.
At your next planning meeting, ask which current investment will make the company structurally better at solving its chosen problem. If nobody can name the capability, the evidence, and the customer promise it serves, pause the work before time turns activity into strategy by accident.
References
Shivam.Consulting Blog — Playing the 25-Year Game: Rethinking Networking, Ditching OKRs, and Owning the Full Stack
Product analytics isn’t a specialist’s sport—it’s a team capability. In my role leading product teams, I’ve seen designers, engineers, marketers, and customer success partners uncover insights that shape strategy, accelerate product-led growth, and improve outcomes for customers. When we demystify the basics and bring analytics into everyday decisions, we build truly empowered product teams.
Here’s the core promise of this approach: "Learn the product analytics fundamentals of funnels, retention, and conversion drivers so that anyone can confidently answer key product questions." That line has guided how I teach product managers to think—start with the essentials, tie them to real customer behaviors, and make the work repeatable across the organization.
I start with funnels because they tell a story—the journey from discovery to value. A simple example: track the path from sign-up to user activation to the first value event. This reveals where onboarding succeeds or stalls, what friction blocks adoption, and which moments are ripe for optimization. With tools like Amplitude analytics or Pendo, we can break down conversions by segment, channel, or feature usage to isolate where improvements matter most.
Next comes retention analysis, the clearest signal that we’re building something customers choose to return to. Cohort analysis shows who comes back and when; retention curves show where value compels a second, third, and tenth use. Tie retention to activation milestones and the outcomes customers achieve—not just logins—and you’ll quickly spot whether your product discovery assumptions hold up in the wild. A unified analytics platform makes these insights discoverable and repeatable across teams.
Conversion drivers round out the picture. Once the funnel is clear and retention is stable, I look for the behaviors and experiences that predict success: feature combinations, time-to-value, message timing, or supportive content. Whether in Amplitude analytics or Pendo, correlating these drivers with outcomes lets us prioritize roadmaps with confidence. Pair this with continuous discovery—qualitative interviews, in-product feedback, and rapid experiments—and you’ll move from interesting data to decisive actions.
This is how we build empowered product teams: by making analytics a daily habit rather than a quarterly report. We bring insights into roadmap reviews, design critiques, and sprint planning; we celebrate learning from experiments as much as shipping features; and we hold ourselves accountable to customer outcomes, not just output. When everyone can interpret funnels, discuss retention, and isolate conversion drivers, we make smarter bets faster.
If you’re getting started, keep it simple. Define a clear activation metric, instrument the top of your funnel, and track a small number of cohorts. Share a weekly readout with highlights, surprises, and questions to investigate. Over time, stitch insights into narratives that drive product-led growth—and, most importantly, help customers achieve what they came for.
Product analytics isn’t just for analysts. It’s a shared language for product discovery, onboarding excellence, user activation, and long-term retention. When we practice it together, we build better products and stronger teams.
Inspired by this post on Amplitude – Best Practices.
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.
Your AI agent is resolving enough conversations that queue volume is no longer a useful blueprint for organizing the team. Yet your org chart still assumes that every customer outcome belongs to a human agent. The result is a dangerous ownership gap: everyone can recognize a poor AI interaction, but no one is clearly responsible for the content, behavior, action, or handoff that caused it.
The decision in front of you is not simply which jobs AI will remove. It is which responsibilities become more important, who should own them now, and when that work deserves a dedicated role. You can answer those questions before adding headcount.
The unit of work has shifted from tickets to systems
A human-owned ticket usually has a visible assignee, a queue, and a closed state. An AI conversation can fail much earlier in the system. The policy may be stale. The right knowledge may exist but be difficult to retrieve. The response may be accurate but confusing. A backend action may fail. A handoff may reach a person without the context needed to continue.
If you classify all of those outcomes as generic AI accuracy problems, the team will spend its time rewriting prompts while structural defects remain untouched. Diagnosis has to begin with the layer that failed.
Knowledge: Did the system have an accurate, current, and unambiguous basis for answering?
Conversation: Did it communicate clearly, follow policy, and recognize when it should stop or escalate?
Action: Could it complete the requested task safely and confirm the result?
Operations: Could the organization detect the failure, assign it, correct it, and verify that the correction worked?
Start with a simple accountability rule: every layer needs one named owner. Several people can contribute, but shared contribution is not shared accountability. If nobody has the authority to prioritize a correction and see it through, performance will drift between support, product, engineering, and content teams.
Assign four ownership roles before opening four requisitions
I would not begin by hiring four specialists. I would begin by assigning four explicit responsibilities to people who already understand the customers, policies, tools, and failure modes. A dedicated job becomes necessary when the work is continuous, consequential, and repeatedly displaced by the owner’s primary role.
AI operations lead: owns performance and improvement
The AI operations lead is accountable for day-to-day performance. This person maintains the quality view, classifies recurring failure modes, prioritizes corrections, and coordinates changes across support, product, data, content, and engineering.
This is not a meeting coordinator or a person who manually edits every weak response. The role needs enough operating authority to decide which problems deserve attention and enough analytical depth to separate isolated bad conversations from systemic patterns. Support operations is often a strong internal starting point because the function already understands workflows, tooling, routing, and capacity.
The first useful deliverable is an AI performance register. For each recurring issue, record the affected customer intent, observed outcome, failure layer, accountable owner, proposed change, validation method, and current status. That register becomes the shared backlog for the AI support system.
A good decision boundary is equally important: the operations lead prioritizes what must improve, while the relevant domain owner decides how to change knowledge, conversation behavior, or automation. Otherwise, one person becomes a bottleneck for every adjustment.
Knowledge manager: owns what the AI is allowed to know
The knowledge manager owns the material that grounds customer answers: help content, internal procedures, macros, snippets, policy explanations, and the relationships between them. The job is not merely publishing more documentation. It is making sure the AI has one dependable answer for each supported question.
Conflicting content is often more damaging than missing content because the system can produce a plausible answer from the wrong instruction. Every important knowledge item should therefore have a clear owner, audience, scope, status, and review trigger. Product or policy changes should update the source of truth before teams try to compensate through prompt wording.
The first useful deliverable is a knowledge inventory organized by customer intent. Mark where content is missing, duplicated, contradictory, overly broad, or dependent on information the AI cannot reliably access. This turns an abstract content audit into a prioritized quality backlog.
Measure this role by whether knowledge-related failures become easier to prevent and diagnose. Page count is an output. Dependable answers are the outcome.
Conversation designer: owns how the AI behaves
The conversation designer defines how the AI communicates and how an interaction progresses. That includes tone, question sequencing, explanation structure, confirmation language, boundaries, escalation triggers, and the context passed to a human agent.
This role is broader than polishing wording. A response can be factually correct and still produce a poor outcome because it is too confident, asks for information in the wrong order, buries a constraint, or continues after the situation calls for human judgment. Conversation design turns brand, policy, and customer-experience expectations into observable behavior.
The first useful deliverable is an interaction specification for each important intent. It should define the customer’s likely goal, information required, acceptable response structure, prohibited claims, escalation conditions, action confirmation, and handoff payload. That specification gives QA something concrete to evaluate and gives the automation specialist a stable flow to implement.
Content design, UX writing, and support enablement are natural backgrounds for this work. The essential skill is not clever phrasing. It is recognizing how small language and sequencing choices affect comprehension, trust, and completion.
Support automation specialist: owns safe execution
The automation specialist connects customer intent to business systems. This person builds and maintains the workflows that let an AI agent retrieve account-specific information, update a record, initiate an approved process, or complete another backend task.
This is the role that moves AI support from answering to resolving. It also introduces a different class of risk. A weak answer can be corrected in conversation; a wrongly executed refund, cancellation, permission change, or account update can create financial loss, access problems, or corrupted state. Begin with reversible, bounded actions. Enforce identity, authorization, business rules, and transaction limits outside the language model, and preserve a human path when the system cannot establish that an action is safe.
The first useful deliverable is an action catalog. For each action, document the eligible intent, required inputs, source system, authorization rule, success response, known failure states, recovery path, and human fallback. Do not enable an action merely because the model can call it.
Support engineering, systems administration, solutions engineering, and tooling operations can all supply the necessary background. The role must be able to work with product and engineering without waiting for those teams to own every support-specific workflow.
Organize around human support, AI support, and optimization
Resolve complex, sensitive, ambiguous, and exception-driven customer needs
What requires judgment? What should be escalated? What are people learning that the system does not yet know?
AI Support
Own automated knowledge, behavior, actions, and continuous performance improvement
Where does the AI succeed or fail? What change will improve the outcome? Who can safely approve that change?
Support Operations and Optimization
Provide tooling, analytics, enablement, QA, workflow design, and capacity planning
Can performance be measured? Can failures be routed to an owner? How should human capacity change as automation coverage changes?
The reporting lines can vary. The interfaces cannot. Before debating where each role sits, write down how work crosses the boundaries.
Human Support to AI Support: Frontline agents provide structured evidence about missing knowledge, failed automation, confusing language, and escalation gaps. A collection of anecdotes is not enough; feedback needs an intent and a failure category.
AI Support to Human Support: A handoff carries the customer’s goal, relevant context, questions already asked, actions attempted, confirmed results, and remaining uncertainty. The customer should not have to reconstruct the conversation.
Operations to both: Operations supplies the measurement, workflow, tools, and change process needed to turn observed failures into verified improvements.
Product and engineering partnership: Support owns the customer problem and operating priority. Product and engineering own changes that affect the core product, shared platform, security boundary, or technical architecture.
Make decision rights explicit as well. Name who can publish source knowledge, change conversational behavior, enable or disable an action, alter handoff rules, accept residual risk, and declare a correction ready. Without these boundaries, teams either move recklessly or wait for broad consensus on routine changes.
Transition the current team without hiring ahead of the work
Most organizations do not need a separate AI department on the first day. They need visible ownership. Distributing the responsibilities across existing people lets you prove where the workload and leverage actually sit before converting responsibilities into job titles.
Map recent failures to ownership layers. Classify each meaningful problem as knowledge, conversation, action, or operations. If the team cannot classify it, that ambiguity is itself an operations problem.
Put a person’s name beside every layer. Avoid team names such as Support Ops or Product. A team cannot make a decision; an accountable owner can.
Give each owner an artifact and decision boundary. Use a performance register, knowledge inventory, interaction specification, and action catalog so that the role produces something inspectable.
Run the work on a fixed operating cadence. Review outcomes, inspect representative conversations, assign root causes, prioritize changes, and check whether previous corrections held.
Formalize the role when borrowed capacity stops working. A dedicated hire is justified when the responsibility is continuous, affects important outcomes, and repeatedly loses priority to the owner’s original job.
The existing support functions should evolve at the same time:
Frontline agents spend less time repeating known answers and more time resolving exceptions, preserving trust in difficult moments, and supplying structured feedback about system weaknesses.
Enablement teaches agents how to receive AI handoffs, identify failure layers, use AI-generated context critically, and submit feedback that another owner can act on.
Quality assurance expands beyond grading agent conversations. It evaluates the end-to-end customer outcome, including AI behavior, action results, escalation decisions, and continuity after handoff.
Workforce management plans for automation coverage and the type of work reaching people, not only gross inbound volume. Lower human volume can still demand substantial capacity when the remaining cases are more complex.
Support leadership becomes a player-coach responsibility. The leader must understand performance data and system behavior well enough to guide priorities while helping people move into unfamiliar work.
Do not treat the move as a title-renaming exercise. A knowledge manager without publishing authority, an operations lead without a performance view, or an automation specialist without access to technical partners will reproduce the old model under new labels.
This transition can also create credible internal career paths. Analytical support-operations talent can grow into AI operations. Content and enablement specialists can move toward knowledge or conversation design. Technically inclined support staff can develop into automation. Frontline experts with strong policy judgment can contribute to knowledge governance, QA, and escalation design. The best candidate is often the person who already understands where customer intent and company systems fail to meet.
Run AI support as a product, not a side project
An AI support system changes whenever its knowledge, instructions, workflows, integrations, policies, or underlying product changes. It therefore needs a product-like operating loop: observe an outcome, diagnose the responsible layer, change the right artifact, validate the result, and watch for regression.
The scorecard should distinguish customer outcomes from automation activity. An impressive volume metric can hide poor resolution, unnecessary handoffs, or actions that appear successful but do not complete in the business system.
Resolution quality: Did the customer achieve the intended outcome, rather than merely receive a response?
Handoff quality: Was escalation appropriate, correctly routed, and supplied with enough context for a person to continue?
Action reliability: Did the requested action complete, produce the expected state, and recover safely when it failed?
Knowledge health: Which failures came from missing, stale, conflicting, or poorly scoped information?
Customer signals: Do repeat contacts, corrections, abandonment, or explicit dissatisfaction indicate that an apparently completed interaction did not work?
Coverage: Which customer intents are eligible for automation, and which remain deliberately human-owned?
Human workload: What volume, complexity, and urgency reach agents after automation and handoffs?
Segment these measures by customer intent. A single aggregate can conceal a reliable password-reset flow beside a weak billing or cancellation flow. Intent-level views also make ownership clearer: you can connect a measurable outcome to the knowledge, conversation specification, action workflow, and escalation rule behind it.
During an operating review, resist the urge to solve every failure by changing the prompt. First classify the root cause. Correct the source material when the knowledge is wrong. Change the interaction specification when the behavior is wrong. Repair the workflow when an action is wrong. Improve instrumentation or accountability when the organization cannot tell what happened.
The leader’s job is to keep that loop moving. AI support needs someone who can move between customer experience, operational data, content, and technical constraints. Pure people management is insufficient, but so is pure systems administration. The effective leader coaches the people while actively shaping the system they operate.
Key takeaways
Organize AI support around four accountable layers: operations, knowledge, conversation, and action.
Assign the responsibilities before creating dedicated positions; hire when continuous ownership can no longer fit beside an existing role.
Connect Human Support, AI Support, and Support Operations through explicit handoffs, feedback contracts, and decision rights.
Evolve enablement, QA, workforce management, and leadership around system outcomes rather than ticket throughput.
Measure resolution, action reliability, handoff quality, and knowledge health by customer intent, then fix the layer that actually failed.
Your first move should be small but explicit. Pull recent AI failures, classify each one into the four ownership layers, and put a person’s name beside every layer. Then publish what each owner may change and how the team will verify that a correction worked.
Do that before requesting a new organization chart. Once the work is visible, you will know which responsibilities can remain distributed and which have become real jobs. More importantly, your customers will no longer depend on an AI system that everybody observes but nobody owns.
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.
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.
Inside-out or outside-in thinking? I choose both. The strongest product strategies fuse a bold internal vision with relentless customer evidence, creating a flywheel that lifts adoption, engagement, and revenue while reducing risk.
When I lead with inside-out thinking, I articulate a clear product thesis, technical roadmap, and platform leverage. This is where we define points of parity and differentiation, sharpen our value proposition, and ensure our architecture scales. It’s disciplined, outcomes-first, and anchored in product positioning—not output checklists.
Outside-in thinking ensures that vision stays honest. I listen to customers, analyze friction in onboarding, instrument user activation, and study retention analysis to validate whether our promises translate into real user value. This is where product discovery, A/B testing, and in-app signals tell me what’s working, what needs refinement, and what we should stop doing.
In practice, I operationalize this balance through Software Experience Management. “Increase revenue, cut costs, and reduce risk with Pendo’s Software Experience Management platform. Optimize the entire software experience to drive adoption and improve engagement.” That promise captures the core of how I align strategy with reality inside the product, not just around it.
Concretely, I combine product analytics with in-app guides and product tours to accelerate onboarding and improve user activation. I run targeted experiments to de-risk decisions, and I iterate quickly based on what users actually do—not just what they say. The result is a product-led growth engine that compounds over time.
This approach also builds trust with finance and go-to-market partners. Inside-out clarity gives us confident, sequenced bets; outside-in data provides proof that those bets pay off. When engagement expands and adoption climbs, the business case writes itself.
If you’re deciding where to start, begin with three moves: define activation events aligned to your value proposition, instrument the experience end-to-end, and ship one high-impact in-app guide to remove a known onboarding blocker. Then measure, learn, and iterate—quickly.
The truth is, great products emerge when conviction meets evidence. Inside-out sets the vision. Outside-in earns the right to scale it.
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.
Time to value is the most reliable early indicator of long-term user retention I know. When customers experience meaningful product impact fast, they stick around, expand, advocate, and cost less to support. Over the years leading product teams, I’ve learned that speed-to-impact isn’t a nice-to-have—it’s the engine behind sustainable product-led growth and efficient go-to-market.
Accelerate retention by reducing time to value. Learn how faster product impact drives growth, reduces costs, and keeps users engaged in the long term.
Practically, I define time to value as the duration from first touch (or first login) to the moment a user achieves their “aha” outcome—something tangibly useful aligned to their job-to-be-done. The shorter that journey, the higher the likelihood of user activation, trial conversion, and durable engagement. This is why I obsess over onboarding, in-app guides, product tours, and the clarity of our value proposition.
My first move is to map the Minimum Path to Value (MPV): the smallest set of actions needed to deliver a real result for a new user. I strip away everything non-essential in that path—fields, clicks, choices, and jargon. Opinionated defaults, smart templates, sample data, and single-player workflows let customers succeed in minutes, not days. The goal is to reduce cognitive load while making the next best action unmistakably clear.
Instrumentation turns TTV from a hunch into a system. I track activation events, cohort retention, and conversion using platforms like Amplitude analytics and Pendo, with timely nudges through Intercom when users stall. I look at the distribution of TTV (not just the average), correlate it with retention analysis, and set explicit targets such as “new users reach first value within 10 minutes.” Those targets become team-level outcomes—not outputs—and we review them weekly.
Experimentation is how we iterate toward the fastest path to value. I rely on A/B testing to compare onboarding flows, progressive profiling to delay non-critical inputs, and opinionated setup wizards to remove guesswork. Auto-generated example projects, pre-configured integrations, and guided checklists accelerate user activation without sacrificing flexibility for advanced users.
Content and guidance matter as much as UX. Tooltips, contextual in-app guides, and short product tours should be timely, skippable, and laser-focused on the outcome, not the feature. I pair these with a concise knowledge base and short explainer videos that reinforce the same value narrative a user sees inside the product.
Cross-functional alignment is essential. Product, marketing, sales, and customer success must rally around the same activation metric and TTV target. That alignment ensures our trial messaging, onboarding emails, and CS playbooks don’t compete—they compound. When everyone points to the same first-value moment, friction drops and adoption rises.
Pricing and packaging can also accelerate time to value. Free trials should be long enough for users to credibly reach first value; usage-based gates should never block the MPV. I prefer to unlock everything needed to hit the “aha” moment, then meter after the value is viscerally felt—this respects the user’s time and reinforces trust.
There’s a cost story, too. Faster time to value reduces tickets, shortens onboarding cycles, and lowers cost-to-serve. It also clarifies product discovery: when we see where users stall, we don’t guess at roadmap priorities—we let the data guide our next bet.
In my experience at HighLevel, I’ve repeatedly seen activation rates jump when we cut time to value from days to minutes. The specific tactics vary by product, but the pattern holds: when the first outcome is undeniable and fast, retention follows—and so does efficient growth.
If you’re looking for a starting point, try this: define one activation event that clearly signals value, instrument it end-to-end, design a Minimum Path to Value that gets new users there in under 10 minutes, and run weekly experiments until you consistently hit the target. Do that, and you won’t just improve onboarding—you’ll build a product that earns loyalty from the very first session.
Inspired by this post on Amplitude – Best Practices.
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/
I treat agent performance analytics as a strategic product lever, not a back-office metric. When I combine Pendo’s product signals with Agent Analytics from our support systems, I get a unified view of where users struggle, how agents intervene, and which in-app experiences accelerate resolution. That visibility lets my team drive product-led growth and improve customer experience while lowering support costs.
Increase revenue, cut costs, and reduce risk with Pendo’s Software Experience Management platform. Optimize the entire software experience to drive adoption and improve engagement.
In practice, I build a clear scorecard that blends both product and support KPIs: first response time, resolution rate, first contact resolution, CSAT, containment/deflection rate, average handle time, ticket volume per active account, onboarding completion, user activation, and time-to-value. This balanced view ensures we reward not just speed, but durable outcomes that reduce repeat contacts and improve retention.
To make the data actionable, we connect our CRM integration, ticketing events, and Pendo product analytics in a unified analytics platform. That gives me cohort-level clarity—who needed help, what they were doing before opening a ticket, how agents responded, and whether users stayed engaged afterward. With clean instrumentation and consistent taxonomies, Agent Analytics becomes a reliable operating system for both product and support leadership.
I then use in-app guides, tooltips, and product tours to proactively address the top friction points that drive ticket volume. Through A/B testing, we compare cohorts exposed to guided workflows versus control groups, measuring deflection, faster task completion, and downstream conversion. When a guide meaningfully reduces tickets for a given workflow, we promote it from experiment to standard onboarding, and we feed those learnings back into our roadmap.
The real unlock comes from tying outcomes to business impact. I track how improvements in resolution quality and self-serve adoption influence expansion revenue, support cost per account, and risk signals like churn propensity. Retention analysis helps us validate whether reduced friction and better agent coaching translate into sustained engagement and healthier accounts.
Operationally, Agent Analytics helps me coach teams with precision. I spotlight high-performing behaviors, identify knowledge gaps, and standardize winning playbooks directly in the product via in-app guidance. This approach empowers agents, shortens onboarding for new hires, and keeps our best practices current as the product evolves.
None of this works without trust. We apply privacy-by-design principles and strong data governance, ensuring that analytics, coaching, and automation respect user consent and data minimization standards. With that foundation, we can scale confidently—experiment faster, learn from every interaction, and continuously improve the software experience.
If you’re getting started, begin by baselining your agent and product KPIs, ship one high-impact guide to deflect a top ticket driver, and review results weekly. Within a quarter, you’ll have a repeatable loop: diagnose friction, test an in-app solution, measure deflection and satisfaction, and reinvest the gains into the next set of improvements.
