I didn’t expect my first product idea to become a map.
At first, it was small enough to fit in one sentence:
What if there were a chatbot that helped people find genuinely remote jobs?
Not every remote job. Not another enormous job board with filters that mostly work. I wanted to focus on companies that truly hire internationally. Curated companies where working from Ecuador, Colombia, Brazil, or anywhere else is not an exception hidden in the fine print.
And then go one level deeper.
What do those companies actually value in a candidate? Is it deep technical knowledge? A specific way of communicating? Experience working async? A portfolio that shows initiative? A combination of all or some of those things?
The product started to feel like it could help people find more than openings. It could help them understand their fit before applying, which became the point.
I called the idea Lalo. It stands for Life After Layoffs.
An idea rarely stays one idea for long.
The problem was personal
Not long ago, I started watching friends, colleagues, and countless people across tech navigate a wave of unexpected layoffs. Their search for remote work often felt less like finding an opportunity and more like navigating a maze.
There were platforms everywhere: LinkedIn, FlexJobs, We Work Remotely, Working Nomads, and plenty more. But listings often had a catch: some were geographically limited, while others were outdated. Some sent you through several registrations before revealing anything useful, and then plenty more felt like a conversation with a bot whose only goal was to collect your email and personal data, without ever offering a real human interaction.
I applied to some myself, only to receive the familiar mass-produced, AI-written rejection not days or weeks later, but several months later: praise for my CV followed by the news that the company had chosen another candidate, without further feedback.
After rejection email #20, I started to feel the desperation any other job hunter feels, and I was running out of companies to apply to or roles that were really aligned with my skills.
Then, the distance from Ecuador was not only physical. It was built into the filters.
In job boards like LinkedIn’s, companies are constrained by location settings, listing roles for specific countries despite being willing to hire remotely much more broadly, something that candidates couldn’t see over a quick search. Other companies said “remote” but meant “remote within a three-hour drive of our office.” It made clear why looking for a new opportunity can be so stressful. There's also the case where a single company floods LinkedIn’s job board with the same role posted for ALL the countries in the world to ensure it reached everyone.
Remote does not always mean without borders.
That frustration became the starting point for Lalo.
The goal was not to build another list of jobs. It was to build an assistant around the messy parts of remote hiring: location, experience, salary expectations, working style, and the less-visible signals that tell you whether a company is actually a good fit for people, or for that particular someone.
Simple. Or so I thought.
Every answer created more questions
I spent weeks organizing the idea before writing a single line of code.
I asked:
- What would make this different from other job sites or chatbots?
- Why would someone use it instead of LinkedIn?
- Who exactly am I trying to help?
- What would make its recommendations trustworthy?
- Where would the information come from?
- Is a chatbot enough, or does it require producing a massive app?
- Should it be a web app, an iOS app, a public GPT or something else?
- Which AI provider should I use?
- How much of the experience needs to be automated?
- What about the tokens and limits?
For every question, I found an answer.
Sometimes I found three. That might sound useful but isn't always the case.
An answer is often just a question wearing a nicer outfit.
“I’ll focus on remote-first companies.”
How do I know they are really remote-first?
“I’ll curate the companies.”
Who maintains that curation, and how?
“I’ll personalize recommendations.”
What information can I responsibly infer about a person?
The product was growing in my head faster than it was becoming real.
That was the moment I started appreciating product managers much more.
Their work is not simply making roadmaps or organizing tickets. A huge part of it is deciding which questions deserve an answer now, which can wait, and which reveal that the idea is not ready yet.
There is a point where coding is not progress
We are living through an exciting moment for building software. You can go from a rough idea to a prototype remarkably fast. AI can write components, suggest architectures, generate copy, summarize research, and help unblock technical work.
A working prototype can still leave the important questions unanswered.
But speed can hide uncertainty.
If you do not have a clear process, AI does not remove the fog. It lets you move through the fog faster.
I could have built a polished chatbot. I could have picked a stack, designed a landing page, connected an API, and made the product look alive.
But some of the hardest questions were still unresolved:
- What would make the recommendations meaningfully better than existing options?
- How could I build trust without pretending the data was more complete than it was?
- Was the problem narrow enough to solve well?
- Would people need a chatbot, or did they need better information and clearer decisions first?
Those are not implementation questions. They are product questions.
And product questions are stubborn. They do not disappear because the prototype looks good. Without that research, even strong ideas can stall at the MVP stage, unable to articulate why they matter or how they stand apart from what already exists.
Lalo did not ship—and that is still useful
Lalo never made it to production.
For a while, that felt like failure. I had motivation, a real problem, technical skills, and enough tools to get started. Why was that not enough?
Because building a product is not only about being able to build it.
It is about understanding what deserves to be built, for whom, and why it should exist in this particular form.
I still believe the original problem is real. Finding remote work across borders remains unnecessarily difficult, especially for people outside the usual hiring hubs. I still want better tools for that.
But I also learned that a convincing answer to “Can I build this?” is not the same as an answer to “Should this exist yet?”
Maybe that is the first real product lesson: progress is not always a launch.
Sometimes progress is getting close enough to an idea to see its unanswered questions clearly while having the discipline not to hide them behind code.