Blog

Seneca wrote that every new beginning comes from some other beginning’s end. He was writing about time — how we live in a continuous flow of transitions, each new phase emerging from the completion of the last. Product leaders building AI systems are working through exactly this dynamic, whether they’ve named it or not.

Every AI model update creates a new beginning by ending the previous version’s assumptions. Every infrastructure upgrade rewrites the operational playbook. Every significant capability improvement from a frontier provider makes yesterday’s integration architecture obsolete. The question for product leaders isn’t whether your AI systems will become obsolete — it’s whether you’ve designed for that obsolescence or against it.

The Paradox of AI Infrastructure

Here’s the tension: we want the reliability of traditional software — predictable, testable, maintainable — but we’re building with components that evolve continuously through training updates, capability improvements, and API changes. The mental model of “build it, test it, ship it, maintain it” breaks down when the underlying model your product depends on updates monthly and the new version behaves differently than the version you tested.

Traditional software has a stable lifespan. A well-built accounting system can run for a decade with minimal changes. AI systems don’t work that way. The capability floor keeps rising. A system that uses GPT-3.5 for a task that GPT-4 now handles better isn’t just suboptimal — it’s a competitive disadvantage, and the gap between the current capability and your deployed system grows every month you maintain the old architecture.

This creates a design challenge that has no equivalent in traditional software: you need to build systems that are robust enough to operate reliably at scale AND modular enough to be replaced component by component as better capabilities become available. These two requirements pull in opposite directions, and resolving the tension is one of the defining architectural challenges of AI product development right now.

Designing for Obsolescence

The practical answer is designing for obsolescence rather than designing for permanence. This means:

Modular AI architecture. Build so that individual AI components can be upgraded or replaced without rewriting the product around them. The abstraction layer between your product logic and your AI provider isn’t just a technical nicety — it’s what makes planned obsolescence economically viable. Without it, every major model upgrade is a replatforming project.

Shorter depreciation cycles. AI infrastructure doesn’t depreciate on the same timeline as traditional software infrastructure. Planning for 6-12 month cycles on AI-specific components — rather than the 3-5 year cycles that traditional software justifies — is a more honest accounting of how quickly the capability landscape moves. Finance teams that don’t understand this will consistently underfund the migration work required to stay competitive.

Evaluation frameworks that survive component changes. If your AI system doesn’t have an automated evaluation suite that runs against new model versions before deployment, you have no safe migration path. Every model update becomes a manual testing project, and the cost of that manual work is what prevents organizations from adopting capability improvements on a competitive timeline. Build the evals first. They outlast every model generation.

The Economics of Planned Obsolescence

There’s a counterintuitive economic argument here that takes time to internalize: the goal isn’t to build AI systems that last forever. It’s to build AI systems that create enough value before their obsolescence to fund their own replacement.

This is different from how most organizations think about infrastructure investment. The traditional framing is: invest once, amortize over years, minimize ongoing costs. The AI infrastructure framing is: invest in modularity, accept component replacement as a regular operational cost, and measure success by how quickly you can upgrade — not by how long you can avoid upgrading.

Organizations that accept this economic reality build faster. They ship AI improvements on the timeline of capability improvements rather than on the timeline of their budget cycle. The ones that treat AI infrastructure like traditional software infrastructure spend their engineering budget on maintaining increasingly outdated components rather than on adopting the capability improvements that would actually serve users better. Andreessen Horowitz’s AI Canon has useful framing on the infrastructure investment thesis that informs this economic argument.

The Human Side of Technological Obsolescence

There’s a team-level version of this design-for-obsolescence principle that’s equally important: the skills required to build AI products are themselves subject to rapid obsolescence.

Prompt engineering techniques that were genuinely valuable 18 months ago have been partially automated. Fine-tuning approaches that required deep ML expertise are now accessible with far less specialization. The skill set that makes a great AI product team today is different from the skill set that will matter in two years — not completely different, but different enough that teams that don’t continuously build learning into their culture will find themselves behind.

