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:
- Undervalue and therefore fail to prioritise important technical work they do not understand.
- 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:
- Undervalue and therefore fail to prioritise important feature work they do not understand.
- 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:
- Value — how much will we benefit from doing this work?
- Cost — how much will it cost us to do this work?
- Opportunity cost — what is the cost of not doing this work?
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.