The Build-Ship-Learn Loop
I have been a product leader for six years. In that time, I have lived inside roadmaps, prioritization frameworks, stakeholder alignment sessions, and quarterly planning cycles. These are real skills. They matter. A product leader who cannot navigate organizational complexity will fail regardless of how sharp their instincts are. But there is a cost to spending all your time in this layer: you drift away from building.
The distance is gradual. You go from writing code to reviewing it. From sketching solutions to approving them. From feeling the friction of a bad user experience to reading about it in a research report. Every promotion moves you one step further from the raw material of the craft. After a few years, your product intuition starts running on memory rather than fresh signal.
Side projects collapse that distance entirely.
When I build something on my own, there is no product team. No design review. No sprint ceremony. I am the PM, the engineer, the designer, and the first user. Every decision is mine. Every consequence is immediate. If I scope too broadly, I feel the cost in evenings and weekends. If I make a bad architectural choice, I am the one refactoring at midnight. If the user experience is confusing, I watch someone struggle in real time because the first users are usually people I know.
This creates a feedback loop that no day job can replicate. Build something. Ship it to real people. Watch what happens. Learn from the gaps between your intention and their experience. Then build again, carrying those lessons forward.
The loop is simple. The compounding effect is not. Each cycle sharpens your judgment about what to build next, how to scope it, and what "done" actually looks like. These are the exact instincts that make someone a great product leader. And they atrophy without practice.
I have read hundreds of product books and articles. I have attended conferences, taken courses, sat through workshops on every framework from RICE to Jobs-to-be-Done. Some of it was useful. Most of it was theory. The lessons that actually changed how I think about product came from the hours I spent building Agent Watch, Health Agents, PM-OS, and the other tools I have shipped in the last year. Not because books are bad, but because building is where theory meets reality, and reality always wins.
What Each Project Taught Me
The interesting thing about shipping multiple projects in a short window is that each one teaches you something different. Not because you plan it that way, but because every project has its own constraints, and constraints are where lessons live.
Agent Watch
Agent Watch was the first tool I shipped publicly. I was running AI agents across several projects and had no visibility into what they were costing me. Token usage was a black box. Cost attribution across agents was nonexistent. I knew other people had the same problem because I saw the complaints in forums and Discord channels.
The lesson Agent Watch taught me: start with the smallest useful thing.
The entire API surface is two decorators and a CLI. That is it. No dashboard. No cloud service. No configuration files. No setup wizard. You install it, add two decorators to your agent code, and run a command to see your costs. The whole thing can be understood in under five minutes.
I did not arrive at this simplicity through discipline. I arrived at it through impatience. I wanted the tool to exist, and I wanted it to exist fast. So I kept cutting scope until only the essential remained. What stayed was the core value proposition: see what your agents cost. Everything else was decoration.
That constraint of "what is the absolute minimum?" forced better product decisions than any prioritization framework I have ever used. When you have infinite time and a team, you can justify adding features. When you are one person building on evenings and weekends, you ruthlessly eliminate anything that does not serve the core use case. The result is a product that does one thing well instead of ten things poorly.
The best V1 is the one that makes the user say "finally" instead of "interesting."
I carry this lesson into my day job constantly. When a team pitches me a feature-packed V1, I ask them: what is the two-decorator version? What is the thing so small and so useful that someone would adopt it today? Usually that conversation cuts the scope in half and doubles the clarity.
Health Agents
Health Agents is an AI agent orchestration framework designed for healthcare. The core challenge is not the AI, it is the compliance. Healthcare data is governed by HIPAA, and HIPAA is not a suggestion. It is a set of hard constraints that dictate what you can store, transmit, process, and log.
The lesson: compliance is a product feature, not a roadblock.
Most product leaders treat regulatory requirements as obstacles. Something you deal with after the product is built. Something legal tells you about in the review meeting. Something that slows you down. I used to think this way too.
Building Health Agents changed my perspective completely. When you cannot store protected health information in plain-text logs, you have to design the logging system differently from the start. When you cannot pass patient data between agents without encryption, the inter-agent communication protocol designs itself. When audit trails are mandatory, you build them into the architecture rather than bolting them on later.
The hardest constraints produced the clearest product decisions. Every time I hit a HIPAA requirement that seemed restrictive, it actually eliminated a design choice I would have agonized over. "Should we log the full payload or just metadata?" HIPAA answers that for you. "Should agent-to-agent messages be encrypted?" HIPAA answers that too. The regulation became a forcing function for clean architecture.
This reframing now shapes how I approach every regulated product decision at work. Constraints are not problems to solve later. They are design inputs that, when embraced early, make the product better. The teams I lead now treat compliance requirements the same way they treat user requirements: as first-class inputs to the design process.
PM-OS
PM-OS is the project I am most proud of, and the one that taught me the most counterintuitive lesson.
On the surface, PM-OS is a collection of 27 skills for product managers. Write a PRD. Run a prioritization exercise. Generate a sprint scope. Conduct a retro. Each skill is useful on its own. But the real product is not the skills. The real product is the knowledge system that connects them.
The lesson: systems beat features.
When you write a PRD in PM-OS, it pulls context from your strategy document, your OKRs, your competitive intelligence, and your previous decisions. When you run a prioritization exercise, it references the same strategy and OKRs to weight the scores. When you generate a sprint scope, it considers your team's velocity data and the priorities you already set. Every skill feeds into and draws from a shared knowledge base that compounds over time.
The most valuable work I did on PM-OS was invisible to the user. It was the architecture that connects skills to the knowledge system. The way context flows between commands. The schema that ensures every piece of information is stored in a way that makes it useful to every other skill. None of this shows up in a feature list. All of it is what makes the product valuable.
This is the lesson I wish every product leader would internalize. The features that users request are the visible layer. The system that connects those features, the data model, the workflow architecture, the way information flows, is the invisible layer. The invisible layer is almost always where the real value lives. Users cannot articulate it, but they feel its absence immediately when it is missing.
At work, I now spend more time on system design than feature design. How do the pieces connect? What data flows between them? Where does context get lost? These questions produce better products than "what feature should we build next?" ever will.
Why This Makes You Better at Your Day Job
I hear a version of the same question from other product leaders: "That sounds great, but I barely have time for my day job. Why would I spend my limited free time building side projects?"
Because the skills transfer directly, and they transfer in ways that no amount of reading or training can replicate. Three specific ways:
- Speed of judgment
When you ship your own products, you develop intuition for what works before you have data to confirm it. You learn to read a feature proposal and immediately sense whether it will land or miss. This is not magic. It is pattern recognition built through hundreds of small decisions where you experienced the consequence directly. That speed of judgment translates to faster prioritization, more confident roadmap calls, and less time stuck in analysis paralysis at work. The product leaders who move fastest are the ones with the deepest reservoir of first-hand building experience. - Technical empathy
Every product leader has said "can we just add a small feature?" at some point. When you have been the one implementing, that sentence lands differently. You understand the real cost of "small." You know that a "simple" API change can cascade through the codebase. You feel the weight of technical debt because you have carried it yourself. This empathy does not make you a pushover. It makes you a better partner to engineering. You ask sharper questions. You scope more precisely. You earn trust faster because engineers can tell you have been in the trenches. - User obsession
When you build a side project, your marketing budget is zero. Your sales team is nonexistent. Your growth channel is exactly one thing: building something people actually want. There is no brand equity to coast on, no existing user base to cross-sell, no account executives to compensate for a mediocre product. The only way people use your tool is if it solves a real problem better than the alternative (including doing nothing). That discipline, the relentless focus on genuine user value, carries over to your day job in a way that user research reports and NPS scores never quite capture.
These three skills are the foundation of effective product leadership. And they all sharpen faster when you are building your own things than when you are managing other people's work. Management is important. But management without ongoing hands-on building experience is like coaching basketball without ever playing pickup games. You lose the feel.
How to Start Shipping
If you have read this far and are thinking about starting, here is the formula. It is not complicated. The challenge is not knowing what to do. It is deciding to do it.
Find a problem you personally experience. Not a problem you think the market has. Not a problem a blog post told you about. A problem that irritates you regularly. Something where you have caught yourself thinking "why doesn't this exist?" or "why is this so hard?" That irritation is the best possible starting point because it means you already understand the problem deeply and you are already motivated to solve it.
Build the smallest possible solution. Not a prototype. Not a "coming soon" landing page. A working tool that solves the core problem. Refer back to the Agent Watch lesson: what is the two-decorator version? What is the thing so minimal that you are almost embarrassed by how simple it is? Ship that.
Ship publicly. Push it to GitHub. Write a clear README. Share it in one community where the problem exists. Do not over-promote. Do not build a marketing site. Just put the tool where people who feel the same pain might find it.
Write about what you learned. Not a tutorial. Not documentation. A reflection on the decisions you made and why. What did you cut? What surprised you? What would you do differently? This step is what converts a weekend project into a career asset. The writing forces you to extract and articulate the lessons that would otherwise fade.
Repeat.
The goal is not to launch a startup. The goal is not to go viral on Hacker News. The goal is to stay in the builder's seat often enough that your product instincts remain sharp. Product leadership is a craft, and every craft requires practice. The executives who stop practicing become theorists. The ones who keep building stay practitioners.
Over the past year, I shipped six projects while holding a full-time Director-level role and studying AI at Stanford. I am not saying this to brag. I am saying it to make the point that time is not the bottleneck. Scope is. Each of these projects started small. Some stayed small. The ones that grew did so because they earned it through real usage and real feedback, not because I planned an ambitious roadmap upfront.
The best product leaders I know are the ones who still build. Not occasionally. Regularly. They have side projects. They contribute to open source. They prototype ideas on weekends. They stay close to the raw material of the craft even as their titles move them further from it. That closeness is what separates a product leader who can evaluate a solution from one who can feel whether it is right.
The build-ship-learn loop is not just a product development methodology. It is a career development methodology. Every cycle makes you faster, sharper, and more grounded. Every project adds a data point to your intuition. Every public ship creates evidence of your judgment that no interview or resume can match.
Start building. The loop will do the rest.