I've recently been asked to give the architecture for the second release of a project. I do not know what will be in this second release as the content of that release depends on what tools we'll choose to use.
Seems that I have a chicken and egg situation. The UX team doesn't want to introduce a new functionality without knowing what tool will be available to use it properly and how users will be able to interact with it. But how is it possible to select a tool without knowing what it will be used for? Of course, there is a vague idea of what it would be used for. Let's say the UX asks for a catalog tool, something that can contain products, a bit like what Amazon has. With a vague requirement, it's difficult to know what the real objective is.
Since the objective is vague, why not use the most generic product tool out there? Why not use a CRM for example? That should cover most needs and if not, an extension should be feasible.
Such a tool could fit most needs, but the cost of such a tool is complexity. I'm thinking about installation, deployment, maintenance, onboarding for such a tool. Is it really worth it?
I'm a big fan of the Lean Methodology, which advocates starting small, and do just enough to build a solution to the project's top must-have features. Then iterate. It's very likely that needs will have evolved and that priorities will have changed by the first iteration. In comparison, a Waterfall Methodology would not have had the feedback from iterating and chances are the initial direction was wrong.
Choosing a complex one-size-fits-all tool is to be avoided. Instead, an incremental work on requirements is preferable.
NB : For some, this may be obvious, but it takes implacable arguments to make this clear.