![](./spec_version_control_cover.png)

## Opening: A Familiar Pain 

If you've worked in a software company, you've probably seen a file named something like: 
`spec_v2.1_20250905_hotfix.docx` 

But what does it actually mean? 
1. The live version? 
2. The in-development version? 
3. A draft under discussion? 

The answer could be any of them — or worse, different people might interpret it differently. 

## Why Version Semantics Matter 

Each spec state is necessary for different reasons: 

- **Live version**: For CS, QA, and even customers to know what the system currently does. 
- **In-development version**: For engineers to align on the features being built. 
- **Draft version**: For teams to explore future directions and contribute to planning. 

It gets even more complicated when a hotfix affects the spec. Without clear version control rules, documentation quickly becomes disorganized and unreliable. 
 
Many teams simply **choose not to do version control** — leading to chaos: 
PMs all have different habits: some mark changes with colors, some duplicate entire documents with new filenames, others just overwrite the same file. Some team members only maintain one file, mixing live, development, and proposal content all in one place. People end up referencing whichever version they're used to, ignoring the rest. 
 
In the end, **everyone is effectively working off different drafts**, and discrepancies are patched through ad-hoc conversations. This risk compounds until late in the project, when it explodes. 

### 🎯 Real Case 

I once managed a large project involving a Japanese client and a Taiwan-based dev team. 
 
Because there was no strict documentation control, versions were scattered. Combined with translation delays and time zone differences, we encountered serious issues: 

- The client was never sure which spec version was the source of truth and kept asking, "Is this feature included or not?" 
- QA frequently filed tickets saying "Does not match spec," but often those features were not even in scope for the current release. 
- The worst case was when development accidentally deployed a feature the client was still reviewing, causing production confusion. 

This incident forced the client to spend 3 days re-testing, while the development team worked 2 weeks of overtime to roll back and fix the issue, delaying the project and damaging trust. 
 
Root cause? **No single source of truth, no status labeling, and no version synchronization.** 

## Why Most Teams Don't Feel the Pain 

This is a serious issue, but often ignored. Here’s why: 

1. **Documentation errors don’t break immediately** 
Code fails to compile right away when broken. Documentation errors often surface only in testing or production, multiplying fix costs. 

2. **Meetings and Slack fill the gap — masking the problem** 
Teams rely on ad-hoc verbal sync, hiding the underlying problem but adding invisible communication cost. 

3. **Responsibility is diffused** 
Docs involve PM, design, engineering, QA — meaning everyone is responsible but no one truly owns quality. 

## Borrowing from the World of Code 

Fundamentally: 

- **Code = specs for machines** 
- **Docs = specs for humans** 

Code has Git for version control. Why shouldn’t documentation have something equivalent? Before Git, engineers also lived with `final_v3_latest.doc`. We know how that ended — chaos at scale. 

## Practical Solutions: Bringing Version Control to Documentation 

### 1. Define a “Single Source of Truth” 

- There must always be **one main document** that represents the live version. 
- This document only contains the most authoritative state; drafts and proposals must live elsewhere. 
- CS, QA, devs all know that "this is the place" to check specs. 

### 2. Decide “Marking vs. Separate Files” 

- **Inline Marking** (small, short-term change): use highlights or comments with labels like *In Progress* or *Draft*. 
- **Separate Files** (large, long-term changes): spin up a new document (e.g. `Spec_vNext`) clearly marked as Draft, then merge it back into main after approval. 

### 3. Tool-Specific Guidelines 

- **Google Docs / Word**: Use `Spec_main` for the main file, add `Draft` or `Proposal` suffix for others; use version history but manually tag release milestones. 
- **Figma**: Keep live state in the main pages; open new pages for drafts, name them clearly (e.g., `Draft - Payment Flow v2`), delete them after merging. 
- **Notion / Confluence**: Use hierarchy (`Spec/Main`, `Spec/Proposals/*`), and clearly mark status with Live/In Progress/Draft properties. 

## Adoption Strategy: Making Rules Stick 

Good rules are easy to write — hard to get adopted. Here's how to drive adoption: 

1. **Collect Pain Points First** 
Interview PMs, engineers, QA, designers, gather real cases of confusion. Show these pain points to the team to create urgency. 

2. **Co-Design the Solution** 
Don't impose rules top-down. Use these pain points as discussion starters, get the team to co-create a version control process that fits them. 

3. **Start Small** 
Pilot the process with one team or product line. Measure impact (fewer version mismatches, fewer QA tickets), then roll out org-wide. 

4. **Assign Roles & Responsibilities** 
Appoint document owners. Add a simple pre-release check: “Is the spec up to date?” 

5. **Iterate Continuously** 
Review and refine the process as the team grows or workflows evolve. 

6. **Show Results Publicly** 
Quantify wins (e.g., 30% fewer QA mismatches, fewer meetings) and broadcast them to build momentum. 

## Closing: A Call to Action 

