How do you approach information architecture for a product with a lot of features?

Base the structure on how users group things, not on how the company is organized. Inventory what exists, then run card sorting or tree testing to find the users' mental model, and validate with first-click testing on real labels. Prefer clear labels over clever ones, keep navigation shallow where you can, and give a migration path when you change a structure people already know.

I start with an inventory, which is tedious and always reveals something. On one B2B product we found forty-one destinations in a navigation that presented itself as having nine, because features had been tucked into settings for years. Then I go and find the users' model rather than assert mine. An open card sort with fifteen people tells me what belongs together and, more usefully, what words they use. Teams love internal vocabulary and users do not have it. Then I build a tree and test it before designing a single screen. Tree testing is the cheapest high-value research there is: no visuals, just can you find where you would go to do this. If a task is under 60% findable, the structure is wrong and no amount of visual design will rescue it. The part people underrate is the transition. If you reorganize a product people use daily you have broken their muscle memory, so I plan for redirects, a short in-product explanation, and search that still understands the old names.