# Technical Founder Trap #concept #positioning #marketing ## Summary Technical founders are excellent at **solving** problems and poor at **explaining** how they solve them — and the explaining is what sells. *"You and I are the same guy — software people, systems thinkers. 'Give me your problem and I'll go.' You don't want to explain, you just want to do it."* ([[dan-martell]], [[2026-07-20-referrals-will-sink-your-business]]). The claim is that this single gap is upstream of a technical founder's marketing failure: not laziness, not the wrong channel, but the absence of a communication skill they never had to build. `Status: tentative` — one source asserts the mechanism with no data — but it connects several existing pages that were describing the same disease from different sides. ## Current Understanding **The mechanism.** Solving and explaining are different skills, and a technical career selects hard for the first while never testing the second. The founder's instinct — *give me the problem, I'll go* — is precisely what makes them valuable in delivery and invisible in market. The source's claim is sequencing: **communication is the unlock**, and only after it exists do the paid channels work, "because you now have something to say and know how to say it." Publishing is therefore proposed as *practice*, not just distribution — the stated reason for going live daily is to get reps at explaining ([[marketing-system]]). **The same failure, seen from the buyer's side.** [[dmitry-rodenko]]'s central diagnostic says *"'expensive' doesn't exist — 'I don't see what for' does"* ([[pricing-from-value]]). That is this concept restated as a symptom: when a buyer can't see what the money is for, the usual cause is not that the value is absent but that it was never articulated. Two unconnected traditions — a US founder coach and a Russian-language dev-sales practitioner — land on the same point from opposite ends of the transaction. That convergence, not either source alone, is the reason to take this seriously. **Why it compounds with the rest of the vault.** Nearly every asset the vault tells a developer to build is *articulation-dependent*: - [[methodology-as-moat]] — a proven method you cannot describe is not a sellable asset; "people buy your standards" presumes the standards are legible. - [[outcome-based-selling]] — selling a countable outcome instead of hours *is* an act of explanation; the outcome has to be named before it can be priced. - [[information-vs-implementation]] — the content mandate is literally "explain what you do"; its 5×10×4 factory is a machine for forcing the reps. - [[pain-discovery]] — the standard is naming the buyer's pain *better than they can name it themselves* ("how do you know?"). That is an explanation skill aimed at their world rather than yours. - [[productized-service]] — fixing scope, price, and **name** is packaging, i.e. explanation crystallized into an offer. Read together: the vault's whole selling chain assumes an articulation capability it never asks whether the reader has. This page is where that assumption is made explicit. **The product-startup form of the same trap — feature #26 syndrome** ([[2026-07-26-how-to-build-a-billion-dollar-company-2027]], [[oskar-hartmann]], added 2026-07-26). His live example: an AI startup's team is building the 26th feature in Jira while revenue sits below 1M ₽/month — "the most valuable thing right now is not feature #26, it's a repeatable go-to-market." Same disease, different symptom: Martell's founder can't *explain*, Hartmann's founder *builds instead of selling* — both are the technical instinct ("give me the problem and I'll go") consuming the hours that selling needs. Hartmann's paired rule — the founder is the company's chief salesperson, no exceptions, and he won't invest otherwise ([[sales-discipline]]) — is the blunt behavioral fix where Martell prescribes the skill-building one (reps at explaining). A third tradition independently locating the constraint *outside* the building work strengthens the page's core claim more than another coaching source would. No framework is offered — the remedy is reps at explaining in public (answer questions, add value, explain what you do), measured as reps rather than views. See [[marketing-system]] and [[sales-discipline]]. ## Evidence - The trap, the "same guy" framing, and communication-as-unlock — [[2026-07-20-referrals-will-sink-your-business]], [[dan-martell]] (single source for the concept as stated) - *"'Expensive' doesn't exist — 'I don't see what for' does"* (the buyer-side symptom) — [[2026-06-15-rodenko-selling-development-expensively]], [[pricing-from-value]] - "Explain what you do" as the content mandate, and a factory for practising it — [[2026-07-18-information-is-free-implementation-is-paid]], [[information-vs-implementation]] - Name the pain better than the buyer can — [[pain-discovery]] - Feature-#26 syndrome; founder-as-chief-salesperson as the behavioral fix — [[2026-07-26-how-to-build-a-billion-dollar-company-2027]] ([[oskar-hartmann]], independent tradition) - Slogan-grade restatement of the build-instead-of-sell form: stated audience is "developers who over-invest in building and under-invest in selling," blocker diagnosed as psychological, not technical — [[2026-07-29-start-a-business-with-claude-code]] ([[dan-martell]], attributed 2026-07-29 — same author as this page's founding source, so restatement, not corroboration) - Adjacent, from the labor-market side: value migrates to judgment and client-facing ownership, both articulation-heavy — [[product-ownership]], [[future-of-engineering-work]] ## Related Pages - [[marketing-system]] — the source's prescribed cure (publish for reps); this page is its diagnosis - [[information-vs-implementation]] — what to actually say once you can explain - [[pricing-from-value]] — the buyer-side symptom ("I don't see what for") - [[methodology-as-moat]] — an inarticulable method is not a moat - [[product-ownership]] — owning an outcome requires being able to state it - [[eugene]] — the vault's resident technical operator, whose stated blocker this reframes - [[overview]] ## Contradictions / Uncertainty - `Status: tentative`. **Single source, asserted not demonstrated**, and self-serving: a coach who sells communication-heavy programs diagnosing communication as the bottleneck. No data, no counterfactual, no failed cohort. - **[[sebastian]] offers a rival diagnosis of the same symptom.** If a technical founder isn't winning work, Sebastian's answer is not "you can't explain" but "you have no in-person relationships" — the fix is recurring physical presence, not better articulation ([[relationships-as-moat]]). These are genuinely different causal claims about the same observation, and the vault has no evidence to choose between them. They are not exclusive: trust may be necessary and articulation sufficient, or vice versa. - **Possible reverse causation.** "Can't explain it" may be downstream of not having a [[niche-selection|chosen niche]] or a repeatable [[productized-service|package]] — you can't explain a service that isn't yet a definite thing. Under that reading the fix is offer clarity, not communication practice, and the vault leans that way elsewhere ("category = pain + result"). - **The convergence argument is weaker than it looks.** Rodenko's "I don't see what for" is about a *specific* sales conversation; this source's claim is about a founder's *general* market invisibility. Same theme, different scope — treat the convergence as suggestive, not confirmatory. ## Next Questions - Is the bottleneck articulation or offer definition? A cheap test: can the founder state the outcome, buyer, and price in one sentence? If yes, the problem is distribution; if no, it's [[productized-service]], not this page. - Does publishing actually train explanation, or only train *performing* explanation for a feed? The two may diverge for B2B services sold in private conversations. - For [[eugene]] — a computer-vision/embedded developer whose stated blocker is building a network — is the missing skill really networking, or the ability to say what he does in a sentence a non-engineer repeats to someone else? (That second form is also what makes a [[referrals|referral]] transmissible.)