Clarity and Conviction: Insights, Strategy, Big Rocks
The whole craft of PM in two words, expressed as a two-page narrative every team can recite.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 6
- Confidence
- 94%
Atawodi defines product management as clarity plus conviction. Clarity is the sifting-out of everything polluting the core problem; conviction is the felt sense of how the world should be, held firmly enough to pick a lane. The artefact that carries both is a two-page written narrative — insights, strategy (approach), big rocks — that precedes the roadmap and answers why we exist, how we'll get there, and what we'll do.
Origin
Ebi Atawodi's own formulation, sharpened at Uber, Netflix and YouTube. She credits the write-don't-deck discipline to a former engineering manager, Gergely Orosz (author of The Pragmatic Engineer). The 'big rocks' metaphor and the write-first culture echo Amazon and Netflix practice.
Core principles
- 01Clarity is the simplicity of understanding — sifting out everything polluting the core thing.
- 02Conviction is a feeling of how the world should be. It is not certainty, not absolute, not perfect.
- 03Clarity comes when you write. Fancy decks are not clarity.
- 04Big rocks first, sand after — if you asked for a cocktail you'd put the ice in before pouring the drink.
- 05Don't peanut-butter resources. Nobody does anything well by spreading thin.
- 06There is an informed captain for every decision — one owner, not six people with consensus.
How to run it
- 1
Establish clarity — the problems
Produce a crisp, evidenced, stack-ranked set of problems (see Top 10 Things You Should Know). Clarity means someone can read your email or your doc and know exactly what is being asked and why it matters.
Pro tip Clarity saves cycles: it lets you say 'we all know that's a problem, we don't need foundational research here — do UX validation later instead'.
Watch out If people read your work and ask 'what do you want me to do?', you have not brought clarity.
- 2
Write the narrative as a two-pager
Write — do not deck — a two-page (four at most) document with three sections: Insights, Strategy (or 'approach'), and Big Rocks. Treat it as a startup pitch: what big problem do you solve, what's the strategy, what will you deliver that would end up in the future headlines, and why do you need the resources.
Pro tip Give it a short-link (go/<team>-narrative). When someone asks for an intro meeting, send the narrative first — many calls simply fall off, and the rest start smarter. It's also the onboarding doc for new joiners.
- 3
Keep the big rocks to three to five
Big rocks are not a laundry list of twenty items. They are the three, four or five things that, if landed, most move you toward solving the problems. Everything else is the sand you pour in around them.
Pro tip Test: can anyone on the team remember them without looking?
Watch out An endless roadmap is pouring the drink before the ice — it splashes and it's messy.
- 4
Force conviction by removing the options
Stress-test the team draconically: if I took away all your resources and you could only build one of these, which is it? Whatever the answer, that is where conviction lives. Where the answer makes them uncomfortable, that discomfort marks the exact place to spend research cycles.
Pro tip When someone brings you two options with pros and cons and no recommendation, ask: if leadership weren't in the room, which one does the team want? Then send them away to do the work.
Watch out Do not let people outsource the pick to you. It is too easy to bring the leader two options — and it will not make them a better PM.
- 5
Name the informed captain, then convert the narrative into a roadmap
For each decision, name the single person on the hook — the informed captain — who gathers all the context and input and decides. Then unpack the big rocks into a roadmap (a sheet of items with resources assigned) and surface the blocks.
Pro tip Atawodi's heuristic: fewer than three engineers on a problem, consolidate it; more than three, it earns its own line on the roadmap.
Watch out Consensus by committee is not a decision. One person owns it and is empowered.
- 6
Refresh the narrative, hold the vision
The narrative is an evergreen doc refreshed quarterly or half-yearly as the world and the problems change. The vision behind it should last at least three years.
Pro tip Version the doc (2022 version, 2023 version) rather than starting a new one — the short-link stays memorable.
In the wild
Each team under Atawodi took the overarching vision, brought it to life for their own area, listed their problems, wrote their strategy/approach and big rocks, and produced a two-page narrative. They circulated it to their engineering partners for feedback, then used it to build the roadmap — a Google Sheet of items with resources assigned — applying the three-engineer consolidation rule.
→ A planning cycle where the roadmap is derived from a written narrative every partner has read and commented on, rather than assembled bottom-up from requests.
A team brings Atawodi a doc with two scenarios and the usual pros and cons, asking her to pick. She asks which one the team would choose if leadership weren't in the room — and often finds they haven't even done the work of debating it among themselves.
→ She sends them back to do the work; if they reach conviction but see risk, the conversation shifts to mitigating the risk, not choosing for them.
Common mistakes
Program-managing instead of product-managing
Relaying what engineering said can't be done and what UX said they could do is not the job. The job is bringing clarity and curating the problems together.
Peanut-buttering because you're scared to pick a lane
Spreading resources thinly across everything is a symptom of absent conviction. Nobody does anything well when resourced this way.
Hiding behind a fancy deck
Clarity comes when you write. A beautiful deck can conceal a muddled argument that a two-page prose document would expose.
Sending an email whose purpose is unreadable
If the recipient can't tell whether it's an FYI, a problem statement or an ask, you've failed the most basic clarity test of the role.
Is it for you?
Best for
PMs and PM leaders who want a single operating definition of the craft plus the concrete artefact (the two-page narrative) that operationalises it before roadmap season.
Not ideal for
Organisations with a strong deck-and-consensus culture where a written, opinionated two-pager with a named decider would be politically rejected without groundwork.
From the transcript
“I use I sort to say Clarity and conviction and that's what product management is it's like you bring clity and you have conviction”
“clarity comes when you write and so I made them write two page documents”
“if I asked you to make me a cocktail you would put ice in first then you would pour the drink you would not put…”
“definition of conviction is a feeling of what you think the way the world should be it's a feeling it is not certainty it is…”
“what if I took away all your resources and you only have five which is the one you're going to build”
“don't peanut butter like nobody does anything well by peanut buttering resources spreading them thin”
“if you have more than three Engineers on it less than three Engineers on a problem consolidate more than three it needs a line”
From the episode
Crafting a compelling product vision
Ebi Atawodi (YouTube, Netflix, Uber)