Why We Hire Product Engineers, Not Software Engineers

We don't have software engineers at Opply.

Not because we don't write software — we write plenty — but because the title describes the wrong thing. It puts the emphasis on the output rather than the outcome.

Job titles shape expectations. Expectations shape behaviour. Call someone a software engineer and they'll optimise for software. Call them a product engineer and they'll optimise for the product. That difference matters more than it sounds.

The distinction

Software engineers ask "what should I build?" Product engineers ask "what problem are we solving?"

Software engineers measure progress in pull requests. Product engineers measure progress in user impact.

Software engineers are done when the code ships. Product engineers are done when it’s in the hands of real people & solves their problem.

This isn't about skill or seniority. Plenty of brilliant engineers write excellent code and never ask why they're writing it. They take pride in clean architecture, elegant solutions, and well-tested modules. And those things matter. But they're not enough.

The best code in the world is worthless if it solves the wrong problem. A beautiful system that nobody uses is just an expensive art project. Product engineers understand this instinctively. They treat the code as a means to an end, not the end itself.

Why this matters at Opply

We're a startup. We don't have the luxury of a relay race where product defines, design refines, and engineering builds to spec. That model is slow and breeds learned helplessness. Nobody owns the outcome because everyone owns a small piece of it.

We reject that model entirely.

We need people who hold the whole thing. Engineers who talk to customers, challenge requirements, and care whether the feature actually moved the metric. Engineers who feel uncomfortable shipping something they don't believe in — and speak up before it's too late.

Product engineers at Opply aren't waiting for permission to care about the product. They're expected to. That expectation changes everything — how people prepare for meetings, how they review code, how they think about their week.

What we look for

When we interview, we're not just testing whether someone can code. We're looking for signals that they think beyond the ticket.

Do they ask about the user? When given a problem, do they interrogate the assumptions or jump straight to implementation? Have they ever killed a feature they were building because they realised it wasn't the right solution? Do they talk about projects in terms of what shipped, or in terms of what changed?

We listen for curiosity about the "why." Some engineers light up when you give them context about the business problem. Others just want the requirements finalised so they can start building. Both can be effective. Only one fits how we work.

We also look for discomfort with ambiguity paired with willingness to operate in it anyway. Product engineers don't wait for perfect specs. They clarify what they can, make reasonable calls on the rest, and stay close enough to the outcome to course-correct, iterate and solve the right problem.

The industry is shifting

The best engineers we meet already think this way. They're frustrated by environments that treat them as ticket machines. They want context, ownership, and the ability to influence what gets built — not just how.

This isn't a new idea. Good companies have always valued engineers who think holistically. But the explicit distinction between "software engineer" and "product engineer" is becoming more common, and we think that's a good thing. Language matters. When you name something, you can hire for it, develop it, and expect it.

We think the term "software engineer" will start to feel dated. Not because software stops mattering, but because the job is no longer just about the software. It's about the product, the user, and the problem worth solving.

That's who we hire. That's who we are.