
![](./vibe-coding-getting-started_cover.png)

# Can You Build a Product Without Knowing How to Code?  

Have you ever thought, "I wish there were a little tool to help me with this"?  
But then quickly followed with—"But I can’t code, forget it."

In the past, this idea would’ve stayed in your head.  
Now, thanks to AI, you can say one sentence and let AI build it for you. That’s what Vibe Coding is all about.

Imagine saying to AI:  
“I want a webpage to showcase my dog’s growth,”  
and it instantly creates the layout, features, and even adds a cute photo timeline!

---

As someone who used to be a developer, then became a product manager, and recently built four new projects using Vibe Coding (plus maintained an old system), I want to share:

- How Vibe Coding helps both beginners and more advanced users  
- In which situations it's powerful—and where it hits limits  
- How to start and what knowledge (if any) you need  

---

## 1. What Is Vibe Coding, and Why Should You Care?

Vibe Coding means **using natural language to ask AI to write runnable code**—you can get things done by chatting, instead of coding from scratch.

Depending on your background, it means different things:

- **For non-coders and beginners**: It’s an accessible entry into the tech world and a way to gain real hands-on experience and confidence.
- **For experienced developers**: It speeds up prototyping, removes syntax overhead, and helps you explore new tools and languages fast.

This article focuses on beginners—what use cases suit Vibe Coding, how to start, and how far you can go with or without coding.

---

## 2. How Should Beginners Start?

Many people get excited by the idea of Vibe Coding,  
but then get stuck:

> “I just wanted to try building something—but suddenly I need servers, databases, login systems… Isn’t this too much?”

Here’s what I recommend:  
**Start with a simple static webpage**, because:

- **You don’t need to install anything**: Just paste the code AI gives you into a blank plain text file (use Notepad on Windows, or TextEdit in plain text mode on Mac), then rename the file extension to `.html`. Open it in your browser and you’ll see the result—no need to install development tools or set up a server.
- **No complex setups like login, database, or cloud**: These are unnecessary at first and can kill your motivation.
- **Instant feedback**: Save, refresh, and immediately see changes. That fast loop builds momentum.

This works great for fun mini-tools or personal helpers.  
For example, this blog (louisan.dev) is something I quickly built with Vibe Coding.

<div style="text-align: center;">
  <img src="./vibe-coding-getting-started_example.png" alt="Vibe Coding 範例" width="60%" />
  <small>▲ Blog page created with Vibe Coding.</small>
</div>

<br/>

But—this method does have limits:

- You can’t share data between users (everything’s local to your browser)
- No user login, cloud storage, or cross-device sync
- As your needs grow (e.g., access control), it becomes insufficient

So this is best for **personal use or quick prototypes**—not for production apps.

---

## 3. Do You Need Any Basic Knowledge?

That depends. Let's split it up:

### ✅ If You Have No Coding Background

You can start without knowing any code. Just chat with GPT.  
But you need to accept:

- The design might not match your expectations
- One small change might break existing features
- You won’t always understand why something doesn't work

That’s totally fine. Try generating code and run it in Chrome.

Later on, when you want more control or stability, that’s your cue to learn more.

### 📘 If You’re a Beginner and Want More Control

Then it’s worth learning a few fundamentals:

- **HTML / CSS** – To adjust layout and styles
- **Basic JavaScript** – For interaction, events, local storage
- **APIs** – To fetch external data (like weather, translations, AI)

Why learn these?

- To understand what AI-generated code is doing  
- To debug when something breaks  
- To tweak things faster than constantly re-asking AI

You’ll work better with AI as you learn more. But don’t let “not knowing enough” stop you—just start, and you’ll learn what you need.

---

## 4. What Are the Limits of Vibe Coding for Beginners?

At first, you’ll be amazed how quickly AI builds things.

Then it hits:

> “Why did editing one thing break something else?”  
> “I asked for login, now it’s all jargon I don’t get…”

These are common beginner pitfalls:

- AI doesn’t maintain clean architecture
- Changing A might accidentally break B
- Without deeper concepts (like servers), you can’t scale

It’s like photography:

- You can take great photos with filters on your phone
- But if you want to control lighting or depth, you’ll need to learn manual settings

Same with Vibe Coding:

- For quick tools or MVPs: it’s amazing
- For long-term, complex apps: you’ll hit technical walls

