Nguyen Chau
Câu chuyện nghề thật · không phải sales pitch A real delivery story · not a sales pitch 実体験のストーリー · 営業トークではありません
One Project · Four Years · One Delivery Team

Japanese B2B SaaS — 4 years building a delivery team

I won't tell you the client's revenue numbers. I'll tell you the decisions a real BrSE / Delivery Manager had to make.

Japanese client B2B SaaS platform 2022/10 — present BrSE → Delivery Manager
Executive Summary
  • Context: Took over a small team lacking standard processes, bus factor = 1, frequent delays, and many technical bottlenecks.
  • Action: Restructured using a Delivery Manager approach: applied a 5-step analysis flow, validated specs twice, and became a knowledge-sharing Hub rather than just coding.
  • Impact: Scaled the team; optimizing the system architecture took production bugs from 10–15/month down to 1–2/month, and no release missed its committed date across 4 consecutive years.
4 years summarized — in 3 lines
PROD Bugs
10–15 / month
→ 1–2 / month
Delivery
Frequently delayed
→ 100% of releases on time
Knowledge
Bus factor = 1
→ Shared team-wide
01 Context

What state was the project in when I joined?

October 2022. I joined as a BrSE. The team was still small.

The product was already running in production, but it was "clunky" — most features weren't smooth. Performance was bad, pages loaded slowly, making it easy to lose customers. Back then, the team was only handling a small group of features.

But the biggest problem wasn't technical. The biggest problem was how the team worked:

  • Working on a task here meant a bug appeared there. Issues everywhere.
  • The person doing task A didn't understand task B. The person on task B didn't understand task C.
  • Bus factor = 1. If one person took a day off, their task was delayed. The client would immediately complain.
  • No daily meetings. Written reports only. Weekly meetings didn't solve anything.
  • Knowledge was locked inside individuals' heads, never shared.

That was the starting point.

02 Turning Point

When I took on full 1.0 effort for this project

After an initial period of observing while working, I took on full 1.0 effort for the project. That was when I decided: we couldn't just keep patching individual tasks. We had to change how the team worked first, before talking about product quality.

I didn't believe in forcing a rigid framework — textbook Scrum, SAFe, etc. I chose a hybrid Agile + Waterfall — keeping the predictability of Waterfall for Japanese clients, but introducing MVP-first thinking and Agile iterations into the team.

Specifically, I did 6 things. Each was a deliberate decision, not a "best practice copy-paste".

03 Decisions log

Six decisions made over 4 years

Not marketing milestones. These are the moments I had to choose — and the real reasons behind those choices.

01

From "carrier pigeon" to a 5-step analysis flow

Before

The client spoke, the team quoted. Devs coded mechanically according to the spec. Met the spec → released. Went to PROD → feature didn't solve the user's real pain point → client requested changes → team reworked → repeat.

Decision

Created a 5-step requirement processing flow that every new req had to go through:

1
Receivereq from client
2
Analyze4 views: User, Client, Dev, QA
3
Brainstormfind optimal approach
4
Aligninternal alignment & propose
5
Client OKstart development
Hindsight

This was the most important decision in 4 years. It wasn't a process — it was an attitude: the team was no longer a robot, but the client's technical partner. The sharp drop in the bug rate later on was entirely due to this.

02

Spec validation twice — before dev and after completion

Before

Spec came from JP, VN devs built it, released it, bugs appeared. Why? — "The dev followed the spec perfectly." A true but useless answer.

Decision

Every spec is validated twice, and I am responsible for the review:

  1. 1st time (before dev starts): Verify from the user + client perspective. Does it solve the pain point? Are there missing edge cases?
  2. 2nd time (after completion): Verify from the execution team's perspective (dev, QA). Is this task necessary? Is there a better way? Should we propose cutting some parts?
Hindsight

This principle was born from pulling all-nighters to fix features that were already released. I baked it into the DNA of every sprint for 4 years. Rework due to misunderstanding specs virtually disappeared.

