You make it sound easy and obvious, but the problem is that customers doesn't actually know what they need. They know what they think they want, but they usually want something very much tailored to their business, using their ideas, and their workflows, but at a price of $10/month because it's a SaaS app. Building something that works for many customers means you actually have to come up with a very astute compromise between what the customer thinks they need and what they actually need, and sell the product to them by persuading them they don't actually need the things they just want.
On top of that there's an added problem that customers are often wrong. They tell you what you want to hear, or worse, they tell you what they want to hear. And you have to work out what's really needed based on those conversations.
My startup failed for this exact reason. We listened to our potential customers, we talked to them in focused test groups, we built what they said they needed, we showed them prototypes, but at the end of the day they realised what they really wanted was something else, and in many cases the pain we were solving (managing project requirements) wasn't even that important to them. By then we'd run out of funds. The end.
We took similar actions at my recently failed startup, which headed on a slow, downward path. I identified an apparent pain in our target market based on past conversations with friends working in that space. My team and I felt we validated the pain because we kept hearing about it in our face-to-face interviews with potential users & buyers. One interviewee even went into mild theatrics half way through his interview, "Stop! This keeps us up at night because we ..." That was just the beginning of his 10 minute proclamation that the problem was worth solving, and that they'd pay a decent amount for the solution. Exactly how he said it.
We developed what we thought and what our potential customers claimed was a solution to an unmitigated problem in a very sensitive financial process. We followed startup advice and made it clear that we would charge for the solution. Fast forward a few months: usage dropped from supercharged to minimal then to nothing. Most of the customers we worked so hard to acquire went back to their old ways. When we did followup calls, their newer recruits were none the wiser that we even built something specifically for them. Clearly, the problem wasn't that important in the grand scheme of things.
Customers know their pain. Don't expect them to innovate and create the solution for you, but get them to describe the problem. You can then go back in other rounds offering potential solutions through prototypes. Try to keep moving towards getting them to commit (i.e. pay). Ask what it would take to make them buy, what they'd pay, etc.
It may not be easy to do, and I agree that people don't know what they want, but it took these guys 10 months to do any research. They shouldn't have built a thing, but should have put prototypes in the hands of customers ages ago. Then they might have learnt the things 10 months ago they're only just learning now.
There's the old adage from Ford "If I'd have asked customers what they wanted, they'd have said a faster horse". But that's asking them for a solution. It's your job to come up with that. But the customer is the one who knows the pain. And if they can't describe it, it's not big enough to solve anyway.
Nail it then scale it (www.amazon.co.uk/Nail-then-Scale-Entrepreneurs-Breakthrough-ebook/dp/B0055D7O1U/) describes a practical product development process that puts research at the forefront.
On top of that there's an added problem that customers are often wrong. They tell you what you want to hear, or worse, they tell you what they want to hear. And you have to work out what's really needed based on those conversations.
My startup failed for this exact reason. We listened to our potential customers, we talked to them in focused test groups, we built what they said they needed, we showed them prototypes, but at the end of the day they realised what they really wanted was something else, and in many cases the pain we were solving (managing project requirements) wasn't even that important to them. By then we'd run out of funds. The end.