The Product Model is Alive
From mountain prototypes to intelligent call centers: how the most enduring logic of product development is finally meeting the technology it always deserved.
There is a particular kind of truth that only becomes visible in retrospect. The kind that was always operating in the background, shaping outcomes, but had no name yet. The product model is one of those truths.
I. The Mountain as a Product Lab
There is a particular kind of truth that only becomes visible in retrospect. The kind that was always operating in the background, shaping outcomes, but had no name yet. The product model is one of those truths.
In the winter of 2011, somewhere in the Appalachian highlands during a cold-weather direct action training exercise, a group of U.S. Army Special Forces soldiers were doing what they always did: they were breaking things. Never carelessly, always deliberately. The cold had stiffened the articulation points on a prototype boot designed for rapid elevation changes. A moisture-wicking base layer was wicking in the wrong direction under sustained exertion. A load-bearing integration panel on a plate carrier vest was creating friction at exactly the wrong point of the hip flexor during a tactical low-crawl.
I know this because I was tracking it. Not from a desk at Under Armour’s headquarters in Baltimore. Because feedback like this was the product. Between 2010 and 2013, I served as Global Product Line Manager for apparel, footwear, and accessories within Under Armour’s Military Tactical Business Unit. During that period, our team did something that the formal language of product management had not yet found words for. We built a real-time product development cycle, tested not in a usability lab or a survey panel, but on the side of mountains and inside live training environments.
We didn’t call it continuous discovery. We didn’t call it an empowered cross-functional team. We didn’t have a product development lifecycle document or a project backlog. We had soldiers, altitude, cold, and mere minutes between prototype and field correction. And looking back now, as enterprise organizations worldwide struggle to internalize what the market now calls the product model, I believe those mountain exercises were not just early prototyping. They were an early expression of the only way product has ever actually worked.
“The mountain doesn’t lie to you. A soldier in a cold-weather direct action environment cannot tell you politely that your moisture management system has a problem. He shows you. His core temperature tells you. His movement efficiency tells you.”
The moment you put distance between the people building a product and the people using it, whether that distance is geographic, organizational, or mediated by requirements documents, you introduce a translation layer that distorts feedback. Requirements become proxies for needs. Specifications become proxies for outcomes. The organization starts optimizing for hitting the proxy rather than achieving the underlying objective.
On the mountain, there were no proxies. The boot either performed at the required temperature gradient or it did not. The vest either distributed load acceptably during a six-hour movement or it created injury vectors. This is, in miniature, exactly what the modern product model attempts to replicate at enterprise scale. The difference is that in 2026, we have tools that can make the feedback loop not just fast, but effectively continuous, and intelligent in ways that were previously impossible.
II. What We Mean When We Say “Product Model”
The phrase has proliferated enormously in the last several years. Like most good ideas that achieve mainstream adoption, it has picked up conceptual debris along the way. Let’s be precise.
A product model is not an organizational chart. It is not a methodology. It is not agile, or lean, or any named framework whose certification you can hang on a wall. It is something more fundamental: the answer to the question, how does your organization decide what to build, learn whether you built the right thing, and improve continuously on the basis of that learning?
Practitioners across multiple traditions have arrived at the same destination by different roads. Marty Cagan and colleagues at SVPG define the product model around a single organizing principle: empowered teams, given a clear problem to solve and the authority to solve it, consistently outperform feature teams executing a predetermined roadmap. Teresa Torres, in Continuous Discovery Habits (2021), operationalizes what this looks like in practice: small cross-functional teams maintaining ongoing, structured contact with customers on a weekly cadence, using that contact to generate and test assumptions before committing resources. Enterprise scaling frameworks like SAFe extend these principles into larger organizational contexts, addressing the coordination and governance layers that emerge when dozens of teams need to operate coherently toward shared outcomes.
These are not competing philosophies. They are different lenses trained on the same operating reality. What they share is more important than what distinguishes them.
Both SVPG and SAFe converge on a distinction that sounds simple and is, in practice, organizationally difficult.
Project model: A fixed scope is delivered by a fixed date. Success equals delivery. The team disbands. The learning dissipates.
Product model: A continuous mission is pursued by a persistent team. Success equals outcome. The learning compounds. The capability grows.
What strikes me about the cross-functional team structures that serious enterprise organizations are now formalizing is not that they are new. It is that they are a formal articulation of something effective product teams have been doing informally for decades. In garages, on factory floors, in field training environments, and increasingly inside AI-augmented operations centers. The terminology evolves. The underlying logic does not.
The deeper challenge is not conceptual clarity. Most product leaders understand the distinction between project and product. The challenge is organizational: implementing a product model on top of an organizational architecture designed for projects. Funding models, governance structures, headcount allocation, performance measurement, and leadership behavior all evolved to support project delivery. Changing the operating model without changing those underlying systems produces the hybrid that large enterprises know all too well: agile language on top of waterfall execution.
Research across multiple sources puts the failure rate of product model transformations in large enterprises between 70 and 97 percent. The model works. The foundation underneath it usually does not.
III. Testing on the Side of a Mountain
When I joined Under Armour’s Military Tactical Business Unit, the company was navigating a fascinating inflection point. Under Armour had built its brand on performance compression wear for athletes, a domain where feedback loops are relatively controlled. You put an athlete in a garment, they compete, you observe and iterate. The cycle, while fast, operates in a bounded environment.
The military and tactical context was categorically different. Our customers were not competing in a stadium. They were operating in environments that no human-factors lab could replicate: sustained cold-weather movement at altitude, rapid transition between exertion states, load-bearing configurations that interacted unpredictably with layering systems, and mission contexts in which a product failure was not a performance inconvenience but a potential safety or operational incident.
Standard development timelines were insufficient. What we needed was something closer to what Teresa Torres would later describe as continuous discovery: a state in which the team maintains ongoing, direct contact with the people who use the product in the conditions where it actually operates. We arrived at this not through design theory, but through necessity.
Prototype garments and load-bearing equipment were introduced into live training exercises with operational units. We didn’t send a survey. We sent the product into the environment and established feedback mechanisms with the users inside it: performance debrief sessions, materials analysis after sustained wear, biomechanical observation during training scenarios, and direct dialogue with operators about what the product did and did not do under stress.
The feedback was not filtered through a procurement specification. It came directly from people whose professional lives depended on their equipment performing correctly. The valuable-feedback-to-junk ratio was extraordinary. And the iteration cycle compressed to hours rather than months, driven by the structure of training cadence.
What the Mountain Taught About Scale
The most important lesson from that period was about the relationship between user proximity and product quality. Every layer of organizational distance between builder and user is a translation layer. Requirements become proxies for needs. Specifications become proxies for outcomes. Roadmaps become proxies for strategy. And organizations gradually shift their energy from solving customer problems to defending their interpretations of them.
On the mountain, that dynamic was impossible. The feedback was unambiguous and immediate. And because the team was embedded close enough to receive it directly, we could act on it quickly.
This is, in miniature, exactly what the modern product model attempts to replicate at enterprise scale. The difference is that in 2026, we have tools that can make the feedback loop not just fast, but effectively continuous, and intelligent in ways that were previously impossible.
IV. A Wireless Insurance Provider Discovers What We Already Knew
Consider a wireless insurance provider, the kind that sits behind your carrier’s handset protection program, handling device replacement claims and customer service for a few million policyholders.
In 2019, their call center was the canonical project-model operation. Agents handled claims according to a script developed by a product team that had last conducted systematic customer interviews eighteen months earlier. The claims processing platform, built in 2014, had been maintained through a series of discrete projects, each scoped and funded separately, each delivering against a requirements document already outdated by the time code shipped.
The system worked, in the narrow sense that claims were processed. But the metrics told a more complicated story. Average handle time was well above industry benchmarks. First-call resolution was declining. CSAT scores were flat at a level leadership characterized as “acceptable,” which in practice meant they had stopped trying to improve it.
The issue was not effort or talent. It was architecture: the organizational architecture of how the product was developed and improved. There was no continuous feedback loop between the people experiencing the product and the people shaping it. There was no persistent, empowered team with a clear outcome mission, ongoing customer access, and the organizational authority to act on what they learned. There was a roadmap. There were project teams to execute it. And there was a growing distance between what customers actually needed and what the organization was building.
The Transformation
Beginning in 2021, the organization restructured around a product model. The change was not primarily technological. It was organizational.
A cross-functional team was assembled around the claims resolution product: engineers and a product manager, yes, but also a UX researcher embedded in the call center two days per week, a data analyst with direct access to call recordings and resolution metadata, and a customer success partner maintaining direct relationships with frontline agents who provided ongoing feedback on product friction.
The team’s mandate was redefined from “deliver features on the roadmap” to “improve claims resolution outcomes.” This shift, from output accountability to outcome accountability, is the pivot on which effective product models turn. Cagan and his SVPG colleagues call it the move from feature teams to empowered product teams. Torres calls it the shift from build-trap thinking to continuous discovery. Whatever you call it, the organizational experience is the same: the team stops asking “what did we ship?” and starts asking “what did we change?”
The critical shift was governance, not technology. Leaders gave up control of the what, specific features and delivery dates, in exchange for greater influence over the why: strategy, outcomes, mission. Most found this harder than they expected.
Within twelve months, average handle time had decreased significantly. Not because of a technology revolution. Because of a series of small, evidence-based product improvements discovered through continuous engagement with agents and customers: a simplified device verification flow, a proactive status update system that eliminated a large share of inbound status-check calls, and a contextual knowledge surface that surfaced relevant policy information to agents at the precise moment they needed it. None of these improvements appeared on the original roadmap. All were discovered through ongoing, embedded customer contact.
Then AI Arrived, and the Cycle Got Faster
In 2023, the organization began integrating AI-powered capabilities: an AI-assisted triage system that pre-classified inbound claims by complexity and routed them accordingly; a real-time transcription and sentiment analysis system providing supervisors with live call quality indicators; and an automated processing pathway for straightforward device replacement claims requiring no human agent involvement.
This reflects an industry-wide shift. According to McKinsey’s 2024 analysis of AI in insurance, UK insurer Aviva deployed more than 80 AI models in its claims domain, cutting liability assessment time for complex cases by 23 days, improving routing accuracy by 30 percent, and reducing customer complaints by 65 percent. Broadly, AI assistance has reduced overall claims resolution time by as much as 75 percent in high-performing implementations, from 30 days to under 8, with routine claims moving from a week or more down to 24 to 48 hours.
The AI system didn’t tell us what to build. It told us, faster and more clearly than anything before it, what wasn’t working, and for whom, and under what conditions.
What these AI systems did, beyond their immediate functional benefits, was something more structurally significant: they created an unprecedented volume of continuous feedback. Every automated claim that succeeded or failed generated data. Every sentiment inflection in a live call was timestamped and tagged. Every routing decision could be evaluated against its outcome. The product was, for the first time, generating its own discovery data at scale.
This is where the product model and AI become genuinely inseparable. Not because AI replaces the human judgment at the center of good product work. It does not, and the organizations that believe it does will discover this expensively. But AI provides the feedback infrastructure that makes continuous discovery operationally feasible at enterprise scale.
V. What the Frameworks Got Right, and Where Most Enterprises Are Still Stuck
Multiple research streams now agree on why product model transformations fail at scale. The model itself works. The failure is almost always organizational readiness, not conceptual validity.
The root cause is consistent across frameworks and traditions. Cagan and his SVPG colleagues argue in TRANSFORMED (2024) that the degree of change required is more disruptive than most companies expect, not because the principles are complicated, but because they require genuine behavioral change from senior leaders, not just organizational restructuring. SAFe’s enterprise guidance points to the same failure mode: building a product-based way of working on top of an organizational culture optimized for centralized decision-making and project delivery.
Both diagnoses point to the same root cause: product model adoption is a leadership transformation before it is an organizational one. You can restructure teams, rename roles, and stand up discovery rituals without changing the underlying dynamic in which senior leaders maintain control over the what, the specific features, timelines, and delivery commitments, rather than the why, the strategy, outcomes, and customer problems the team is authorized to solve.
This produces the hybrid that large enterprises know all too well. Teams that are nominally empowered but practically constrained. Discovery rituals that generate insight but no authority to act on it. Roadmaps that are labeled outcomes but function as feature delivery plans. The language of product model maturity layered on top of project model execution.
The Three Foundations
Across the practitioners and frameworks that have studied enterprise product transformation most rigorously, three non-negotiable conditions emerge. Each is load-bearing. Addressing only one or two of them produces stall, not transformation.
Team and technical agility. Teams need the structural conditions to move fast: small enough to coordinate without ceremony, persistent enough to develop domain knowledge over time, and cross-functional enough to carry a problem from discovery through delivery without handoffs that introduce delay and distortion. Technical practices matter here too. Continuous delivery, automated testing, and modular architecture are not engineering preferences. They are organizational capabilities that determine how quickly a team can act on what it learns.
Strategy clarity and outcome orientation. Teams need to know what they are optimizing for at a level of precision that makes daily decisions possible without escalation. OKRs and similar instruments are not about measurement. They are about communication: translating organizational strategy into team-level operating clarity. Without this, empowerment is directionless and accountability is theater.
Leadership behavior, not just structure. The product model asks senior leaders to give up control of the what in exchange for greater influence over the why. Most senior leaders in large organizations have built their careers on being good at controlling the what. The transition requires a genuinely different kind of leadership fluency. As Torres frames it in Continuous Discovery Habits, the team closest to the customer should have the most authority over the solution. In most large organizations, the inverse is true. Changing this requires sustained behavioral change at the leadership level, not just a new org chart.
The Leadership Paradox
The hard work is not in the ceremonies or the tooling. The hard work is in the leadership decisions that either enable or disable the model.
Dedicated cross-functional teams require leaders to give up the resource allocation control that matrix organizations are designed to provide. Outcome-based deliverables require leaders to accept the ambiguity of result-based measurement rather than the false certainty of feature delivery metrics. Continuous learning requires leaders to treat team capability development as a strategic investment rather than a cost to minimize.
In the Under Armour military context, this leadership question was answered by the nature of the customer relationship. When your end users are operational units with specific mission requirements and the organizational credibility to specify what they need with clarity and authority, it is very difficult for a product leader to substitute their own judgment for that of the user. The customer context forced a kind of organizational humility that civilian product organizations often have to cultivate deliberately.
The best product leaders I have worked with share this quality: a genuine conviction that the customer’s reality is the product’s truth, and a willingness to let that reality reshape their assumptions in real time.
VI. A Brief History of How We Got Here
2010 to 2013. Under Armour’s Military Tactical Business Unit embeds prototype garments and equipment in live training exercises, creating near-real-time feedback cycles that anticipate the continuous discovery discipline by a decade. The operating insight: user proximity is not a research technique. It is an organizational design principle.
2017 to 2020. Two bodies of product thinking mature in parallel. Cagan’s revised INSPIRED (2017) and EMPOWERED (2020) formalize the vocabulary of empowered product teams and outcome orientation for technology companies. Enterprise scaling frameworks evolve their product delivery competencies to place customer-centricity and continuous feedback at the center of delivery at scale.
2021. Teresa Torres publishes Continuous Discovery Habits, providing the operational framework for what weekly customer engagement by the building team actually looks like in practice.
2022 to 2024. Large industrial, financial, and insurance organizations begin serious attempts at product model adoption. TRANSFORMED (2024) and LOVED (2022) complete the SVPG series. Research from McKinsey and others begins documenting the gap between pilot success and enterprise-scale transformation.
2023 to 2024. Generative AI and intelligent automation begin augmenting product operations at scale. McKinsey reports that leading insurers are deploying dozens of AI models in the claims domain, achieving routing accuracy improvements of 30 percent or more and customer complaint reductions of 60 to 65 percent. The AI system becomes feedback infrastructure, generating continuous discovery feedback from every customer interaction.
2025 to present. The distinction between “building a product” and “operating a continuously improving system” collapses. Full AI adoption in the insurance sector jumped from 8 percent to 34 percent year-over-year between 2024 and 2025. The product model becomes the only viable organizational architecture for companies competing in AI-native markets.
VII. The Road Ahead
The fundamental logic of the product model is not new. It is, in its essentials, the same logic that governed effective product development long before anyone had a name for it. It is the logic of the mountain exercise, of the embedded prototype cycle, of the team that stays close to the user and lets user reality shape product direction. What is new is the scale at which that logic can now operate, the speed at which feedback can now travel, and the intelligence that AI can bring to the task of making that feedback legible.
For a wireless insurance provider running AI-powered claims triage and automated processing, the product is no longer a static artifact that improves in discrete quarterly releases. It is a living system that learns from every interaction, surfaces its own improvement opportunities, and delivers value in increasingly precise alignment with individual customer needs. The product model is not just the organizational structure that governs this system. It is the only organizational structure that can keep pace with it.
When I was tracking boot performance on a hillside in Appalachia, I had no idea I was doing product management. I was just trying to make something work better for people who needed it to. That impulse, that fundamental orientation toward the user’s reality, is the origin of everything that the product model tries to formalize.
AI gives us tools to pursue that impulse at a scale and speed that would have seemed implausible five years ago. The product model gives us the organizational architecture to use those tools well. And the mountain, wherever you find it, gives us the reminder that none of this was ever about the framework. It was always about getting close enough to the truth to do something useful with it.
The shift from project model to product model is not, in the end, a transformation of process. It is a transformation of relationship: a fundamental reorientation of the organization toward the people it serves, sustained by the structures, disciplines, and now the intelligent systems that make that reorientation durable. Organizations that make this shift will compound their advantage over time. Those that do not will find themselves increasingly unable to explain why their investments in technology and talent are not translating into outcomes. The gap between those two futures is the gap between project and product.
— Adam Mattis
Working on This Problem? The Select Group Can Help.
The distance between understanding the product model intellectually and executing it inside a real organization, with real teams, real stakeholders, and real AI infrastructure to integrate, is where most transformations stall. That gap requires more than a framework. It requires the right people, the right capability, and a partner who has built at the intersection of technology and organizational change.
The Select Group (TSG) has spent more than three decades helping Fortune 500 and mid-sized companies turn ambitious initiatives into working outcomes.
Headquartered in Raleigh, NC and operating across the United States and Canada, TSG delivers end-to-end technology consulting across Data and AI, Digital Transformation, Cloud and Infrastructure, and Agile and Product practices. Their adaptive model brings together solutions strategy, high-caliber technical talent, and dedicated engagement oversight: the three things most organizations are missing when a product transformation quietly becomes just another project.
If your organization is asking how to move from shipping features to creating outcomes, how to build continuous discovery into your operating rhythm, or how to make AI a genuine part of your product feedback loop rather than just a technology investment, TSG is the partner equipped to help you answer those questions with action, not just analysis.
Connect with Adam on LinkedIn to continue the conversation.
References
[1] Scaled Agile, Inc. (2025). The Product Operating Model at Scale: Three Keys to Implementation Success. Executive Guide, April 2025. scaledagile.com
[2] Cagan, M., Hickman, L., Jones, C., Idiodi, C., and Moore, J. (2024). PRODUCT IS HARD: SVPG Box Set. John Wiley and Sons. ISBN: 9781394326266. svpg.com/books
[3] Torres, T. (2021). Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC. ISBN: 9781736633304. producttalk.org
[4] McKinsey and Company. (2025). The Future of AI in the Insurance Industry. mckinsey.com
[5] Datagrid. (2025). 42 Insurance AI Agent Statistics (Adoption and Impact). datagrid.com