Describing a new feature, optimization, or new section of an existing app for engineering and the product team is fairly solvable. You can build on a specific existing point of reference and user research to describe the new thing to the teams.
But how do you communicate something big, new, and unfamiliar? You can do market and user research, competitive analysis, draw up real or imagined user journeys, and use all that to describe job stories and scenarios. But this thing starts to get really big (and very un-Agile). To the point that your documents are unlikely to be studied well. But all of that information is no less necessary to getting to MVP.
I'm feeling this more than usual at the moment as I work on a niche product that solves new and unique problems. Some problems that the target industry doesn't even recognize yet. There isn't a lot to point to as reference.
Have you found a consistent and cohesive format to describe a large new MVP in such a way that Engineering can confidently begin planning their stack and iterations?
Or does this "document" need to evolve in chunks over time, with the knowledge that it won't be done until the product is?