Observed-Behavior Evolution Loop
Release lessons, watch real use, and rewrite where behavior exposes friction
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 99%
The Observed-Behavior Evolution Loop treats development as evolution rather than a school test with one correct answer. Convert the work into something representative users can actually engage with, then watch what they do. Do not rely only on asking whether they like it; observe confusion, repetition, completion, abandonment, and unexpected use. Revise the underlying work where behavior exposes friction, preserve what users successfully adopt, and run the loop again. This shifts attention from cooking an artifact until it feels perfect to engaging with the surrounding system and discovering what it will embrace. The output improves through selection grounded in use, not through creator certainty.
Origin
Before publishing This Is Strategy, Godin made 44 video lessons and watched 300 community members use them.
Core principles
- 01Use reveals problems opinions may miss
- 02Confusion is evidence for revision
- 03What works gets repeated
- 04Engagement with the system beats polishing in isolation
How to run it
- 1
Build usable units
Create an early form that exposes the core ideas or functions to real use. Keep each unit observable.
Pro tip Match units to the sections you expect to revise.
Watch out A description of the product does not generate the same evidence as use.
- 2
Recruit representative users
Invite people from the intended audience to engage in a realistic context.
Pro tip A committed small group is more useful than a broad unmotivated sample.
Watch out Friends trying to be supportive can distort the signal.
- 3
Watch behavior
Observe where people pause, misunderstand, repeat, complete, or abandon. Record the behavior before interpreting it.
Pro tip Let users encounter friction before explaining the intended path.
Watch out Do not replace observation with a generic satisfaction question.
- 4
Rewrite the friction
Change the relevant section, flow, or instruction where observed behavior shows confusion. Preserve the parts users navigate successfully.
Pro tip Tie each revision to one observed failure mode.
Watch out Do not overhaul sections that produced no evidence of a problem.
- 5
Repeat the selection
Return the revised work to use and continue repeating what works while removing what fails.
Pro tip Track whether the targeted behavior changes after revision.
Watch out Iteration without a measured behavior becomes random churn.
In the wild
Godin translated sections of his draft into 44 lessons, offered them to 300 members of his online community, and watched their interactions. When participants became confused, he rewrote the corresponding book sections.
→ The manuscript became clearer through observed use rather than requested opinions.
Common mistakes
Asking only for feedback
People's opinions can miss the exact point where their behavior shows confusion.
Polishing before contact
Perfection in isolation delays the evidence needed to know what the system will embrace.
Is it for you?
Best for
Creators and product teams able to expose an early version to representative users.
Not ideal for
High-risk releases where unvalidated exposure could cause irreversible harm.
From the transcript
“things that work get repeated and things that don't go extinct”
“I didn't ask them for feedback I watched them use it”
From the episode
Seth Godin: How to Build a Business Strategy That Actually Works
Seth Godin