What Is Product Engineering?

Startups see their path to success as building a product many people want and pay for.

A crucial component to this is an engineer, someone who has the skills to manage and deliver parts of the product. Software comprises of many moving parts across an array of different technologies which created demand for the full-stack developer.

With the recent evolution of how software plays an integral part of peoples lives at an increasingly large scale, the role of product engineer has become emergent.

They are a core part of many teams building the next generation of great products which is why the demand for hiring product engineers is increasing and also why more engineers and product managers alike are building the skills needed to be one.

What is A Product Engineer?

A product engineer, at its most basic, is a software engineer building products. “Isn’t this just a normal engineer??” I hear your cry.

They do similar work to software engineers: writing code and shipping features.

Whereas a common trait of engineers is often focus on using the latest technology and the quality of code they produce, the goal of a product engineer is creating a great product for users.

A product engineer’s connection and responsibility to specific parts of the product cause them to pay attention to the details of the product as well as the larger picture of how what they are engineering product fits into the company vision and competitive landscape.

They care about building a solution to problems that provides value to users, being empathetic towards what the user experiences and caring about obtaining quality user feedback and usage data of the software they’re producing so they’re able to make it even better.

Product engineers have responsibility for the overall product they are working on by:

• Talking with customers, analyse data, and be aware of the competitive landscape to understand what to build using a hypothesis-driven approach.
• Shipping features that users care about, wherever they are on the stack. Ship rapidly and iterate.
• Developing opinions using data to communicate them and turn them into features.
• Explaining why a feature matters to customers as well as its importance in the competitive landscape.
• Creating prototypes and test them with users.
• Running experiments and understand their results. Be able to design for yourself and use design systems, not just “components”.
• Using tools that automate non-product work like infrastructure, integration, deployment, and testing.
• Contributing towards the roadmap and future of the product; making decisions on priorities and what to work on obtained through user data.
• Building a product for users, less loyal to features they’ve added in the past.

The product engineer specialisation is no different to the more technical specialisations such as backend engineer or DevOps. You can specialise in both being a DevOps engineer and a product engineer.

As a product engineer you also focus on learning particular patterns, techniques and technologies.

Characteristics Of Product Engineers.

Human-Centric Culture.

For engineers; the quality of their code is important. Maybe only secondly to what stack their code runs on. For product engineers both these play second fiddle to the people and organisations using their product and are continuously striving for building a better experience for them.

Talking to users isn’t only a job for product managers and salespeople, it’s also what product engineers do.

Users are human. We have a need to feel connected as humans. This is the same case for engineers and users. By connecting with your user you start to build empathy an intuitive understanding about what your users do and don’t want.

This helps gain insight into real problems users are having and figure out solutions for them. From here the idea pulling internal team resource such as collaborating with a product manager or designer to validate and shape your ideas becomes valuable.

Features without a direct connection to users are less important to product engineers. They focus less of their time here.

Navigating The Competitive Landscape With Analytics.

Because product engineers own their product, they also often own the data and roadmap for that product. This means doing analysis of usage data and how that’s contextualised within competitive landscape. They are constantly analysing user feedback and figure out what to do next.

There are many tools out there to help assist with this task such as LogRocket and Fullstory that allow engineers to gain realtime insights about how users interact with their product with session replay.

By knowing what is working and what needs improvement. They are comfortable digging into the data, watching session recordings, and once they’ve gathered insights, communicating future work.

Product engineers understand how their product fits in the business landscape they understand what makes them special and how to refine this and can continue to allow their product to remain relevant within the prospective niche. Tools like A/B tests and feature flags help with this.

Although analytics, data and insights are indispensable tools for forming great insights on what to build, you can have all the data in the world but there’s only one more thing more valuable than that; user feedback.

Ship Early, Ship Often.

…the best thing is to get something out there, understand what is appealing and what isn't from the “early adopter” feedback, then ship another version that responds to that feedback as soon as you can…

Chris Pratley

Product engineers understand without shipping, the product doesn’t grow.

Shipping too late and too infrequently is a common problem that can arise from a series psychological factors such as perfectionism, scope creep, fear of criticism, fear of rejection.

Many things can happen in the time spent waiting for features and updates to ship. The product can stagnate as you become fixate on outdated ideas. Trends can rise and fall causing your users to migrate from whatever services you’re offering.

As a product engineer, being ruthless about working on stuff that your users will see and care about and not ruthless about shaping and refactoring code endlessly is hugely important.

Shipping fast allows you to get what you’re working on into the hands of users quicker but more importantly allows you to get feedback sooner and the ability get to an understanding what the best solution is faster.

A new product has many unknowns: You do not know which features will be important, and you do not know what design or implementation is going to work, only your user base can tell you what they find valuable and what isn’t.

Always Be Experimenting (And Demoing).

The end goal of a product engineer is to ship a great product.

Briefs, mockups, written reports, and presentations although are sometimes really useful, are not a great product. A product engineer will constantly be prototyping minimum viable products and experimenting with product and feature ideas to give the most tangible application of their ideas as possible in the shortest amount of time.

