The other week, a post by someone at Google went viral. The gist: PMs should focus on building prototypes that show what the product is supposed to do, rather than merely telling through written PRDs.
That resonated with me.
As a developer-turned-PM, I always found it limiting that “building” was considered out of my scope. I got to write specs, user stories, and requirement docs — but those often failed to capture the intent behind an idea, leading to botched execution of a feature. A lot got lost in translation.
Now, working on poketto.me, I see the value of a multi-pronged approach:
✅ I prototype directly in the actual codebase. As I wrote in TIL #26, I rarely create UI mockups — I just build it in Angular straight away and show others what I’m up to.
✅ I write about what I build — like in yesterday’s TIL about toast notifications. Writing forces me to think: Why did I show a toast in this scenario, but not that one? Can I explain that decision clearly, or do I need another iteration? (While I wrote yesterday’s post, for example, I fixed a myriad of details about the toast notifications on the go!)
✅ I demo features, live and in videos. And demoing is often where flaws get exposed. It’s when you walk through the entire user flow end-to-end — and realize something hasn’t been fully thought through.
Whether you're starting with specs or with scrappy prototypes, the risk is the same: Incompleteness.
And the best way to catch that is:
Show. And Tell. And Write.