When I’m building an AI product team, I prioritize adaptability and learning velocity alongside current expertise. Current tool knowledge matters. The capacity to acquire new tool knowledge matters more over a multi-year horizon. This is the team-level version of Seneca’s principle: build organizations that benefit from change rather than organizations that resist it.

Your Turn: Apply This Today

Design for obsolescence before the next obsolescence cycle forces you to:

• Audit your AI architecture for replaceability. For each AI component in your product, ask: if we needed to swap this model or provider in 60 days, what would it take? If the answer is “months of reengineering,” you have a design-for-permanence problem that will cost you competitively every time the capability landscape shifts.
• Build your evaluation framework before you need to migrate. Create an automated suite that tests your AI system’s behavior against defined quality criteria. Run it against new model versions before deployment. This is the single most important investment for making planned obsolescence operationally viable.
• Restructure your infrastructure budget cycle for AI components. Present a 12-month replacement plan for AI-specific components to your finance stakeholders — not as a failure to build durable systems, but as a realistic amortization of infrastructure that improves faster than traditional software. Make the economic argument explicitly.
• Map your team’s “obsolescence risk” skills. Identify the skills in your team that are most likely to be automated or made obsolete in the next 18 months. Build a plan for transitioning those team members to higher-leverage work before the transition is forced. This is better for your team and better for your product.
• Build abstraction layers into every new AI integration. Make it a team norm: no direct AI provider dependency in product logic. Every AI integration goes through an abstraction layer that can be retargeted without rewriting the product. This is the architectural equivalent of designing for obsolescence.
• Run a “what if this model becomes unavailable?” exercise quarterly. For your primary AI capabilities, simulate a scenario where the current provider or model is unavailable in 90 days. How long does migration take? What breaks? The exercise will reveal architectural dependencies you’ve accepted without explicitly deciding to.

Seneca’s discipline about time connects directly to the hidden cost of real-time AI decisions — Seneca’s email rule and the cost of always-on AI explores the other dimension of this Stoic lens on AI product decisions.

Building AI systems and trying to make architecture decisions that hold up as capabilities evolve? I consult with product teams on AI architecture strategy, planned obsolescence frameworks, and building organizations that adapt rather than resist when the capability landscape shifts. Let’s talk.

Teresa Torres built continuous discovery as an antidote to product teams that build in isolation — teams that spend months building solutions to problems they think exist, then ship to users who wanted something entirely different. The framework is genuinely valuable: weekly customer interviews, systematic opportunity mapping, iterative testing. It solved a real problem.

Here’s the question I’ve been wrestling with: in an environment where AI can monitor customer behavior, surface opportunity signals, and flag behavioral anomalies continuously — not weekly, not daily, continuously — is the weekly interview cadence still the right rhythm for discovery? Or has it become a bottleneck?

The Continuous Discovery Promise

Torres’s core insight is sound and worth protecting: most product failures happen because teams build solutions for problems they imagined rather than problems that actually exist. Her framework forces the discipline of staying connected to users rather than getting lost in internal roadmap debates.

The weekly interview cadence is the mechanism that makes the framework work in human-speed product environments. A team that talks to users weekly, maps what they hear, and designs experiments based on that mapping has a significant advantage over a team that does discovery quarterly or on an ad hoc basis. That’s true and it’s worth affirming before getting into the breakdown.

Where Continuous Discovery Breaks Down

The breakdown isn’t in the principles — it’s in the gap between the discovery cadence and the signal velocity that AI-augmented product environments now generate.

When you’re monitoring support channels, usage patterns, and behavioral data continuously with AI, you’re not waiting for a weekly interview to surface a new opportunity cluster. The signal is arriving every hour. The opportunity identification is happening faster than the discovery cadence can process it. The bottleneck shifts from “we don’t have enough signals” to “we have more signals than our discovery process can evaluate.”

There’s also a deeper problem: some of the most important signals about user needs don’t come from what users say in interviews — they come from what users do that doesn’t match what they said. AI is better at surfacing the behavioral signal than interviews are. The weekly interview remains valuable, but it’s no longer the primary source of opportunity discovery in a well-instrumented product environment. Torres’s framework was designed for the interview as the primary signal. The role of the interview has changed.

