Use this when
Use this skill before writing any asset where persuasion or attention matters:
- LinkedIn About sections
- profile headlines
- article introductions
- YouTube/video hooks
- landing-page sections
- project README positioning
- portfolio pages
- banner or article-header concepts
- offer descriptions
Core principle
People read only when they believe reading will benefit them.
Before writing, define the reader's transformation:
current painful situation → bridge/mechanism → desired situation
The text must make the reader feel:
"This person understands my problem and may have a useful way out."
Step 1 — Define the reader/avatar
Answer:
- Who is likely reading this?
- What are they trying to decide?
- What problem, fear, deadline, risk, or desire is active in their mind?
- What are they already searching for?
- What would make them stop scrolling or keep reading?
Common reader types:
- recruiter
- hiring manager
- senior engineering leader
- founder
- technical peer
- potential user of a project
- reader of a post/article
- buyer of a service/product
Step 2 — Define the painful current state
Make it concrete. Avoid abstract pain.
Good current-state examples:
- too much manual work
- unclear requirements
- missed deadlines
- costly bottlenecks
- AI demos that never become adopted systems
- engineers overloaded by repetitive operational work
- hiring uncertainty: unclear who can actually create value
- a tool exists, but users still cannot achieve the outcome
Ask:
- What is frustrating right now?
- What is expensive right now?
- What feels risky right now?
- What is slow, confusing, manual, brittle, or invisible?
Step 3 — Define the desired outcome
The desired outcome should be what the reader actually wants, not merely what the creator wants to talk about.
Good desired-state examples:
- hit deadlines
- reduce manual load
- make the system reliable
- get leadership buy-in
- make users adopt the tool
- make work measurable through KPIs
- turn vague requests into shipped outcomes
- avoid wasting effort on the wrong solution
Step 4 — Define the bridge
The bridge is the mechanism that moves the reader from current state to desired state.
The bridge should not be a buzzword. It should be a believable process, framework, tool, or capability.
Good bridge format:
I help [audience] move from [painful current state] to [desired outcome] using [specific mechanism].
Examples:
I help engineering teams turn messy manual processes into adopted automation systems using data, software, and agentic AI.
I turn messy operational context into reusable automation capabilities.
Step 5 — Identify objections and risks
The reader may object:
- Is this just hype?
- Does this generalize beyond one lucky case?
- Can this person do it in my stack/domain?
- Is this only a demo, or did people adopt it?
- Does this require too much effort from my team?
- Is AI safe enough for this workflow?
- Are the results measurable?
Address objections with:
- numbers
- proof examples
- scope boundaries
- clear mechanism
- adoption evidence
- before/after comparison
- risk reversal or low-friction next step
Step 6 — Choose the promise
Every asset needs a promise.
Templates:
If you read this, you will understand how [unexpected result] happened despite [constraint].
If you read this, you will learn a repeatable way to move from [current pain] to [desired outcome].
If you use this, your team can reduce [pain] and achieve [result] with [mechanism].
Output format
Before drafting, produce this map:
## Reader
- Primary reader:
- What they want:
- What they fear:
- What they are deciding:
## Current Situation
-
## Desired Situation
-
## Bridge / Mechanism
-
## Objections
-
## Proof Needed
-
## Core Promise
-
Quality bar
Strong positioning is:
- reader-centered
- concrete
- benefit-driven
- emotionally legible
- grounded in proof
- connected to a mechanism
Weak positioning is:
- generic
- self-centered
- full of buzzwords
- focused on tools instead of outcomes
- missing the reader's pain
- missing why the reader should care