Marcus Orochena

Keeping things simple

Software vs Product Engineers


For companies that participate in software development, terminology can sometimes be difficult to keep consistent. We talk about 'software engineers', 'product engineers', 'developers', and a dozen other similar sounding titles that all tend to mix together. However, I think it would be helpful to take a step back and try to disambiguate or define some of these terms.

I want to focus on two terms in particular: Software Engineer and Product Engineer. I'm going to use these terms to describe two distinct types of software professionals, and I'll explain why I think it's important to understand the difference between them. Both can be fullstack, frontend, backend, mobile, etc. The difference is in how they approach their work.

Note that this is my own personal definition. I'm not trying to define these terms for the entire industry, but rather to provide a framework for how I think about these roles.

Software Engineers

Software Engineers are the workhorses of the software development process. They're skilled, competent and can transform a detailed set of requirements into a functioning software application. You give them a task, they'll deliver it to spec. Software Engineers need a clear path, comprehensive specs, and they'll churn out the code you need. Ambiguity or lack of detailed specs will leave them feeling lost and frustrated.

They'll be the ones asking for more details, and they'll be the ones who are most likely to push back on a story that isn't well defined. At best, they will deliver exactly what you asked for. At worst, they will deliver exactly what you asked for.

Here's a spec geared towards a Software Engineer:

Feature: Customer Login 

1. Functionality: 
   - Users should be able to log in using their email address and password.
   - Unsuccessful logins due to incorrect credentials should show an error message stating 'Invalid email or password'.

2. UI/UX:
   - *link to Figma* the the login page should exactly match the designs. Designs have been provided for all the various states and flows of the login page.
   - The login page should be accessible from every page of the website, positioned at the top right corner.
   - It should contain two fields: 'Email' and 'Password', and a 'Log In' button.
   - The error message should be displayed in red below the 'Log In' button.

3. Performance:
   - The login process should not take more than 2 seconds.

4. Security:
   - Passwords must be stored encrypted and never be displayed in any form.
   - After each failed login attempt, the system should record the timestamp and number of unsuccessful attempts associated with the user account.
   - After the first three unsuccessful attempts, there should be no restrictions or changes in behavior.
   - Upon the fourth failed login attempt within a 15-minute window, a warning message should be displayed to the user, informing them about potential account lockout after another unsuccessful attempt.
   - If the user enters incorrect login credentials for the fifth time within the same 15-minute window, the system should lock the user account. 
   - Once the account is locked, any attempt to login (even with correct credentials) should display a message informing the user that their account has been temporarily locked and will be available again in 30 minutes. This message should also provide guidance for password recovery or contact information for customer support.
   - The 30-minute lockout timer should begin immediately after the fifth unsuccessful login attempt. After 30 minutes have passed, the account should automatically be unlocked, and the failed login attempt count should be reset.
   - The failed login attempt count should also be reset if the user successfully logs in before reaching the fifth failed attempt within the 15-minute window.

5. Tech Stack:
   - The backend should be implemented using Node.js with Express.js.
   - The frontend should be implemented using React.js.

Product Engineers

Product Engineers are an interesting breed of software professionals who understand product, design, UX, and also have the ability to develop an app. They see the bigger picture, and they thrive in an environment that allows them to have a hand in shaping that picture. Give them strict specs, and you might as well be putting a brake on their productivity. They're the ones who add value not by following a detailed map, but by helping to draw the map in the first place.

They're the ones who will push back on a story that is too well defined, and they're the ones who will ask for more autonomy to make decisions. They may disagree with the product team on the best way to implement a feature, and they may even disagree with the product team on what features should be built in the first place. At best, they will deliver a product that is better than what you asked for. At worst, they will deliver a different product than what you wanted or derail your well-laid plans.

Here's an example of the same spec geared towards a Product Engineer:

Feature: Improve User Login Experience 

- Streamline the process for returning customers to log into our e-commerce website to improve user retention and increase customer loyalty.

- Must not compromise on security measures.
- Must be mobile-friendly.
- Must align with our website's current visual aesthetics.

- What additional features can we implement to enhance the login process? (E.g., 'Remember Me' checkbox, social media login, etc.)
- How can we handle and communicate login failures effectively?
- How should this feature be implemented within our current tech stack?

Which One's Better?

It's not about labeling one as 'better' than the other. Both Software Engineers and Product Engineers play vital roles within the tech industry. The issue is that companies often do a poor job disambiguating the two. This lack of clarity can create friction, misunderstandings, and missed opportunities.

If you already have a robust product team, and the ability to define detailed functional and design specs - a software engineer may be a better fit. If you are relying on more cross functional collaboration, and need someone who can help shape the product - a product engineer may be the way to go.

Ultimately, if you hire a software engineer and expect them to be a product engineer, you'll be disappointed. Equally, if you hire a product engineer and expect them to be a software engineer, you'll also be disappointed.