Why Engineering Teams Need a Strong Product Mindset

Too often, engineering teams are far removed from their customers and have little understanding of what they are doing or how they are using the product. This can lead to a lot of wasted time and effort, not to mention frustrated customers.

Why is a product mindset important?

In a fairly common team set-up for most organisations, engineers often look at the product owner as the source of truth for what they build. They get handed tickets with crafted stories and a set of criteria for what the thing they build should do. They then see their job as taking these criteria, translating them into a set of technical requirements, and then writing software to meet them. I'll put it flatly ... this is wrong.

To be able to build an effective solution, you first need to understand the problem. The product owner isn't the person facing the problem, the user is. To be able to solve the users' problems effectively, you need to understand them, and what they want and need to do. This isn't to poke holes in the Product Owner, but they won't be able to fully take the evidence and client input they gathered and turn that into effective software. Chances are they may well miss things a software engineer would consider vitally important to know. I say this a lot, but it's worth repeating, writing good software is a team sport!

The product owner and software engineering team should work closely together from the start. If possible having an engineering representative on a call with the client as well as the product owner would be perfect, but even if not, the very next step they should certainly be involved in.

Non-function requirements ... they're a very important thing in writing good quality software, and something that a product owner may overlook. They're the things like, is it more important for this to be fast, or for it to be reliable. It's not a pure one-or-the-other scenario, but to an engineer, this can be the difference between choosing a cutting-edge technology or design to get the fastest possible performance or picking an old well known and very slow-changing technology that is known to be highly reliant. The classic product viewpoint is that speed is important, users don't like things to be slow, data will show drop off if it's not a sub-1-second request etc. However, it may be that this data is a legal requirement, and can't be dropped or malformed, in which case, speed could be bad, and speed could be risky. In this case, it may be a chance to build a technical solution that provides that stability, and to partner with User Experience experts to determine how to best give the perception of speed, or the confidence something is happening.

Thinking about the user, and their problems is a key critical skill in being able to write good software solutions to problems. This skill is often underdeveloped in engineering teams with a poor product mindset. They act like they're part of an assembly workshop, not a creative problem-solving team.

Product mindset = Job satisfaction

Another great added side benefit to having a product-focused engineering team is that we can close the feedback loops. The engineers are closer to the customer and get to see and feel the difference their solutions made. It's far more satisfying to get feedback that tells you something like "Feature X saved me 2 hours a day on Y repetitive task, it freed me up from working longer hours, and means I get to see my children before bed" than it is to be told something generic like "Customer satisfaction increased" or even worse ... nothing.

Lo and behold, when engineers start to get this first-hand feedback and see their positive impact, it drives them to become even more involved in the product, and in solving the users' problems. They start to think like the user and make suggestions to improve the product with the user in mind. It increases innovation. It increases customer satisfaction. But most importantly, it is going to increase your retention in your teams. That sense of impact, that tangible recognition of their work, breeds a sense of purpose and belonging, and believe it or not, even your most head-down headphones on the engineer is a social being. Those things make people stick around.

How do I build the product mindset

Building a product mindset in your teams could be either a very simple thing or a very complex thing. I'm afraid it will depend entirely on your company and situation. The principle at heart is very simple though, work together more, work together sooner. Get the people involved in building the software involved from the very beginning, from the requirements gathering with the user. Work closely with each function in the business to ideate, define, and deliver the solution. Track how that solution is used, and how it is performing (user analytics through to technical observability). Then gather feedback using whatever tools you have available, and make all this information available to everyone on the team.

To do this, you can just follow healthy best practices, I'd advise using Extreme Programming best practices to help shorten feedback cycles. Make sure conversations are centred around the user and focused on delivering value to those customers. Sure, we are building something technical, but it doesn't matter how great a technical solution is ... if the user isn't happy and doesn't use it. To borrow a classic statement ... User first, always!

I hope this short article helps you think a bit about how you can start to create a more product-centric mindset in your engineering teams, and why it would be beneficial to your team and company to do so.