This keeps happening. The iOS apps I build in Swift, the AWS API integrations I prototype, the HTML/CSS I push to production on my personal site—they directly inform the product decisions I make at scale.
At Amazon, I led initiatives that reduced payment launch time by 60%. The insight came from the same place as debugging GoingVegan or PetSafe: if a process is manual, it's a bottleneck. When I proposed using LLMs to streamline Prime Payments documentation, I wasn't guessing at feasibility. I'd already prototyped similar integrations in my own projects.
My Capital One background as a Mobile iOS/Network Engineer means when my teams discuss API contracts or system architecture for Starlink Enterprise, I'm not nodding along—I'm stress-testing the approach in real-time. I know what breaks at scale because I've broken it myself building production iOS apps and backend systems.
The $55MM partnerships and $116MM expansion strategies I manage today succeed partly because I still think like a builder. When we shipped that 8-week sprint in Brazil that delivered a 15% activation lift for 2.5MM users, the speed came from knowing exactly where we could cut corners and where we couldn't. You only develop that intuition by shipping real code.
Coding doesn't make me a better engineer. It makes me a better product manager. I see the cost of technical debt before it compounds. I know which architectural changes are theater and which are foundational. Most importantly, I can tell when my engineers are sandbagging versus when they're genuinely stuck.
If you've stopped coding, start again. Build something small. Break it. Fix it. Ship it. The pattern recognition you develop will make every product decision sharper. Currently working on automating more of my content pipeline. The lessons will show up in my next roadmap review.