I'm a Product Manager and I Ship Code to Production

I started my career convinced I wanted to be a software engineer. I loved the logic, the clear cause-and-effect and the feeling of building something from scratch. Over time, though, I realised that what I cared about most wasn’t just how things worked, but why they mattered. I was most energised in user interviews and messy problem spaces, trying to understand the gap between what people needed and what they had. That realisation is what pulled me into product management.

The frustrating part of being a PM

As a PM, you spend a lot of time spotting things that could be improved. Sometimes those are big strategic decisions, but often they’re small details: wording that’s slightly confusing, a workflow with one too many steps, or a UI that doesn’t quite behave the way you expect.

Those details matter. But when timelines are tight, they’re hard to prioritise. Fixing them usually means writing a ticket, explaining what you mean, waiting for capacity, and hoping the nuance survives the handover.

That’s the reality of building software in teams with limited time and competing priorities. Still, it can be frustrating to see problems clearly and not be able to act on them directly.

Vibe coding as a communication tool

I originally started vibe coding prototypes as a way to communicate ideas more clearly. It can be surprisingly difficult to describe an interaction or workflow in words alone. Specs grow long, Figma only goes so far and subtle behaviours get lost in translation.

One example was around Projects, a core concept in our product. We already had Projects, but I felt they weren’t fully supporting collaboration or giving senior stakeholders enough visibility. There was useful data we could surface - progress, key documents, decisions - to make Projects a clearer source of truth, not just for the person doing the work but for anyone who needed to understand what was happening.

Instead of describing this in a long spec, I built a new Projects prototype. It wasn’t polished or production-ready, but it was interactive. When I showed it to users, the reaction was immediate. They were excited by the idea of shared visibility, but they also quickly surfaced what didn’t work.

For example, I added an activity feed showing everything that had happened in a Project. In theory, it felt like a great way to improve collaboration and visibility. But when users saw it working, it quickly felt noisy and distracting, burying the important bits in a stream of updates. Seeing it live made that trade-off obvious in a way a document never could.

Building a rough prototype helped me show what I meant instead of just describing it. These weren’t polished or production-ready, but were quick, scrappy experiments designed to make an idea tangible.

Prototyping made my product thinking sharper

What I didn’t expect was how much this would sharpen my product thinking. Even when you’re building something rough, writing code forces specificity. Edge cases surface quickly. Assumptions become obvious. Changes that seem simple reveal hidden complexity.

Prototyping turned abstract conversations into concrete artefacts, and it made trade-offs clearer much earlier. It wasn’t about trying to be an engineer, it was about making my reasoning visible and pressure-testing ideas before they became roadmap commitments.

Shipping code changed my relationship with the product

I’m still not an engineer and my core responsibilities haven’t changed. My job is to understand users, define problems, prioritise trade-offs and bring clarity to ambiguity.

What has changed is my relationship to the technical side of the product. By building small things myself and shipping changes to production, I’ve developed a more grounded sense of how systems are structured and how changes ripple through them. I have a better intuition for where complexity hides and how fragile a seemingly small tweak can be.

One of the most meaningful changes I’ve shipped was around citations in our drafting outputs. Citations are critical because they allow users to verify information and trust what they’re reading, but they weren’t always coming through reliably. Instead of writing a ticket and waiting for capacity, I dug into how the model outputs were being handled and where citations were being dropped. I updated the logic so they were consistently captured and rendered correctly, opened a PR, iterated on feedback and shipped the fix. The impact wasn’t flashy, but it was foundational. Drafts felt more trustworthy and we reinforced something core to our value proposition: transparency.

There’s something powerful about learning technical concepts in the context of real user problems. You’re not learning in the abstract - you’re learning because you want to make something better for someone.

In some ways, I’ve come full circle. I didn’t become a software engineer, but I’ve found a way to stay close to the craft of building while still focusing on the craft of understanding people.

The uncomfortable part: hitting the edge of what you know

This kind of empowerment comes with discomfort. Product management is a role where you’re expected to have strong opinions and bring clarity, so working closer to the implementation means regularly bumping into the edge of what you understand.

Sometimes you can tell something is wrong but don’t yet know why. Sometimes you start making a change and realise you’ve wandered into a part of the codebase that’s far more complex than you expected.

What’s helped is treating that discomfort as part of the learning curve. I’ve had to get better at asking questions earlier, slowing down when needed and leaning on engineers with deeper context.

And honestly, it’s made me feel closer to the engineering team. Being able to contribute directly turns collaboration into something more like pairing than handover and it’s easier to build shared ownership from idea through to release - without blurring role boundaries.

What changed in my day-to-day work

I still spend most of my time talking to users, understanding what matters and working with the team to decide what we should build next. But shipping code has changed how I approach those responsibilities.

I test ideas more quickly instead of debating them in the abstract. I think more precisely about edge cases and implementation details. And I’m able to close the loop faster when I notice something that could be improved.

What I’m pushing myself to do next

For me, going deeper means building confidence by understanding why something works, not just getting it to work.

I slow down to learn what good looks like - the patterns the team prefers, the kinds of changes that age well and the ones that are likely to create problems later. When something feels outside my comfort zone, I collaborate more closely with engineers so I’m building the right instincts, not just shipping blindly.

It’s not a shift away from what I’ve been doing, but a deepening of it - combining deliberate learning and shared ownership so I can contribute with more confidence and impact over time.

The real lesson: environment matters

More than anything, this experience has highlighted how much environment matters. Having the space to experiment, the trust to learn in public and the encouragement to stretch beyond a narrow job description changes what you’re willing to try.

At Orbital, ownership matters more than role purity. We talk about “Everyone Ships Code Now”, and it’s not aspirational - it’s how work happens. If you notice something small that matters, you’re encouraged to fix it and ship it. Being AI-first also changes the speed of delivery. It’s easier to go from noticing an issue, to exploring a fix, to getting something reviewed and shipped, which makes it more realistic to tackle the small but important details that often get deprioritised.

For me, it’s meant feeling closer to the product, more accountable for the details and more connected to what users actually experience. It feels like the start of a new phase in how I practise product management and I’m very excited to see where it leads.

We’re hiring. If you’re excited about working in a team where ownership matters more than role boundaries, check out our open positions.