Building alone taught me I’d been doing product management at a safe distance.
The contractor’s customer never opened my app. My app’s quality depended on them anyway.
My app, HVAC Load Calculator, went to market with a PDF feature. Contractors were generating reports and handing them to homeowners to close jobs. The PDF was generated quickly. The data was right. It just wasn’t good enough for what it was actually being used for - and I almost missed that entirely.
I started noticing the pattern through user conversations. People weren’t just running calculations. They were using the PDF as a sales tool. A contractor would size a system, generate the report, and walk into a homeowner’s kitchen with something that looked official, something that said: here’s what your house needs and here’s why.
That’s a different use case from the one I’d designed for. The contractor was my user. Their customer was reading my work.
When I actually sat with the PDF and thought about that second person - someone who doesn’t know what a load calculation is, who’s making a significant financial decision, who’s judging the contractor’s credibility partly based on this document - I realized the bar I’d been measuring against was wrong. Accurate wasn’t the same as trustworthy.
Functional wasn’t the same as professional. Some of the contrast and type weight needed attention. Small stuff. But small stuff that mattered when the document was doing a job I hadn’t fully accounted for.
I fixed it. Released an update. Moved on.
But I kept thinking about why I almost didn’t catch it.
Fifteen years in product. Large enterprise software companies, early-stage startups, everything in between. In all of that time, I was never the last line of defense between a mediocre experience and a lost customer. There was always someone else downstream.
A designer who’d catch the readability issue. A customer success team absorbing the friction. Users who’d keep using the product anyway because switching costs were high and the contract was already signed. Enterprise software has a thousand ways to insulate the PM from the actual consequences of the experience they shipped.
That insulation is so complete you stop noticing it. It starts feeling like the job. You get very good at describing user problems. Mapping journeys. Writing research briefs. Advocating for the user in planning meetings. All real skills. All practiced at a comfortable remove from the actual moment someone encounters the thing you built and decides whether it’s worth their time.
Building alone removes every buffer. There’s no designer downstream. No CSM to patch the relationship. No contract keeps users locked in. Someone searches the App Store, finds your thing, downloads it, and either keeps using it or doesn’t. That’s the entire feedback loop.
What changes isn’t your standards. It’s your attention. Suddenly, you’re looking at your own product the way a stranger would, because strangers are the only people you have.
This is what I think corporate PM experience actually trains poorly: the ability to feel the weight of a product decision in real time. Do not describe it. Do not advocate for it in a meeting. Feel it when the outcome is yours.
Most of the product people I know are excellent at process. They can run a discovery sprint, synthesize research, and write a crisp PRD. The craft is there. What’s missing is skin in the game, and it’s missing because the structure of most product roles makes it nearly impossible to have any.
If you’re somewhere in the early building phase, one thing is worth sitting with before anything else: trace the full value chain before you decide what “good” looks like. The person using your interface isn’t always the person your product is actually serving. I didn’t design the PDF for homeowners. I didn’t think about homeowners at all. That was the gap, and I only found it because I was paying close enough attention to notice how the tool was actually being used in the wild.
Nobody was complaining about the PDF. Downloads were steady. Absence of complaints is easy to mistake for things being right. It isn’t. When you own the outcome, you have to hold the quality bar yourself, because there’s no org structure to catch what you let slide.
Most product people reading this have strong skills and genuine experience. That’s not the gap.
The gap is having built something where the quality decision was entirely yours, the user was entirely a stranger, and the outcome was entirely on you. That experience changes how you see product work. It doesn’t make enterprise experience irrelevant. It just makes the distance visible.
Once you can see the distance, you can’t unsee it.
Mike Watson @ Product Party
P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.