One of the most discussed people in the tech world are the elusive product-minded engineers. People have been kicking this term around for years — in job descriptions, “Looking for a product-minded engineer,” on company About pages, “Our team prides itself on product-focused engineering” — but how do you define a product-minded engineer? Why does everyone want to hire this type of engineer? And how can engineers become more product-focused?

The basic concept is simple enough: A product-minded engineer is someone who keeps the finished product top of mind as they go about solving problems. But, it’s obviously more than that, because ask any engineer and they’ll tell you that of course they think about the product they’re building with their team. They think about it all day. So, where’s the disconnect?

No engineer is an island

Many engineers are in their careers because they love to solve problems with code. That’s a great motivation, but companies are learning more and more that when every member of the team keeps the end result top of mind and communicates their vision for the product, the entire process is smoother and more efficient.

The tough reality is that as much as they may want to, the engineering team can’t be siloed away from the rest of the group. Everyone involved in the company is building the product, together. That doesn’t mean everyone should have the same perspective. We would never suggest that your team be filled with a homogenous group of people who come at every problem the same way. On the contrary, diverse teams come up with more innovative solutions. The different perspectives, experiences, and areas of knowledge will improve your product, but only if you bring them together. 

Mokriya’s engineers have largely built their own products that have been released into the App Store and in some cases downloaded hundreds of thousands of times. Hiring talented engineers like this with demonstrable success at shipping their own apps is one surefire way to ensure a product-minded engineering culture. Any engineer who has been through the experience of building and releasing an app that users actually paid for is going to have the ability to look at a project in a unique way. They will possess a business perspective as well as a user experience perspective. Viewing problems from this multi-faceted lens, rather than simply an engineering lens, will allow them to spot things in a project’s scope that could be troublesome and potentially lead the client down the wrong path. This type of engineering is impossible to teach. Rather it comes from actually shipping products.

Shipping product, baked into the culture

Engineering teams and design teams have all sort of obstacles in front of them whenever they have to work together. And communicating across the engineer/designer divide can be frustrating. When designers pass on their specifications for the product, it’s often done in a way that implies the process is linear. The designers decide what the product will look like and then tell the engineers to build their vision. Many great products have been built this way, but it’s an inefficient process that fosters miscommunication and overlooks great opportunities to improve the product through collaboration.

The engineering team can’t just leave the product design to the designers anymore than the designers can ignore code. That’s exactly the kind of siloed thinking that creates unnecessary friction in an already challenging process. For example, at Mokriya we will ideally include a blended team of product manager, designer and developer in our client project meetings from the outset to ensure the entire team is product-minded. But, as an industry, we’re not really there yet.

By deliberately building a culture that is pragmatic and practical, one that ensures shipping the product and getting it out the door rather than getting stuck in silo-driven process, you’ll need to hire product-minded talent.

Outside in vs. inside out

Returning to the broader challenge facing software-building teams, you could say that designers have an outside-in approach while engineers tend to take a more inside-out approach. Engineers know the code, what the technology is capable of accomplishing and the designers know products and user experience.

Engineers build the product from the inside-out. They’re the ones who are in the depths of the thing, imagining all the the possible functions and features that could be built into it. They’re so focused on the possibilities, engineers have a habit of building ugly, overly-complex products. These products are packed full of great features, but not really usable to anyone who isn’t an engineer. Meanwhile, designers are looking at the product from the outside-in. How will users approach this product? What confuses users? What delights them? They start from the end result and work their way back to the beginning.

By viewing the product in such different ways, these two teams are bound to come up with very different (sometimes even contradictory) solutions. Engineers tend to have this wonderful habit of building products that can do a lot of different things — it’s a great perspective, one steeped in curiosity and imagination. Unfortunately, it’s also an easy way to overstuff a product and turn users off if they get overwhelmed or lost.

Left to their own devices most engineers would build massive, complex products with a million moving parts and almost limitless uses. Users would be able to do so much with these products! The problem, of course, is that users don’t necessarily want limitless uses and endless customization, they want the product to do the thing it’s supposed to do with minimal effort, intuitive features, and little-to-no onboarding time.

There’s already a strong push toward this holistic product building process, one where the designers and product managers learn the tech side while engineers become more involved in product and user experience. One that we are in favour of here at Mokriya. But there are still too many teams operating as silos and missing out on the experience of effective collaboration.

Does every engineer need to a product-minded engineer? Probably not, but getting that perspective will likely only improve your work. Being a product-minded engineer is not for everyone, but if you care about the user’s experience and business outcomes as much as the code itself, then you are a product-minded engineer. And it’s time you embraced it. 

About Tricina Elliker

Tricina Elliker is a regular contributing writer to Mokriya, based in Portland, Oregon. She's been writing about science and tech since 2008 and received her MFA in nonfiction writing from Columbia University in 2013.