> The “limit” isn’t AI—it’s whether you want to go deeper.  
> If not, no problem. If yes, there’s a whole world to explore.

---

This post lays the foundation.  
In the next one, I’ll share tools and prompts to help you go further.

Got an idea? Open ChatGPT and build your first project—you might be surprised what you can do today.



Build a Product Without Coding? A Beginner-Friendly Guide to What Vibe Coding Can and Can’t Do


**In the AI era, there's more than one way to build: a faster way to align and validate ideas**

> **Why is this worth reading?**  
> If you've ever been stuck in endless spec reviews, unclear requirements, or communication loops, this article may offer a fresh alternative. I share how I built a fully working DocuSign integration in a week using AI, and introduce a prototype-first approach I call Demo-Driven Development. For early-stage teams or resource-constrained builders, this may be a more effective way to move forward than traditional spec-heavy workflows. Whether you're a PM, engineer, or someone launching something new, you'll find ideas you can act on.

---

![](./demo_driven_development_cover.png)

## The limits of traditional processes

In traditional product teams, PMs define the requirements, designers produce wireframes, and engineers implement them. This separation of duties makes sense in large organizations—it ensures stability and accountability. But it also creates significant communication overhead.

Worse, there's often a gap between what users "understand" and what they "actually use."

- For B2B products, we show mockups and ask, "Would you use this like that?"
- For B2C, we rely on surveys or click-throughs to simulate intent—but real behavior is hard to imagine without something to try.

Even with agile methods like Scrum, where we release something every two weeks, the cost of iteration is still high.

## A new option: Build a prototype in one week with AI

What if we had another option?

Use a 1–2 person micro team—say, a PM and a technical partner, or a PM who can build—to skip full specs and directly deliver a working prototype.

This is not about skipping alignment. It's about using a prototype as the source of alignment—verifying needs through actual interactions, not documents.

With the help of AI tools—prompt-based coding, GitHub Copilot, or AI agents—you can quickly build a product that is functional, adaptable, and understandable.

## Case study: DocuSign automation integration

Recently, I worked on a case where our sales team was managing contracts and forms via email.

As our customer base grew, this became unscalable. There were steps that required manual confirmation (like checking inventory) before the client could even sign. We needed automation.

Using traditional methods, this would’ve taken months:

- I wasn’t familiar with DocuSign’s APIs, templates, and webhook systems.
- We didn’t have a confirmed spec—sales didn’t know exactly what they needed.
- Writing a full spec before building felt risky and pointless.

So instead of stalling, I built a demo.

I did quick alignment via a few simple PPT flowcharts, then used AI-assisted coding to create a working version in a week:

- Used composite templates to allow “fill first, sign later” flows
- Triggered different documents for individuals vs companies
- Embedded the flow into our frontend
- Automatically routed CCs, updated webhook status, and eliminated manual handoffs

Now sales can demo this directly to clients. Clients interact with the real forms. Feedback is grounded in reality, not assumptions. This revived a project that had been stalled for half a year.

I call this method **Demo-Driven Development**.

## It's not a silver bullet—but it gives you direction

Is this approach perfect? No.

AI-generated code can be buggy, inconsistent, or break existing features. Eventually, you’ll need professional engineers to harden the system. But in early stages—when you don’t even know if the market wants what you're building—this method reduces risk.

Worst case? You waste a week. No spec writing, no stakeholder meetings, no months of negotiation.

## A Flavor of Lean MVP—with a Twist

This is, fundamentally, a lean MVP approach: **build the minimum version to test your assumption**.

The difference is emphasis: Demo-Driven Development starts with **a working demo to align understanding**, rather than with planning sessions or spec documents.

It's not about building fast for its own sake—it's about making feedback loops more real, more specific, and more grounded in actual user interaction.

## A lightweight, action-first mindset

This isn't about glorifying overwork or turning PMs into engineers.

It's about using new tools to reduce the cost of trying. To validate ideas before overcommitting.

So if you’re a builder—or supporting an early product with few resources—I recommend asking:

> “Can I build something testable before asking for alignment?”

Because products aren't born from consensus. They're born from momentum.


Skip the Specs, Show the Demo: A New Approach to Product Development in the AI Era


![](./pm-vertical-cut-vs-horizontal_cover.png)

