Product engineering – developing software that meets a customer need – is a skill that is developed rather than taught. When deployed effectively, strong product engineers have extraordinary leverage, crossing crossfunctional boundaries and getting (a lot of) stuff done.

As an engineering leader, developing and unleashing product engineering is a force multiplier. Vanta has grown quickly, and I’ve been thinking about how best to scale product engineering with that growth. Ultimately, cultivating effective product engineering comes down to motivation, empowerment, and execution. In short, show great engineers the problems, give them the tools to approach those problems, and get out of the way.

Motivation

One cannot design and build good software without knowing the underlying need they’re solving. I’ll assume that engineers at one’s company ultimately care about the customers’ and, by proxy, the company’s success – if that’s not true, one has much bigger problems to solve.

Motivation is derived from customer empathy. Personally feeling the customers pain and the potential that software can bring is deeply motivating, and developing customer empathy is a matter of ritual and access to customer feedback. How a leader structures meetings, what they talk about, and where they spend their time indicates what’s most important to them. Putting customer focus at the top of every team meeting, ensuring that all works are framed in terms of customer impact, and actively engaging with product work all signal that customer needs are important to a leader, and the team follows suit.

One also needs to limit friction to getting access to customers. Depending on the product, employees may be customers – ask them for feedback! At early-stage companies, might know all customers by first name – ask them for feedback! As a company grows and develops support teams that talk to dozens of customers a day, these teams becomes a proxy (but not a substitute) for talking to customers – ask them for feedback!

Seeing the product through a customer’s eyes develops a burning sense of urgency for a product engineer to fix all the problems and realize all the opportunities.

Empowerment

Once an engineer feels a customer’s pain, they must feel empowered to act on it. Otherwise, the urgency dies on the vine.

In a typical EPD (Engineering, Product, Design) crossfunctional team, Product is typically responsible for deciding what to build that best meets the business need, Design is typically responsible for the design and user experience of that feature, and Engineering is responsible for delivering a product in a way that appropriately balances speed and quality. Many companies, whether or not they realize it, treat this relationship linearly – a product manager designs a product requirements doc and hands it to a designer, the designer develops a design spec and hands it to an engineer, and the engineer picks it up for the first time and builds it while the PM and designer watch.

The best EPD triads (or three-legged stools) are better than the sum of their parts and collaborate at each step of the way. The PM kicks ideas around with Engineering and Design as part of defining product requirements, Design and Engineering build prototypes, get feedback, and iterate on the requirements and specs. Even if Product is the final decision maker and ultimately accountable for the product requirements, leveraging everyone’s ideas and engagement ultimately leads to a better product.

Not every product change needs to go through this process, though. Connecting engineers directly with customers’ needs should leave them chomping at the bit to fix them. In some cases, especially for straightforward fixes and improvements, an engineer can drive changes on their own, perhaps asking for feedback or review from Product/Design before they ship it. Shipping each little fix or improvement offers a hit of dopamine, and tightening the iteration loop keeps product engineers wanting more.

Execution

Now that engineers are motivated and empowered, the final piece of effective product engineering is proper execution against more ambiguous and/or complex customer needs. Optimizing for learning – sequencing discovery and delivery in phased milestones with crisp hypotheses and purpose for each – enables a team to spend its time efficiently in solving the customer need. Framing the project as a series of questions (“will anyone pay for this?”, “is this extra configurability necessary?”, “do customers want this feature?”) and associated deliverables to test those enables a team to scope the solution to an appropriate MVP iteratively and quickly. Each project milestone should be framed as an opportunity to reevaluate the viability of the project and kill it if necessary.

Engineering time is often the scarcest resource, and many leaders hesitate to cancel or downscope projects they’ve invested in. Instead, optimize for learning, embrace failure, and celebrate putting down projects that aren’t going to deliver meaningful customer value. Engineers can tell when they’re working on something useless, and a properly motivated product engineer will want to spend their time on something meaningful, anyway.