The Product Challenge

The Head of Product Hat: Equal Parts Compass, Sponge, and Lightning Rod

Working as Head of Product for a software company can be challenging at times. That opening line is the understatement of the century, but it’s also true in the most everyday, slightly unglamorous way.

The job is basically the art of balancing: the needs of the organisation, the needs of the customer, the realities of engineering, the noise of the market, the internal politics you never asked for, and—if you’re lucky—the original ideals that made the product worth building in the first place.

That last part is the one that keeps me awake occasionally. Not in a dramatic “staring at the ceiling at 3am” kind of way. More in the “tea in hand, laptop open, thinking: are we still building the thing we set out to build?” kind of way.

I’ve been writing software for over twenty years, and I’m still one of the core developers of the product at my current company. That puts me in a slightly odd position: I’m not just the person prioritising work, I’m also someone who has to live with those choices in the codebase. That can be a blessing, a curse, or—more often—both before lunch.

The messy middle: customers, company, and the product’s “soul”

There’s a romantic version of product leadership where you glide around with a perfect roadmap, customers cheer, engineers high-five, and every feature ships on time with zero regressions. In reality, you’re doing a lot of translation.

• The customer says: “We just need it to work like this.”
• Sales says: “We need this to close the deal.”
• Engineering says: “That’ll take longer than you think, and also it might explode.”
• The business says: “We need growth, retention, and margins.”
• The product says nothing… but it does quietly keep score.

Preserving a product’s core ideals sounds a bit lofty, doesn’t it? Like you’re protecting a sacred relic. But in practice it’s simple: the product has a shape, a philosophy, a way it behaves. And once you bend it too far in too many directions, it stops feeling coherent. Users might not articulate it, but they feel it immediately.

It’s like a well-designed tool versus a cluttered Swiss Army knife where everything technically exists, but nobody enjoys using it.

The head scratcher isn’t “what do we build?” — it’s “what do we refuse?”

Early on, product decisions can feel exciting because they’re additive. You’re building capability, unlocking workflows, making the thing more useful. Later, the harder decisions are subtractive: not removing features necessarily, but removing possibilities.

When you say yes to one customer’s “small tweak”, you’re often saying yes to:

• a new edge case,
• a new configuration option,
• a new support burden,
• and sometimes an entire new direction that nobody really agreed to.

And here’s the awkward truth: the most dangerous requests are the ones that sound reasonable.

A good product leader develops a kind of polite scepticism. Not cynicism. Just the habit of asking: what problem is this really solving, and what does it cost us (now and later) to solve it properly?

Because “properly” is doing a lot of heavy lifting there. You can hack almost anything in. But if you’re in this for the long run, you’re not just shipping features—you’re shaping a system that needs to remain understandable, maintainable, and… frankly… sane.

Wearing two hats: product leader and core developer

Being both Head of Product and a core developer gives you a slightly different perspective on trade-offs.

On the one hand, it’s useful because you can smell nonsense early. When someone casually suggests, “Can’t we just…”, you know whether that’s a one-day change or a six-week saga involving data migrations, performance work, UI changes, and a round of bug-fixing that makes you question your life choices.

On the other hand, it can make you dangerously attached to “the right way” to build something.

Sometimes the business needs a scrappy version first. Sometimes the customer needs a workaround now, not an elegant solution in six months. Part of the craft is knowing when to push for proper architecture—and when to accept that shipping a rough-but-safe step is better than shipping nothing while we polish our own egos.

I’ve learned that “good product” often looks like:

• doing the simplest thing that solves the real problem,
• without quietly wrecking the rest of the system.

That’s the sweet spot. It’s not glamorous. It’s not a keynote talk. It’s mostly judgement, pattern recognition, and occasionally saying, “No, we’re not doing that” and surviving the resulting meeting.

A practical approach that keeps me (mostly) honest

Over time I’ve ended up with a few rules that help me keep the balance without becoming the office misery-guts.

1) Separate the “ask” from the “need”.
Customers (and internal teams) ask for solutions. Your job is to find the underlying need. If you solve the need, you often solve multiple asks at once—and avoid building a bespoke mess.

2) Protect the product principles like a budget.
If the product stands for “clarity”, “speed”, “trust”, “compliance”, “simplicity”—whatever your values are—then treat them as non-negotiables. You can spend them, but only deliberately. If you spend them accidentally, you’ll go bankrupt.

3) Make trade-offs visible.
A lot of conflict disappears when people can see the cost. Not in a melodramatic way—just transparently. “If we do X this sprint, Y slips. If we do it properly, it’s four weeks. If we do it quickly, it’s one week but we accept these risks.”

Adults can handle trade-offs. They just don’t like surprises.

4) Keep a small list of “core bets”.
Roadmaps get crowded. Everyone wants something. Having a short, stubborn list of the few things you believe will genuinely move the needle keeps you from becoming a feature-order-taking service.

5) Don’t confuse loudness with importance.
Some requests arrive with urgency because someone is stressed, not because it’s strategically vital. Urgency is an emotion. Priority is a decision.

Staying positive without pretending it’s easy

None of this is to say the role is miserable. It isn’t. It’s actually deeply satisfying when it clicks.

There’s a particular joy in watching a customer use something you built and seeing their shoulders drop because it’s made their job easier. There’s joy in a team shipping something clean. There’s joy in taking a chaotic set of opinions and turning it into a crisp plan that people can rally behind.

And there’s a quiet pride in protecting the product from death by a thousand “tiny improvements”.

Because that’s what “preserving the core ideals” really means. It means keeping the product coherent. It means making it better without turning it into a Frankenstein of one-off demands. It means building something you’d still be proud to maintain five years from now.

And if you’re also one of the people in the trenches writing the code, you feel that responsibility in a very immediate way. Future You is always watching. Usually with a slightly disappointed expression.

Final thought

Head of Product isn’t about always being right. It’s about being consistently thoughtful—especially under pressure. It’s about doing the unsexy work of trade-offs, listening properly, and occasionally being the person who says “no” so that the product can remain “yes” to what it’s meant to be.

It’s a head scratcher, sure. But it’s a worthwhile one.