> **Why is this worth reading?**  
> This article takes a practical approach to discuss why product managers should be responsible for vertical cuts (complete feature ownership) rather than just horizontal cuts (functional division) in over 90% of development scenarios. You'll see specific practical challenges, organizational structure comparisons, and actionable strategies and recommendations.

---

## Why is "Vertical Cut" a More Practical Product Thinking?

Vertical cut means: PMs are responsible for a complete user story or feature, covering everything from user interviews, feature design, technical selection, development coordination, go-to-market, to cost management and pricing.

- It's not "I only handle UX" or "I don't handle releases," but taking responsibility for the outcome.
- It's not just about delivering, but also about selling the product.
- Only by mastering the entire process can you truly understand if the product solves problems and can be marketed effectively.

> **Example**: In a multinational SaaS project, I was responsible for a module where I planned everything from API design, frontend operation logic, user education materials, to pricing strategy. Although the pressure was high, each decision was built within a logical system, preventing inconsistencies or risk miscalculations.

---

## Vertical vs. Horizontal Cuts: The Tug-of-War Between Efficiency and Responsibility

| Aspect | Vertical PM | Horizontal PM |
|--------|------------|---------------|
| Focus | Complete user journey | Single function (e.g., API) |
| Responsibility | High (outcome-driven) | Fragmented, passive support |
| Communication Efficiency | High (unified cross-platform logic) | High synchronization costs |
| Organizational Fit | Small teams, innovative products, new markets | Large companies, stable development, process-oriented |
| Drawbacks | High skill requirements, cross-domain needs | Lack of ownership |

### Why is Vertical Cut More Efficient?

Horizontal PMs (e.g., those only responsible for backend or writing specs) must synchronize with various other stakeholders for overall requirements. Every change requires additional time for meetings, clarification, and modifications. When requirements are vague or development scenarios change rapidly, this communication overhead grows exponentially, making it easier to "drop the ball."

In contrast, vertical PMs can lead the entire process, reducing back-and-forth confirmations. They can more easily integrate experience, learn quickly, and optimize the next development cycle. Iteration cycles become shorter and more compact, naturally improving product evolution speed.

---

## What About "PM Skills Not Being Broad Enough"?

This is the most common objection to vertical cut design: "One person can't master so many functions!"

I believe this is true, but can be solved through the following mechanisms:

### Virtual Support Team

- Create knowledge-oriented roles responsible for writing specs, marketing strategies, pricing frameworks, and other best practices (e.g., feature documentation templates, different business tone email templates, requirement convergence and breakdown processes)
- PMs share templates, cases, and guidelines with each other, or senior PMs coach junior ones
- Leverage AI tools (like ChatGPT, ToneFlow) to assist in initial drafts, lowering skill barriers

> AI has lowered the entry barrier. Today's PMs don't need to know everything, but they need to know "who to ask, how to research, and what to achieve."

---

## Supporting Measures for Vertical PMs

To make the vertical work model truly effective, the following systems and process designs are needed:

- **Clear PM Responsibility Matrix**: Let other teams clearly know which PM corresponds to each module, who to contact for what content, avoiding information confusion or responsibility ambiguity.
- **Regular PM Alignment Meetings**: Periodically hold alignment meetings between PMs to align module progress and strategies, and identify conflicts or risks early.
- **Integrated and Documented Best Practices**: Through Notion or knowledge base format, compile knowledge and experience in writing specifications, requirement breakdown, time estimation, technical collaboration processes, etc., forming stable output standards for the PM team.
- **Transparent Delivery Process Data Platform**: Let other teams like development, design, and marketing instantly check each feature's owner, timeline, and design direction.

These supporting systems allow PMs to work independently while collaborating within a systematic framework, helping with knowledge transfer and responsibility clarification during team expansion.

---

## Practical Module Division Recommendations

Some question: "Features are hard to completely separate." I believe this is actually a **MECE Principle (Mutually Exclusive, Collectively Exhaustive)** problem. This management concept from the McKinsey framework means that divided items should be "mutually exclusive but collectively exhaustive." Each PM's responsibility area should not overlap but should completely cover all product requirements.

### Good Vertical Module Examples:

- **Recommendation System**: From data collection → algorithm → frontend presentation, all handled by one PM
- **Account Module**: From login logic, permission management, to third-party integration, all managed by one person

### Modules Not Suitable for Independent Division:

- Such as iOS / Android / Web FE / BE: These are function-oriented and not suitable for single PM management

