Vibe Coding: A Product Manager's Journey from Zero to One

Vibe Coding: A Product Manager’s Journey from Zero to One

Vibe Coding allows product managers with no technical background to quickly realize their ideas, but the real challenge comes after the initial excitement. The author shares their experiences through five practical projects, revealing the complete emotional journey from creation to obstacles, and offers hard solutions for managing AI collaboration and version control. Ultimately, it emphasizes that lowering development barriers does not equate to lowering success thresholds.

After a long hiatus, I became immersed in Vibe Coding, neglecting my appearance and video recordings. Today, I want to share some thoughts.

Why Write This?

Many people talk about how amazing Vibe Coding is: you can create products without coding. But few discuss: What happens after you create something?

As a product manager with no technical background, I used Vibe Coding to create five small projects over the past two months. I want to discuss the stages I went through, the problems I encountered, and the solutions I found.

Stage One: Addiction Phase

The Joy of Creation

I have been a product manager for nine years, and like other PMs, I entered the field with enthusiasm: transforming ideas into tangible products that people love brings a sense of achievement that is captivating.

Vibe Coding amplifies this feeling by 100 times.

All you need is a chat window to express your ideas:

“I want to create a puzzle game/clown card”
“I want to make a budgeting tool”
“I want to create an AI chat interface”

It helps you find benchmarks, apply templates, and generate code, allowing you to get things running in just a few minutes.

This speed can be addictive; my programmer friends said I resembled them when they first learned to code and created a runnable program.

Why Are There No Obstacles in This Stage?

Clear requirements
Defined benchmarks (“create something similar to XX”)
Front-end code can handle it
AI’s understanding is sufficient
Many mature open-source products are available in the market

In this stage, you feel: I am so capable that I can independently take orders! (just kidding)

Stage Two: Wall-Hitting Phase

When You Want More Complex Features

Open-source projects no longer meet my needs when I require back-end support, custom logic, or multiple features to interact.

Problems begin to emerge.

Problem 1: AI’s Memory Fades

As the conversation progresses, the AI forgets previous agreements and starts to deviate.

The output is completely different from what you wanted.

Without coding knowledge, you can only copy and paste when facing front-end errors: it’s a black box, and you don’t know how to locate or fix the issues.

Problem 2: Changes Can’t Be Reverted

If you ask it to change something, it might submit changes without your consent.

When you want to revert, you realize you can’t go back.

When multiple agents collaborate, submissions become chaotic, and the code turns into a tangled mess.

Problem 3: Easy to Set Up, Hard to Modify

To quickly run an MVP, I used many “as long as it works” solutions.

When you want to add new features, you find that it’s impossible to integrate them.

Many people will get stuck, give up, or struggle through this stage.

Stage Three: Solutions

1. Use PMO Logic as a Safety Net

For those of us who have taken PMP or similar exams, we realize that these issues are not new; traditional industries and IT have long solved them.

So, can the solutions be similar? Use standard PRDs to lock in direction.

Before each iteration, align with the product document (PRD).

If the goals change, update the document; don’t let the AI deviate from the direction.

2. Predefine Technical Choices

It’s fine to run an MVP with simple technology.

But think ahead: what scale will require a mature tech stack?

This avoids situations where features cannot be added later.

3. Branching and Version Management

Branches:

I recommend three branches:

Development branch (for casual changes)
Testing branch (to validate features)
Master (stable online version)

Additionally, create a version package for each release to archive it, allowing for easy rollback.

Versions:

My version management is simple: v1.2.3

1 is the major version - for significant features; 2 is for intermediate changes, like modifying modules; 3 is for minor versions, such as bug fixes.

4. Divide Work Among Multiple Models

Design, operations, development, and project management should utilize their strengths.

However, the finer the division, the more documentation is needed to keep everyone “locked” on the same goal.

Stage Four: A Great Product, But No Users

You Created It, But No One Uses It

Even if you follow the norms perfectly, after launching, you’ll find:

No one uses it.

You thought a good product would sell itself, but the market won’t automatically find you. Competitors with better products already exist, and your efforts go to waste.

At this moment, I finally understand why many unmaintained projects on GitHub end up that way…

It’s not a technical issue; it’s because no one ever used it.

This Is the Most Expensive Cost

You’re wasting not just time or money, but attention. Time can be quantified, money can be quantified, but attention cannot.

Yet, it is your most important resource.

The Correct Sequence Should Be

Conduct market research and competitive analysis first → validate whether it’s worth pursuing → then take action.

Lower R&D costs do not mean lower attention costs.

Sound familiar? We’ve returned to the core of product management.

An Unanswered Question

At this point, I began to question:

Is it reasonable for someone with no technical background to do Vibe Coding?

Currently, it seems reasonable to run an MVP.

But if the goal is to create a truly mature product, later stages of:

Error localization
Performance optimization
Architectural adjustments

Are difficult without technical knowledge.

So, is technology the only solution?

It’s best not to rely solely on it, as creating something is just the first step.

Perhaps a More Realistic Position Is

Use Vibe Coding to quickly validate ideas; getting it running is enough, without pursuing a mature product.

This way, the previous set of norms can be much lighter, and product managers should focus more on whether the idea is worth pursuing and how to build a moat around it.

Is There Anything New Under the Sun?

Looking back at this entire process, it becomes clear: Vibe Coding is retracing the path of the traditional IT industry.

From chaotic growth to standardized processes, from individual exploration to collaborative division of labor, even the pitfalls encountered are the same.

The only difference is:

Traditional IT took twenty years to traverse this path, while Vibe Coding has done it in just one or two years. The barriers have lowered, and the people stumbling through are no longer just engineers but everyone.

Yet, no one tells them that these issues have already been solved by predecessors.

Tips for Those Interested in Diving In

Validate the demand before starting.
An MVP is sufficient; don’t pursue perfection.
Learn some technical basics.
Use PM thinking to manage projects.
Or find a technical partner.
- If you genuinely want to create a product, the fastest way is to partner with someone who understands technology.
- I want to thank all my colleagues who kindly responded to my chaotic error reports, wishing you all great success.

Final Thoughts

Vibe Coding has lowered the barriers to creating products, which is a good thing. However, it has not lowered the barriers to creating successful products.

Turning ideas into code is quick, but turning code into a product is challenging, and making that product used by people is even harder.

On this journey, technology is just the first step.