I wrote a post for the Replit blog, part of a six-part series by and for product managers on how they're using AI tools to build. Mine is about a problem most PMs will recognize: a big part of the week goes to keeping artifacts in sync. The requirements doc, the leadership deck, the marketing brief, and the Jira tickets all describe the same product, and every one of them drifts the moment the product changes.
The argument is that the drift is a symptom of where the source of truth lives. When the doc is the source of truth, everything downstream has to be updated by hand. When a working prototype is, the doc, the deck, and the tickets can be generated from it and change with it. Design reviews happen against working UI instead of a description of one. Research comes in through Glean, and specs go out to engineering through Atlassian once the team agrees the prototype is ready.
PMs are hired to direct work, but spend most of their time coordinating it.
The part I care most about is what this does to the job. It doesn't shrink it. It moves the time from coordination to judgment: what to build, whether the output is any good, and what not to build at all.
"The prototype as the center of gravity" is the phrase I keep coming back to when I explain how I like to work, and this piece was my chance to write down why.
It's a post about prototypes because that's where the change is easiest to see right now. I don't think it stays there. The line between a prototype and production software is already blurring, and the tools that let a PM build a convincing prototype keep getting better at building the real thing. Making the prototype the source of truth is the first step. The bigger one comes when there's no prototype stage at all: you build the real thing from the first day and iterate on that.