For most of my career, "the product" was something that arrived at engineering already decided — a spec, a Figma file, a set of acceptance criteria. My job was to build it well. Founding Momena, where I own product design, architecture, engineering, and App Store operations myself, rearranged that relationship entirely. Here's what actually changed.
A feature isn't done when the code is
As an engineer on a team, "done" usually means the pull request merged and QA signed off. As a product owner, I learned that's maybe sixty percent of the work. The other forty is the App Store listing copy that has to be honest without being boring, the onboarding screen that has to earn a permission request instead of just asking for it, and the support email template for the one edge case you didn't think users would hit but three of them did in the first week.
Engineers who've never shipped the whole thing tend to underrate this. I did too, before I had no one else to hand it to.
Saying no is a product skill, not just a project management one
With a team, "we don't have bandwidth" is usually the reason a feature gets cut. Building alone, bandwidth is infinite in theory — I could always work another hour — which meant I had to develop a different filter: does this feature make the core experience better, or does it just make the product bigger? Those aren't the same question, and conflating them is how good products get cluttered.
The engineering version of this instinct — avoiding unnecessary abstraction, not building for hypothetical requirements — turned out to be the same muscle as the product version. Once I noticed that, I started trusting my own product judgment more, because it was built on the same discipline as my architecture judgment.
Constraints you set yourself hit differently
Every engineer has opinions about scope creep imposed by a product manager or a client. Momena removed the person to blame. When I decided a feature wasn't worth building, or that a redesign could wait a quarter, that was entirely my call — and I noticed I made better decisions when I couldn't externalize the disagreement. There's a kind of clarity in constraints you can't blame on someone else.
Technical decisions are product decisions in disguise
Choosing CloudKit over running my own backend for Momena wasn't just an infrastructure choice — it was a product decision about what kind of company I wanted to run. No server meant no on-call rotation, no infrastructure bill that scales with growth, and a genuine architectural guarantee behind the privacy promise, not just a policy page. An engineer evaluating this in isolation might weigh it purely on technical merits. A product owner has to weigh it against what kind of business is sustainable for one person to operate for years.
I now audit every "purely technical" decision I make for teams I work with by asking the product question behind it, even when I'm not the one who gets to make the final call. It's made me a better advisory voice in architecture discussions, not just a better solo founder.
The parts that never show up in a portfolio
Writing support responses at 11pm. Reading App Store reviews that sting a little more than a code review comment ever did, because there's no team absorbing the impact with you. Deciding whether a bug is bad enough to justify an expedited review request. None of this is glamorous, and none of it appears in a case study's architecture diagram — but it's most of what "shipping a product" actually means once you own all of it.
What I'd tell an engineer considering this jump
You already have more of the skills than you think. The instincts that make you good at estimating technical risk, saying no to unnecessary complexity, and writing code that's honest about its own limitations are the same instincts a good product owner needs — they just haven't been asked to operate on the whole surface yet. The gap isn't skill. It's willingness to own the parts of the job that don't have a clean pull request at the end of them.