Moving Between Abstraction and Execution
English
When I first became a product manager, my boss told me something that stayed with me:
"Whether you succeed as a PM depends on your ability to abstract."
At the time, I was strong on execution. I could understand customer situations, optimize workflows, and get things built. That part was relatively straightforward.
But it also meant I was solving the same problem, repeatedly, in slightly different forms.
What he was pointing at was a shift:
- What is the underlying problem here?
- How do you structure it so it works beyond a single customer?
That was the first time I realized that execution and product thinking operate at different layers.
⸻
Over time, though, I learned the inverse is also true.
Abstraction alone doesn't hold.
You can define a clean model or a reusable system, but if it doesn't survive real constraints—messy data, edge cases, operational limits—it collapses on contact. On the other hand, staying too close to execution turns everything into local optimization.
So it's not abstraction vs execution.
It's whether you can move between them—and close the loop.
- Step back and define the problem
- Shape it into something reusable
- Bring it down into constraints
- Build
- Then step back again
For example, in product work, this often shows up in something as concrete as a data model or an API. If it's too abstract, no one can implement it. If it's too specific, it doesn't generalize beyond one customer.
Most product failures I've seen are not about bad ideas, but about this loop breaking—either never abstracting, or never coming back down.
⸻
This tension is especially visible in how teams handle customer input.
If you follow every request, you fragment. If you ignore customers, you drift.
The distinction that matters is subtle:
- Customers are often unreliable at proposing solutions—especially early on
- But they are highly reliable at exposing constraints
Confusing those two leads to either overfitting or irrelevance.
⸻
What made me revisit this recently is not just experience, but the changing environment.
LLMs are very good at execution. Given a direction, they optimize, generate, and iterate quickly. A lot of what used to be hard on the "doing" side is getting compressed.
But they don't decide:
- What problem is worth solving
- What should be shared vs customized
- What success actually means
That doesn't eliminate abstraction—it sharpens where it matters.
Not abstraction as an isolated skill, but the ability to define something that can actually be closed in reality.
⸻
Looking back, what my manager said was directionally right.
But incomplete.
Abstraction matters. Execution matters. But the difference shows up in the transition.
Can you move between the two—and make it work under real constraints?
That's where products start to scale.
日本語 {#japanese}
プロダクトマネージャー（PdM）になりたての頃、上司にこんなことを言われました。今でも頭に残っています。
「PdMとして成功できるかどうかは、抽象化できるかどうかにかかっている」
当時の私は、実行力にはわりと自信がありました。 顧客の状況を理解して、ワークフローを最適化して、ものを作り上げる——そこまでは比較的うまくできていました。
ただ、その結果として、少しずつ形の違う同じ問題を、繰り返し解き続けていたんです。
上司が指摘していたのは、こういう視点の転換でした。
- そもそも、根っこにある問題は何か？
- 一人の顧客を超えて機能するように、どう構造化するか？
実行とプロダクト思考は、異なるレイヤーで動いている——そのことに気づいたのは、このときが初めてでした。
⸻
ただ、時間が経つにつれて、逆も真なりだということを学びました。
抽象化だけでは、成り立ちません。
きれいなモデルや再利用可能なシステムを定義できたとしても、現実の制約——雑然としたデータ、エッジケース、運用上の限界——に耐えられなければ、接触した瞬間に崩れてしまいます。かといって、実行に近づきすぎると、あらゆるものがローカルな最適化になってしまう。
だから、抽象か実行か、という話ではないんです。
そのあいだを行き来できるか——そしてループを閉じられるか、という話です。
- 一歩引いて問題を定義する
- 再利用できる形に整える
- 制約の中に落とし込む
- 作る
- そしてまた一歩引く
プロダクトの仕事では、これがデータモデルやAPIのような具体的なものにそのまま現れます。 抽象的すぎると、誰も実装できません。 具体的すぎると、一人の顧客の外には広がりません。
私が見てきたプロダクトの失敗の多くは、アイデアが悪かったからではなく、このループが壊れていたことが原因でした——抽象化が起きないか、地に足が着いた形に戻ってこないか、そのどちらかです。
⸻
このテンションが特にはっきり見えるのが、チームが顧客のインプットをどう扱うか、という場面です。
すべてのリクエストに従えば、プロダクトは断片化します。 顧客を無視すれば、方向性がずれていく。
ここで大切な区別は、ちょっと微妙なところにあります。
- 顧客はソリューションの提案には当てにならないことが多い——特に初期段階では
- でも、制約を露わにすることには、非常に高い信頼性がある
この二つを混同すると、過学習か、あるいは的外れか、どちらかに陥ります。
⸻
最近この問いに立ち返ったのは、経験だけがきっかけではありません。環境が変わってきていることも大きいです。
LLMは実行がとても得意です。方向性を与えれば、素早く最適化し、生成し、繰り返してくれます。「やる」側でかつては難しかった多くのことが、圧縮されてきています。
でも、LLMは決めてくれません。
- どの問題を解く価値があるか
- 何を共通化して、何をカスタマイズするべきか
- 成功とはそもそも何を意味するのか
これは抽象化の重要性をなくすのではなく、むしろどこで重要かをより鮮明にします。
孤立したスキルとしての抽象化ではなく、現実の中で実際に閉じられるものを定義できるか、ということです。
⸻
振り返ってみると、上司が言ったことは、方向性としては正しかった。
でも、不完全だったとも思います。
抽象化は大事です。実行も大事です。 ただ、違いが現れるのは、その移行のところです。
二つのあいだを行き来できるか——そして、現実の制約のもとで機能させられるか？
プロダクトがスケールし始めるのは、そこからです。