Joseph Earl

Conveyor belt with products in boxes moving quickly along it

Product engineering

agileproduct-thinkingshifting-left

If you observe the majority of organisations involved in delivering digital products today and examine how their employees spend their time, you might not be surprised to discover that almost all of their time is dedicated to the development and delivery process!

A diagram showing most of peoples time in software organisations is spent on the development and delivery process, and not on serving the customer or improving how we serve the customer

This might seem obvious and expected, leading to the assumption that it should not be questioned. However — is it really the ultimate goal?

What if our goal was to to maximise the time spent on the customer, focusing on outcomes and impact rather than tools and implementation?

And I don’t mean just the product managers or executives, but everyone involved in product delivery. This includes the developers, testers, business analysts, and delivery managers. All team members.

In that case, we would want the development process to be as efficient as possible, requiring the least amount of work, so that we have ample time to focus on what truly matters: our customers.

This is product engineering.

A diagram showing how in product engineering the goal is to spend as much time as possible focused on the customer, and as little as possible on delivery activities

As product engineers, our goal is to solve our customers’ problems and make them happier. We want to spend our time on the following:

  1. Serving our customers better today, by:
    • Understanding how we are serving our customers through observability and monitoring
    • Responding rapidly to and resolving customer-originated incidents
    • Improving our customer service through enhancements and defect fixes
  2. Preparing for the customers of tomorrow, by:
    • Researching our customers’ needs, desires, and preferences
    • Conducting experiments to evaluate the value and viability of ideas

To achieve this, we must minimise the cognitive load and time required for software development and delivery.

Less work is better: If automation can handle a task, it should. If we can achieve our goals in a simpler way, we should opt for it.

Less code is better: Ideally, we should strive for codeless solutions. If AI tools allow us to write code faster, enabling us to build digital products more efficiently, as product engineers, we should embrace this advancement.

Less stuff is better: We should aim for a minimal number of environments and infrastructure. Anything that stands between us and the customer demands our attention and detracts from customer focus.

Less waste (blocking) is better: Whenever possible, asynchronous processes should be favoured, and we must trust and empower individuals rather than gatekeeping.

Less hand-offs are better: If one person can handle a task, it’s more efficient than involving multiple people. Collaborative parallel work surpasses serial work.

More adaptible individuals are better: When hiring, we should prioritise intellect over specific skills or knowledge. Ideally, roles should be fluid to prevent pigeonholing, allowing teams to self-organise.

As product engineers, our value lies in our ability to comprehend our customers’ needs and solve their problems efficiently and effectively using any available tools.

Today, these skills may involve activities such as designing, writing, testing, or deploying software. Tomorrow, it could change to encompass other domains entirely, like designing, writing, and testing an AI prompt, or configuring a no-code tool.

Whatever the future holds, we have nothing to fear.