I spent nine months building the wrong thing.
During my MBA at MIT, my co-founder and I created machine learning algorithms that could characterize clinical properties in stool images, a technology useful for gastroenterology clinical trials. We scraped Reddit for training data, launched campaigns, and refined the models. The tech was cool. The problem: we built it first, then went looking for someone who needed it.
We spent about nine to 12 months developing a technology that was looking for a problem. The clinical trial use case turned out to be non-viable. Only after nearly wasting a full year did we stumble onto a real problem: people with irritable bowel syndrome (IBS) and inflammatory bowel disease (IBD) struggling to connect diet and symptoms. We built an app around that pain point. The computer vision tech made it in, but this time it supported the solution rather than defining it.
That experience crystallized a principle that now shapes how I lead solution teams at WellSky: tech without a problem leads to wasted effort. The way to avoid that waste is to fall in love with the problem, not the solution.
It sounds simple, but anchoring on solutions too early creates three risks. First, you may solve the wrong problem entirely. Second, problems evolve over time while solutions ossify. And third, premature attachment to one solution blinds teams to better approaches hiding in plain sight.
Take patient discharge delays – a multi-layered challenge in hospital operations – for example. System automation could help. So could workflow redesign. Or staffing adjustments. Or training. Or managed services. Each represents a valid path. Locking onto one before fully understanding the problem constrains what you can build and who you can serve.
Multiple solution paths for a single problem
I offer three habits to stay problem-centered. The first: dissect the problem using the five Ws. Who experiences it? What pain do they feel? When and where does it occur? Why does it matter? Answering these forces clarity before anyone writes a line of code or drafts a feature spec.
The five Ws framework for dissecting problems
The second: expand the solution space. Use mental models to generate alternatives. Consider different time horizons, different users, different constraints. The goal is not to implement everything, but to choose the best fit consciously rather than defaulting to the first idea that feels plausible.
The third: validate solution assumptions early. Solutions rest on hypotheses about user behavior, willingness to pay, and integration complexity. Testing those assumptions with small experiments beats building for months on untested beliefs.
At WellSky, this approach shaped how my team brought prior authorization solutions to market. By anchoring on the core problem rather than a fixed product vision, we maintained flexibility to adapt as we learned what hospital systems actually needed. That flexibility made the difference between a solution that worked and one that merely shipped.
My call to action: ask "what problem are we solving?" in every meeting. Crystallizing the problem saves time and unlocks better solutions. Solutions are temporary. Problems endure. When you fall in love with the problem, you give yourself room to find the answer that actually matters.
