Writing the Code is the Easy Part

• 6 min read
software-development product-management testing operations market-validation

A few days ago, I was chatting with some friends about a tool I built (available at clickjacking.productowner.ro), and in the WhatsApp conversation that followed, Nicolae Marin said something that stuck with me:

“But code is just a tool. In the software development lifecycle, writing the code is just one part that might become smaller, faster, or easier in certain projects and circumstances.”

He’s right. And I want to unpack that, because from a product owner perspective, this matters enormously.

The Illusion of “Done”

There’s a common misconception, especially loud right now in every conversation about AI coding tools, that building software is fundamentally about writing code. Get the code right, and you’re done. The faster you write code, the faster you ship.

This is not true. Not even close.

I’ve seen projects where the code was beautifully architected, well-tested, and readable, yet the product still failed. I’ve also seen messy, rushed code powering products that millions of people use every day. Code quality matters, but it’s not the whole story.

So what is the whole story?

Before You Write a Single Line: Market Validation

The most expensive mistake in software development is building something nobody needs. This applies whether you’re building a public product or internal tooling for your company.

I’ve made this mistake. Most people who’ve shipped products have made this mistake. You spend weeks or months building something that felt important during planning, only to discover that users don’t actually need it the way you imagined.

Validation is the work you do before you write code. It’s the part where you figure out whether the problem is real, whether the proposed solution actually addresses it, and whether now is the right time to build it.

Here’s the tricky part: asking these questions can easily cast you as the naysayer, always skeptical, always pushing back, always demanding proof before committing to anything. That dynamic turns stakeholders into adversaries, and it doesn’t help anyone.

The approach I’ve found works better is to offer discovery sessions. Instead of questioning assumptions head-on, you invite stakeholders into a structured conversation: let’s explore this problem together. Who’s affected by it? What does success look like? What have we tried before? The validation happens naturally as part of that process, without anyone feeling interrogated or second-guessed.

As a product owner, running discovery sessions is the foundational step before committing to a solution. Skip it, and everything downstream, including the architecture decisions, the sprint planning, and the testing, is built on assumptions that might not hold.

Testing: The Formal Answer to “Did We Build What We Intended?”

Even after validating the market and building the right thing, software isn’t done because the code compiles and runs on your laptop.

I’ve worked with teams where “done” meant “the developer said it works.” That’s not done. That’s the starting point for QA.

Testing, whether automated, manual, or both, is how we confirm that software actually does what it was supposed to do. It’s the formal answer to a deceptively simple question: did we build what we intended?

And here’s where it loops back to validation: you can only test against requirements that exist. If you never defined what success looks like, you can’t verify that you achieved it. The testing phase creates a forcing function: it requires you to have articulated, in concrete terms, what “correct” means.

For product owners, this is the reminder that requirements and acceptance criteria aren’t bureaucracy. They’re the foundation of the feedback loop.

Deployment and Operations: The Forgotten Iceberg

Here’s the part that most people, including experienced engineers, tend to underestimate.

Deployment is not the finish line. It’s where the work transitions from building to maintaining, from controlled environments to the chaos of production.

I’ll admit I’ve always been genuinely curious about this side of things, sometimes maybe too curious. I’ve spent time digging into infrastructure configs, monitoring dashboards, and deployment pipelines to the point where I occasionally lost sight of my more traditional PO responsibilities: talking to users, refining requirements, keeping the roadmap coherent. But that curiosity gave me something valuable.

Discovery sessions, requirements gathering, production operations, and observability are all pieces of the same puzzle. When they work well, it’s because product and engineering are genuinely collaborating on all of it, not treating them as separate domains with clean handoff points at the edges of a job description.

When you ship software, the team takes on responsibility for:

  • How it behaves under real load (not just in staging with three test accounts)
  • What happens when it breaks (and it will break, in some way, at some point)
  • How you’ll know it’s breaking (observability, monitoring, alerting)
  • How quickly you can respond (incident management, runbooks, on-call rotations)

Operations aren’t exciting to talk about. There’s no demo day for “we reduced our mean time to recovery by 40%.” But every product that survives past its initial launch does so because someone took this seriously.

The part that matters most for product owners: the feedback loop. Production is where you find out what users actually do versus what they said they would do. It’s where you discover the edge cases you didn’t anticipate. It’s where the real requirements emerge.

Observability, knowing what your software is doing in real-time, is the foundation of continuous improvement. Without it, you’re flying blind after launch.

Why Product Owners Need to Care

We are responsible for the experience we provide to our stakeholders, and that responsibility stretches from the initial insight that triggered a project all the way to the moment a user actually achieves their goal with the product.

You don’t need to know how to configure Kubernetes or write CI/CD pipelines. But you do need to understand:

  • Why market validation matters before building anything
  • What “done” actually means (hint: it’s not “code complete”)
  • How observability and operations close the feedback loop

The teams that consistently ship great products aren’t just great at writing code. They’re great at the whole thing. And as a product owner, your job is to keep the whole thing in view, even when the conversation wants to reduce it to just the code.

Thanks for the prompt, Nicolae. Sometimes a WhatsApp message is all it takes.