Product Manager in the Middle - Giving Into the Vibe
How losing 20 minutes a day to dinner decisions finally converted me to Vibe Coding (Revised Edition)
She moved across the world, survived the relocation chaos, and now she is back. Inês Pinheiro-Kumar returns with a new chapter of The Product Manager in the Middle, this time sharing the truth about vibe coding: the fun, the pain, and the sheer number of 404s.
If you’ve ever glued yourself to a chair to fix one tiny life annoyance with AI, you’ll feel seen.
Most of you who know me must be searching the sky for flying pigs. But it’s true. After much resistance and wondering when I would finally give in to AI vibe coding, the moment finally arrived. I learned a lot about this trend, and even more about why so many people struggle with it or fail at it altogether. So jump in and let me take you on my vibe coding ride.
And for those who might be getting deja-vu from this, there was a small misfire of the article before it was ready to go, and this is the revised edition. The consequences of taking too long a hiatus from Substack.
Finding a (Me) Problem
This all started with my relocation to Singapore and figuring out how to strengthen my presence as a Product Manager in a place where I had a very small network. After looking at the trends out there, I decided to build my own product portfolio. I had plenty of case studies, but they were just that. Great at showing my thinking, but not great at showing what I could actually build beyond taking an idea and writing a two pager about what it could become.
Add to that the doomsday idea that AI will kill Product Managers (yes, this is how I am choosing to frame it), and it felt clear that thoughts alone would not cut it. I needed to show what I could create. But whenever I tried to come up with a concept, it failed from the start. It took me quite a while to get to the why.
(Yes, yes, we all know this is a hoax. But it is a fun one.)
The why was so obvious it might as well have slapped me in the face. I saw the same pattern happening to my peers too. Product Managers are, hopefully, innate problem solvers. The kind of people who cannot look at a problem without thinking here, let me fix that for you, even as we get weird looks from strangers whose phones we just snatched because they were trying to scan a boarding pass with the screen brightness at zero.
But the worst case is when that instinct gets paired with the second most common trait in PMs. We are visionaries. People who dream big and dream of disrupting. Which makes us want to take down the world and solve its problems. But there is a reason world problems are world scale. They are complex, multi layered and require far more than an afternoon of chatting with an LLM as it spits out code for you to copy and paste into a project.
Most people were aiming too high with their problem statement to vibe code. And many went at it with aspirations that were too big. The moment vibe coding actually worked for me was when I found a problem so annoying that I was willing to glue myself to the chair until I could find a way to make my own life easier. That is when it clicked.
Finally Ripping the Itchy Band Aid
The breakthrough came when a problem that was unique to my reality became so annoying I had to solve it.
Since moving, there was a broken job to be done between me and my husband. Because I work on site most of the week, I usually pick up dinner on the way back home from the closest hawker center every evening. If you have experienced hawker centers in Singapore, you know the following:
There are usually over 50 stalls and exponential options.
They loosely follow schedules, and the opening days depend on the owner.
They close when they sell out, which makes availability unpredictable.
They are not easily found or identified on Google Maps or other directories.
So every day I found myself doing laps around the market on a call with my husband, reporting what was open, whether they still had what he wanted, and repeating the conversation until we finally secured dinner. It easily added 15 to 20 minutes every evening, which made me more frustrated by the day.
If only there was a way to easily show him what was open, and he could tell me what he wanted.
And that is how I finally got my feasible vibe coding idea. I needed a database with all the options, an interface for me to mark stalls as open or closed, and another for him to select what he wanted and send it back to me.
The Ups and Downs of It All
The idea was clear in my head, and I could write a PRD for this life saving application in my sleep. Yet the first realization of vibe coding is that not only are you the PM and the developer, you are also every other function you normally get to delegate work to.
So my first step was not sitting with my loyal friend ChatGPT. It was spending a morning in 32 degrees Celsius and 90 percent humidity, walking around the market taking photos of the stalls, mapping out their numbers, and starting to write their menus down. This is still only 25 percent done, even now. I knew this was the core of my prototype. A visual cue to identify the stall, the name, and the number. Enough for me to find it physically, and for my user to pick it. The menu could wait for a second iteration.
After that suffering was done, I threw my PRD at ChatGPT and told it that I had both it and Claude Pro available to tackle this project. I asked it to recommend free tools for anything else I might need. Luckily, it offered some familiar names and a list of next steps. That is when I put my developer costume on.
I used its SQL prompts on Supabase, a great tool for data hosting and architecture that does not require more than your usual familiarity with database design. I uploaded my clean data, mapped fields using clear naming conventions, and checked that ChatGPT had created some future proofing tables like events and sessions, which later became a headache.
I used Claude as my project terminal because some of its debugging features and AI coding assists paired well with the code ChatGPT was producing. One of the lessons I learned was to be very clear in my instructions when asking ChatGPT how to give me instructions. Whenever it gave me code snippets, it would not clearly explain where they belonged, and the message below became the most common and painful one to see in my terminal.
Sometimes it was easier to ask for the entire code of a page with the new logic added. It would often take the opportunity to clean and optimize its own code. But more often than not, it would over clean and over optimize to the point it forgot things and broke everything. Rule of thumb: if you are at 300 lines of code and it gives you 90, there is a high probability it killed your project.
Even with all this help, it took many attempts to troubleshoot with both Claude and ChatGPT why I kept getting 404s when trying to run the project locally. And unlike a software engineer, I could not truly understand the code. I could read it and know what the words meant, but I could not understand what they did or where they fit in the overall project. Once I finally figured it out, Vercel became my best friend and an easy and free way to bring the web app to life.
(My final product. My lifesaver for the past weeks.)
Once the app was live, we did a few tests ruins…and voilà. Took me under a minute of walking through the rows to mark the stalls as open or closed, and hit the “All stalls checked button". Once I did that, my husband got a notification to refresh the page. After perusing the available stalls, he chose the one he fancied for the day, and typed out his order. This triggered a notification on my side per each action. This way, I could head to the stall to start queuing whilst he still made the final decision. What usually took 20 min and was a source of friction, now was a 5 minute task.
The best part? I not only solved a problem I experienced, but I also learned a bunch of new things I would most likely never had in other situations.
Persistence, trial and error are the keys to this process. My biggest learning was to keep it as simple as possible to get the first version out so I could test it in real life and see if it solved our problem. ChatGPT will always try to sneak in more features, and that is where you have to switch back into PM mode and focus on delivering your own MVP. It can look rough, and that is fine. Keep the ideas in your back pocket and decide later if you actually need them.
Have I Changed My Mind About Vibe Coding?
Yes and no.
It brought me insights I could not have gotten any other way. I now have much more appreciation and patience toward my developers. Trying to be in their shoes for even a couple of days showed me how tricky certain errors can be, and how one small line can break everything.
It also brought me a feeling I had been craving for a long time. The feeling of making something myself, no longer feeling like I can talk the talk but cannot walk the walk. That is one of the biggest impacts this technology brings. I am sure I will never want to fully build a production level, sellable product with just me and a couple of LLMs. I would still need a human developer to think creatively, optimize without repetition and build reliably. And a development team would still need a PM to keep them on track and focused on the actual problem.
The takeaway from this article is to start small and start personal. Find something annoying enough that you will be willing to go through the grueling process of iterating alone. Something that gives you a euphoric sense of accomplishment that makes you want to come back again.
Will I ever sell my pet project? Probably not. Will some people want to use it? Possibly. But did it solve my problem? Most definitely.
Let us know in the comments if you have joined the Vibe Coding bandwagon, and how your first attempt that made it to production looked like!
And as a treat for making it to the end of my rant, here are the tools used in my tool:
Supabase / Vercel / Claude / ChatGPT