The Human-AI Discovery Gap

The specific gap I’ve encountered: AI surfaces opportunity patterns from behavioral data faster than human-centered discovery processes can validate and act on them. This creates a queue of AI-identified opportunities waiting for human investigation that grows faster than the weekly interview cadence can clear it.

The result is that teams using AI-augmented discovery alongside Torres’s cadence end up in one of two failure modes: they ignore the AI-surfaced signals and run a traditional discovery process that is now missing a large class of opportunities, or they try to validate every AI-surfaced signal through the traditional interview-and-experiment cadence and create a backlog so long that validated insights are stale before they reach solution design.

The framework needs an explicit mechanism for triaging AI-surfaced signals before they enter the discovery process — something Torres’s original framework doesn’t provide because the volume of signals it was designed to handle was fundamentally human-generated.

What Discovery Looks Like With AI-Augmented Signals

The adaptation I’ve found most useful: restructure the discovery cadence so that AI handles continuous signal monitoring and human-centered discovery handles signal validation and solution design.

AI monitors behavioral signals continuously and surfaces clusters of anomalies or emerging patterns for human review. This replaces the “discovery” part of the weekly interview — the team is no longer relying on interviews to surface new opportunities, because the AI is doing that continuously. The weekly interview becomes a validation mechanism: we talk to users about opportunities the AI has already identified, rather than hoping the interview will surface something new.

This shift changes what the interview accomplishes. Instead of “tell me about your experience” (open-ended discovery), the interview becomes “the data shows users are abandoning this workflow at step 3 — can you walk me through what that experience is like for you?” (targeted validation). The insight quality goes up. The discovery efficiency goes up. The interview becomes more valuable because it’s now pointed at a specific signal rather than fishing for signals generally.

The Missing Piece in Torres’ Framework

The missing piece isn’t a critique of Torres — it’s a gap that didn’t exist when the framework was designed. The missing piece is an explicit decision rule for how AI-surfaced signals enter the discovery process and what it takes for them to earn human investigation time.

Without that decision rule, every AI-surfaced signal competes for the same human attention budget as the signals coming from interviews. The volume overwhelms the process. The team either starts ignoring signals or starts investigating everything and producing nothing.

The decision rule I use: AI signals get human investigation time when they meet a significance threshold (behavioral change above a defined magnitude), a duration threshold (the pattern persists for at least two weeks), and a strategic relevance filter (the affected workflow or user segment is in current strategic focus). Signals that don’t meet the threshold stay in monitoring. Signals that meet it get a targeted interview and a fast experiment to validate. Teresa Torres’s original continuous discovery documentation is the right foundation — the adaptation is building the signal triage layer on top of it.

Your Turn: Apply This Today

You don’t need a 20-agent AI system to apply this. Start with the principles:

• Audit how your current discovery signals are sourced. List the top five sources of opportunity signals your team acts on. What percentage come from interviews? What percentage from behavioral data? If the behavioral data is underrepresented, you’re missing a signal class that doesn’t require AI to access — just better instrumentation and review habits.
• Shift at least one weekly interview to validation mode. Before your next customer interview, identify one behavioral anomaly from your product data — a workflow with high abandonment, a feature with unexpectedly low engagement, a search query with no good results. Make that the focus of the interview. Validate the signal, don’t fish for new ones.
• Build a signal triage decision rule. Define explicitly what it takes for a behavioral signal to earn human investigation time: significance threshold, duration threshold, strategic relevance filter. Write it down and apply it to your next backlog grooming session. Everything that doesn’t meet the bar stays in monitoring.
• Create a “discovery queue” separate from your opportunity backlog. AI-surfaced signals that haven’t been validated by a human should sit in a discovery queue, not the opportunity backlog. They don’t get resourced until they’ve been validated through a targeted interview or behavioral experiment. This prevents the queue from contaminating your actual opportunity prioritization.
• Measure your discovery process’s throughput, not just its output. Track how many signals enter your discovery process per month and how many get resolved (validated or dismissed). If the queue is growing faster than it’s being cleared, the discovery cadence needs to be restructured — not accelerated, restructured.
• Protect the interview for the human insight it uniquely provides. As you shift interviews from discovery to validation, stay alert for the kinds of insight only an interview can generate — the emotional context, the unstated assumption, the use case nobody modeled. These won’t show up in behavioral data. The interview is still the best tool for them. Just don’t use it for signal discovery when the data is already doing that job.