Messy documentation is not a trivial issue — it’s one of the most expensive forms of hidden technical debt. 

- Every misunderstanding can trigger another meeting 
- Every version mismatch can misalign development, QA, and even the client 
- Every fix costs much more than preventing the issue in the first place 

Code has Git because mistakes explode immediately. Docs don't break immediately — but the cost only grows the longer we ignore them. 

### 💡 Immediate Action Plan 
Here are three things you can do **today**: 
1. **Choose a single source of truth**: everyone knows where to look for the latest spec. 
2. **Define marking rules**: decide which changes stay inline and which get split into separate files. 
3. **Label version status**: at minimum, add Live / In Progress / Draft labels. 

👉 **“If code has Git, why can’t specs?”** 
👉 **“Documentation management is not clerical work — it’s critical project infrastructure.”**

Behind final_v3_last_fixed.docx: The Hidden Technical Debt of Documentation in Large Projects

![](./ai_freelance_cover.png)

# The Restructuring of Work in the AI Era: From Disappearance to Reconstruction

As a PM and developer in the software industry, I observe every day how AI tools reshape workflows. The shift is not just about large-scale layoffs reported in the news — there is also a quieter, ongoing restructuring. The very shape of work is changing.

## Invisible Shrinkage

Imagine sitting at your familiar desk, but colleagues around you vanish one by one. Departures are not replaced. With processes simplified, tasks once requiring ten people can now be completed by three, and the remaining roles quietly dissolve.
 
 
In practice, I have seen AI cut knowledge work time in half or more, but demand on the client side has not expanded accordingly. Instead, the surplus workforce is naturally eliminated.
 
 
The recent waves of layoffs in North American tech highlight this trend. Big software firms (Meta, Google, Amazon) made repeated cuts from 2023–2025. Beyond efficiency gains from AI, overexpansion during the pandemic, economic downturn, and shareholder pressure all played a part. Other industries follow the same pattern: Intel’s recent mass layoffs also reflect broader organizational pressures.

## The Disappearance of Middle Roles

This tension between efficiency gains and stagnant demand directly compresses the middle layers of work:

- Building a website shrinks from a week to half a day — but customer demand does not grow 14-fold. 
- Market analysis shrinks from three people over a month to one person in a week — but companies don’t request ten times more reports. 
- AI-driven education content allows one person to produce curriculum, quizzes, and interactivity — but schools don’t need three times more courses.

As a result, workflows that used to require multiple roles—such as draft writers, editors, designers, and testers—can now often be completed by just one or two people working with AI tools. The middle roles are quietly losing their place. From my own experience in the software industry, many projects used to require at least a designer, an engineer, and a PM to collaborate in order to deliver results. But today, if the goal is just to build a POC, often a single person with the help of AI is enough to cover most of the essential needs.

## Freelance Crowding and Skill Pressure

Many shift to freelancing, side hustles, or content creation. But according to the **MBO Partners 2024 Report**, nearly 72.7 million Americans now work independently — making the market more crowded than ever. Income stability and security are falling.
 
 
Freelance is no longer about “having skills.” Independent workers must also handle marketing, client acquisition, project management, contract negotiation, and financial planning. For most developers, analysts, or designers, mastering all these domains is difficult. Platform fees and biased algorithms only worsen the imbalance. The market is not expanding fast enough to sustain the old freelance model, creating long-term challenges.

## One Direction: Modular Collaboration

Against this backdrop, I believe that freelancing in the future may evolve into a more structured form of **modular collaboration**.
 
 
The key shift here is moving from billing based on hours worked to billing based on value and outcomes. Traditionally, project compensation has been tied to estimated working hours—less time meant less income. In modular collaboration, however, professionals no longer sell “time”; they sell clearly defined, high-value **modules of deliverables**.
 
 
For example, the true value of a website project does not lie in the number of hours spent, but in the benefits it brings to the client. A skilled expert, leveraging AI tools, might finish what used to take a week—say, a **UI/UX optimization module**—in just half a day. Their compensation should not be discounted just because they were more efficient; in fact, their ability to deliver faster amplifies the value for the client.
 
 
This is similar to how top surgeons charge for operations: not based on how many hours they spent in the operating room, but on the successful completion of a complex surgery. They focus on the high-skill, high-value “surgery module,” while delegating pre-op assessments or post-op care to other specialists. This maximizes their unique value and allows them to handle more cases in less time.

### Example Scenario – Software Project

A project that once required five people working for a month could, under modular collaboration, be broken down into:

1. **Requirements Analysis Module**: AI summarizes user interviews into needs and pain points. 
2. **System Architecture Module**: AI generates architecture diagrams and deployment scripts. 
3. **Core Development Module**: AI scaffolds the codebase and optimizes algorithms, with humans reviewing critical logic. 
4. **UI/UX Module**: AI produces design drafts and runs A/B tests. 
5. **Testing & QA Module**: AI generates and executes test cases, compiling defect reports. 
6. **Coordinator Role**: Oversees cross-module collaboration, tracks progress via Jira/Notion, runs weekly check-ins, and ensures consistent delivery.

