Know Your Customer
Customer-driven development is the only way I think makes sense to develop "real" software. I am an advocate for and enthusiastic participant in, experimenting with new-and-exciting technology. This allows me to try new things and expand the surface area of my skillset, without the expectation of making something particularly useful. But if it is something I am intending to use for myself "long-term" (whatever time period that ends up being) or offer to others to use, where I will support them (either open source or as a paid product), it is essential, at inception, that I have the customer top of mind.
I need to document what they need (which MAY even be what they want) and start from there. As you may have inferred, I believe all "users" of an application are literally customers of some kind. They pay you with real dollars (or your currency of choice :) ) or their attention. Internal or external to your organization, they are your customers and your duty is to serve them with what they truly need. Clearly, you need to determine what that actually is.
If you are building for yourself, you have the distinct advantage in knowing what you need (although I would make the argument, based on personal experience, that it is sometimes hard to honestly distinguish between wants and true needs). Which makes it tempting to just start writing code, something I have done plenty over the years. However, when you take this nonchalant approach, it is easy to get lost since you have not defined a path to get you to your destination (i.e., the finished product). Though, as a stereotypical developer, I have a natural resistance to documentation, for the sake of documentation, you are doing yourself a (potentially huge) disservice by not establishing some basic essentials. Yes, even when you are the primary or sole customer!
When you are building for a customer who is not just you, it seems like it would be obvious to document what the application is going to do. After all, all parties involved need to know when the application is "done" (meaning version N is "good enough" to deploy to production). But I've observed, through my experiences over the years, at companies large and small, a wide discrepancy in how "requirements gathering" is performed and deemed complete.
You need some standards, consisting, at a minimum, of templates and a repository to serve as the single source of truth. The templates, the documents created from them, and the structure of the repository can evolve and should be considered living documentation. If you use a project management system or discuss requirements in other systems (IM, email, etc.) you should ONLY link to the corresponding document(s) in the repository. Otherwise, as soon as a document is cloned and sent in an email to someone, everyone starts doubting the accuracy of the system and the thrash cycle begins. Few things are more momentum-killing than meetings about documentation being out of synch or an eventual realization that code has been written by two developers from two different specs.
You also need the specs to be written with a "design language" that is confirmed to be understood by all team members (not just the "functional" subteam or the "technical" subteam, if these labels exist).
If the entire team cannot be confident that ALL members agree that the application's requirements have been captured AND that it is clear what each requirement means (because it's been captured at a sufficient granularity at which it's unequivocal) how can you possibly think that what eventually gets built is going to be what the customers need?!
If everyone smiles and nods and assumes gray areas and lingering questions will get sorted out automagically down the line, the problem gets kicked down the road to the developers, who, if they have time and confidence and are empowered to do so, should push back and demand clarity. However, if they don't, down to the testers it goes. The same thing applies to them as it did to the developers. However, if all of their tests, based on acceptance criteria defined during requirements gathering, passes, out to production it goes.
Now, I know some people who legitimately enjoy being on-call for after-hours production support. They find it exciting and, while I don't share their enthusiasm, it is critical to have well-defined support and make sure your customers' systems are doing what they need them to do when they need them to be doing it. I personally don't enjoy being on-call, round-the-clock, for production support because I've often been paged in the middle of the night to deal with something whose root cause will eventually be determined to be an issue that should have been caught during testing (of some sort) or an unclear use case that a developer guessed wrong on, or, worst of all, a missed requirement. Why not do everything in your power to reduce production support to instead addressing things that are unlikely, uncommon, and infrequent?
It all starts with getting to know your customer, figuring out what they actually need, making it clear to them that you are in agreement as to what you're setting out to build together, and then, for the fun part(!), actually building (AND supporting!) it.