I’ve been recruiting for tech companies for a while now, and a few years ago, I started seeing a shift in how early-stage SaaS businesses were operating, and the majority of that was due to the engineers working in them.
Their job titles would be a version of “Software Engineer”, but seeing and hearing them operate up close, I realised that they were something else entirely.
They didn’t just write clean code and ship features on time. They’d challenge and influence the roadmap, question whether a feature made sense, dig into usage data, and genuinely care about whether users actually benefited from what they built.
After having multiple coffees and lunches around Melbourne over the last few months and raising this idea with people, it turns out there’s a name for this kind of engineer. They’re being called Product Engineers, and I think understanding the difference between them and what we might call traditional software engineers really matters if you’re hiring for early-stage companies.
Customer obsession isn’t just a buzzword
When I’m running role intake meetings with hiring managers at product-led SaaS companies, the difference becomes pretty clear.
For traditional software engineering roles, the conversation focuses on technical requirements. What’s the tech stack? What’s the architecture challenge? What level of experience do they need?
For product engineering roles, the conversation shifts. Hiring managers talk about wanting someone who’ll ask to join customer calls, who’ll shadow the PM when they spend time in the usage analytics looking for patterns, or who’ll watch session recordings to see where users get stuck.
The thing is, product engineers want to be involved in understanding users, not just building for them. They want context, not just a list of features to build.
They also tend to own their part of the product differently to traditional software engineers. They’re involved in roadmap discussions. They have opinions on priorities. They make design decisions. If something breaks or a feature isn’t working for users, they see it as their job to iterate on it, not just log a ticket.
Jean-Michel Lemieux, former VP of Engineering at Shopify, describes product engineers as “engineers who have a thirst for using technologies to leapfrog human problems, those with empathy to reach for magical experiences.” Which all sounds amazing, but I think what he’s getting at is that they care more about the outcome than the implementation or the tech itself.
Different questions, different outcomes
Traditional software engineers ask, “How do I build this properly?” It’s a good question. You want clean code, solid architecture, and reliable systems.
Product engineers start somewhere else. They ask, “Why are we building this, and is this the right thing to spend time on?”
I’ve seen this play out in hiring processes. When you give candidates a take-home challenge, software engineers will focus on the implementation. They’ll think about the right frameworks, clean architecture, and test coverage.
Product engineers will often come back with questions first. Who’s this for? What problem does it solve? Have we validated that users actually want this? Sometimes they’ll even suggest a simpler solution that achieves the same outcome with less code.
It’s the difference between building it right and building the right thing. Both matter, but they’re fundamentally different approaches to the work.
Prototype, ship, iterate, repeat
Product engineers also work differently on a day-to-day basis. They’re often engaged in more prototyping and experimenting. Mockups and presentations aren’t the end goal, shipped features that users actually engage with are.
This means running a lot of experiments. A/B tests, feature flags, and quick prototypes to test with users. The goal is to learn fast and iterate fast. You can’t do that if you’re spending weeks perfecting code before anyone sees it.
The product engineers I’ve worked with firsthand often have side projects or come from founder backgrounds. They’re the ones who actually enjoy hackathons because they get to build something from scratch and ship it quickly. Ghost, the publishing platform, specifically looks for this when hiring:
“The majority of our team is made up of former founders, freelancers and self-starters who are confident and comfortable working independently and getting things done.”
This approach only works if you’ve got the right infrastructure, though. Product engineers rely heavily on automation and solid CI/CD systems. They need to be able to ship multiple times a day without thinking about deployment. If they’re spending hours on manual testing or dealing with infrastructure problems, they can’t focus on building for users.
Different scorecards
Software engineers measure success by output. Did the code ship on time? Is it bug-free? Is the system fast and stable?
Product engineers measure success by outcomes. Did user engagement go up? Are customers actually using this thing? Did it move the business forward?
Both matter, but I feel that they’re fundamentally different ways of thinking about the work.
I’ve interviewed brilliant software engineers who take immense pride in elegant solutions and technical craftsmanship. That’s valuable. But when I ask them about impact, they’ll talk about the quality of the code they shipped, not whether it solved a user problem or moved a metric.
Product engineers, when you ask them about their proudest work, will talk about the feature that increased activation by 20%, or the onboarding flow they rebuilt that reduced drop-off, or the iteration they shipped based on user feedback that doubled engagement with a particular feature.
It’s a tough shift if you love the craft of coding. But there’s something rewarding about watching features you built actually improve someone’s day.
I’ve seen a lot of left eye twitching come from me asking an engineer to describe the last customer call they were on.
The autonomy question
One pattern I’ve noticed is that product engineers expect more autonomy than traditional software engineers.
They want to own the roadmap for their part of the product. They want to be able to spot something, validate it with a few users, prototype a solution, and ship it without going through multiple approval layers.
This works better at smaller, early-stage companies. Larger organisations with complex products need more coordination, more specialisation, more process. That’s just reality.
But in the early-stage SaaS world, product engineers are expected to be opinionated about what should be built and why. They make design decisions. They decide priorities. They’re trusted to understand the business context and competitive landscape well enough to make good calls.
That level of ownership requires comfort with ambiguity. You need to be willing to make decisions without perfect information, happy to experiment and potentially be wrong, and confident enough to have opinions on the product direction.
When I’m interviewing candidates for product engineering roles, I’m looking for people who’ve actually done this. Maybe they had a side project where they shipped something and iterated based on user feedback. Maybe they came from a founder background. Maybe they’ve worked at early-stage companies where they had this kind of autonomy before.
If someone’s only ever worked in large organisations with defined processes and clear handoffs, they might struggle with the ambiguity of product engineering.
Why this actually matters for startups
Most startups see their path to success as building a product people want and will pay for. Product engineers are fundamentally designed for that mission.
They write code, yes, but they also talk to users, analyse data, understand the competitive landscape, and make decisions about what to build. That’s basically the entire startup playbook, just executed by someone who can also ship the features.
When I’m working with founders and CTOs now, this distinction matters more than most people realise.
They’re different skills. Different mindsets. Different ways of measuring success.
The reality check
I’d be lying if I said this distinction is clear-cut everywhere. Plenty of software engineers think about product, and plenty of product engineers care deeply about code quality. The best teams I’ve seen have a mix of both, and they learn from each other.
But these are also the ones who get frustrated in environments that treat them as order-takers rather than problem-solvers. If you’re hiring for this kind of role, you need to be ready to give them the autonomy, tools, and access to users they need to actually work this way.
Otherwise, you’re just adding “product-minded” to the job description and wondering why it doesn’t change anything.
What’s your take on this? Have you seen the difference between these approaches in your own teams? Hit reply and let me know, I’m curious whether this matches what you’re seeing.
Before you go, can you help me out?
Now over 1300 people have subscribed to this newsletter, which makes me feel that it’s resonating. So thank you to all of you 🙏🏻
If you found this issue useful, here are four ways you could support me.
- Share it – Forward this to a founder, leader. hiring manager, or job seeker who you think might find it useful and/or interesting.
- Subscribe to this newsletter
- Follow and/or connect with me on LinkedIn if you’re not already – https://www.linkedin.com/in/simonfromcrew/
- Send feedback – What topics would help you most? What’s working? What isn’t? Just hit reply.
These small actions make a massive difference in helping me reach more people who need this content.
Thanks for being here. Have a brilliant week ahead.
Weekly newsletter drop: Wednesday, 1:30pm
Need hiring help?
If you’re struggling with a specific hiring challenge, I still offer 1:1 strategy calls through my consultancy, Crew. Book a 15-minute clarity call here.
Simon
