What Did You Learn? Retrospective Is the Next Asset

Retrospective isn't tidying results — it's asset-building for what comes next.

People who jumped to the next without retro — and tanked

A year ago Seoyeon Park shipped her marketing-column auto-classifier SaaS and gathered the first 100 users. 5 paid. "I built one, now onto the next." Over 2 weeks she sketched 3 new ideas. She couldn't stop, because the current shortfall felt like her own inadequacy. Result? 6 months later, all 4 projects were stuck mid-stride.

Junho Lee was more extreme. 3 months after his first MVP, he looked at his login function and thought, "What is this?" Reading his own legacy code took time, so he vowed "I'll write the next one clean." And he made the same mistake. Nothing compounded for the second time either.

What they both missed is the same — retrospective. But most people think of retro as "time to tidy up finished work." Write "good points, regrets" in Excel and stash in a folder. That isn't retrospective. That's a "log."

Retrospective is asset-building, not tidying

Understand the real purpose. Retrospective is, at the moment the first MVP ends, building "assets" to spend on the next MVP.

Look back at your first MVP year. Inside are many assets. Code, sure, but also know-how, relationships, tools, habits. Patterns where you erred. Repeated decisions. Records of conversations with customers. All of it is "compost" that lets you build the next MVP 5 days faster.

People who skip retro and go to the next show a clear pattern.

1. Repeat the same mistake from the first MVP
2. The second takes as long as the first
3. End up blaming themselves: "I'm just slow"

Wrong. You're not slow — you're not aware of the asset. Daangn validated their "Pangyo Local Market" MVP in one neighborhood first, then expanded that pattern nationwide. Toss mined "fast transfer" as a core signal, then stacked 40+ products on that foundation.

Without retro, every lesson ends as "one experience." Through retro, the same lesson becomes "strategy for next time." The difference is big.

3 retrospective frameworks compared

1. KPT, the most intuitive 3-way split

Keep / Problem / Try. The most common method in agile teams.

Park's first-MVP retro example:

Keep
- Did 1 customer interview every week (keep this cadence)

Problem
- Mixing feature dev and marketing made both half-baked

Try
- Push marketing 2 weeks back for the next MVP
  (measure: Day-7 signups)

KPT's strength: simple structure, leads directly to action. Weakness: "Try" can stay abstract. Each Try item must have owner, deadline, and measurement criteria.

2. 5 Whys, drilling to root cause

Toyota technique. Ask "why?" 5 times to get past symptoms to the root cause.

Lee's second-MVP retro example:

Q1: Why did the first MVP's code rot in 6 months?
→ I coded quickly for every customer request

Q2: Why code so quickly?
→ I didn't set deadlines

Q3: Why no deadlines?
→ I had no definition of "enough"

Q4: Why no definition?
→ No marketing team, no external validation

Q5: What now?
→ For the next MVP, write a "feature freeze doc" with the team in week 1

Strength: tunnels past surface problems to the real root. Weakness: takes time. Apply only to "one or two big issues."

3. KIS (Keep-Improve-Stop), fastest to action

From organizational psychology. Three buckets, but you put only "action items" inside.

• Keep: 1–2 behaviors to keep (specific, measurable)
• Improve: areas to improve + how
• Stop: what to stop from now (phrased non-negatively)

Strength: retrospective becomes "next week's protocol" immediately.

How to separate emotion from data

The hardest part. Separating your emotion from data.

Most founders read first-MVP results like this:

• 5 paid users → "marketing still lacking"
• High churn → "UI is ugly"
• 20 signups/month → "needs more time"

This is "if I try harder it'll work" psychological defense. Reality may differ.

3 steps to separate

Step 1. Pull the emotions out. First, acknowledge what you felt while building. "I built this for a year, I tried hard, and I still believe this market is big." Write it. No need to hide.

Step 2. Just look at data. Then look only at numbers.

• Day-1 signups vs Day-30 signups (is the growth curve rising?)
• Active user share among signups (what % of signups are active 30 days later?)
• Repeated phrases in customer interviews (did 3+ customers mention the same problem?)

Step 3. Read the data as "signal." "Marketing is lacking" isn't a signal. But "100 signups week 1, 15 signups week 2" is a signal. A signal shows what you can't do.

The most common second-MVP trap: re-doing the first MVP's "emotional interpretation." "Market more," "make the UI prettier." If you miss the real signal, you walk the same road again.

The best tool for separating emotion from data is another person. Show your written retro to a colleague or mentor and ask "what do you think this data is saying?"

3 types of "do differently next time"

1. Things not to do this time

"Don't take in every feature request" → next MVP, when a customer requests a feature, first ask "does this align with our roadmap?"

2. Things I didn't do this time but will next

"Couldn't run customer interviews often enough" → next MVP, block 4 hours/week for interviews. No deadline.

3. Things to do differently

"Did marketing at the end" → next MVP, from Day 1. How: email list, Disquiet, ProductHunt prep.

For each, write "when," "who," "how measured."

Retrospective workbook, 4 stages

Stage 1. Numbers (20 min)

- Ship date / end date
- Day 1·7·30·150 signups
- Paying users
- Retention
- Most active customer segment (e.g., marketing teams using 3x/week)

Stage 2. Acknowledge emotion (10 min)

My feelings about this project:
- "5 months of effort, surely more chance ahead"
- "Customers said it was good, demand must exist"
- "Just more marketing will do it"

Stage 3. KPT structure (30 min)

Stage 4. Codify assets for the next MVP (20 min)

1. Customer interview protocol (every Tue/Thu 14:00, Notion logs)
2. Feature priority system (customer repetition + our roadmap)
3. Marketing start point (Day 14, prep: email list + community)

Retrospective checklist

• Are all first-MVP final numbers recorded? (signups, active, paid, retention, interviews)
• Did you write at least 1 paragraph separating emotion from data?
• Did 5-Whys drill into 1–2 root causes?
• Did you extract 3+ concrete actions for "do differently next time"?
• Each action has owner, deadline, and measurement criteria?

Wrapping up

Once you've done the retro, a harder question arrives. Is the data you extracted really the right signal? Most makers get fooled here.

Of the 100 data points from your first MVP, the real signals are 3–5. The rest is noise. Next post: recognizing confirmation bias and distinguishing real signal from self-rationalization.

Previous: [Fail School S2] After the First MVP — How the Next One Is Different
Next: What the Data Said vs. What You Wanted to Hear

About the characters (Seoyeon Park, Junho Lee)
Characters in this series are fictional personas created by Fail School. Company cases (Daangn, Toss, etc.) and frameworks (KPT, 5 Whys, KIS) are real.

Minchul Kim, CEO of Freeive, Fail School