Therefore, I recommend that vertical cuts should be **feature**-centric, not technology or platform-centric.

---

## Who's Responsible for the Overall Product?

Some worry: "If everyone is only responsible for their own features, who manages the overall product strategy?"

I agree there should be a product lead (Lead PM or Head of Product):

- Sets product direction and principles, responsible for overall organization operation
- Resolves cross-module conflicts
- Acts as coach and final gatekeeper when module PMs are less experienced

This design allows each PM to be independent while preventing overall strategy fragmentation.

---

## Conclusion: From Division Logic Back to Product Essence

The PM's role is never just bridging requirements and development, but having substantial influence on product success.  
When we let everyone specialize in just one area, we easily cultivate a "that's not my responsibility" culture.  
But product success is the result of a complete chain of events.

Vertical thinking isn't about making PMs do more, but making them think more comprehensively.  
Let each feature, each user experience, each business decision have a true owner.  
Only in such a framework can PMs truly evolve from executors to outcome drivers.

---

## Extended Thinking: If You Want to Adopt Vertical Structure, What's Next?

- **What PM Division Model Suits Your Team?**  
  Evaluate current PM numbers, background differences, and collaboration models. Do you have the foundation for vertical operation? Which areas need adjustment or reinforcement?

- **Does Module Division Follow MECE Principles?**  
  Review current module division. Does it follow mutually exclusive but collectively exhaustive logic? Which feature modules should actually be managed by one PM?

- **How to Help PMs Quickly Develop Cross-domain Capabilities?**  
  Do you have virtual support mechanisms, such as internal best practices, AI tools, internal consulting systems, to help teams reduce cross-functional burden?

These questions don't have single answers, but they're worth deep discussion and design with your team before implementing vertical division. 

Vertical vs. Horizontal PM Cuts: A Practical Discussion on Responsibility and Efficiency Design


**Field Notes on Trilingual Collaboration, Role Alignment, and Information Flow Design**

> **Why is this article worth reading?**  
> The real challenges in cross-language product development aren’t about language itself, but about how information flows, who owns what responsibilities, and how decisions are confirmed. This article shares six common issues I've faced in actual trilingual (EN/JA/ZH) project work, along with visual models and practical solutions. Whether you're a PM, developer, coordinator, or exploring product internationalization, there's something useful for you here.

---

![](./cross_language_collaboration_cover.png)

## Why Language Is Just the Tip of the Iceberg

Language issues may seem like something solvable by simply “understanding each other,” but more often, what happens is:

- The client throws in a bunch of technical questions, and it takes 3 days of back-and-forth just to respond.
- The Japanese spec and the original English version diverge, and engineers deliver something different from what the client expects.
- Upstream and downstream engineers in the same module have no idea how the other side implemented their part.

These problems can’t be solved by translation alone.

---

## Six Real Challenges and Practical Solutions

### 1. Japanese Clients Reject English Documents Outright

I once submitted a complete English technical spec, only to have the Japanese contact say, “It’s not that I don’t understand English, but our client won’t even look at it. We need Japanese to avoid misunderstandings.” 

**Solution:** During the discussion phase, use English as the main spec file, accompanied by a user journey map and a simplified Japanese version with key points and diagrams. Once direction is confirmed and the content is stable, provide a full Japanese translation.

---

### 2. Mismatched Spec Versions Across Languages

Sometimes the Japanese version is updated but the English isn’t—or vice versa. Dev teams follow different versions and end up building inconsistent features. 

**Solution:** Designate English as the single source of truth. Strictly avoid maintaining separate translated documents. Use bilingual in-line format (EN + JA paragraph-by-paragraph) to help the client understand English context via Japanese support. This also helps internal teams ensure updates stay synchronized.

---

### 3. Japanese PMs Have to Answer Technical Questions They Don’t Understand

Non-technical sales or PMs are forced to answer questions about CDN architecture or streaming setups.  

**Solution:** Create a shared Q&A doc with common technical questions, diagrams, and Japanese phrasing templates. Additionally, assign development PMs full R&R for each feature so field staff only need to ask one person for a complete answer—no more fragmented, half-correct explanations.

---

### 4. Slow, Repetitive Bilingual Q&A Process

One question has to go: JA → EN → tech reply → JA again. This often takes 2–3 days per question.  

