Speaking from experience from both the business and technical (web/software) sides discovery can be absolutely crucial (depending on one’s goals) and it is one of those areas where even if you think you can and are skipping it in reality you just hide it or bake it in to another step in the process. Just cause something isn’t confronted by you doesn’t mean it no longer exists, it’s really of question of do you want an explicit discovery phase or an implicit one.
For instance, a developer builds a software program in isolation but intends for someone other than themself to use. They figure they have a good grasp at what the end user’s real problem and a solution that is intuitive to use and effective at solving said problem, so they skip discovery. Months later, they launch and several things could happen.
They have immediate success, proving their initial assumptions were right. (this is rare but possible). What next? How do they expand on their initial success to help more new users or new features current users are requesting? How do they balance features for new users versus continuing to support existing users? If they didn’t have a process for discovery before they will probably need one now and they’ll have less time, more to lose, and more users to disappoint.
They have moderate success proving they were right on some assumptions. Same questions as above. How do they tweak their current features and offerings to bring in more users or increase existing user satisfaction encouraging the coveted word of mouth marketing or network effects? <- Seen this happen
They launch to crickets proving all original assumptions incorrect (margin of error could be huge or very small depending on competition). Where do they go from there? How do they learn where they went wrong and how to resolve? More features? Improve existing features? More marketing? <- Seen this happen
In all of these scenarios, discovery happens eventually it just depends on when you want it to happen and the level of risk you’re comfortable with at conception versus at launch.
As @Dane mentioned it depends though on what your expectations are out of whatever it is you’re thinking to make.
If your goal to is simply to make for the sake of making then the discovery phase isn’t really necessary. (Side note: still probably want some measure of “done” unless you plan to continually work on this until something else becomes more interesting)
If your goal is to make something specifically to solve a problem that you have then discovery is limited to what you want and what you define is “done”.
If your is goal is to make something to solve someone else’s problems (even if you share the problem) it’s probably best to do a little discovery at the beginning and at regular intervals throughout the process. There’s no shortage of startups and products that expected huge success but failed due to not understanding their user, the user’s problem, or the best solution for the user.
If you plan to get funding from anyone beyond friends, family, or inexperienced angel investors, then expect those investors to expect that you’ve done some discovery. Otherwise you’re just asking them to trust you (potentially a stranger) with a lot of money (more than most us of will see in a lifetime) that you know what you’re doing. <- This route often requires ridiculously big personalities or previous startup success.
In the end, this is all just my view based on my experiences and this is the web so take this with a grain of salt. Your situation and experiences could be drastically different than mine or others.
Personally, I constantly have to rein in the urge to just make and avoid the often daunting (to me) discovery phase as it may bring the realization that my idea just isn’t that good or will require more work to make good than initially thought, and can require the potentially uncomfortable situation of talking to people about something you care about and they may not like or understand.
Best of luck!