Building in Public: What I Actually Learned

What "building in public" means for a PM

Most building-in-public content is from engineers or founders. They share code commits, revenue numbers, user counts. It maps cleanly onto tangible outputs.

For a product manager, the work is harder to show. Requirements documents aren't shareable. Stakeholder calls aren't tweetable. The decisions that matter most often happen in a 30-minute meeting that leaves no artifact.

So when I set out to build this portfolio in public, I had to figure out what "public" even meant for my kind of work.

What I shipped

The portfolio itself became the artifact. Every feature I added; the experience modal, the AI chatbot Tia, the interactive map to show a global experience (sadly didn't make it to prod), was a chance to practice the full PM cycle: discover, define, build, measure.

The changelog became my build log. Instead of just shipping features, I started writing down what changed and why. That discipline forced me to be deliberate about what I was building and why it mattered.

The honest part

Building in public is uncomfortable. You ship things that aren't perfect. You make decisions you later reverse. The experience modal went through three different designs before landing on the current one (card style view) and I shipped all three of them publicly.

That's the point, I think. The process is more interesting than the polished outcome.

What's next

This blog is the next experiment. Long-form writing about product thinking, supply chain operations, and what I'm learning at First Solar. No growth hacking. No engagement bait. Just honest writing about the work.