03

Redefining "Done"

Before

"Done" = dev finished + QA passed + released.

Decision

"Done" = answering 3 questions:

  • Why did we build this feature? (Business Value)
  • How will the user use it? (UX/Scenario)
  • If an error occurs, how does the system recover? (Technical Resilience)

If the first question can't be answered — I push it back to the analyst. Development doesn't start.

Hindsight

This is what separates an "executor" from a "consultant". Executors are measured by output. Consultants are measured by outcome.

04

I became the knowledge sharing hub

Before

Everyone kept knowledge in their head. Knowledge didn't circulate. Bus factor = 1.

Decision

I organized MTGs, personally hearing the knowledge and documenting it.

  • Scope of impact
  • Analyzed content
  • Finalized decision

So that all parties have a shared understanding.

Hindsight

Sounds simple, but doing it for 4 years straight is another story. This is why the team could scale without breaking quality — knowledge wasn't dependent on individuals.

05

Weekly training — mind-set first, technical second

Before

The team scaled fast. Many juniors. Without training, everyone would define "good" their own way.

Decision

One training session every week (2024 → 2025/6). I prepared the materials myself. Content followed this order:

  1. Problem-solving approach (Mind-set)
  2. Product domain (what the product does, why it matters)
  3. Technical architecture & coding standards

Format: pre-prepared materials → two-way discussion → not a one-way lecture. From mid-2025, as the team matured, training frequency decreased.

Hindsight

Mind-set training is 10 times more important than technical training. You can Google tech. You can't Google mind-set.

06

Hiring for mind-set

Before

Pressure to scale up. The temptation is to hire anyone with a nice CV and long experience.

Decision

Mind-set is the first gate. Conservative mind-set → auto reject from the start.

Onboarding is 3–6 months. Mentors get a monthly financial bonus.

Hindsight

The pass rate for juniors in onboarding is 100%.

04 Mistakes

Mistakes I made — and what I learned

I'm not telling this story to feign humility.

Context: To prioritize development speed, we proceeded with implementation without fully digesting the specs from the client.

I forgot to put myself in the end-user's shoes. I assumed the client had thought it through.

Result: After release, the feature was extremely hard for users to use, eventually requiring a massive rewrite.

Lesson: Being a "yes-man" who just implements whatever the client asks is beneficial to no one in the long run.

Since then, for every requirement, I always pause for a beat and ask 3 questions:
  1. Who is the end user?
  2. What is their real pain point?
  3. Does this feature solve that pain point — or just the surface symptom?
05 Trust

Why the client judged the team by trust

I've thought a lot about this question. After 4 years, I realized one thing: in the first year, the client judged the team by speed — how fast features were built. But from the second year onward, the client's yardstick changed.

1

Does the team see risks before they happen?

Meaning, proactively raising concerns when reading the spec, not just reporting errors after it's built.

2

Does the team understand the business pressure behind every requirement?

Meaning, when the client pushes hard, we understand why they're pushing — and sometimes propose a different approach to help them relieve that pressure better.

That is what kept the partnership going for 4 years — not promotions, not discounts, not sales efforts.
It was trust.

06 Internal Metrics

Numbers I can share

I won't show the client's revenue. Those are their numbers. But these are the metrics that belong to my team.

Internal Metric Before (2022) Now (2026)
PROD Bugs per month 10–15 1–2
On-schedule delivery Frequently delayed 100%
Junior pass onboarding — 100%
Rework due to spec misunderstanding High (unmeasured) Almost zero
If you've read this far

Thank you — and a no-pitch invitation

No sales pitch. No templates. Just practical insights from someone who has been through that phase. Let's connect and chat.

Get in touch View the 6-step process
Open to networking · Sharing expertise · No commitment

This article does not disclose technical details, architecture, or business data of the client. All content is presented from the perspective of an internal team manager and has been cross-referenced with publicly disclosed information.