Writing 100 posts proved to be the cheapest prototype I have.

TL;DR This is my 100th post, and the lesson that outranks the other 99 is simple. A written draft is the cheapest prototype you own. It costs an evening, and it exposes a half-baked strategy before you spend a quarter building it. If you only write to record decisions, you’re using writing backward. Write to make the decision, find the paragraph you can’t finish, and ship it weekly so real readers correct you for free.


There’s a folder on my laptop called /posts/. Last Sunday night, I sorted it by name, scrolled to the bottom, and counted. Ninety-nine Markdown files, and a blinking cursor in a hundredth.

I remember the first one. I wrote it at the kitchen table with a cold cup of coffee, changed the title four times, and sat with my finger over the publish button for a genuinely embarrassing amount of time. I had convinced myself it was a business decision. Trevean Spice was a few months in, nobody had heard of us, and every founder deck I’d read said the same thing: build an audience, own a channel, control your own distribution. A blog was cheap. A blog would compound. I told my co-founder it was “top of funnel.”

That was the wrong reason. It worked anyway, but not the way I sold it, and a hundred posts later, I can finally say what the journal was actually for.

It was never the output. It was the thinking.

The line I keep coming back to is from Paul Graham, the essayist and Y Combinator co-founder, who argued in his essay “Putting Ideas Into Words” that writing an idea down forces you to find out whether you actually have one. His claim is almost rude in how direct it is: if you’ve never written about something, your ideas about it aren’t fully formed; they feel like they are. You discover the gaps only when you try to make a sentence hold together, and it won’t. I didn’t believe that at post one. I believe it completely at post one hundred, because I have felt the vacuum he describes pull half-finished thoughts out of my head roughly a hundred times, usually around paragraph three, usually at 10 pm.

So this is a milestone post, and milestone posts are supposed to be victory laps. This isn’t one. It’s the five things writing 100 posts actually taught me about product work and where I’m pointing the next hundred.

The idea: a post is the cheapest prototype I own

At Trevean, we prototype constantly. A new blend like Persian Sunrise goes through round after round of bench versions before it ever sees a co-packer. That’s expensive prototyping, real saffron, real cardamom, real hours from a small team. The whole point of a prototype is to be wrong cheaply, before you’re wrong at scale.

Somewhere around post thirty, I realized a blog post is the same instrument, pointed at ideas instead of ingredients. When I write “here’s how we should think about onboarding a new supplier,” the draft is the prototype. If the argument collapses by the third paragraph, I just saved myself a quarter of the cost of building the wrong process. If it holds, I’ve got a spec I can hand to someone. A post costs me an evening. The wrong strategy cost me a season.

That reframe is the spine of everything else I learned. Here are the five lessons that follow from it.

1. The draft is where the strategy actually happens

I used to think strategy happened in the meeting, and writing was just how you wrote it down afterward. Backwards. The meeting produces the feeling of alignment; everyone nods, everyone leaves, and everyone is quietly holding a slightly different version of the plan. The writing is where those versions collide, and you find out they were never the same plan.

More than once, I’ve sat down to write up a decision the leadership team had supposedly already made, and discovered mid-paragraph that I couldn’t actually state it in a single sentence. That’s not a writing problem. That’s a strategy that isn’t done problem. The blog trained the reflex, but it bled straight into the real work. It’s the same instinct behind the three-line PRD I wrote about last year: if you can’t say the problem, the change, and the way you’ll know it worked in three plain lines, you don’t have a spec yet; you have a feeling.

Writing doesn’t record the thinking. It is the thinking. The document is just the outcome.

2. Cadence beats quality, and it isn’t close

If I’d waited to publish only my best posts, I’d have published about eleven of them. The other eighty-nine are the reason the eleven exist.

This is the single most counterintuitive thing 100 posts taught me, and it maps exactly onto how we build product. We have an internal loop I’ve called “build-to-learn”: ship the smallest real thing, watch what it teaches you, and adjust. The enemy of that loop is the instinct to polish in private until it’s perfect. Perfect in private learns nothing. A B-minus post that goes out on Tuesday teaches me more than an A-plus post that never leaves drafts, because the B-minus one comes back with a reply from an actual reader who tells me the part I got wrong.

Weekly cadence also does something to your standards that’s hard to describe until you’ve lived it. When you know another one is due in seven days, you stop treating each post as a monument. You lower the stakes of any single piece, which is the trick, exactly what frees you to take bigger swings in them. The safety net is the schedule.

I missed the deadline maybe six times in two years. Every miss taught me less than the worst thing I ever shipped on time.

3. Subtraction is the hardest edit, on the page and in the product

My first drafts are almost always too long. Not because I have too much to say, because I haven’t yet figured out the one thing I’m actually saying, so I say five things at seventy percent. The edit that most improves a post is almost never adding a better sentence. It’s deleting four paragraphs so the fifth one can finally be heard.

I wrote a whole post about this once, the subtraction audit, and it started as a piece about editing prose. It became one of the most useful things I’ve ever done to the actual product. I ran the same audit on the Trevean Spice roadmap, literally asking “what happens if we cut this and does anyone bleed?” and the feature list got a lot shorter. The app got better. The team got faster. Customers noticed the few things that survived, which they never would have if those had been buried under everything else.

You learn subtraction by editing your own writing, because your writing is the one place where nobody can tell you the extra stuff is load-bearing. It isn’t. It seldom is.