**Solution:** Use a Q&A template: original question, translated version, technical reply, and suggested tone/language for reply. Store everything in a shared spreadsheet with timestamps, language versions, and final answers. Combine with tools like ChatGPT or ToneFlow to auto-translate and rephrase answers efficiently.

---

### 5. Scattered Knowledge, No One Sees the Full Picture

With many contributors and fragmented documents, different people remember different things—and no one knows everything.  

**Solution:** Set up a knowledge hub (e.g. Notion) with tags, templates, and update protocols. Most importantly: define who updates what, where, and when. Enforce it strictly—otherwise, knowledge lives only in individuals’ heads and disappears when they leave.

---

### 6. Overcrowded Multilingual Meetings

Meetings often include 10+ people—translators, sales, engineers, PMs, advisors—and still end without consensus.  

**Solution:** Clarify meeting purpose and participant roles ahead of time. Take live notes during the meeting. Send a trilingual (EN/JA/ZH) summary afterward. For discussion design, slice roles vertically (by function) rather than horizontally (by department), so only the right participants are included. This ties into larger org design issues, which I’ll cover in a future article.

---

## Visual Model: Total Communication Cost

![](./cross_language_collaboration_diagram.png)  
<small>▲ Left: full mesh communication — total connections = n(n-1)/2. As team size grows, communication cost grows exponentially. Right: hub-and-spoke model — total lines = n-1. Centralized roles or tools help reduce duplication and clarify responsibility.</small>

<br/>

Think of each person as a “node” and every interaction as a “line”:
- Without coordination, everyone talks to everyone: `n(n-1)/2` lines.
- With a centralized node (a person/tool/wiki), only `n-1` lines are needed.

That’s why workflow and knowledge design are critical—not just brute-force communication.

But each central node has its own tradeoffs, as described below.

---

## Centralization Isn’t a Silver Bullet (People, Tools, Wikis Compared)

| Type                      | Pros                        | Cons                                  |
|---------------------------|-----------------------------|----------------------------------------|
| **People** (bilingual + tech) | Flexible, fast response         | Bottlenecks easily, overworked         |
| **Tools** (Database, RAG) | Fast, efficient draft generation | Prompt design needed, human review required |
| **Wikis** (e.g. Notion)       | Collaborative, version-controlled | High maintenance, easily outdated       |

There’s no perfect solution—but what matters is deciding **who maintains what**, **how it’s used**, and **when it’s updated**.

---

## FAQ: Common Issues in Cross-Language Teams

**Q1: How do I manage multilingual specs without inconsistencies?**  
Define one language (usually English) as the source of truth. Others are supplementary. Use version control tools like Git or Notion to manage translations and updates.

**Q2: What if Japanese clients can’t read English technical docs?**  
Create a simplified Japanese summary with diagrams and key points for reference. Helps them understand quickly and share internally.

**Q3: Bilingual Q&A is too slow—what can I do?**  
Use a Q&A sheet template and tools like ChatGPT or ToneFlow to generate drafts in both languages and adjust tone for formality.

**Q4: Is Notion good for multilingual knowledge sharing?**  
Yes. Use language tags (EN/JA/ZH), dedicated sections, and duplication-friendly templates to manage multiple language versions.

**Q5: Can AI help with tone/formality adjustments?**  
Absolutely. You should focus on the content—not stress over cultural nuances. That’s why I built ToneFlow: to make tone-switching and translation seamless. Whether it’s adjusting Japanese keigo or rewriting Chinese into business English, the goal is to save time and reduce ambiguity.

---

## Conclusion: It’s About Flow and Responsibility, Not Just Language

Once you’ve worked on a few multilingual projects, you’ll realize the hardest part isn’t the language—it’s how information flows, who owns decisions, and how responsibilities are distributed.

What seem like “small process details” are actually the key to making cross-language product development succeed.

---

## Coming Soon

- Designing a Sustainable Multilingual Q&A System  
- Organization Design Across Cultures and Companies  
- Efficient Structures for Multilingual Meetings and Consensus


Blog

Build a Product Without Coding? A Beginner-Friendly Guide to What Vibe Coding Can and Can’t Do

Skip the Specs, Show the Demo: A New Approach to Product Development in the AI Era

Vertical vs. Horizontal PM Cuts: A Practical Discussion on Responsibility and Efficiency Design

Real Challenges and Practical Solutions in Cross-Language Product Development