Discover people not projects. If you want to deliver a service that really meets user needs, you need to understand what people are trying to do, and how they're trying to do it, when they encounter your service. This means that research during discovery might seem 'bigger' than it needs to be for your specific project. This is because you've got a bunch of preconceived ideas about what your project should be. This is exactly why we do user research: to find out what people are doing now to solve their problem, understand what needs they have, and to understand how we can best help meet those needs. Then it's time to work out what the project should be.
Discovery is for discovering, not for prototyping. Making is an excellent way to learn about a problem, but that doesn't mean you need to make from the very beginning. Put the code away for a few weeks, get out into the field, and understand your users. Understand how different they are from you and your team. Spend some time doing this at the outset of the project, and it's much more likely that the thing you make will meet everyone's needs and not just yours.
If you haven't discovered you were wrong about some things, you probably haven't done it right. Discovery is not for validation. The point of research during discovery is to work out what people need, and what you need to do to meet those needs. It's not to prove that a project should proceed. If you set out to validate, you won't learn what you don't know. What you don't know is the thing that will ultimately make your project fail. It's fine to have some hypotheses about what the project will be, but go into discovery to test those hypotheses, not to validate assumptions. The way you frame the user research in discovery will make all the difference.
Edās note: While our approach and methodology is more structured than that shown in the diagram that accompanies this post, these points made about the discovery phase are worth noting.