The OST framework has related adaptations at scale worth reading alongside this — how OSTs need to evolve for AI-augmented discovery and the execution complexity branch that’s missing from most opportunity trees.

Running product discovery and trying to figure out how AI changes the process? I consult with product teams on discovery operations, AI-augmented research processes, and building the systems that keep human judgment at the center of AI-accelerated product development. Let’s talk.

Teresa Torres’s opportunity solution tree framework is one of the better discovery tools I’ve used. The structure — mapping customer opportunities to potential solutions in a visual tree — helps teams stay connected to user needs rather than defaulting to feature lists and stakeholder requests. I use a version of it. But running product for a platform at significant scale, and building AI agents to support the discovery process, has taught me where the framework needs substantial adaptation before it works in the real world.

This isn’t a critique of Torres. Her framework is sound. It’s an observation that opportunity solution trees as designed assume a pace and a data volume that most scaled products don’t operate at — and that AI changes both the opportunity and the failure mode of the entire discovery process.

The Opportunity Tree Reality Check

The OST framework looks clean in workshop settings. Customer interviews surface opportunities. Teams map solutions. Experiments get scoped. Everyone leaves feeling aligned. At scale, the process breaks down in a specific way: the rate of incoming opportunity signals overwhelms the team’s capacity to process them through a manual discovery rhythm.

When you’re monitoring support channels, usage patterns, feedback streams, and behavioral data for a large user base, the volume of potential opportunity signals is enormous. The question isn’t “how do we find the opportunities?” — AI can surface opportunity clusters from that data continuously. The question is “how do we evaluate and prioritize opportunities that are emerging faster than we can interview users about them?” Torres’s framework was designed for a world where discovery is the bottleneck. At scale with AI, discovery is no longer the bottleneck — judgment about what to do with what you’re discovering is.

Where AI Changes Everything in the OST Process

The adaptations I’ve made to the OST process at scale are all about restructuring what AI handles vs. what humans handle:

AI handles continuous opportunity sensing. Rather than quarterly or monthly discovery cycles, I’ve shifted to AI agents that monitor support channels, usage patterns, and feedback streams continuously — flagging opportunity clusters for human investigation. The tree is no longer built in workshops; it’s maintained continuously with AI surfacing new branches as they emerge from data.

Humans handle opportunity prioritization and solution imagination. Torres often combines opportunity identification and solution generation in workshops. At scale, separating these produces better results. AI excels at recognizing opportunity patterns from data. Humans excel at imagining solutions that connect to those opportunities in ways that AI wouldn’t generate without significant prompting. Keeping these steps separate — and keeping humans firmly in charge of the prioritization step — prevents the discovery process from becoming AI-driven by default.

The tree becomes a living document, not a workshop artifact. The biggest practical change: the OST is updated continuously based on incoming data rather than rebuilt quarterly. AI maintains the structural connections. Humans make the strategic decisions about which branches to pursue, which to prune, and which to flag for deeper investigation.

The Missing Piece: Solution Validation Speed

Torres’s framework handles opportunity identification well and provides a solid structure for mapping solutions. Where it provides less clarity — and where I’ve had to build my own process — is solution validation speed at scale.

When you can run experiments across a large user base, the question isn’t “how do we test this?” — it’s “how do we test this fast enough to keep up with the opportunity identification rate?” If AI is surfacing new opportunity clusters weekly but your experiment design and execution cycle takes six weeks, you’re building a backlog of validated opportunities that never get addressed before the next cycle of discovery makes them stale.

