lilpacy.infoJA
Product Success Hinges on Three Axes: Who x What x With Whom

Product Success Hinges on Three Axes: Who x What x With Whom


TL;DR

The key to product success isn’t “who builds it” or “what to build” — it’s all three of “who x what x with whom.” I disproved the hypothesis that attention is what matters in the AI era and found that track record and trust are the real substrate. Through self-analysis I arrived at a framework: even if you’re weak at problem discovery and articulation, the ability to design “with whom” — recruiting power and a discerning eye for people — lets you route around your weaknesses and lead a product to success.

Background

This article is a logical reconstruction of a dialogue with Claude (Feb 24–26, 2026), distilled into the conclusions I ultimately arrived at. The original discussion started from the two axes “who builds it vs. what to build,” and after counter-arguments and self-analysis, the third axis “with whom to build it” was added.

Let me state the conclusion up front. The framework for thinking about product success has three axes.

  • Who: your own resources, track record, and traits. What strengths and weaknesses you have
  • What: the problem, product, and value you address. Whose pain you solve, and what kind of pain
  • With Whom: co-creators, team, recruiting, orchestration. Who you bring in
graph LR
    A["Who"] --- D["Product success"]
    B["What"] --- D
    C["With Whom"] --- D
    A -.- B
    B -.- C
    C -.- A

Below, I trace the discussion that led to this conclusion.

”Who Builds It vs. What to Build” Isn’t Enough

Starting point: maybe “who” matters more

For most products, “who builds it” matters more than “what to build” — that was the starting point.

A great team can take a mediocre initial idea, listen to user feedback, pivot quickly, and turn it into something good. Conversely, even the most appealing concept will end up half-baked in the hands of a team without execution. The well-known VC line “we invest in teams, not ideas” reflects exactly that intuition.

But “who” and “what” aren’t fully independent. The better the team, the better its judgment about “what to build.” So “who” includes a sense for “what to choose,” and rather than being opposed, “who” may actually subsume “what.”

Attention Is All You Need

A hypothesis emerges. Now that AI lets anyone build products easily, what matters is monopolizing human attention and converting it. “Attention Is All You Need” — a double meaning playing on the Transformer paper title and the attention economy.

When AI dramatically lowers the supply-side cost of products, building itself becomes a commodity. The point of differentiation shifts from “build” to “deliver / get chosen,” and the game becomes one of distribution and attention. Whether you can capture attention depends less on a product’s spec and more on “who” is broadcasting, whose brand it is, whose community it belongs to.

This is the same pattern that already played out in music and content. Once production tools were democratized, just being able to make a song stopped being a differentiator, and being a “someone” with followers and a fan base became the value.

Five Counter-Arguments to the Attention Hypothesis

I pushed back on my own claim. Here are five rebuttals to the “attention is everything” hypothesis.

1. The retention problem

Even if you go viral and get people to show up, if the product itself is weak, they don’t stick. Quibi is the canonical example — built by Hollywood heavyweights, lit on fire with massive marketing, attention captured, but the product itself had no reason for people to keep using it, and it died. Attention is the top of the funnel; conversion and retention depend on product quality.

2. AI commoditization is only “surface deep”

What AI makes easy is the UI / MVP layer. The “invisible” parts at scale — architecture, data pipelines, edge cases, security — are still nowhere near commoditized. The difficulty of “building” hasn’t disappeared so much as relocated.

3. Attention itself can be commoditized

If AI lets anyone build products, AI can also let anyone produce marketing content. If influencer-style broadcasting can be mass-produced by AI, the cost of capturing attention also inflates. The supply side of attention saturates, and it stops being a differentiator.

4. Influencers’ fragility

The “who” advantage is actually fragile. There are remarkably few influencer-built products with long-term success. Fyre Festival is the extreme case, but most celebrity brands fizzle within a few years. Conversely, neither Slack nor Notion had founders with prior public profiles. The product experience itself drove word-of-mouth and grew organically. The active force is the product’s own “do users want to recommend this to someone?” capability — not “who” built it.

