Sounds Smart, Says Nothing

Yesterday I got to talking with a senior PM about a topic that’s hard to talk about well: what makes someone “strong,” what makes someone “smart.” He gave a lot of examples, all circling around what strong people tend to have — product sense, judgment about information, logic, the knack for making the right call at the right time.

He asked me: “Did you go to grad school? If so, you know research methods, right?”

After I got home, my first rough take was: smart people are probably just easy to understand when they talk. They use frameworks well, so listeners can follow.

And that’s where my thinking stopped.

Then I remembered a fresh-out-of-school PM I met in recent years who was flat-out brilliant, which convinced me that strength has nothing to do with seniority. But what it does have to do with — at first I couldn’t say.

Later I observed another person. I could never figure out why, but everything they said felt slightly off. Or they’d keep tossing out the kind of punch lines I hear on Lenny’s Podcast: tradeoffs, balancing dev effort against the timeline, knowing what not to build matters more than deciding what to build⋯

Sometimes it felt like talking to an AI bot. 聽君一席話，如聽一席話。(A popular Taiwanese internet meme — literally “hearing you speak was like hearing someone speak.” A perfect tautology, and the title of this post.)

So I started untangling it: what is strength in a PM? When do I feel a PM is strong, strong enough that I want to learn from them? A pattern slowly emerged: no matter how far the topic wanders, these people can always come back to the essence. They don’t start at A, drift through B all the way to Z, and end up picking an option that doesn’t solve A.

So that’s the difference: whether this person has spent years building logical thinking and problem-modeling, and whether they have their own framework for taking things apart.

The PMs I’ve met who could grasp the essence of a thing and get up to speed almost immediately, regardless of age, all shared one trait: they’re very good at breaking a problem into shapes they can understand, then knocking the pieces down one by one. The other kind of PM talks beautifully — great English, great delivery — but listen closely and nothing is actually being said.

I used to think the zoning out was my problem. When I drifted off mid-meeting, I chalked it up to poor focus. Looking back now: those “PM maxims” that sound substantive on first hearing all stop at the surface. They never touch the core of the problem.

Have you seen this one?

At one retrospective, engineers complained that the PRD never gets finalized — requirements keep changing mid-development. The PM side’s view was that some edges genuinely can’t be known at PRD time: you don’t know the current state of the underlying systems, or whether interactions with other services will affect the feature, so of course unexpected issues surface mid-development or in QA.

One PM proposed: let’s cut it into a release every two weeks — that should reduce the surprises.

Sounds agile. Sounds like the right answer. But the team already had phases, already did staged development, and the root cause of unstable requirements doesn’t disappear because the cycle got shorter. Cut it up, and those last-minute surprises just get dispensed in smaller installments — same total, plus added regression-testing risk in every QA round. It’s an answer pulled from the agile textbook and force-fitted onto a scene that only looks similar.

A strong PM would have steered the discussion toward how, in the age of AI-assisted development, you fundamentally speed up iteration and quality verification.

Another time, we were discussing a content-delivery feature: cap how many times a given piece of content is shown to the same user. One PM said, to balance dev effort and timeline, let’s just do a frontend cap control first.

Every word in that sentence is right: effort, timeline, tradeoff, start small. But the content needs segmentation, and there are multiple endpoints — mobile native, web. For the cap to stay consistent across endpoints, you inevitably need one piece of server-side state. A frontend cap can’t solve the core requirement from day one. He was speaking perfectly standard tradeoff language, but he hadn’t modeled the system. The result of that “tradeoff”: extra dev effort on top, nothing solved, and phases cut with no logic at all.

Where does talking too much go wrong?

Beyond those incidents, there’s also the person who, in a Slack discussion, replies with an enormous wall of text that somehow doesn’t answer the question, or asks scattered ones.

Writing a lot is cheap — AI can generate piles of it.

(Disclaimer: yes, this post is long, and I typed all of it myself — then had AI translate it into English, because my Chinese is better. Thanks w)

What I’ve noticed is that when a strong PM gets asked something cold, the path is usually “situation → find a framework and build a model → derive the answer from the model.” The weak version runs “situation → fish a similar-shaped answer out of the move library.” Which is why this so often gets misread as a matter of experience. The real difference isn’t experience — it’s the ability to derive. And it compounds: with less experience the move library is shallow too, and the whole thing ends up looking like plain incompetence.

One more thing makes the judgment harder: humans default to using fluency as a proxy for competence. Speak smoothly, with structure, with precise words, and we hand out high marks first. Put a native English speaker across from a non-native one and it’s a rout — the latter can’t quite follow, so they assume the former must be right. You see this constantly in Japanese workplaces.

So when you run into “sounds great, content empty,” you get cognitive dissonance. You genuinely can’t say whether this person is smart or not, because two signals are fighting each other.

Form can be learned. Grounding can’t — not the same way.

I mentioned that some people sum this whole thing up as “experience — do it long enough and you’ll get it.”

I’m not that optimistic. If someone never took anything like Theory of Knowledge early on, never learned what logical fallacies are or how an argument is structured, then studying product-development theory later tends to become learning-as-ritual, and experience doesn’t accumulate either. Like strength training with bad form: the muscle never grows, and you get injured on top of it.

I never went to school in the US, so I asked AI first: American secondary-school critical-thinking classes teach two layers. The first layer is the form of expression — how to organize structure, use sentence patterns, give a paragraph a spine. The second layer is grounding: a claim needs evidence, and you need to be able to say why this evidence supports this claim. The CER framework (Claim, Evidence, Reasoning) common in US middle schools drills exactly these parts separately.

None of this can be memorized as form. You have to be questioned until you’re sick of it — questioned until you’ve already asked yourself before you even open your mouth to propose anything. Same with fact, opinion, inference: it sounds like common sense, but telling them apart in real time in a meeting — “this is what we measured, this is my guess, this is what I inferred from that number” — takes practice.

Writing this, an obvious counterargument occurs to me (punching myself here): does that mean anyone who didn’t take that class as a teenager is doomed? Of course not. I know several people with zero such background and formidable modeling ability — most of them spent years in some environment where they were relentlessly questioned. So maybe what I really mean isn’t the class. It’s whether you’ve been through a period of being interrogated, and that kind of class just happens to be the easiest place for it to happen at scale. This is my conjecture, and I have exactly zero data.

One last thing. I recently started watching Friends over dinner (I had somehow never seen Friends. I know. QQ) and hit the episode where Ross and Phoebe argue about evolution (S2E3). Phoebe keeps pressing Ross: can you be one hundred percent sure? Ross fumbles and has to admit he can’t. Her killer move is swapping “scientific uncertainty” for “weak conviction” — which is itself an epistemological trap. I’m fairly sure the writers were playing exactly this bit, and for the joke to land, the audience has to have met this vocabulary in high school, has to know precisely where Ross lost. A sitcom dared to write that in 1995. I find that genuinely delightful.

So what?

All of this turned out to be a reminder about me, too: I have the say-whatever-comes-to-mind habit, and my chronic jumping-ahead also comes from unstable frameworks. There are two very unglamorous habits I want to build. One: on hearing any proposal, first ask “what are the preconditions for this approach, and under what conditions does it stop holding?” If there’s an answer, keep going; if there isn’t, think hard about whether to proceed at all. Two: ban myself from jumping straight to solutions — first describe the problem itself in three sentences: what’s the current state, what are the constraints, and why does the current state look the way it does. When those three sentences won’t come out clean, none of the downstream solutions are worth comparing.

That includes my own career. I’ve spent too long polishing things in places that can’t scale. If the premise of a thing is that there’s no room to grow, maybe it doesn’t deserve any more polishing.