>Once you identify your benefiter, you need to understand how your product can help them get where they want to be.
How can you identify a benefiter of a product, without knowing the problem that the product is going to solve (help them where they want to be)?
>hacks are temporary fixes at best. They (the high expectation customers) need a single solution that meets all their demands.
This isn't true, a hack doesn't imply that it's temporary, its longevity depends on the underlying problem and problem space. And even if they would be temporary, quick hacks can be more flexible and make it easier to react to a changing environment, so if that's important..
> How can you identify a benefiter of a product, without knowing the problem that the product is going to solve (help them where they want to be)?
The two go hand in hand. You need to have an idea of where you want to be. However once you find the customer willing to spend money (if you are a business make sure they are willing to spend money!), you should chase the and ensure they are satisfied first. Don't make them regret giving you money by prioritizing features that they don't need over features they need. Make sure they are satisfied first, and use their satisfaction to drive more customers who are treated the same way.
Of course you need to be careful. If you want more than one customer you may eventually need to do a feature your customer doesn't need because future customers will, even at the expense of losing your one customer. This is a complex decision that you need to consider carefully - in part because how you treat your customer gets out and may drive away potential customers. There are a lot of products out there with exactly one customer, one more consideration. You need to figure out how this applies to your product yourself.
Wouldn't it be smarter to be the customer yourself, basically develop something for your own (business) progress or job to be done, and then sell it optionally to those in a similar situation?
The market first approach (developing a product for demand) only seems to really work with more generic products without high development cost, where the product advantages that result from deeper customer insights can't really play out. Where you don't run the risk of being outcompeted by a company that has those insights and customer trust from "wearing the same shoes" as their customers.
Market first could also work if you anticipate a future demand and it's a completely new market without any players yet, where you'd become the trusted choice over time because you're then seen as the original brand. But without funding it could be impossible to sustain to the point until you have enough customers.
Only if you are your own customer. There is a lot of need for software where the user is not a developer, and has better things to do with their time than write software.
Very true about "hacks". Oftentimes they have longer lifespan that standard solutions - because they "just work", might actually be inherently fragile, the original hacker is not around anymore, etc. => better not touch what ain't broken.
How can you identify a benefiter of a product, without knowing the problem that the product is going to solve (help them where they want to be)?
>hacks are temporary fixes at best. They (the high expectation customers) need a single solution that meets all their demands.
This isn't true, a hack doesn't imply that it's temporary, its longevity depends on the underlying problem and problem space. And even if they would be temporary, quick hacks can be more flexible and make it easier to react to a changing environment, so if that's important..