5. The scarce thing isn’t attention, it’s trust

In a world flooded with information and products, what people ultimately open their wallets for is trust. Trust isn’t generated by attention volume — it’s generated by a track record of a product keeping its promises. Apple’s new products sell not because they’re noticed, but because past products didn’t betray expectations.

Interim conclusion: Attention is necessary but not sufficient. Even as AI lowers production cost, the difficulty of “actually making something good” persists in changed form.

Integrating Toward “Track Record Is All You Need”

From attention to track record

After the counter-arguments, the discussion converged like this.

“Who” matters → but attention alone isn’t enough → track record builds trust → and the process of building a track record sharpens both “who” and “what” simultaneously

The “who” and “what” that initially looked opposed get unified by introducing the time axis of track record. This is a healthy counter to the “go viral first” / “build an audience first” shortcut mentality. Attention without track record is a castle on sand, and the judgment and trust you only get from accumulating track record can’t be skipped.

You don’t need to be a perfect “who” from the start. Build small, deliver small, accumulate trust small — the speed and frequency of running that loop is what shapes “who.”

Three angles on track record

But “track record matters” is too abstract to act on. There are different kinds of track record.

Track record relative to whom? Users care about an experiential track record: “this product solved my problem.” Investors look for quantitative track record: “this person grew a number.” Peers respond to expert track record: “they pulled off something technically hard.”

Depth vs. breadth. The Stripe founders earned trust in payments through depth, while Elon Musk’s trust at SpaceX is breadth-trust transferred from PayPal — credibility moved across domains.

The track record of failure. Silicon Valley says “founders who failed once are more trustworthy,” but probably it’s not the failure itself — it’s the judgment and integrity displayed during failure that builds trust. Failure-counting alone doesn’t accumulate trust.

The “What I Built Doesn’t Get Used” Problem

Here the discussion turned personal.

When I scroll X, the people who command attention build things that pile up stars, get used, accumulate issues, and improve dialectically through thesis-antithesis-synthesis. I’ve built up my own track record as a CTO, but it feels like that record amounts to nothing — a kind of futility.

After analyzing my motive for wanting attention, the closest fit was attention as a means. Not for validation, but a developer’s desire to run feedback loops on what I build. A product that isn’t used can’t be improved. Without improvement, it doesn’t get better. Without getting better, it doesn’t get used. I want to break that negative loop.

But there’s a leap between “what I built doesn’t get used” and “I have no attention.” Plenty of OSS gets used without attention. Unflashy CLI tools, libraries solving specific niches — people with concrete pain find them via search and start using them.

The problem decomposes into two parts. Is what I’m building actually hitting “the concrete pain of a specific someone”? And am I placing it where the people with that pain can find it?

The structural difference between work and personal projects

I can do requirements gathering as a CTO inside an organization and put out fires on burning projects, but on personal products requirements gathering doesn’t go well. This isn’t an ability problem — it’s a structural one.

  • Work-style requirements gathering: there’s already a customer, the problem is articulated, there are stakeholders and constraints. You search for an optimum within an existing “frame”
  • Personal products: no customer, fuzzy problem, no constraints. Too much freedom — there’s no “frame”

In that state, two traps lie in wait. The start-from-an-abstract-problem trap (“I want to improve developer productivity” — too big to focus), and the start-from-the-solution trap (“I want to build something with this technology” — problem retrofitted afterwards).

Maybe I don’t need to get better at requirements gathering — I need to delay when I start it. I’m starting to write requirements while my problem resolution is still too low.

”Problem Discovery” — the Step Before Requirements

Before requirements gathering comes the step generally called “problem discovery.” Design Thinking calls it “Empathy” + “Define,” Lean Startup calls it “Customer Discovery,” and Christensen’s Jobs to Be Done is the same essence — correctly identifying the problem worth solving.