A lot like good product engineers- prototypes are self-reliant. Product engineers often have a history of doing just that. They are more likely to have side projects they’ve built themselves. Some might be former founders, have unorthodox methods or come from self-taught backgrounds.

New ways of thinking are always demonstrated by new techniques. Unreflective people adopt the techniques but not the thinking. - Alan Cooper

There are great selection tools out there to help with notion of rapid prototyping such as Figma a collaborative design interface tool and more recently Framer that allows you to launch interactive prototypes with zero code.

A great way to encourage experimentation and prototyping within your teams culture is by introducing internal product demos into the company culture.

Demoing ensures everyone is in the loop on what you’re about to release as well as giving you one final defence against releasing a bad release to your customers. It also fosters team communication and creates accountability and a drive to deliver.

Your prototype might not be a complete solution to a business problem, so don’t feel so attached to the idea that you feel dejected if it’s not received in the way you would have hoped. At the very least will be a step into inspiring a solution that does meet a certain requirement. It’s not about getting it perfect, it’s about ensuring the road to what is needed becomes more clear for the team.

Automation, Testing And Continuous Delivery.

Shipping fast and talking to customers requires time on top of engineering, as an engineer how to do buy time?

Product engineers get this time by relying on tooling and automation. Ideally, they are spending little of their time on automating testing, infrastructure, and deployment.

“If it hurts, do it more frequently, and bring the pain forward.” - Jez Humble

A great developer experience enables product engineers to ship fast and focus on the other parts of the work. Having to deal with integration, deployment, and infrastructure prevents them from focusing on shipping features, talking to customers, doing research, and other valuable tasks.

This includes being disciplined with prioritisations and deciding which aspects of automation tooling are crucial to invest time and resources in and being able to whether these investments trickle down into making the user experience greater.

Mapping Technical Debt.

Perhaps the biggest point of contention between engineers and product managers is technical debt.

Bugs are code that doesn’t behave the way you expect. Tech debt is code that behaves exactly as you expect, but your expectations are incorrect. - Alan Holub

Technical debt is a concept that refers to the accumulation of work that needs to be done on a software project due to shortcuts taken during the development process. These shortcuts may involve using outdated technology, ignoring best practices, or prioritising speed of delivery over quality of code.

Technical debt can have significant negative impacts on a product’s long-term viability and presents a significant challenge by causing delays, increasing costs, decreasing user satisfaction, affecting the product’s roadmap and overall success.

A product engineer has enough discipline to tow the line that often blurred in a traditional product manager to engineer relationship, with the ability to prioritise what is essential in terms of refactoring and reducing debt while keeping shipping velocity at an optimum.

This is achieved by taking a proactive approach to addressing technical debt. Rather than waiting for it to become an emergency that requires immediate attention, a good product engineer will continually be assessing and improving processes to reduce technical debt and improve code quality over time.

Being able to clearly identify and prioritise technical debt by weighing the cost of addressing the debt against other priorities such as new features or bug fixes. A great product engineer is able to take into account factors such as impact on users and impact on product stability.

Become A Better Product Engineer.

In the ideal world, every engineer would be a product engineer as well as being a technical master.

But in here in the real world, as humans; we are all blessed with strengths and weaknesses. It’s unrealistic to expect one person to be able cover everything and you usually need a high performing team that compliment each other; you’re better off playing to people’s strengths. Every team usually have stars but everyone acts as equals.

The best way to increase your product engineering capabilities within yourself or your team is by introducing practices that form the foundation of your teams culture. The simplest way of doing is this by re-framing the process.

You’re not developing software, you’re building a product.

Great products are engineered when you truly understand the desired outcomes by actively listening to people, not users - Michael Fountain

The smallest step you can take towards becoming a better product engineer is by developing a base level understanding of the product you’re building.

This will set you up to function better as a product development team member, product thinking causes your team to understand that they are the machine, not the cog.

You will come to understand why decisions are being made, whether the team is following appropriate practices and gain some empathy with stakeholders, but more importantly the people you’re building for.

Bring knowledge that exists between the technical and engineering world through to the product world, which ultimately translates into your users world and the overall success of the company. Understand how and why your company is successful. What’s the business model? What parts are most profitable, What parts cost the most?

If you’re building tech products then there is a good chance engineering is a significant part of the time, cost and effort involved in building the product. As an engineer identify and present the challenges that slow you down. What improvements need to be made to the developer experience? What needs attention so that you’re able to spend more outside of the engineering world so when you step back into it, you can be sure you’re working on the right thing?

Sometimes what seem like small technical nuances can turn into serious product issues. A product minded engineer will be able to balance the technical with the product considerations and present them in terms of how they effect your companies business goals.

Conclusion

As long as building great products is an important goal for many companies, product engineers will continue to be important.

What product engineers do now is what is thought to be the path to success, but never combined into one role. A growing number of people are developing the skills needed to become successful as product engineers.

On the other side, a growing number of companies are looking for people with these skills to help build and maintain building great products for people to use. This combination is creating the current surge of demand for product engineers.

By adopting a more product focused approach, you’ll be an indispensable member of the team by having clarity to see shortcuts that reduce churn and increase retention by presenting data validated feature ideas.