The Product Engineer – Rands in Repose

This article starts with a salacious assertion on not needing product managers that I wouldn't agree with, but it is a good attention grab for the actual point of it. In reality you have many disciplines involved to creating a great product, and this dives into three of those: product manager, designer, and engineer. I've seen and experienced every one of the scenarios described. The scenario around "designer island" literally made me laugh out loud in the "yeah, I've seen that one too" kind of way. The punchline of the engineer scenario is the most damning.

Extend this passive-aggressive product-hostile situation over a few years, and our bright and eager Engineer becomes the Disconnected Engineer. The human accountable for building the product with their hands exists as a semi-motivated engineer who is grabbing bullets as they come over the fence and combining them with misaligned and misinformed design from the island, which results in strangely constructed features that… work. I mean, they look like features, but when I asked this engineer why she chose this approach, she said the thing that crushed my soul, "They told me to do it this way."

Unacceptable.

If the people writing the actual code don't understand the problem they are helping the customer solve you can’t possibly build a great solution. This is super critical in B2C software, but in B2B software companies ignore it to their peril. It matters everywhere.

The conclusion of this is to embrace a more meaningful way of thinking about product builder.

A Product Engineer:

• Uses the product every day and reports bugs aggressively when they find them.
• Intimately knows how the products work and can explain any feature or inner workings to anyone. When they find a gap in their knowledge, they fill it.
• Have a deep understanding of how users perceive their features and how their changes would affect their perception. They can wear the customer mindset.
• Remember the debates around the most complex decisions and why we chose this path.
• Have living breathing code in the product -- right now.
• Can effectively argue with anyone on the team regarding the product. Will defer to their team members when the argument is sound, but they will continue to argue until there is product clarity.
• Communicates well in every direction because they've developed professional relationships in all those directions.
• Are aggressively curious and willing to learn anything relevant to the design and development of the product, especially when it's outside of their area of expertise.

A Product Engineer is accountable for the product.

This is a good approach, but I think it would fail at some level of scale. And in the B2B world it can be difficult to impossible to be using your product everyday. But the intentions here are right, and figuring out how you bring this "one team" feel to all the disciplines involved in a product is key.

It all circles back to shared goals, and one of my favorite metaphors drives this home. What is the objective of the goalie on a soccer team? Nearly everyone will say to stop the ball from getting in the net. Wrong. The objective is to win the game.

The objective of everyone building a product needs to be to create a great product.