What a Product Engineering Mindset Can Teach Software Developers

They are often just given a list of requirements by the business and expected to deliver a final product without providing much input beyond that.

Yet, can involving the software developer in the conception stage and giving them a more active role produce better results?

Dawid Janiga, Netguru’s Software Architect Frontend & Tech Lead, seems to think so. He’s worked on some fantastic products throughout his career but has experienced his fair share of failed projects in the past. Each project he’s worked on has equipped him with invaluable lessons that have refined his skills and helped him develop what he calls a “product engineering mindset.”

We invited Dawid to share his insights during Burning Minds internal Netguru conference, on why adopting a product engineering mindset is so important for software developers to have, and why it’s key to delivering much more successful products for clients.

What is software development?

In Dawid’s view, being a software developer is often seen as just a purely technical role to deliver a product rather than a vital part of the overall project.

Typically, the cycle of software development involves the following stages:

• The client explains what they need.
• The development team determines the project feasibility and the time needed to complete it.
• Implementation

Dawid believes that we should change this thinking. For him, software development is just a sub-section of the wider product engineering lifecycle. In fact, there are many more layers that make up product engineering, including market and user research, competitive analysis, quality assurance, and software development. Each of these should be of interest to a software developer and not siloed off to the business.

The benefits of getting developers involved in the entire lifecycle of the product

Focusing on separate tasks is not as effective as having a wider vision of product feature development. Software developers should be seen as consultants, says Dawid, and not just another cog in a machine, because they have a valuable role to play in the success of the product.

If software developers can understand the business better, Dawid explains, then they can start to ask “why” more. They can critique the requirements and design and learn more about where the project fits into a business’ overall aims.

With this knowledge, they can make better data-driven decisions about the product. By being more involved, developers can earn the client’s trust, increase ownership, and hopefully deliver a successful product.

Why data-driven decisions are so important in product engineering

Dawid explains that:

"Data-driven decision-making is about stripping out the emotion from decisions and looking at the cold hard facts."

The first step, however, is deciding what the right things are to measure.

Once you know what to measure, you can identify issues even before the customer does.

How developers can find out what’s going on in the business

As a developer, Dawid says that it's vital to stay in touch with what’s going on in the business to refine requirements, anticipate feature requests and refine the product. To do this, he suggests taking the following actions:

• Try staying in the loop about the business roadmap. Developers can prepare software for changes if they know what direction the business is headed. This could be expansion, new features, or expanding to other languages.
• Subscribe to the client’s newsletters or podcasts to stay abreast of upcoming changes.
• Follow the client on social media to understand their user base.
• Listen to the client’s podcast or podcasts where they are a guest interviewee. This may give you insight into how to improve the product.

What developers can learn about the product users

Developers can also keep a check on the audience and their behaviors by regularly reviewing user analytics. Google Analytics and monitoring the error reporting tools are key.

Dawid highlights that on previous projects, checking the volume and behaviors of users on different devices was vital to product development.

“There is no sense in implementing the really nasty bug from the backlog that is only on tablets where their user base is 1.110%.”

Dawid explains that on a previous project, 60% of users were on smaller laptops, but the development team were using 4K retina screens. They discovered that the content they had developed was too big for the average user’s smaller screens and was forcing them to scroll.

Having detailed knowledge about the user base in this case helped them develop better products. Knowing how users are interacting with a product can help software developers push back on client feature requests or recommend a better use of resources or changes.

Why being part of the requirement process can lead to a better product

Dawid details how this product engineering mindset came into play in an NFT/blockchain project for Koii.cx. In this project, the initial requirement was to create a platform to onboard users, but after listening to the founder on a podcast, Dawid came up with the idea of doing more to execute the product vision. The target audience of Koii is tech-savvy. The team proposed placing the onboarding experience in as cutting-edge NFT technologies. The final outcome is a 3D and sound experience.

This is a great example of where they reverted the requirement lifecycle and proposed requirements themselves. The result? A website that the client was incredibly happy with. This is the product engineering mindset.

Standing out as a developer in a crowded market

Dawid believes that developers need to stand out in the market and stop thinking about themselves as only good at technical skills.

Instead, developers should demonstrate that they have wider skills and show their interest in the industry and the client’s business development as a whole.

Knowing code is good, but also being able to provide detailed feedback is even better. Listening to business podcasts, subscribing to newsletters, and being interested in the competition is a critical part of Dawid’s process. This allows him to give more informed feedback and suggestions to clients.

Involving developers in the business plan

Dawid explains that clients sometimes think that the development team doesn’t want to know about the wider business plan. The truth is, clients often want developers to understand more than just the technical stuff. They want developers to work in line with the entire roadmap, the marketing plan, use cases, and not just the features to be designed.

This leads developers to design better products and stay prepared for updates and new releases.

If you would like to learn more about product development, Dawid recommends the book “Inspired” by Marty Cagan.