The Client Knows What's Best and Most Important

We need to be careful here, because on the surface, this cliche is true. The signatories of the Agile manifesto thought it was true and I don't disagree.

Knowing what features are most important to the client tells us little about how to build those features.  There is often a massive gap between the problem-space and the solution-space. And there are many other issues that must considered. Not all involve the client.

The client may view a feature's importance different if it costs $50,000 vs. $5,000,000. The method of construction often defines the cost and schedule. Even the client can't know what's "best" or "important" until the product team has had a chance to weight in. I'm not saying the client won't have an important opinion. Just that it's not the full picture.

Architecture and design are part of the team weighting in. If you design a feature of a shopping cart that takes 5 minutes to add an item, it may be useless. 1-click ordering that has the user paying for the order in 10 seconds may be valuable.  The client cannot say which of these is possible.  They can be clever enough to ask for one versus the other, but feasibility is going to require more input.

And last, let's not forget that there is rarely just one client. Often there are a range of clients. Operations are a client, for example.  So is the analytics team.  So is marketing.  So are each of the user roles and the people that play them.

The idea that priority is solved by letting a product owner rank the backlog is naive.  The architect and project manager should establish the integration milestones. They then need to discuss them with the team. Once everyone is familiar with the milestones, consideration for features is appropriate.