Through this decomposition and efficiency boost, specialists can deliver higher-priced modules and complete more projects within the same time frame. Ultimately, this aligns compensation directly with expertise and value delivered, rather than with the number of hours spent.

## Unresolved Challenges

But modular collaboration is no cure-all. It raises key issues:

1. **Market Size**: If demand doesn’t grow, are we just slicing the same pie thinner? 
2. **Fair Value Distribution**: How do we price modules fairly across difficulty and contribution? 
3. **Coordination Costs**: Who handles cross-module communication and management? The coordinator role is essential. 
4. **Quality Consistency**: Finer division increases risks of mismatched style and quality. Standards and review processes are crucial. 
5. **Trust and Reputation**: Transparent evaluation and fulfillment records are key to scaling collaboration.

## Continuing Exploration

AI blurs the boundaries of traditional roles. Some will continue freelancing, some will move toward modular squads, others may invent new models entirely. Staying open and experimental may help us find fairer and more efficient ways to create value.

---

## Further Reading

- [MBO Partners State of Independence Report 2024](https://www.mbopartners.com/state-of-independence/) 
- [Tech Layoffs Tracker by layoffs.fyi](https://layoffs.fyi/)

The Restructuring of Work in the AI Era: From Disappearance to Reconstruction

![](./rethinking-meeting-notes-cover.png)

---

### The Default Logic Around Meeting Notes

In many workplaces, there's a familiar pattern:

 

**"When a meeting happens, it's always the PM who ends up taking the notes."**

 

It doesn't matter whether this is explicitly assigned, or whether the meeting is directly related to the PM’s responsibilities—if no one is designated, the task silently falls on someone. And more often than not, that someone is the PM, the most junior person, or simply the one who seems the easiest to ask.

 

In different cultures, this role might be assigned differently. For example, in some Japanese or Korean companies, administrative staff take notes as part of their institutional role.

 

Most people think, “It’s not a big deal.”

---

### The Deeper Workplace Logic Behind It

But this behavior reveals a deeper logic:

- Taking notes isn’t seen as core work → No need to assign significant resources
- The person with the lowest hourly rate, lightest title, or least likely to complain is expected to do it
- Someone has to do it—even if it's not voluntary

It sounds practical. But this approach leads to a common workplace outcome: not just note-taking, but also who books the meeting room, who orders lunch, who prints the documents... all these “someone has to do it” tasks tend to fall on the same person—because that’s how implicit task distribution works.

 

Whether or not this leads to a mismatch in capability and responsibility, one has to ask:

 

**Can this kind of work culture truly foster the sense of ownership we all say we want?**

---

### Why Do We Take Meeting Notes in the First Place?

Let’s look at this from another angle: 
**Why do we need meeting notes at all?**

 

Common answers include:

- So that absent team members can catch up
- To follow up on action items later
- To revisit the discussion’s context weeks or months later

If those are valid reasons, then the **accuracy and clarity** of the notes become critical—otherwise, they risk misleading others.

 

In that case, note-taking isn’t just typing—it’s **translation, interpretation, and alignment**.

 

Would we still assign such responsibility to the person with the least understanding of the discussion? Or, if the notes don’t fulfill these essential purposes, should we even bother writing them at all?

---

### Let the Right Person Define What Notes Should Look Like

From this perspective, the note-taker should ideally be the person who best understands the discussion’s context or has the most vested interest in its outcomes—someone who can **define what the notes should capture**, because that becomes the foundation for all future decisions.

- **If it’s a technical discussion**, the engineer should take the lead. 
 Imagine a meeting debating Pulumi vs Terraform, and the notes are taken by a newly hired PM without a CS background—wouldn’t that be unfair?

- **If it’s a design review**, the designer should anchor the summary. 
 Suppose the conversation is about visual language and the meaning of red in the product, and the note-taker is a developer PM with no design sensitivity—he might just write: “Everyone seems to prefer red.”

- **If it’s a cross-functional strategy meeting**, then yes, the PM is probably the best person to document it—because their role is to ensure alignment across teams and between actions and product direction.

---

### But What If the Right Person Doesn’t Want to Take Notes?

This is the reality: 
The person with the most context is often the busiest and least willing to take notes. They can’t fully participate in the conversation if they’re distracted by documentation.

 

**This is exactly where tools and technology come in.**


- Tools like **Google Docs** allow for collaborative note-taking. Other attendees can contribute in real time, or fill in their thoughts before the meeting starts so the structure is already there.
- Generative AI tools like **Otter.ai** or **Fireflies.ai** can transcribe audio and generate rough summaries, which can be reviewed and refined afterward.

However, a word of caution:

 

While many AI tools advertise “automatic summaries” and “action item detection,” these can’t fully replace human-written notes. 
Because **meeting notes are not just text—they are about communication, alignment, and sometimes even commitment**. That human nuance is still hard to automate.

 

That boundary between what AI can and can’t do is something each team will need to define for themselves.

---

### From "Who Should Do It" to "How to Make It Valuable"

You might still believe the PM should write all the notes. 
Or maybe you prefer a rotation system, or delegating to an intern or admin.

 

But the more important point is this:

 

**The way we choose to handle these “minor tasks” is how we shape our culture.** 
Not by title or salary, but by participation, motivation, and understanding—backed by tools that can help share the load.

---

### ✅ Practical Suggestions

- Clearly define a **topic owner** who reviews and finalizes the meeting summary. Let others contribute collaboratively, especially those who are close to the topic.
- If using collaborative docs or AI tools, make sure the owner does a brief post-meeting check and supplements action assignments if needed.
- Keep reinforcing the mindset within your team that **“notes ≠ chores.”** They are a tool for building shared understanding.

---

### In the End

Meeting notes aren’t just about documentation. 
They reflect **what we, as a team, choose to remember**.

 

And maybe, just maybe—rethinking how we approach that task is where real collaboration begins.

Why Is It Always the PM? Rethinking the Logic Behind Meeting Notes

![](./pm-background-cover.png)

# How Much Tech Does a PM Need to Know? From Engineers to Designers: How Different Backgrounds Can Thrive as PMs

 

As a former software engineer turned product manager, and someone who has worked with PMs from diverse backgrounds, I’ve noticed something interesting: 
**Everyone asks, "How much tech should a PM know?" but rarely, "Is my background a good fit for PM?"**

 

Rather than obsessing over technical depth, perhaps a better question is: 
**What strengths do people from different backgrounds (design, QA, sales...) bring to the PM role, and what should they watch out for?**

 

But before diving in, let's first define what PMs actually do.

---

## Two Main PM Roles: Product vs. Project

In most companies, PMs generally fall into two categories:

### Product Manager

- Defines product vision, direction, and goals
- Writes specs, defines requirements and acceptance criteria
- KPIs often focus on product performance: retention, conversion, business outcomes

### Project Manager

- Ensures projects are delivered on time
- Coordinates across departments, syncs updates and progress
- Manages risk, allocates resources, controls schedules

While many companies don’t draw a strict line between the two (and I personally don’t recommend doing so rigidly), this framework helps us understand which background might suit each role better. 
This article focuses primarily on **Product Managers**.

---

## Strengths and Watchouts by Background

Every background comes with natural strengths — and transition challenges. 
The following "watchouts" aren't flaws, but common hurdles you’ll encounter and grow through. Becoming aware of them is the first step toward mastery.

### PMs from Engineering Backgrounds

**Strengths**:

- Quickly understand system architecture and estimate dev effort
- Can deeply engage with engineers on solutions
- Great fit for technical products like APIs or developer tools — often being the user themselves

**Watch out for**:

- Tendency to get lost in implementation details and lose sight of user or market needs
- Pursuing the perfect architecture can delay validation and time-to-market

 

→ Tip: Start lean, validate fast, then scale. Tech excellence should support the product — not replace market fit.

 

**Scenario**: 
An engineer-turned-PM spends weeks designing a clean microservice architecture before launching a dashboard. But later realizes a simpler solution would have let the team test the market much sooner and adjust accordingly.

### PMs from Design Backgrounds

**Strengths**:

- Strong user empathy and intuitive understanding of UX
- Advocates for thoughtful flows and delightful product experiences

**Watch out for**:

- May underestimate implementation cost, leading to over-engineered details
- Can overly compromise when facing technical pushback, even when their design had merit

 

→ Tip: Proactively engage with engineers to clarify constraints and find balanced solutions.

 

**Scenario**: 
A design-focused PM spends two weeks perfecting onboarding transitions and animations. Later learns those touches had minimal impact on conversion, while the core flow needed more attention. A reminder: polish ≠ value.

### PMs from QA Backgrounds

**Strengths**:

- Naturally detail-oriented and skilled at identifying edge cases
- Excellent at defining clear quality standards and testable requirements

**Watch out for**:

- Can create overly long, complex specs that dilute team focus
- May prioritize completeness over clarity and delivery speed

 

→ Tip: Start from core user stories, then layer in exceptions — not the other way around.

 

**Scenario**: 
A QA-turned-PM writes a 50-page requirements doc covering every possible condition. Engineers feel overwhelmed and lose sight of the main goal. Later, switching to concise user stories with supplementary notes helped everyone align faster.

### PMs from Sales Backgrounds

**Strengths**:

- Great market sensitivity and direct knowledge of customer pain points
- Comfortable navigating internal business priorities and stakeholder expectations

**Watch out for**:

- Risk of over-prioritizing one client’s feature request, leading to technical debt and bloated products
- May overlook product consistency or maintainability

 

→ Tip: Always ask, “Do multiple customers need this?” and work with tech/design to find reusable patterns.

 

**Scenario**: 
A sales-driven PM fast-tracks a custom feature to close a deal. Months later, it’s barely used and adds complexity to the codebase. The lesson: explore the underlying need before building the surface request.

---

## The Essence of PM: Becoming a True T-Shaped Contributor

From the examples above, it’s clear that PMs need to juggle:

- Technical feasibility and architecture
- User experience and logical coherence
- Customer needs and business value
- Go-to-market and positioning

It’s rare for one person to master them all — and that’s okay.

What matters most is that you:

- **Have a solid domain you’re confident in** — your vertical depth
- **Are curious and open enough to learn the rest** — your horizontal breadth

That’s the essence of a **T-shaped person** — and a great PM.

This is why people say “PMs are like product CEOs.” 
But in reality, PMs don’t have formal authority. They lead through **influence** and **collaboration**. Your **expertise** gives you credibility, and your **cross-domain understanding** allows you to work effectively with others.

---

## Keep Growing: Embrace Discomfort, Stay Curious

So, can anyone become a great PM? 
Yes — **if you're willing to keep learning beyond your comfort zone**.

Try these to stretch yourself:

- **Try on different hats**: 
 Before handing things off, run your own test cases like a QA, or sit in a customer demo like a sales rep. You’ll learn where your product really shines — or breaks.
 
- **Read outside your field**: 
 Engineers can read business strategy books; designers can explore backend logic basics. You don’t need to master everything, but exposure leads to faster growth.

- **Ask questions — a lot**: 
 Talk to teammates from other roles. Ask: “How do you usually approach this?” or “What’s challenging about your process?” This accelerates your learning and builds trust.

---

## Quick Self-Check: Is PM Right for You?

If you’re considering a transition to product management, ask yourself:

1. **What’s your current area of strength?** 
 → That’s your foundation for initial credibility and influence.

2. **Are you willing to learn new skills outside your domain?** 
 → PMs are cross-functional by nature.

3. **Can you make decisions in uncertain, messy situations?** 
 → Clarity is rare — PMs often work in ambiguity.

4. **When things go wrong, do you step up or deflect?** 
 → PMs don’t always have power, but they’re still responsible.

5. **Do you enjoy continuous learning?** 
 → Tech, business, design, comms — it never ends.

If you answered “yes” to most of these, you’ve already got the mindset of a great PM.

---

## Final Thoughts: Being a PM Is Like Living a Full Life

People say a PM is like a product’s CEO — but to me, 
**Being a PM is more like living a full, intentional life.**

 

You start with a vision, limited time, and incomplete resources. 
No one tells you exactly what to learn or how to proceed. 
You make choices, face trade-offs, take ownership.

 

That’s what makes this role beautiful — and hard.

 

You don’t need to know everything. 
But you do need to take responsibility, stay open, and keep growing.

 

When you do, you’ll start seeing connections others miss. 
You’ll bring people together. 
And you’ll build things that truly matter.

---

In the next article, I’ll talk about the Project Manager role — and why I believe folks from engineering or QA backgrounds are especially suited to it. Stay tuned.

Do You Need a Tech Background to Be a PM? Exploring the Strengths and Pitfalls of Different Paths

![](./vibe_coding_part2_cover.png)

In the previous article, we introduced the concept and process of Vibe Coding. But in practice, many problems still arise.
 
 

This time, I’ll walk you through a complete example — my wife is a Chinese teacher, and she made a simple game for her students to practice “matching Chinese characters with their pinyin.” It also features text-to-speech and score tracking for added interactivity.
 
 

In this article, I’ll break down the entire development journey using three common scenarios: "starting out", "debugging", and "understanding". You’ll see how she asked ChatGPT, what it responded with, and how we gradually improved it through prompt adjustments.
 
 

Live project: [https://afangchinese.github.io/wordmatch/](https://afangchinese.github.io/wordmatch/?data=JTdCJTIyZGF0YSUyMiUzQSUyMiVFNCVCOCU4MCVFNSU4MCU4QiUyQyVFMyU4NCVBNyVDQiU4QSUyMCVFMyU4NCU4RCVFMyU4NCU5QyVDQiU5OSUyMCUyMCU1Q24lRTUlODUlQTklRTUlODAlOEIlMkMlRTMlODQlOEMlRTMlODQlQTclRTMlODQlQTQlQ0IlODclMjAlRTMlODQlOEQlRTMlODQlOUMlQ0IlOTklMjAlMjAlNUNuJUU0JUI4JTg5JUU1JTgwJThCJTJDJUUzJTg0JTk5JUUzJTg0JUEyJTIwJUUzJTg0JThEJUUzJTg0JTlDJUNCJTk5JTIwJTIwJTVDbiVFNSU5QiU5QiVFNSU4MCU4QiUyQyVFMyU4NCU5OSVDQiU4QiUyMCVFMyU4NCU4RCVFMyU4NCU5QyVDQiU5OSUyMCUyMCU1Q24lRTQlQkElOTQlRTUlODAlOEIlMkMlRTMlODQlQTglQ0IlODclMjAlRTMlODQlOEQlRTMlODQlOUMlQ0IlOTklMjAlMjAlNUNuJUU4JUE1JUJGJUU3JTkzJTlDJTJDJUUzJTg0JTkyJUUzJTg0JUE3JTIwJUUzJTg0JThEJUUzJTg0JUE4JUUzJTg0JTlBJTIwJTIwJTVDbiVFOCU5OCU4QiVFNiU5RSU5QyUyQyVFMyU4NCU4NiVFMyU4NCVBNyVFMyU4NCVBNSVDQiU4QSUyMCVFMyU4NCU4RCVFMyU4NCVBOCVFMyU4NCU5QiVDQiU4NyUyMCUyMCU1Q24lRTklQjMlQjMlRTYlQTIlQTglMkMlRTMlODQlODglRTMlODQlQTUlQ0IlOEIlMjAlRTMlODQlOEMlRTMlODQlQTclQ0IlOEElMjAlMjAlNUNuJUU2JUExJTgzJUU1JUFEJTkwJTJDJUUzJTg0JThBJUUzJTg0JUEwJUNCJThBJTIwJUUzJTg0JTk3JUNCJTk5JTIwJTIwJTVDbiVFNiVBMiVBOCVFNSVBRCU5MCUyQyVFMyU4NCU4QyVFMyU4NCVBNyVDQiU4QSUyMCVFMyU4NCU5NyVDQiU5OSUyMCUyMCU1Q24lRTYlOTclQTklRTQlQjglOEElMkMlRTMlODQlOTclRTMlODQlQTAlQ0IlODclMjAlRTMlODQlOTUlRTMlODQlQTQlQ0IlOEIlMjAlMjAlNUNuJUU0JUI4JUFEJUU1JThEJTg4JTJDJUUzJTg0JTkzJUUzJTg0JUE4JUUzJTg0JUE1JTIwJUUzJTg0JUE4JUNCJTg3JTIwJTIwJTVDbiVFNiU5OSU5QSVFNCVCOCU4QSUyQyVFMyU4NCVBOCVFMyU4NCVBMiVDQiU4NyUyMCVFMyU4NCU5NSVFMyU4NCVBNCVDQiU4QiUyMCUyMCU1Q24lMjIlMkMlMjJsYW5nJTIyJTNBJTIyemgtSGFudCUyMiUyQyUyMnZvaWNlJTIyJTNBJTIyMCUyMiUyQyUyMnNvdW5kJTIyJTNBdHJ1ZSU3RA==)

＊ For more on what Vibe Coding is and its pros and cons, see the previous article: 
[Vibe Coding: What Is It, Who’s It For, and What Can You Do With It?](https://www.louisan.dev/en/blog/vibe-coding-getting-started)

---

## Scenario 1: Starting — “I want to make a game, but where do I begin?”

This is where most beginners get stuck — not knowing what to ask or how to start.

Her first prompt was:

> I want to make a pinyin matching game. Please use HTML + JS to help me build a simple web page. Users can input multiple lines of “Chinese character Pinyin”, and after clicking Start, matching cards will be displayed.

ChatGPT responded with a working demo that included:

- User input of multiple Chinese + pinyin pairs
- Displaying cards on Start
- Text-to-speech when clicking Chinese characters (via SpeechSynthesis API)
- Cards disappearing after successful matches

**Tips:**

- Add info about your “skill level,” “tech preferences,” or “intended use environment” to get more tailored responses
- It’s okay if the first version isn’t perfect — just iterate
- If you don’t understand terms like HTML, JS, server, local storage, or ReactJS, don’t worry. This uses the simplest stack for beginners as explained in Part 1. You can directly use this add-on to your prompt:

> Just to clarify, I have no coding experience. I want something that runs in the browser with no server or frameworks like React. Please use plain HTML and JS. If data needs to be saved, use local storage in the browser.

Here’s a refined version I helped her write:

> I want to make a Chinese pinyin matching game. There should be a text input where I can enter multiple Chinese + pinyin pairs. The input should persist even after refreshing. When I click Start, the game will use my input to display cards for students to match. The game ends when all pairs are correctly matched. If they get it wrong, that pair should appear again until answered correctly. At the end, show the number of correct and incorrect answers. I have no coding experience. I want something that runs directly in a browser, no server or React, and use local storage if needed.

---

## Scenario 2: Debugging — “Something broke, what do I do?”

Everyone runs into this at some point. Here are a few common issues and how we fixed them:

### 1. Cards don’t refill after matches

> After a correct match, please refill from unmatched words so there are always 4 pairs on screen.

### 2. No red flash on incorrect answers

> When players get it wrong, show a red highlight on both cards briefly before resetting.

### 3. Pinyin cards also trigger audio

> Please make sure only Chinese character cards trigger audio.

**Tips:**

If your screen goes blank or something inexplicably breaks, try this:

> I pasted your code, but the screen is blank. Please walk me through how to open browser developer tools and send you the error message.

---

## Scenario 3: Understanding — “What does this part mean?”

Sometimes, ChatGPT gives code that works, but you don’t fully understand it — or your edits aren’t producing the effect you want. Try asking for line-by-line explanations:

> What is `speechSynthesis` doing? Why is it needed?

> You gave me this code: `element.classList.add("error")`. I don’t understand what it does, and it’s not working as expected. Can you explain line-by-line?

ChatGPT will usually help with:

- What the code does
- The purpose of each line
- Whether parts are optional or modifiable

---

## Tools for Going Further: Making It Cleaner, Safer, and Online

### (A) ChatGPT + Browser is Enough to Start

- Just paste your code in an `.html` file and open it in a browser
- No need for development tools

**Limitations:**

- Can only run on your own machine 
 → Use GitHub Pages (see D) to go public 
- As code gets longer, ChatGPT may break or overwrite working sections 
 → Use (B) Cursor to make smaller, controlled edits 
 → Use (C) GitHub for version control and rollback

---

### (B) Cursor (AI Coding Editor)

- Combines code editing with AI chat
- Highlights exactly what AI changes
- Allows managing multiple files as the project grows

**Limitations:**

- Paid (but free trial available)
- Still recommended to pair with (C) GitHub for backups

---

### (C) GitHub (for version control) — *Advanced, optional*

GitHub is a professional tool for saving code and managing versions. It’s powerful but takes effort to learn. Skip for now unless you're interested.

If you want to try it, I’ve simplified the steps:

1. Create a GitHub account 
2. Make a new repository 
3. Set up authentication 
4. Link your local folder to GitHub (make sure your code is in a dedicated folder)

Use this prompt with ChatGPT to guide you through:

> I want to upload my code to GitHub for versioning. Please walk me through (1) creating an account, (2) setting up a repository, (3) configuring auth, (4) uploading my folder.

Once that’s done, open the Terminal and run:

```bash
cd [your-folder-path]
git add .
git commit -m "Update"
git push -u origin main:main
```
Replace [your-folder-path] with your actual path. Paste and press Enter. You’ve now updated your code to the cloud! Repeat this every time you want to save a stable version.

---

### (D) Publishing It Online — Use GitHub Pages or Other Free Hosts

- Publish your project for free online
- If GitHub is set up (from C), use this prompt:

> I’ve uploaded my project to GitHub. How can I publish it using GitHub Pages?

If not using GitHub, you can also ask ChatGPT to recommend other free hosting options.

---

## Summary: From Idea to Live App—You Can Do It

In this process, I realized that the biggest blockers weren’t writing code, but not knowing what to ask — or how the tools work.

We finished this project in just two evenings. Most of the time went into writing prompts and learning how to go online — the actual “coding” part was minimal.

It reinforced my belief:

> AI coding is mature. What we still need is support for turning prototypes into real, usable tools.

Hope this article helps you create your own first project — and experience that amazing feeling of turning ideas into reality.

You Don’t Need to Code! Vibe Coding in Action: Full Prompt Examples to Launch Your Program Online

![](./japan-market-challenges_cover.png)

---

Have you heard people say “Japanese clients are really picky”? Sure—but at the end of the day, they’re just people. What makes the difference is how Japan’s cultural background, business structures, and risk sensitivity raise the bar for quality and trust.
 
With strong purchasing power, a mature industrial ecosystem, and an obsession with perfection, Japan is an attractive market for many tech companies looking to expand.\
But as with any international expansion, there are hidden costs and hurdles.\
**And when it comes to how strict and meticulous clients can be, Japan is arguably one of the most challenging markets.**
 
In this post, I’ll walk through five recurring challenges I’ve faced while introducing B2B tech products to Japanese clients, comparing them to what I’ve experienced in Taiwan and the US.\
*This is based on personal experience—your mileage may vary depending on your product or industry.*

---

## Challenge 1: Exceptionally High Quality Standards

*Keywords: detail, experience design, craftsmanship mindset*
 
**How is it different?** Similar in essence, but Japan sets a higher bar.

Japanese users and companies expect products to be stable, reliable, and smooth—bug-free is the bare minimum. If a workflow feels confusing or lacks clear guidance, the product may be deemed unusable.
 
**A real case:**\
When rolling out a livestream service, the client barely asked about the core functionality. Instead, they focused on the user experience details: entry flow alerts, error fallback handling, risk prevention mechanisms. They even requested annotated screenshots for every edge case—not just text descriptions.\
Compared to other markets, this preparation took significantly more time and effort.
 
**Cultural context:**\
This reflects a central Japanese value: "Don't cause trouble for others." Product design is not just about features—it's about showing care and responsibility.
 
**What works:**\
Simulate user edge cases before you're asked. Proactively surface your plan for abnormal flows and error handling. Show that you’ve thought through every scenario.

---

## Challenge 2: Complex and Nuanced Internal Decision-Making

*Keywords: nemawashi, consensus-building, co-promotion with champion*
 
**How is it different?** Enterprise politics exist everywhere, but Japan plays the long game.

Even if your point of contact (POC) is responsive and senior, they may not have final say—or be able to directly advocate for you. In Japan, internal "nemawashi" (laying the groundwork) is essential.\
If you ignore this, you might go through several rounds only to find your proposal was never really discussed at the top.
 
**Typical pattern:**\
Japanese organizations tend to make decisions by **consensus**, with layers of internal alignment. Meetings might feel smooth, but they may only be information gathering—not actual evaluation.
 
**The risk:**\
If you expect your champion to “sell the idea” solo, projects can stall, or be rejected last-minute for reasons you never heard.
 
**Tactical fix:**\
Don’t leave your POC to fend for themselves. Instead:

- Help them draft internal messaging
- Provide visuals and summaries to make internal sharing easier
- Act like a teammate—not just a vendor

**What works:**\
Be a partner. Co-own the proposal process instead of handing it off to your champion.

---

## Challenge 3: Deep Scrutiny of Technical Architecture and Longevity

*Keywords: transparency, maintainability, systems thinking*
 
**How is it different?** Japanese clients go deeper—and further into the future.

It’s not just “Does it work?” or “Is it innovative?” You’ll often hear:

- Is the architecture stable?
- Can we maintain this five years from now?
- Will adding new features break the system?

**Real experience:**\
One client asked us to detail how our system handled preprocessing and caching, including:

- What gets preprocessed?
- When and how often?
- How is success verified?
- What triggers fallback logic or cache invalidation?

This was far beyond what we’d encountered in Taiwan or the US. It forced us to upgrade our internal documentation and rethink how we communicated about our backend.
 
**What works:**\
If your product is a black box, lacks docs, or doesn’t show a clear maintenance plan—you’ll have a hard time winning trust.\
Build documentation and versioning plans that show long-term thinking and operational stability.

---

## Challenge 4: Overlooked Local Regulations and Compliance Traps

*Keywords: local laws, industry-specific standards, hidden risks*
 
**How is it different?** Compliance is a global need, but Japan has its own set of unique rules.

Even if your product complies with GDPR or US standards, Japan may catch you off guard. Some key areas include:

- Subtle details in Japan’s Personal Information Protection Law (PIPL)
- Industry-specific regulations in finance, healthcare, education
- Japan-specific digital signature formats (e.g., JPKI), KYC procedures

**Real examples:**

- **Uber**: Couldn’t replicate its gig driver model in Japan. Regulations forced it to partner with licensed taxi companies instead.
- **Airbnb**: In its early days, many listings failed to meet local housing standards, leading to a steep drop in available properties.

**What works:**\
Even global giants get tripped up by local rules. So:

- Consult a local legal or compliance expert early
- Build a checklist into your product development cycle
- Design your product with enough flexibility for industry-specific compliance needs

---

## Challenge 5: Building Long-Term Trust, Not Just Transactions

*Keywords: trust-first, local presence, risk aversion*
 
**How is it different?** Japanese clients expect deeper commitment and stronger signals of reliability.

B2B relationships in Japan are more like long-term partnerships than one-off sales.\
Beyond product and pricing, your client will also evaluate:

- Can you communicate in Japanese?
- Do you reply quickly and clearly?
- Do you have a stable, local presence?
- Will working with you make *them* look bad to their clients?

**Why it matters:**\
Your Japanese client is putting their own trust on the line. A single supplier mistake could harm their reputation. That’s why they want to minimize every uncertainty.
 
**What works:**

- Set up a local entity or hire Japan-based staff to show commitment
- If that’s not feasible, assign a culturally fluent contact who can handle communication smoothly
- Make it clear you’re not here for a short-term win—you’re here to build

---

## Final Thoughts: Understand the Culture, Own the Details, Deliver with Care

These aren’t just theoretical issues—they’re real challenges I’ve faced time and again in Japan.\
While some of them apply globally, **Japan’s level of depth and expectation is on another level**.
 
To succeed in Japan, you’ll need more than just strong tech.\
You’ll need cultural awareness, clear communication, and long-term thinking. But if you invest the effort, the trust and loyalty you earn will be far greater than in many other markets.
 
And in the end, these lessons aren’t just for Japan.\
**Understanding culture, mastering the details, and following through—that’s how you succeed anywhere.**

---

**In the next post, I’ll break down the real costs and timelines behind each challenge to help you estimate ROI and make better decisions.**

Entering the Japanese Market Takes More Than Just Tech: Pitfalls and Lessons from My Experience

![](./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!

[Click here to jump to the practical Part 2](https://www.louisan.dev/en/blog/vibe-coding-part2)

---

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%" />
 ▲ Blog page created with Vibe Coding.
</div>

 

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.

[Click here to continue to the practical Part 2](https://www.louisan.dev/en/blog/vibe-coding-part2)

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) 
▲ 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.

 

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