4. Specifics compound; abstractions evaporate

The posts people still email me about are never the ones with the clever frameworks. They’re the ones where I named the exact thing. The supplier who missed a harvest window, and what it cost us. The taste test where the blend I was personally attached to lost, and how much that stung. The feature I championed for a month and then killed.

Abstractions feel safe because they can’t be wrong. “We should be customer-obsessed” is unfalsifiable and therefore useless. Something like “we refunded a run of orders last spring because the cheaper grinder clumped in humidity, and here’s the teardown” is specific, and something you can actually learn from. This is the same lesson as the product onion: the value is never in the abstract outer layer that everyone can agree on; it’s in the concrete core that nobody wants to commit to. Writing weekly forces you to keep reaching for the core, because vague posts are boring to write and even more boring to read, and you can feel it happening under your own hands.

Name the spice. Name the number. Name the meeting. The specifics are what compound; the next paragraph forgets the abstraction.

5. The audience I got wasn’t the one I wanted, it was the one I needed

Here’s the part where the marketing funnel I originally pitched actually shows up, and it’s the smallest of the five lessons, which tells you something.

Yes, the journal brought in customers. It brought in hires who said a post was the reason they applied. It brought in inbound from suppliers who’d read something I wrote about paying farmers on time as a supply-chain strategy, not a charity, and wanted to work with people who thought that way. Those are real, and I’m not going to pretend the “top of funnel” story was entirely wrong.

But the audience that mattered most turned out to be a few dozen other operators, PMs, and founders who write back with the sharpest disagreement I get anywhere. They are a better board of advisors than I had any right to assemble, and I assembled them by accident, by being specific and wrong in public often enough that the right people felt compelled to correct me. The reach was never the point. The feedback loop was the point. I was optimizing for a megaphone, and what I actually built was a mirror with opinions.

What the next 100 posts are for

If the first hundred were me learning that writing is a thinking tool, the next hundred are about pointing that tool at bigger, more useful targets. Three shifts, concretely:

More tactical, more stealable. Too many of my posts stopped at the insight. Insight is cheap; the expensive part is the thing you can do on Monday morning. So I’m committing to a simple test for the next hundred: every post ships with at least one thing a reader can actually run: a checklist, a template, a decision rule, the subtraction audit written out step by step. If you can’t steal it and use it this week, I haven’t finished the post.

Wider than pure product management. The truth is, I stopped being able to cleanly separate “PM work” from “founder work” somewhere in year one. Hiring, focus, deciding what not to do, sitting in a Level 10 meeting, and keeping the team out of the weeds, that’s the actual job, and pretending the journal is only about product roadmaps has started to feel dishonest. The next hundred lean into the whole operator craft. Same thinking tool, bigger surface area.

Less monologue, more conversation. A hundred posts of me talking are enough for me. The best thinking I’ve done here happened in the replies, so I want to pull that into the posts themselves: guest essays from operators I steal ideas from, reader questions answered in full, arguments I’m losing laid out fairly so someone can finish beating me. The journal has been a broadcast. I want the next stretch to be a room.

What I’m doing this week

Concretely, before next Sunday, I’m going back through the archive and tagging every post that contains a genuinely reusable tool. I suspect it’s fewer than I’d like, and that number is the honest starting line for the “make it stealable” commitment. I’m drafting an open call for the first guest essay. And I’m writing post 101 with the new rule already switched on: insight, then the thing you can run on Monday, or it doesn’t ship.

A hundred posts ago, I thought I was building a channel. I was building a habit that makes me think more clearly than I otherwise would, in public, where being wrong is cheap and getting corrected is free. That’s the cheapest prototype I own. I’m not putting it down.


FAQ

What does “writing is a prototype” actually mean for a PM? It means a written draft of an argument or a plan is a low-cost way to test whether the idea survives contact with real scrutiny, yours first, then your readers’. Like a product prototype, its job is to be wrong cheaply. If the draft collapses, you’ve saved yourself from building the collapse at full scale.

Do I need a public blog to get this benefit, or is private writing enough? Private writing gets you most of the thinking benefit; the act of forming sentences is what forces clarity. But publishing adds a feedback loop you can’t fake alone: real readers correct the specific things you got wrong. Start private if the blank page is scary; go public when you want the mirror to talk back.

How do you keep a weekly cadence without burning out or shipping junk? Lower the stakes of any single post and let the schedule be the safety net. Aim for “useful and honest,” not “definitive.” A B-minus post published Tuesday beats an A-plus post stuck in drafts, because only the published one comes back with feedback. Missing a week costs you more than a mediocre week ever will.

Isn’t “cadence beats quality” just an excuse for sloppy work? No, it’s a claim about where quality actually comes from. Volume plus a real feedback loop produces quality; polishing in private produces the feeling of quality. The eleven posts I’m proud of exist because of the eighty-nine that taught me what worked. Cadence is how you earn the quality, not how you dodge it.

What’s the one thing I should do this week if I want to start? Write one post about a specific decision you made recently, name the real numbers, the real trade-off, and the part you got wrong, and publish it somewhere a few smart people will see it. Specific and slightly embarrassing beats general and safe every time. Then do it again next week.


Related reading from the journal: The subtraction audit on cutting your way to a better product, and Build-to-learn on shipping the smallest real thing. Both are prototypes for the idea above; writing was just where I figured them out.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *