Check out BML, OODA Loop, Google Design Sprints, etc.
They're advocating serial processes that are basically:
1) build just a little
2) go observe what people think
3) harmonize those observations with your next build
A design sprint is a week long thing: some days are pure building, some are pure observing. But most days are a bit messy with a meeting scheduled on a build day, some bug fixing scheduled on an observe day, etc. The mess is okay, you're just following the cycle as best you can to ensure you're doing them both in a self-supportive cadence.
EDIT: adding another consideration, often you don't have a regular stream of inbound conversations, and you have to go outbound to get them. Best to do this when your first assumptions start forming around what you're building, that way, (a) the conversation is scheduled to give you feedback by the time you finish and (b) the meeting itself incentivizes you to build faster.
They're advocating serial processes that are basically:
1) build just a little 2) go observe what people think 3) harmonize those observations with your next build
A design sprint is a week long thing: some days are pure building, some are pure observing. But most days are a bit messy with a meeting scheduled on a build day, some bug fixing scheduled on an observe day, etc. The mess is okay, you're just following the cycle as best you can to ensure you're doing them both in a self-supportive cadence.
EDIT: adding another consideration, often you don't have a regular stream of inbound conversations, and you have to go outbound to get them. Best to do this when your first assumptions start forming around what you're building, that way, (a) the conversation is scheduled to give you feedback by the time you finish and (b) the meeting itself incentivizes you to build faster.