I think many compelling companies come from rigorously testing lots of possible solutions for a problem that the founders understand deeply. You might experime

I think many compelling companies come from rigorously testing lots of possible solutions for a problem that the founders understand deeply. You might experiment and fail with 10 different ways to solve that problem, before one of them sticks. But the important thing for building the right solution is understanding the context, situation, nature of the pain-point, implications of it, and why the world would be better served if it was solved. The benefit of solving your own painpoint is that you often understand these things instinctively, but it's helpful to talk to other people to understand how it is different for them. From there, the first solutions should be to validate this -- maybe the first version is a Google form or a manual inbox (i.e. "What can we test in 1 week vs. 1 year?"). For an example from me, I previously had a start-up where we provided version control for PowerPoint documents. Our first iteration was way too complicated and we went in solution-first. We built all kinds of shit people didn't need, like slide-by-slide version control, git integration, etc. On your current site, I could ask people if they want a plugin into PowerPoint which gives slide-by-slide version control using git, and get a bunch of feedback on that specific solution. Instead, it would be more helpful to step back and try and validate that sharing PowerPoint documents over email leads to versioning problems. From there, maybe I could dig deeper into specific use-cases, verticals, and understand a wider problem space, before talking about how people need the problem to be solved. I think the learnings would be 100x more useful than getting some specific feedback on my myopic solution. Similarly, I have found that users often love talking about their problems more than they love giving feedback on individual solutions.