# Ideas Aren't the Work *The idea isn't the work. The translation is the work, and you keep skipping it.* # Ideas Aren't the Work *The idea isn't the work. The translation is the work, and you keep skipping it.* ![[HERO] Ideas Aren't the Work](https://cdn.marblism.com/p2A0tMDXFuS.webp) Open your Notes app. Scroll past the grocery lists. Past the Tuesday parking-spot reminders. Past the half-written gym routine. There they are. Forty-three of them. The "actually this could be a business" entries from 2022. The "we should do this at work" notes from your last all-hands. The 11pm voice memo titled "PRODUCT IDEA — listen tomorrow." The April 2024 sketch of a system that would have changed how your team operated, if anyone had ever seen it. You have ideas. You have, by any honest accounting, more good ideas than the founders who shipped the products you use every day had at the same age. They shipped. You didn't. The gap isn't talent. The gap isn't time. The gap is that you have not, with any of those forty-three ideas, done the part of the work that turns an idea into a thing somebody else can argue with. You've held them in your head, where they feel real. You've described them to your partner over dinner, where they feel reasonable. You've sketched them on a napkin, where they feel close. You haven't written them down in a way that another person could read, criticize, and decide to build with you. That's the work. You skipped it forty-three times. ## What Amazon made mandatory In 2004 Jeff Bezos sent a one-paragraph memo to the senior team at Amazon. It is now one of the most-quoted internal documents in American business. "PowerPoint-style presentations are no longer permitted in S-team meetings. Instead, the person presenting will write a six-page narrative memo. We will sit silently for the first 30 minutes of the meeting and read it. Then we will discuss." The memo created a culture. By 2010, no major decision at Amazon was made without a six-page narrative document attached to it. By 2015, the practice had extended to a specific document type called the PR/FAQ — a fictional press release announcing the product as if it had already shipped, plus a frequently-asked-questions document covering everything that could go wrong. Every product proposal at Amazon, from a feature on the cart page to a launch like AWS, started as a PR/FAQ. In 2021 two former Amazon executives, Colin Bryar and Bill Carr, published *Working Backwards*. The book is the closest thing to a manual on the practice. The argument they make, supported by 27 years between them inside Amazon, is that the PR/FAQ is the actual work. The PR/FAQ forces clarity. You cannot write a coherent press release about a product whose value proposition is fuzzy. You cannot answer the FAQ about a product whose risks you haven't considered. The document itself becomes the test. If the document is bad, the idea is bad. If the document is good, the team has aligned without a single meeting. Most senior operators have never written a PR/FAQ for any of their forty-three notes-app ideas. The reason isn't laziness. The reason is that the idea feels real enough in their head that they don't believe the document would change anything. It would. It always does. That's the point. ## What Paul Graham named in 2009 In July 2009 Paul Graham published an essay called "Maker's Schedule, Manager's Schedule." It is now read at every YC batch and quoted on every founder Twitter feed. The argument is short. There are two kinds of working time. Manager time runs in 30-minute or 1-hour blocks. Maker time requires uninterrupted half-day blocks. The two kinds of time are not interchangeable. A single 1pm meeting can destroy an entire afternoon of maker work, because makers can't switch back into the deep focus they were in. The essay is usually cited to defend a calendar-blocking practice. The deeper read is more interesting. The translation step — turning an idea into a written document somebody else can argue with — is maker work. It requires four uninterrupted hours. It requires the kind of focus you can only get on a Saturday morning before the first kid wakes up, or a Tuesday between 8am and noon if you've genuinely cleared your calendar. Most senior operators are running on a manager's schedule. They have 19 meetings a week. They have a calendar covered in 30-minute slots. They have answered Slack inside of every gap. They are, by Graham's definition, structurally unable to do maker work. The PR/FAQ never gets written. Not because the operator can't write. Because the operator has not protected a single 4-hour block on the calendar in three months. The forty-three ideas don't die because they're bad. They die because they never get the maker block they would have needed to become a document. ![A pink train in the dirt illustrating an idea without supporting infrastructure.](https://cdn.marblism.com/OeJqEMlTIFs.webp) ## What Eric Ries named in 2011 Eric Ries published *The Lean Startup* in 2011. The book sold a million copies, started the lean-startup movement, and made one specific concept the standard vocabulary of every product team in the world. Ries called it the *leap-of-faith assumption*. Every business idea, no matter how clever, is held together by two or three assumptions that, if false, kill the entire thing. Most founders fail because they spend their first six months building the *product* before they test the *assumptions*. They build the thing they hope works. They never run the experiment that would tell them whether the thing they hope works actually does. Ries's framework, build-measure-learn, exists to surface the assumptions and test them in the smallest possible experiment before scaling. The whole methodology is structured around an obvious-in-retrospect observation: an idea in your head has zero falsifiability. You cannot disprove an idea you haven't written down. You cannot test an assumption you haven't named. The translation step — writing the idea down in a way somebody else can read it — is also the step that exposes the leap-of-faith assumptions. Once it's on paper, the assumptions are visible. Once they're visible, you can test them. Once you test them, you know whether the idea is real. Stay in your head and you protect the idea from being tested. That feels like protecting the idea. It's actually the thing that kills it. ## Three rules that turn ideas into shippable things You don't fix this with a better Notes app. You fix it with three rules that make translation a non-negotiable step. **1. The two-page rule.** No idea graduates from the Notes app to the project list until you've written a two-page document about it. Page one: what is this, who is it for, what changes for them, what does it cost to build. Page two: what are the three assumptions that have to be true for it to work, and how would you test the cheapest one in 7 days. Most ideas die at page one. That's the whole point. **2. The Saturday block.** Pick one Saturday morning a month. Six hours, alone, no laptop screens unless you're writing. The agenda is one item: turn one notes-app idea into a two-pager. Most senior operators have not protected a six-hour creative block in over a year. The block itself is the rare resource. Without it, no PR/FAQ ever gets written, and no idea ever leaves the head. **3. The 7-day experiment.** Once a two-pager exists, the next move is the smallest possible test of the cheapest assumption. Not a build. Not a launch. An experiment. Run a landing page. Send 10 cold emails. Build a Loom describing the product. The 7-day experiment is what proves the idea is real. Most ideas die at this step too. That's also the point. If you want a second voice in the room when you do all three, that's exactly what a [Build Partnership](https://www.unstuckwithmolly.com/work-with-me/build-partnership) is for. ## The reframe You don't have an idea problem. You have a translation problem. Forty-three of them. They've been in your head for years, where they feel real, and the reason they haven't shipped is that you haven't done the boring writing step that would expose them to reality. You don't need more ideas. You need to write one of them down, on paper, for another person to read, with the assumptions named and the experiment designed. Pick the oldest one in the Notes app. Block six hours next Saturday. Write the two pages. That's where it starts. That's also where, almost always, it ends. And that's what makes it real. ![Hands installing infrastructure to secure delivery — a builder, a document, a single block of time.](https://cdn.marblism.com/PLNEBfn_G2_.webp) ## Sources - [Colin Bryar & Bill Carr, *Working Backwards* (2021)](https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets/dp/1250267595) — chapter 4 on the six-page narrative memo and the PR/FAQ practice at Amazon - [Paul Graham, "Maker's Schedule, Manager's Schedule" (July 2009)](http://www.paulgraham.com/makersschedule.html) — the foundational essay on protected creative time - [Eric Ries, *The Lean Startup* (2011)](https://theleanstartup.com/book) — chapters 5-7, the leap-of-faith assumption and the build-measure-learn loop - [Jeff Bezos, 2017 Amazon Shareholder Letter](https://www.aboutamazon.com/news/company-news/2018-letter-to-shareholders) — the public articulation of the "no PowerPoint" rule and what replaced it ## About the Author Molly Shelestak is a Build Partner for Side-Project Shippers. With 20+ years in tech — from Google to Heap to Contentsquare — she helps senior tech employees stop tinkering and actually ship their side projects in 6 weeks. ## Related - [The V1 Manifesto](https://www.unstuckwithmolly.com/writing/v1-manifesto) - [The Embarrassment Test](https://www.unstuckwithmolly.com/writing/embarrassment-test) - [Wait for Clarity Fallacy](https://www.unstuckwithmolly.com/writing/wait-for-clarity) - [Work With Me](https://www.unstuckwithmolly.com/work-with-me)