Is solving your "own problems" the best way to build a product?

I think the strongest product ideas usually start from a personal frustration, but become real opportunities when you notice other people struggling with the same thing too. That repeated signal is what makes it more than just your own problem.

Mine came from watching, not experiencing. I never got sick from a recalled product. But I kept noticing the same pattern: a recall gets issued, it's buried on a government website in a PDF nobody reads, and families find out weeks later if at all.

So I started looking into it. 13 countries, all with different agencies, different formats, different levels of accessibility. Some have APIs. Some publish scanned PDFs. One was behind a bot-detection wall that blocks any non-browser request.

The frustration wasn't "I need this tool." It was "how does this not exist already." That's a different kind of itch than personal pain. And it creates a different kind of product. Personal-pain products tend to be tight and opinionated. Gap-observation products tend to be broader and harder to scope. I've fought scope creep basically every week because of it.

I think the biggest advantage of developing something for your problem is being able to have a user feedback right from the beginning. There are millions of problems to be solved in the world but knowing the customer gives you a great advantage where to start and how to solve the problem. I have just one product but not originated from my own pain. The first aim of my first product was to experience a product's lifecycle from coding to marketing as a solopreneur.

I think solving your own problem is a great starting point, but the important part is checking whether other people feel the same pain.

My current project came from that kind of frustration. I kept watching YouTube videos about AI/SaaS/startup ideas, but after watching them I still wasn’t clear what to actually do next whether the idea was worth building, what the risks were, who would pay, or what the MVP should be.

That repeated gap pushed me to build something around turning startup idea videos into more decision-ready plans.

So for me, the personal problem created the first signal, but now the real test is whether other founders feel the same confusion after consuming idea content.

I think yes, if you can't find solutions that help you. I am actually in the same spot as you are now.

First we started with something easy - a CRM. So we looked at solutions like Zoho, Hubspot etc abut no one was offering stuff we wanted (which I can't explain here). So I decided that enough is enough. I personally jumped into programming - two years ago - while realising that marketing alone, is not enough anymore.

Hence we build - with the help of AI and my own skills - our very own CRM which now does everything we want. While we are not selling it, we are constantly enriching it and eventually we will.

Then we started having other issues - for example, getting traffic. We build a tool that does programmatic SEO. Then we faced issues with shipping providers and tracking - we built a tool as well - and its going to market this Monday.

And then, we decided to start looking at want the market wants that is aligned with what we offer so we are building other tools as well.

I believe the same as you are - frustrations lead people to develop their own products and make them go wild. Plus, it helps with our industry and our job which is going to go extinct in a few years :-(

We spent a lot of time just talking to potential users early on, and used social media as an anchor for questionnaires and quick polls. It's a low-friction way to test whether a frustration you're imagining is actually shared, or whether it's just you.

The trap with "build what you'd use yourself" is that without feedback and iteration, you end up building for an audience of one. Founders are unusual users almost by definition. The polls and conversations don't replace your own intuition, but they keep it honest and you find out pretty quickly which problems people will actually pay to solve versus which ones just sound good in a pitch

I think solving your own problem is probably the best starting point, but not enough by itself. For me, Theoria started from a very personal frustration: I kept opening papers, abstracts, PDFs, related tabs, and somehow ending up more confused than before. The first version was basically just me trying to make research feel less heavy: find papers, explain them in plain language, and let me ask basic questions without pretending I already understood the field. That gave me conviction, but it only started feeling like a product when I noticed other people had the same problem too: students, builders, curious people, even non-scientists who want to understand what a paper actually says without spending an hour decoding it. So my rule right now is: own problem gives you the emotional pull, but other people repeating the same pain tells you whether it should become a product.

Came from my own problem completely. Background: I was structuring renewable energy deals at Ørsted (project finance side of M&A and partnerships), and every new transaction started with the same painful ritual — pulling together a project finance model with DSCR sculpting, DSRA, construction-vs-operations phase logic, sensitivity packaging, lender-grade outputs. Each time, the public templates online were too generic to use without an architectural rebuild, and the deal-tested ones inside any given firm sit behind NDAs and don't follow you out the door.

So I built mine in a way I could re-use across deals: clean inputs separation, an explicit circularity switch for the DSCR-interest dependence, sensitivity tables on the assumptions that actually move the answer rather than every input, an outputs tab built for credit committee not for me. Once I had three or four cleaned-up versions, it was obvious other practitioners had the exact same problem. The "product" was already there; the productization was 90% formatting, documentation, and stripping out client-specific data.

The pattern I'd flag for the question, though: "own problem" works as a starting signal but it's not sufficient. The reason your ProdShort journey resonated is the second step you implicitly took: you noticed the same friction in others doing the same workflow. That's what separates a personal-utility script from a product. The first step tells you the problem is real for someone (you). The second step tells you it generalizes. For me, the generalization signal was talking to other practitioners and finding they were all rebuilding the same waterfall logic from scratch every quarter.

The trap on the other side: building for yourself and assuming the next person wants the same thing. Most people don't want a 30-tab project finance beast — they want the four tabs they actually need. So even when you start from your own pain, the product version is usually a subset and a rephrasing of what you'd build for yourself, not a copy.

Congratulations on the launch of ProdShort, Amrani! I couldn't agree more—authenticity is the hardest thing to "fake" in content, and using your actual calls as the source material is a brilliant way to solve your own bottleneck while keeping it real.

To answer your question: PictaBase was born 100% from a personal "industry itch." I’ve spent 30 years in Hollywood post-production, and PictaBase was specifically conceived because of the nightmare of continuity photos.

The "Small Frustration" that built PictaBase

In film and TV, a Script Supervisor takes thousands of photos to ensure that a coffee cup doesn't magically move between shots or a character's tie doesn't change color mid-scene.

The "Old Way" was a mess: * These critical photos ended up in "dumb" hierarchical folders or, worse, trapped in a private WhatsApp thread on someone's phone.

• If that person left or the phone died, the "visual memory" of a $100M production died with it.

• Searching for "that one shot of the watch in Scene 42" involved endless scrolling through thousands of files named IMG_8432.jpg.

I didn't have a "big vision" of changing the world; I just wanted a relational visual database where a photo wasn't just a file, but a piece of data connected to a scene, a character, and a prop.

Why solving your own problem creates a better product:

When you build for yourself, you don't guess on features; you build for Engineering Rigor:

• Pixel-Blind Privacy: On a film set, security is everything. Our server never sees your pixels; bytes go directly to S3 via presigned POST because that’s the security level I’d demand for a high-budget project.

• No Data Ransom: I’ve seen enough proprietary software "disappear" and take the data with it. That’s why we write every tag and note to a .meta.json sidecar file in the user's own bucket. You own the continuity, forever.

• Stability for Professionals: Built with 38,500 lines of PHP 8.4 code enforced at PHPStan Level 8. When you're on a $500k-a-day shoot, the tool cannot crash.

For any of your users who are archiving their "call-based content" and need a professional way to manage that visual library, our fully functional Free Tier (250 MB) is open for stress-testing today.

Success with ProdShort—solving your own problem is usually the only way to build something that people actually stick with!

Question for you: Now that you've solved the "content creation" part of your call recordings, do you find your users are starting to ask for a way to search back through all those snippets once they have hundreds of them?

Both businesses I currently run are solutions to personal problems. And I've started many businesses in the last 20 years. So yes, I think it's a shortcut to finding good business ideas.