Before defining an IA strategy, you need a real understanding of what content already exists, what's planned, and what gaps need filling, drawing on content-owner interviews and, ideally, a facilitated content-strategy meeting with the range of people who plan, create, and manage that content. If no dedicated content strategist is on the team, the IA may need to take on part of that role directly, since a viable content strategy is a prerequisite for a workable IA strategy, not a parallel, unrelated task.
Just as important is understanding the technology the content will actually live in, particularly the CMS, its capabilities, and its limitations. This means asking developers direct questions: what platforms and devices need to be supported, whether the system can structure content the way the design calls for, whether it supports content reuse and personalization, and what constraints already exist. In an ideal world, technology would be built to match whatever the design strategy requires. In practice, most projects inherit technology choices that are already made, and the design strategy has to be realistic about working within those constraints, reserving the harder conversation about acquiring new technology for cases where the existing limitations would seriously compromise the business goals or the user experience.
An IA strategy that ignores what the CMS can actually do isn't ambitious: it's just a plan for a second, more painful round of renegotiation once implementation starts.
Proposing a realistic strategy that works within current constraints, while documenting faceted navigation as a justified future investment, is correct. Ignoring the technology constraints and designing the full faceted strategy anyway sets the development team up to either miss the deadline or deliver something that doesn't actually work, the source material is explicit that most projects have to design realistically within inherited technology choices, not around them. But abandoning the content findings entirely goes too far in the other direction: the duplication and structured-template opportunities the content analysis surfaced are real and don't depend on faceted metadata support at all, so there's no reason to discard genuinely actionable findings just because one specific recommendation hit a technical wall.
The distinction between what to push back on and what to accept comes down to impact on core business goals versus preference. The lack of faceted metadata support is worth escalating as a real conversation, if faceted navigation would meaningfully affect conversion or findability for a large product catalog: that's exactly the kind of business-critical gap the source material says justifies raising the harder question of acquiring more capable technology, even if the answer turns out to be "not before this launch, but plan for it next." The limited content reuse across templates is more reasonably something to accept and design around for now, restructuring the content model to reduce duplication as much as the current CMS allows, without holding the whole project hostage to a capability that isn't strictly necessary to hit the redesign's core goals.This reflects the balance the source material describes: default to designing within existing technology, but don't treat every constraint as equally non-negotiable, reserve pushback for the constraints that would actually compromise what the business is trying to achieve.