It depends on what you are doing. Frequently you know you have A, B, C, D use cases in that order of complexity.
A lot of people's instincts will be "Let's try it out with an easy use case like B" and then make the go-forward bases on that.
Then you go to tackle C or D and find out it's a no go.
The better strat can be a spike on D to verify the solution can handle it. This is hack and slash; your validating. After you work on the mature solution.
I've seen so many times people sink time into the mature solution based on A. Then you find out it won't work for D or you finally measure and find out there is no benefit.
A lot of people's instincts will be "Let's try it out with an easy use case like B" and then make the go-forward bases on that.
Then you go to tackle C or D and find out it's a no go.
The better strat can be a spike on D to verify the solution can handle it. This is hack and slash; your validating. After you work on the mature solution.
I've seen so many times people sink time into the mature solution based on A. Then you find out it won't work for D or you finally measure and find out there is no benefit.