There are no “technical initiatives” — only ones you don’t understand

Many product development teams distinguish between technical and so-called product initiatives. Generally, these teams will consider product initiatives to be initiatives that deliver new features to customers. These same teams would define technical initiatives as any project that improves the technological foundations of the product but does not deliver customer value.

Product initiatives Technical initiatives
Expand email template library Optimise lists database
Enable segmentation of contact lists Rotate dispatch IPs for deliverability
Dashboard for mail analytics Move caching to redis
Drag-and-drop editor Centralise error logs
Spam-score reporting Migrate containers to AWS

This distinction is often a problem for teams. In a company where product management has more influence over the roadmap, teams become feature factories, and teams neglect technical maintenance or improvements. In a team where engineers hold the power, teams might constantly refactor and upgrade technology without delivering much customer value.

Product and engineering leaders tend to see this as a prioritisation problem. If they allocated more capacity to neglected work, they’d solve the problem. This diagnosis of the problem is incorrect, though.

The real reason why most teams neglect important work is that decision-makers have a poor understanding of the value of the work they are neglecting.

Product managers with a poor understanding of the technical details of the product they manage will do one of two things:

  1. Undervalue and therefore fail to prioritise important technical work they do not understand.
  2. Defer to others, allocating some capacity to more technical people, who may prioritise or advocate for work at their discretion.

Technical leaders with a poor understanding of customer needs will behave similarly. They will:

  1. Undervalue and therefore fail to prioritise important feature work they do not understand.
  2. Defer to others, allocating some capacity to more customer-facing people, who may prioritise or advocate for work at their discretion.

Both options lead to bad results because great strategy comes from a holistic understanding of value, cost, and risk. The better solution for both parties is to build an understanding and appreciation for initiatives beyond their expertise because the distinction between product and technology initiatives does not exist. This distinction is an illusion caused by a lack of understanding.

When deciding what a team should work on, whether an initiative feels more like a feature or a technical improvement should not be a factor. The distinction between product and technical work occurs when we don’t understand the value and cost of doing something and the cost of not doing it at all.

So, to prioritise work, we need to understand:

When deciding whether to tackle one of two potential product initiatives, product managers consider each of these properties (whether explicit or implicit in their process). Which feature will deliver more customer value? Which feature will cost less to do? What type of return on investment does the ratio of value and effort give us? What is the cost of delaying other initiatives?

Technical leaders ask the same questions when weighing their options between various technical initiatives. Which improvement will most lower our maintenance burden, decrease costs, or improve reliability? Which improvement will cost less to do? What return on investment does the ratio of value to effort give us? What is the cost of delaying (i.e., technical risk) other initiatives?

When you understand and appreciate the value and effort dynamics of all initiatives, whether they feel more technical or product-focused, it becomes easy to prioritise them within the same backlog. The motivation to prioritise this work in separate queues only occurs when the people doing the prioritisation lack this understanding and appreciation.

Practical advice for startup leaders

First, whoever is accountable for product strategy needs to understand customer needs and the technical dynamics of the products they manage. This principle means that more complex, back-end heavy services and products require more technical product managers.

Second, engineers need a deep understanding of customer needs. The more you expose engineers to customers and customer feedback, the more they will appreciate the value of product work relative to technical work.

Third, great strategy comes from a deep partnership between product strategists and engineers. Each side of this partnership should constantly challenge the other and make no major decision by delegation. Instead, collaborate until both sides understand the value and costs associated with the decision. Even teams with experienced product managers need trustworthy technical leaders engaged in the strategy process.

Fourth, if you can’t articulate the customer value of a so-called technical initiative, you don’t understand it deeply enough and need to keep digging. There is customer value in every initiative worth doing. Customers want software that frequently improves, so a technical initiative to improve developer experience is valuable to customers. Customers want reliable software, so a technical initiative that improves service uptime is valuable to customers. Customers want to get their work done quickly, so work to improve the performance of services is valuable to customers. Customers want affordable solutions to their problems and vendors who are profitable enough to serve them forever, so initiatives that reduce hosting costs are valuable to customers.

Finally, the better you quantify how each initiative impacts the above, the better outcomes you will deliver. Teams should apply the same scrutiny and outcome-centric mindset to technical work as any other work.

Privacy and terms

I care about privacy as much as you do. I will only use your email address to send you this newsletter or to reach out to you directly, and you can unsubscribe at any time. I will not share, sell, or rent your email address to any third party, though I do store it the software I use to dispatch emails.

The information provided on this blog is for informational purposes only and should not be considered investment advice. The content on this blog is not a substitute for professional financial advice. The views and opinions expressed on this blog are solely those of the author and do not necessarily reflect the views of other organizations. The author makes no representations as to the accuracy, completeness, currentness, suitability, or validity of any information on this blog and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its use. The author may hold positions in the companies or products discussed on this blog. Always conduct your own research and consult a financial advisor before making any investment decisions.

Subscribe for advice

Free weekly advice covering product strategy, development operations, building teams and more.

More advice

Australia to quash angel investing

The Australian Government is about to make it nearly impossible for successful startup workers to reinvest their earnings into new startups. Let’s explore the upcoming changes and how they will affect startups, workers, and the Australian economy.

Stepping on toes

How much should competent people, confidently managing their responsibilities, meddle in the affairs of other teams they perceive to be dropping the ball?

Processes make inexperienced people wiser, and experienced people dumber

People hate process, but process is crucial to scaling a businesses. Today, we explore the difference between good and bad processes, and ways to ensure startups can benefit from standardisation, rather than suffer.