“I just need the technical solution to be figured out before the discovery starts”… ok so you’re not doing a discovery.

I can’t count how many product managers I met in my career who needed to do a discovery but didn’t want to discover (left alone the adventurous concept of “exploring”). Seriously folks if you can’t deal with ambiguity just go back to project management and stop wasting everybody’s else talent. #PM101

And if you’re wondering how to resolve a scope with a variability highly dependent on the technical solution, here is what should help sleep at night (and day):
• scope is always highly dependent on tech solution, this is the only constant ;)
• scope for the smallest thing and go for discovery asap (asap == as soon as you can with a properly staffed and focused team, no joke!) the team will figure out together what can be a working solution and identify if the solution require a lot of tech work
If after this early stopped discovery, user x problem x solution is still unclear then rescope a new discovery. It sounds like making twice the same thing but eventually you’ll save time, build the right thing, contribute to the team learning while building meaningful software. And when shit hits the fan (because it always does more or less) everyone will be able to answer the question “why did we decide this like this last year?”
Also if you have been smart you built a shared understanding of lean planning on your org and maintained a transparent and clear line of communication so that stakeholders understand that planning is a thing subject to change not a matching tattoo. Build to adapt folks, otherwise you’ll end up scared of any question and insight.