Is solving your "own problems" the best way to build a product?
For us, it started from something frustrating: creating content felt very annoying and time-consuming. We tried the classic way: scripting, memorizing, filming, editing. But none of it felt authentic. And honestly, it was eating time we needed to focus on other things.
At the same time, we kept reading the same advice everywhere:
"founders should build in public and create content consistently". Easy to say… but harder to do in reality. So instead of forcing ourselves to create content from scratch, we tried something simple: recording our own calls and using those moments as content.
What surprised us was how much easier it became. The content felt more natural, and it didn’t feel like extra work anymore. That’s how @ProdShort was born.
It made us realize that many product ideas probably don’t start from "big visions", but from small daily frustrations that keep coming back.
From your experience:
Did your product idea come from a problem you personally faced?
Or was it something you noticed while observing others?
Replies
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?
Hello Inbox
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.
Magic
Solving your own problem is a good starting point, but it can also be a trap.
Founders are a pretty specific type of person. When you filter everything through "would I need this," you're basically validating with a sample size of one, or a few co-founders at best.
If you want to build something really big, weekly (ideally daily) calls with actual users will teach you more than any amount of internal conviction. Your own frustration gets you started, but other people's frustration is what builds the product.
I think solving your own problem is often the best starting point, but not always the whole answer.
For me, MapleBridge started from a very specific frustration: buyers and factories were both depending too much on platforms, rankings, and paid visibility. Small buyers often don't know how to describe what they need, and good factories often don't know how to be found unless they play the platform game.
That was my own frustration first. But it only became worth building when I kept seeing the same pattern from both sides.
So maybe the test is: does the problem still feel real after you step outside your own workflow? If yes, it may be more than a personal workaround.
I think building from your own problem is a good start, because at least you are not guessing.
You know the pain for real.
But it can also trick you a bit.
Because sometimes you think “I have this problem, so many people must have it too” — and that is not always true.
I’m facing this now with something I’m building around gym consistency. The idea came from my own frustration after years in the gym.
I know the problem is real for me.
Now the real work is finding out if enough other people feel the same pain strongly enough.
For me it is always observing however my very first IT product was made to solve my bussiness problems