Product teams favor model capabilities

Product teams are reorganizing around model capability first, user research second. That sounds backwards if you grew up on classic product playbooks. But in AI, the bottleneck often is not “what do users want?” It is “what can the model reliably do this month?” That is the shift a bunch of recent operator interviews and enterprise AI writeups are pointing to. Teams are treating the model like a moving platform, not a fixed component, and they are building around its frontier. Why does that change the order of operations? Because model progress is fast enough that discovery can go stale before the feature ships. Cat Wu, who leads product for Claude Code at Anthropic, described a world where launches happen weekly and sometimes much faster. In that setup, the hard part is pulling maximum capability out of current models, then iterating in the open. The old sequence — months of research, then build, then launch — can be too slow for AI-native products. So does user research stop mattering? No — but it moves. Instead of heavy up-front validation, teams are doing more live validation through shipping, telemetry, and rapid feedback loops. Basically, they are using the product itself as the research instrument. That works best when the product surface is cheap to change and the team can watch failure modes in real time. It is less “perfect the spec first” and more “find the capability edge, then shape the workflow around what users actually do with it.” Why are enterprise teams talking this way too? Because most AI projects still fail to become real products. Tech Mahindra argued last week that fewer than 5% of enterprise AI pilots reach production with measurable value, and it pinned a lot of that failure on siloed execution, weak ownership, and vague problem selection. Its answer was not “do more discovery.” It was cross-functional squads, reusable capabilities, visible early wins, and ROI tied to real workflows. That is capability-first thinking translated into enterprise operating model language. What does a capability-first team actually look like? Usually a tight pod — PM, engineers, design, maybe applied AI or evals — that can test prompts, orchestration, fallback behavior, and UX together. The PM’s job shifts too. Less roadmap librarian. More translator between model behavior, business value, and user trust. If the model is non-deterministic, the product spec cannot just describe the happy path. It has to describe what happens when the model is weird, wrong, slow, or overconfident. That is why AI PM interview prep now leans so hard on evals, trust metrics, safety, and failure handling. What is the catch? Capability-first teams can ship impressive demos that do not fit durable user behavior. They can also underinvest in UX research, governance, and change management — especially in big companies where one flashy pilot can hide a broken rollout. Even Tech Mahindra’s framework, which is very pro-speed, still insists on clear ownership, measurement, and business grounding. Fast squads help only if someone is checking whether the thing solves a real problem and can survive production constraints. Why is this showing up now? Because AI product management is splitting into two modes. One mode is frontier-facing — close to the model, fast, experimental, capability-led. The other is workflow-facing — slower, more governed, more focused on integration and adoption. The smartest teams seem to know which mode they are in. They do not pretend a brand-new model feature deserves six months of research. But they also do not pretend weekly shipping alone creates product-market fit. The bottom line is simple. In AI, capability has become part of customer discovery. But it has not replaced customer discovery. The winning teams are the ones that can hold both ideas at once — move at model speed, but still anchor the work in trust, workflow fit, and measurable value.