# Audience Transformation Positioning

> Define the reader/customer avatar, painful current state, desired outcome, transformation bridge, objections, and proof needed before writing profile copy, posts, articles, landing pages, or visual concepts.

- Skill: `arthurzakirov/audience-transformation-positioning` (Agent Skill)
- Install (CLI): `npx skillmds@latest add arthurzakirov/audience-transformation-positioning`
- Raw SKILL.md: https://api.skillmd.com/api/skills/arthurzakirov/audience-transformation-positioning/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: ArthurZakirov (https://skillmd.com/u/arthurzakirov)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/arthurzakirov/audience-transformation-positioning

---


# Audience Transformation Positioning Skill

## 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:

```text
current painful situation → bridge/mechanism → desired situation
```

The text must make the reader feel:

```text
"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:

```text
I help [audience] move from [painful current state] to [desired outcome] using [specific mechanism].
```

Examples:

```text
I help engineering teams turn messy manual processes into adopted automation systems using data, software, and agentic AI.
```

```text
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:

```text
If you read this, you will understand how [unexpected result] happened despite [constraint].
```

```text
If you read this, you will learn a repeatable way to move from [current pain] to [desired outcome].
```

```text
If you use this, your team can reduce [pain] and achieve [result] with [mechanism].
```

## Output format

Before drafting, produce this map:

```markdown
## 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