Last year at Iris, we were planning a major engineering push for Microsoft Word integration. It was a roadmap centerpiece – customers wanted to answer RFP responses directly in Word, our competitors had that feature for years, and our engineers had scoped it at several hundred hours. We had the requirements, the tickets, the plan, and were ready to commit a significant chunk of our quarter to shipping it.
Then Anthropic announced Claude Skills, which included a native Word skill. We tested it and it handled nearly everything we needed to build. Hundreds of engineering hours became unnecessary overnight.
This wasn’t a one-time lucky break. It’s a pattern, and it changes how PMs must think about roadmap prioritization in a way that most teams haven’t adjusted for yet.
The Commoditization Risk Problem
Traditional product thinking follows a familiar rhythm: identify customer problem, evaluate solutions, prioritize by impact and effort, build in order of value delivery. The model assumes a relatively stable solution space, where the tools and capabilities available to you change slowly enough that your engineering estimates remain valid through a development cycle.
AI product development breaks this assumption. The solution space changes faster than sprint cycles. Features that require significant engineering effort today might become trivial API calls next month. Infrastructure you’re about to build might get commoditized by a model update before you finish.
I’ve been referring to this as Commoditization Risk: the risk that frontier AI labs will commoditize your planned work before you ship it.
Not all roadmap items carry equal risk. Building a data-informed customer experience sits on stable ground, because Anthropic isn’t going to ship your specific UX next month. But standard integrations, format conversions, orchestration patterns? These are exactly the kinds of broad tasks that these labs are solving for everyone.
Identifying High-Risk Work
Some patterns make roadmap items particularly vulnerable to commoditization.
Standard formats and integrations come first: Word, Excel, PDF, common APIs. These are universal needs that labs can solve once for everyone. Our Word integration was obvious in retrospect. Of course Anthropic would build that. It’s valuable to every Claude user, which makes it exactly the kind of infrastructure worth centralizing.
Platform integrations deserve special attention. If you’re building AI features on top of platforms like Gmail, Google Calendar, or Microsoft Office, the commoditization clock is counting down fast. It’s too obvious an opportunity for platform owners to integrate AI into their own products, at a deeper level than a 3rd party can do. Third-party AI email assistants became largely obsolete when Google integrated Gemini into Gmail. Dia’s AI browser had a narrow window before major browser vendors brought AI native. This doesn’t mean you should never build platform integrations – the window before commoditization might be valuable enough, or your implementation might be differentiated enough to survive. But you should assess that risk before building.
Undifferentiated capabilities round out the pattern. Anything where your implementation wouldn’t be meaningfully different from what a lab could provide. If your main value is “we connected these two things,” that connection is commoditizable. Again, this work might be necessary, but the question is whether you need to be the one doing it.
Once you can spot high-risk work, the question becomes: when should you actually delay it?
When Strategic Delay Makes Sense
At Iris, once we recognized this pattern, we started tagging roadmap items with a rough commoditization risk assessment. High-risk items moved down the priority stack unless there was a compelling reason they couldn’t wait.
This doesn’t mean never build infrastructure. It means being strategic about timing. If customers are screaming for Word integration today, you might need to build it even knowing it could be commoditized. But if it’s “nice to have” or “planned for next quarter,” consider whether waiting three months might mean you don’t build it at all.
The economics are stark. We were about to spend hundreds of hours on Word integration. By waiting a few weeks, we spent zero hours and got a better solution than we would have built. That engineering capacity went to building differentiated features that Anthropic wasn’t going to ship for us.
Strategic delay works when the opportunity cost of waiting is lower than the risk of building something that gets commoditized. For high-risk infrastructure work, this calculation often favors waiting.
Somethings You Can’t Wait
This strategy has clear limitations.
When customers are blocked today, you can’t wait for Anthropic’s roadmap to save you. Customer pain in hand beats potential commoditization in the future. If a Word integration is preventing deals from closing or causing active churn, you build it regardless of the risk.
When the work creates learning that matters more than the efficiency of the solution, the effort might justify itself, even if it gets commoditized. Building infrastructure sometimes teaches you things about your product or customers that you wouldn’t learn by waiting for a lab to solve it for you.
When differentiation comes from the implementation rather than the core capability, commoditization risk drops significantly. If your Word integration would be meaningfully different from a generic solution – special formatting, custom workflows, proprietary features – then you’re not building plumbing, you’re building something specific to your product.
When the frontier isn’t moving toward it, you’re probably safe. Not every infrastructure task is in frontier labs’ roadmap. Niche integrations, industry-specific formats, custom internal tools might not be commoditized because they’re not valuable enough to enough people.
The key is honest assessment. Are you building generic plumbing that labs will standardize, or are you building something that matters specifically to your product and customers?
What This Changes About Product Strategy
The practical implication is that PMs working on AI products need a different relationship with their roadmap than PMs in traditional software. Your roadmap can’t just be a prioritized list of what to build. It needs to account for what might not need building if you wait.
This requires staying very close to what the industry is doing. Not just model releases, but their product roadmaps, their developer tools, their integration strategies. When Anthropic or OpenAI announces a developer conference, that’s signal about what infrastructure they’re about to commoditize. The labs telegraph their intentions if you’re paying attention.
The harder truth is that this approach requires constant roadmap re-evaluation in a way that makes stakeholders nervous. Traditional roadmap planning works on quarterly cycles – gather requirements, estimate effort, prioritize, commit to a plan, execute against it. Commoditization risk breaks this model. When a frontier lab releases a new capability, your effort estimates become obsolete mid-quarter. A feature you deprioritized last month because it would take 200 hours might suddenly jump to the top of your backlog because a new API just made it a 20-hour job. You need to evaluate roadmaps more frequently, and you need to figure out how to manage this tension with stakeholders who want predictability and engineering teams that want stable sprint commitments.
Traditional PM wisdom says to focus on the problem, not the solution. But when the solution space changes monthly, understanding the solution landscape becomes part of problem evaluation. It’s not enough to ask “what do customers need?” You have to ask “what do customers need that frontier labs won’t provide as infrastructure?”
Your competitive advantage isn’t building Word integration. It’s knowing that Word integration is coming and focusing your team on things Anthropic won’t build for you. The labs are commoditizing infrastructure. Your job is understanding what remains differentiated after that commoditization happens, and building that instead.