The solution I’ve found: tiered experiment design. Some solutions get full experiment design and execution. Others get fast behavioral proxies — early signals from a small user segment that don’t require full experiment infrastructure. The OST needs an explicit tier for each solution branch that determines the validation approach before the experiment is scoped. Without it, every solution competes for the same limited experiment capacity and most of them wait too long.

The Cultural Complexity Challenge

For products serving users across diverse geographies and cultural contexts, the OST needs one more adaptation Torres’s original framework doesn’t explicitly address: opportunity branches that are culturally segmented rather than universal.

The same user need can manifest in fundamentally different ways across cultural contexts — different mental models, different workflows, different relationship to the product’s value proposition. AI helps identify when an opportunity pattern is consistent across user segments and when it’s culturally specific. Without that distinction, you end up building solutions to universal-seeming opportunities that actually only solve for the segment that happens to be most vocal in your feedback channels.

The practical implication: before any significant OST branch gets resourced for solution design, ask explicitly whether the opportunity is universal or segment-specific. If it’s segment-specific, design the solution for that segment first — don’t try to generalize prematurely. Teresa Torres’s original OST documentation is the right starting point for understanding the framework’s foundations before adapting it.

What Still Requires Human Judgment

AI augments the OST process at scale in meaningful ways. It does not replace the human elements that make the framework valuable. Opportunity prioritization is still a human decision — AI can surface opportunity clusters, but the judgment about which opportunity is worth pursuing given current strategic context requires the kind of synthesized understanding that AI surfaces from data but doesn’t hold.

Solution creativity remains human. The connection between a user opportunity and an imaginative solution that users didn’t know they wanted — that’s not something AI generates reliably without creative prompting. And strategic trade-offs — the decisions about which opportunities to deprioritize in service of organizational focus — require human judgment that accounts for context AI doesn’t have.

The adapted OST is better than the original for scaled products. But “better” here means AI is doing more of the pattern recognition so humans can do more of the judgment work. The goal isn’t to automate discovery — it’s to remove the bottlenecks that keep humans from doing the discovery work that actually requires human judgment.

Your Turn: Apply This Today

Whether you’re just starting with OSTs or looking to evolve your current discovery process:

• Separate opportunity identification from solution generation in your process. If you’re currently doing both in workshops, split them into distinct phases. Use your data infrastructure (or AI tools) for continuous opportunity surfacing. Reserve workshop time exclusively for solution design and prioritization — where human creativity and judgment add the most value.
• Build a tiered validation system for your solution branches. Before any solution moves to experiment design, assign it a validation tier: full experiment, behavioral proxy, or customer interview. The tier determines the validation approach and timeline. This prevents every solution from competing for the same experiment infrastructure.
• Make your OST a living document, not a workshop artifact. If you’re rebuilding your OST quarterly, you’re losing continuity between cycles. Move it to a shared, continuously-updated document. Designate someone as the OST owner responsible for keeping the tree current between discovery cycles.
• Segment your opportunity identification by user type before prioritizing. Before deciding which opportunity to pursue, ask: is this opportunity universal across my user base, or specific to a segment? If it’s segment-specific, validate it with that segment first. Don’t let your most vocal users define the universal opportunity.
• Instrument one AI-assisted opportunity monitoring signal this quarter. Set up one automated signal that surfaces opportunity patterns from your existing data — support ticket clustering, feature usage drop-offs, search queries with no good results. Feed it into your OST review meeting as a standing input. This is the minimum viable version of continuous opportunity sensing.
• Explicitly protect human prioritization of the OST. If AI is surfacing opportunity data, establish a clear norm: AI surfaces, humans decide. Don’t let the volume and frequency of AI-surfaced opportunities shift the prioritization decision toward “whatever AI flagged most recently.” The human judgment layer is the framework’s value. Protect it deliberately.

The execution complexity challenge in OST is closely related — I’ve written about the missing branch in opportunity solution trees that most teams overlook when mapping solutions. And the continuous discovery breakdown that AI accelerates is a distinct problem worth examining separately.

Running discovery at scale and trying to adapt your product process to the pace AI enables? I consult with product teams on discovery operations, experiment design at scale, and building the systems that keep human judgment at the center of AI-augmented product development. Let’s talk.