Adam Sand argues that vague problem statements reveal a weak understanding of the solution. Before building anything, ask: what problem are you solving and what KPI proves it's fixed? If you can't measure it, you don't understand it yet.
It's like, what problem are you trying to solve? Because the degree to which someone can explain a problem tells you how well they understand the solution. Because if they can't click, like, like I, like I talk to business owners and I say, well, what problem are you trying to solve? And they'll go on like a 4-minute rant that goes like, well, I want to do this because eventually I think we could do this. And I'm wondering about this. And I mean, AI is probably going to be here in 2 years. And then what happens if Anthropic servers crash, and I think that we could probably build some kind of voice recorder app. I'm like, what, what problem are you trying to solve? What KPI are you trying to solve? Like, and so then I say, well, what would it take to solve that problem, right? What would it take to actually, to actually resolve? Like, what would it take for the problem to be considered solved? And then sometimes there isn't clear— there's like a problem, but they don't really know what the solution looks like. So I'm like, well, what do you want to have happen? Right? And sometimes I'll ask, like, what does that mean? Because sometimes people will say something's a problem and it's like subjective happiness. It's not something objective. And I'll say, well, how do you know that that is actually a problem? Or how do you know that that solution would actually fix the objective KPI or goal?