“I’m bad at sharpening problem resolution” comes in three flavors.

  1. Bad at observing: I don’t notice my own or others’ inconveniences in the first place. I have high tolerance, so daily life flows past as “well, that’s just how it is”
  2. Bad at articulation: I feel the inconvenience but can’t decompose it into “for whom / in what situation / what / why is it painful” and structure it. I’m bad at organizing — my head is constantly cluttered
  3. Bad at taking other people’s perspectives: I understand my own problems, but I don’t go validate whether others share them. As an INTP I’m not the kind of person who actively engages with others, so the opportunities aren’t there to begin with

I’m bad at all three. But trying to “overcome” these probably won’t last. Rather than trying to change personality, it’s more realistic to compensate via systems.

What was suggested: collapse it into one behavior — “observe other people’s complaints.” I don’t need to feel the inconvenience myself. Camp out on programming subreddits, GitHub issues, and Hacker News comment threads — places where other people complain. For an INTP, reading other people’s complaints in text is easier than talking to people directly.

Once a week, take the complaints I find and jot them down in four columns: “who / when / about what / why painful.” Instead of trying to mine problems from inside myself, become a curator who structures external complaints. That fits INTP traits: “good at pattern recognition,” “likes solo analysis.”

Sharpening My Own “Who”

Inventory of traits

INTP + ADHD + high tolerance. That combination structurally makes solo product development hard.

  • Pre-problem-discovery: high tolerance means I don’t notice inconveniences. Even when I do, I can’t articulate or structure them. I don’t go validate them with people
  • Motivation formation: I live with the assumption “other people are smarter than me,” so the conviction “I could do this better” doesn’t arise easily
  • Memory retention: ADHD means I forget ideas as soon as I have them

The “why me?” question

In MBTI cognitive functions, my Fi (introverted feeling) is the 8th and weakest function, so the “why am I the one to build this” perspective is weak. But “why me” doesn’t have to come from Fi-flavored passion or sense of mission.

There’s a Ti-flavored “why me.” “The existing solution is logically wrong. The right approach is this. Nobody is doing it, so I will.” That’s not passion — it’s motivation born from intellectual intolerance for inconsistency, and for an INTP this is the more authentic fuel.

Linus Torvalds didn’t build Linux from Fi-style motivation. It came from intellectual dissatisfaction with existing OSes — the logical conviction “this should be better.”

That said, honestly, as an INTP who’s been a CTO, the moments where I think “why is everyone doing this so irrationally?” are surprisingly rare. I have the prior that other people are smarter than I am, plus ADHD ensures I forget most thoughts I do have.

Validation against external information

I checked the self-analysis against external information. My tech-stack history (Ruby → Elm → Scala → TypeScript → Go → Python → Solidity) shows abnormal pace, while bringing each domain to production level. On GitHub, 173 repositories — but stars are nearly zero. Lots of boilerplate / template repos. That’s the tangible form of “what I built doesn’t get used.” Boilerplate is “I built it because it’s convenient for me,” not “this solves someone’s strong pain.”

The substance of success: contribution as an implementer

Initially the analysis pegged my strength as “ultra-fast full-stack execution × wave-riding instinct,” but a key correction came in.

  • A certain NFT project (1,024 pieces in 2 weeks of solo dev, sold out via collaboration) → the co-founder did business development and requirements
  • A set of DeFi projects (TVL on the order of millions of dollars) → the then-representative did business development and requirements

I just implemented. I didn’t have wave-riding instincts — I just had a vague ability to judge who to follow.

In other words, the substance of past successes is “choosing the right person and high-speed-implementing their instructions.” Not wave-riding instinct, but a “whose ship to board” instinct. And “build something with finalized requirements” is the area AI is best at, so this strength’s shelf life is short.

A Hidden Strength: Recruiting Power and “With Whom”

Recruiting as a weapon

