Solved ain't needed
"Start with the problem", they said. But what does it mean, for real? Let's try to break it down!
Many of you are here just to follow my steps into the startup world, and I promise I’ll keep doing that.
However, I also feel the urge to talk about some things which are not strictly related to the step of the journey I am in right now. I'll try to give my own perspective on these topics, making sure to let you know how it really feels like to try and apply them in real life.
So, from now on, each newsletter issue will have a specific topic to talk about (sorry not sorry, fans of shorter newsletters 🤓). Let’s dive right into it!
But first, the latest updates from the trenches 🎢
We’ve officially moved away from the Clinical Trial (and Healthcare) space. Why?
We realized entering the Clinical Trial market was too complicated for a variety of reasons:
Geography: Italy turned out to be the wrong country, primarily due to budget constraints.
Intrinsic Dynamics: Our product aimed to reduce the power of Contract Research Organizations (CROs), yet the tool we envisioned typically falls under the management and enforcement of those same CROs.
Extremely Long Sales Cycles: The typical sales cycle ranges between 12 to 18 months.
High Regulatory Barriers: Too many certifications were required from day one, creating a significant initial burden.
Founder Fit: Being industry outsiders made navigating these complexities even more challenging.
We had managed to attract interest from some research centers, but their budgets were severely limited. The path forward would have required at least 12-18 months of bootstrapping amidst substantial uncertainty before gaining genuine traction. This route didn’t feel right, particularly as first-time founders.
So here we are again, back at square one!
Letting go of months of hard work isn't easy, but pivoting now is better than persisting down an unpromising path.
We're now exploring new problem spaces and have several new interviews planned.
But how to do that, you ask? Oh well, lucky you that’s exactly the topic of today’s newsletter!
Avoid the solution trap 🪤
"Oh, X looks messy… I bet an agent can fix it!"
Don’t!
If there’s a single piece of advice that gets repeated by successful founders, it’s this: start with a problem, not with an idea.
Engineers are especially susceptible to building “solutions in search of a problem.” We love technology for its own sake; we dive into picking frameworks and designing slick architectures.
A Solution‑In‑Search‑of‑a‑Problem (SISP) happens when you are so focused on creating something innovative that you never validate whether a clear, pressing problem exists. The result is wasted months, demoralized teams and products that no one needs.
Paul Graham famously wrote that “the way to get startup ideas is not to try to think of startup ideas.”1 When you consciously brainstorm ideas, “the ideas you come up with will not merely be bad, but bad and plausible‑sounding,” meaning you’ll waste precious time chasing something that feels real but isn’t. The best ideas emerge when you understand a problem so well that the solution feels obvious.
It should feel almost like a side project, solving a problem you have.
Be careful though. It’s true that by starting on a problem you have, you’ll understand the problem like no one else; but it might very well be a problem only you have, and there’s no market to it.
It’s clear that we need to strike a balance between building something that solves a problem (avoiding overfitting to what you think the problem is), and market research (avoiding analysis paralysis before building something).
I assure you: that’s way easier said than done!
Why is this so hard?
Human nature.
We are wired to love answers. When faced with a problem, we tend to stop ideating as soon as we think we’ve found a solution.2
This is called “Einstellung effect”, the predisposition to stick with our first idea, even when better solutions exist (or, in our case, even when customer feedback contradicts it).
To counteract this, we need a structured process:
Define the problem clearly. Draft a vision statement about how the world will look once the problem is solved; this keeps your team aligned.
Spend time with customers. Customer empathy is the only way to identify meaningful problems (→ avoid overfitting to your understanding).
Test multiple solutions. Write down ideas and put them through Build‑Measure‑Learn loops. Clarify your assumptions and design experiments to invalidate them (→ avoid analysis paralysis).
Be ready to move on. Falling in love with a particular idea isn’t bad as long as you’re willing to discard it when it doesn’t work.
Uri Levine, co‑founder of Waze, pushes this even further. He likens building a start‑up to falling in love: at first you’re infatuated with your idea and ignore friends who tell you it won’t work. That passion gets you through early setbacks, but it also makes you deaf to feedback.
Levine urges founders to identify a big problem worth solving and talk to the people who experience it. If only one person (you) has the problem, don’t build a company. If many people share it, go and speak to them to understand their perception of the problem before building a solution.
Starting with the solution means you start building something when you’re the most ignorant about the problem you’re solving. Start with understanding the problem first, otherwise you risk creating something no one cares about, which is why most startups die before product–market fit.
And even when the problem feels obvious, avoid the “feasibility first” trap. Many startups start by asking whether something is technically possible, rather than whether anyone needs it. It also leads to focus on Analysis, rather than Action (Analysis Paralysis warning!), but in a way that doesn’t let us understand the problem better.
Feasibility mattered more in the manufacturing era; today the biggest risk is building something no one wants. We need to talk to customers to understand their jobs-to-be-done and decide whether the problem is worth solving, viable and feasible.
How it feels like living the “problem‑first” mantra
If all this sounds simple and logical, that’s because in theory it is. In practice, it feels messy and uncomfortable.
As engineers, we derive our sense of progress from building things. Talking to users feels intangible; there’s no dopamine rush from shipping a line of code. Spending weeks on problem discovery makes you feel like you’re standing still while everyone else is sprinting past.
And yet, if you commit to a solution too early, you’re essentially betting your company on the least informed version of yourself, the you who knew the least about the problem.
There’s also fear. Fear that talking too much to customers will somehow “taint” your vision; fear that you’ll discover there isn’t a problem worth solving and have to start from scratch.
The irony is that avoiding those conversations is what leads many startups to quietly fade away.
In my own journey, resisting the urge to build has been one of the hardest disciplines. I’ll sketch out a feature, then force myself to delete it and schedule another interview instead. And each time we stop and listen, we uncover nuances we hadn’t considered.
Sometimes a problem we thought was critical turns out to be a non‑issue, or the real pain is adjacent to what we assumed. Other times we uncover a new segment of users with a much bigger problem. This slow, ambiguous work is what keeps us from spending months on a SISP.
Okay, so what?
If after everything I said, it still looks unclear what we should do, well it’s because… It is unclear.
Let me stress a couple of key points:
desk research is still important to be sure you’re not going into a dead market before investing time
taking Role Models into consideration is a great way to get ideas and uncover non-obvious trends
make sure to understand the problem does NOT mean spending weeks in user interviews without building anything.
All of these are extremely valuable tasks among the bunch of things we need to do, but deciding how to prioritize them is crucial. I’ve already mentioned how hard this is, and no one is going to tell you how to do it. Certainly I’m not here for that.
But I can tell you that knowing “why” we do these things is a key factor to guide us through this intentional prioritization. The north star should be understanding the problem better.
To maximize the chances of getting to Product Market Fit, we need to tailor everything we do in this phase (desk research, trying out existing models, building something, etc) to the sole purpose of learning more and more about a problem. Only then, maybe, we’ll “incidentally” stumble upon a solution that really solves it.
Every step should lead us closer to understanding the real problem deeply enough to make solutions obvious, rather than forced.
That’s it for today!
Excited to dive deeper into our next exploration! Stay tuned, the real fun’s about to begin. Cheers 🍻
Einstellung effect. Finally that thing has a name!
👏🏻👏🏻👏🏻👏🏻👏🏻