Blocked Projects Create Buyers
People buy when an important project is blocked. The winning product does not ask them to admire a capability; it removes the specific work, tokens, speccing, coordination, or implementation burden standing between them and the outcome.
Thesis
Most buyers do not wake up wanting another tool. They buy because a project they already care about is stuck. The stuckness can be visible, like a migration that never finishes, a backlog nobody can clear, or a sales workflow that takes days. It can also be invisible, like model-token cost, prompt speccing, integration glue, unclear ownership, or the emotional drag of deciding where to start. Source: User, 2026-06-29
The practical sales rule: find the blocked project and sell the unblocking. If the buyer is buried under work and the product says "here is a dashboard to manage the work," that is weak. If the product says "we will finish the work, absorb the annoying parts, and hand you the result," that is the wedge.
The Mechanism
A blocked project has already passed the first test: the buyer cares enough to notice the pain. That is very different from selling a speculative improvement. The buyer does not need to be convinced that the outcome matters; they need to believe this path gets them unstuck faster than their current plan.
The blocker is often not the core task. It is the surrounding sludge:
| Blocker | What the buyer feels | Strong offer |
|---|---|---|
| Too much work | "I know what should happen, but nobody has time." | Done-for-you execution or agent-run delivery. |
| Too many tokens | "This is possible, but the cost/latency/context budget is annoying." | Efficient orchestration, batching, caching, and bounded loops. |
| Too much speccing | "I do not know how to turn the idea into runnable steps." | Opinionated defaults, templates, examples, and generated plans. |
| Too much integration glue | "Every tool works alone, but not together." | Pre-wired workflows and maintained connectors. |
| Too much risk | "If this breaks, I own the mess." | Verification, rollback, observability, and vendor-owned support. |
This is the business side of Services-as-Software: sell the outcome because the outcome is what clears the blocked project. It also explains why Long Live Hard SaaS remains true. People pay vendors to absorb product time, bug hunting, maintenance, integrations, and the hidden work that keeps the project moving.
What to Sell
The highest-converting framing is not "we have agents" or "we have a better platform." It is:
- Name the stuck project.
- Name the blocker in the buyer's language.
- Show the shortest path from blocked to done.
- Prove you own the annoying middle.
- Price against the value of unblocking, not the internal cost of your tool.
This is why good demos start with a real job, not a feature tour. The buyer should recognize their stalled project in the first minute.
What This Changes
For ideation, do not ask only "is this useful?" Ask "what project does this unblock?" A useful feature without a blocked project becomes a nice-to-have. A mediocre-looking workflow that unblocks a painful project becomes budget.
For positioning, replace generic capability language with blocked-state language. "AI workspace for teams" asks the buyer to imagine. "Clear the 300-repo dependency upgrade backlog without assigning engineers" names the project and the pain.
For product, build the missing middle. If the buyer is blocked by speccing, ship templates and plans. If blocked by confidence, ship proof and rollback. If blocked by tokens, ship cost controls. If blocked by orchestration, ship the loop.
Failure Modes
- Selling capability instead of relief. The buyer hears "more work for me to understand."
- Solving a fake blocker. If the project is not already important, removing friction does not create urgency.
- Handing back the hard part. A product that still requires the buyer to spec, glue, supervise, and verify has not unblocked the project.
- Pricing like a tool when selling an outcome. If the buyer is buying a finished project, price against the value of being unblocked.
- Ignoring trust. The more work you absorb, the more proof you owe. The buyer has to believe you can own the middle without creating a new mess.
Agent Implication
When an agent researches a product, market, or launch angle for Kevin, it should identify the blocked-project wedge explicitly:
- Who is blocked?
- What project is blocked?
- What exact work, risk, speccing, token, or integration burden blocks it?
- What would count as unblocked?
- What proof would make the buyer trust the offer?
If those answers are vague, the idea is not ready to sell.
Timeline
- 2026-06-29 | Kevin articulated the sales philosophy: people buy when a project is blocked, especially when blocked by too much work, token cost, speccing, or integration burden; the winning offer removes the blocker instead of asking the buyer to do more. Source: User, 2026-06-29