Product Thinking
How I think about products has evolved from "cool idea, let me build it" to "who has this problem, and is my solution better than what they're doing now?" That evolution is the difference between building random projects and building things people actually use.
User Problems First
Every product that worked started with a problem I understood personally:
- LockIn — I was doomscrolling instead of studying. The problem was real, felt daily, and shared by literally everyone I knew.
- Simplifly — travelers in Dubai paying insane roaming charges. Living in a global travel hub, I saw this constantly.
- Raly — expat workers sending money home through fragmented, expensive corridors. My dad works in cross-border payments — I understood the pipes.
- Tipp — service workers in Dubai with no easy way to receive tips. Saw the problem every time I went to a restaurant.
The pattern: observe a problem, feel the problem, then ask whether a solution can be built. Not the other way around. Starting with a solution and looking for a problem is how you build things nobody wants.
The Evolution
Phase 1: Build Anything (Ages 9-13)
Agency websites, markdown tools, photo booths — early projects with no clear user, no clear problem, no clear value proposition. This phase was about learning to build, not about building useful things. The projects were "random shit" (my words), but they developed the technical muscle.
Phase 2: Build Something Real (Age 13-14)
Tipp was the transition. It had a real user (service workers), a real problem (tipping friction), and a real value proposition (digital tips). It failed on regulatory grounds, not product grounds. That failure taught me that good product thinking isn't enough — you also need business thinking.
Phase 3: Build for Markets (Age 14-15)
Simplifly, LockIn, Raly — these are products built with market awareness. Not just "people have this problem" but "this many people have this problem, and they currently spend this much on worse solutions." The B2C to B2B pivot on Simplifly was pure market thinking: consumer eSIM is competitive; business eSIM distribution is an infrastructure opportunity.
The Framework
When evaluating whether to build something, the questions (in order):
- Is the problem real? Not hypothetical. Do real people experience this regularly?
- Is the problem mine? If I don't feel it, I probably don't understand it well enough to solve it.
- Are existing solutions bad? If good solutions exist, I'm competing with established players. If solutions are bad or nonexistent, there's an opening.
- Can I build an MVP fast? If the minimum viable product takes months, the idea might be too ambitious for a solo founder.
- Is there a business model? Not every problem worth solving is a problem worth building a business around. Revenue has to be plausible.
Design as Product Thinking
Product thinking doesn't stop at "what to build." It extends to "how it feels to use it." LockIn's three-step flow (choose apps, tap NFC card, focus) is product thinking expressed as interaction design. Every unnecessary step is a user lost. Every confusing screen is a review that says "doesn't work."
Figma is where product thinking becomes visual. Before any code, the user flow is mapped, the screens are designed, and the critical path from "open app" to "achieve goal" is as short as possible.
What I've Learned
The biggest shift in my product thinking: your product is not your code. Your product is the experience of using your code. The cleanest codebase in the world doesn't matter if the onboarding confuses people. The most elegant architecture is worthless if users can't figure out how to do the thing they came to do.
Build for the user, not for yourself. Unless — like with LockIn — you are the user.
See Also
- Building Philosophy -- the broader principles
- Ideas I Want to Build -- where product thinking meets ideation
- Figma to Code -- product thinking in design
- The Solo Founder -- the constraints that sharpen product thinking