A key piece of information surfaced near the end of the discussion. A certain executive once told me, “I’ve seen many great engineers, but I’ve never seen an engineer who can recruit.”

I’d been saying “INTP, bad at people,” but I can recruit — and that’s not a contradiction. Recruiting isn’t small talk or socializing; it’s the structural judgment of “assess this person’s abilities and place them in the right position.” INTP’s Ti (analysis) and Ne (seeing possibilities) are fully engaged. The shape of my interpersonal capability isn’t socializing — it’s appraising.

Reorganizing the essential strengths:

  • An eye for people (whose ship to board, who to recruit)
  • Ability to bring anything to a working level
  • Abnormal endurance

The missing third axis

So far the discussion only had the “who builds it” vs. “what to build” opposition, and the “with whom to build it” perspective was missing.

Anime brings in famous voice actors. VTubers bring in famous illustrators — bringing multiple people in is itself promotion. Bringing in influential engineers and designers is itself attention. If notable contributors are on a GitHub project, that alone increases trust and visibility.

What’s more, this approach routes around almost all of my weaknesses.

  • Bad at problem discovery → bring in someone with deep problem expertise
  • No distribution → bring in someone with followers; that itself is distribution
  • Bad at articulation → bring in someone with broadcasting power
  • Weak Fi-style motivation → stand next to someone with strong motivation

The pivot foot is “orchestrator” — but the essence isn’t implementation orchestration, it’s people orchestration. Find the right people, woo them, combine them, and fill in the gaps with my implementation. A position as “the person who designs with whom,” distinct from “who” or “what.”

This position doesn’t get displaced by AI. AI can implement, but it can’t appraise people and woo them.

The Final Framework

Three options

The discussion surfaced three career paths.

  1. Master “the person next to”: rather than being the implementer, become “the orchestrator combining the right people and the right AI”
  2. Aim for “who” but with a partner: team up as equals with a partner who covers your weaknesses
  3. Seriously aim for “who”: fight against your traits across the board — by far the most expensive option

The choice: pivot foot on 1, while extending toward 2 and 3.

One-point-breakthrough growth area: articulation

Among the weaknesses, the highest-leverage one is articulation. Becoming able to articulate produces three downstream effects.

  • Problem discovery improves (you can structure what you observe)
  • Distribution improves (you can communicate to people)
  • Recruiting power improves further (you can speak vision)

“Increase frequency of human contact” or “raise sensitivity to inconvenience” are personality changes — bad ROI. Use articulation as a single-point breakthrough that propagates everywhere.

The most accessible way to train articulation is to make a habit of bouncing your thinking off others (humans or AIs) to organize it. I’m bad at generating ideas alone but good at sharpening thinking through dialogue. The dialogue this article was born from is itself the proof.

Execution framework

The framework I ultimately landed on is simple.

flowchart LR
    A["Find someone with\nstrong purpose"] --> B["Design the missing\npositions"]
    B --> C["Find and woo the right\nperson for each position"]
    C --> D["Fill the remaining gap\nyourself"]

In structure this is the same thing I’ve been doing as a CTO. The difference is that instead of doing it passively inside an organization, I choose “whose ship to board” by my own intent. And the eye for that choice exists.

From “first follower” to “who”

This connects to Derek Sivers’ first follower idea: but the path “succeed economically as a first follower, then become ‘who’” doesn’t really work. Money doesn’t automatically grant you problem-discovery skill or strength of motivation.

That said, “the eye for choosing whose ship to board” is itself an ability that can make you a “who.” Angel investors and VCs are exactly that: they don’t build products themselves, but they become “who” by their power to choose “who to bet on.”

Maybe the path to my own “who” is “becoming known as the person who chooses first followers.”


This article is itself an exercise in articulation as a single-point breakthrough. Bounce thinking off an AI, demand counter-arguments, integrate, structure. The “Who x What x With Whom” three-axis framework came out of that process.

That’s all.

References