Progressive Abstraction and the Clear Picture Problem
Shopee deeply shaped how I think about building products. The core skill I developed there: how to build something where you know the rough final form, but you evolve it together with the business.
The questions that became instinctive:
- What can be abstracted? What's worth the abstraction, what's not?
- When do you abstract — too early is waste, too late is debt
- How do you push the thing toward your final goal while collecting signals along the way?
This is a specific product skill: progressive abstraction — knowing when to harden a pattern into an abstraction vs. keeping it concrete and duplicated. It applies to systems (when to build a platform vs. keep building features), to product concepts (when to generalize a workflow vs. keep it specific to one user type), and to strategy (when to commit to a direction vs. keep optionality open).
What I Actually Learned
My old tendency was to abstract too early. The real lesson from Shopee wasn't "learn to abstract" — it was learn to resist the urge to abstract prematurely, and instead find the balance:
- Serve the near-term need — solve the problem in front of you, don't build the platform before you need it
- Collect something compoundable — even while being concrete, make choices that make future life easier. Data structures that generalize, patterns that can be extracted later, interfaces that don't lock you in.
- At minimum, don't introduce too much debt — if you can't invest in the future, at least don't mortgage it. Keep things clean enough that the next move is possible.
The balance isn't "short-term OR long-term." It's: solve today's problem in a way that compounds, or at worst, doesn't create a mess you'll regret.
Shopee: The Clearer Version
At Shopee, the final picture was clear. Digital banking, payments infrastructure — the end state was largely known. The unknown was the path, not the destination. I didn't have many prior beliefs to correct (most corrections happened because I was new to the landscape).
This meant:
- Abstraction decisions were mostly about timing and sequence — when to build the platform, not whether the platform was the right end state
- Signals confirmed or adjusted the path, but rarely challenged the destination
- The multi-layer complexity was real (many intertwined domains), but the layers were legible — I could draw the 2D map
- The "abstract too early" instinct was useful to have and then learn to temper — because the end state was clear enough to know what to eventually abstract, the question was purely when
Startups: The Harder Version
Not a different skill — the same skill on a harder problem. The destination is unclear, you may need significant pivots, and the landscape shifts under you. This adds complexity to every progressive abstraction decision:
- You might abstract toward the wrong picture — the destination itself is a hypothesis
- Signals don't just adjust the path — they can invalidate the destination
- Prior beliefs need constant correction, not because you're new, but because the ground is moving
But the core is the same: balance short-term vs. long-term, stay flexible, collect signals, know when to harden and when to keep things loose. The startup environment doesn't require a fundamentally different approach — it requires the same judgment under higher uncertainty. Harder, but not unsolvable.
What This Is Not
- Not "ship fast and figure it out" — that skips the abstraction question entirely. Speed without structure creates debt you can't reason about.
- Not waterfall planning — that abstracts everything upfront before you have signal. The opposite failure mode.
- Not "never abstract" — perpetual concreteness creates a system nobody can evolve. The question is always when, not whether.
The Real Question
Not "can this skill transfer?" — it does. The question is about calibration: how tightly to hold the picture. At Shopee, you could commit confidently because the end state was known. In a startup, you hold the picture loosely enough to pivot, but tightly enough to make abstraction decisions today.
This is probably what "multi-layer ambiguity" actually feels like in practice — not as an abstract concept, but as the daily question of calibrating confidence: how much structure do I commit to right now, given what I know?
Related
- Role Criteria — Multi-layer problem decomposition — the skill gap this thought describes
- Engineering Maturity — abstraction comfort as growth axis
- Three Startup Philosophies — different startup types require different abstraction strategies
- Execution PM vs Creator PM — creator PM must make abstraction bets under uncertainty