Over the last decade or so, I have seen a reemergence of the dreaded “business analyst”. These folks were the wait-staff of the waterfall lifecycle, taking requests from the customer (or the business), and translating them into orders to be processed by the cooks (the development team). Perhaps business analysts served a need in the waterfall model (or the model of “want” over “need” as I often call it). Maybe they were seen as a necessary component to limit business and product manager interaction with engineering resources, though this lack of interaction in my mind is largely responsible for most of the product failures I’ve seen over time. The role created a moral hazard where folks defining their “wants” were firewalled from the ramifications of defining the wrong “thing”; the business analyst was the scapegoat identified as not correctly turning the “want” into something valuable.
The growing adoption of what is now known as Agile methodologies and lifecycles such as Scrum, XP, et. al gave rise to a meeting of minds and the creation of The Agile Manifesto. The original signatories of the Agile Manifesto, each of whom were practitioners of one of the emerging agile methodologies, agreed on a set of principles to help guide future development efforts. They recognized, among other things, that fixed development schedules and a focus on documentation over collaboration were contributing to several software development failures. Consider the following quote from the Agile Manifesto’s history page
“This type of situation goes on every day—marketing, or management, or external customers, internal customers, and, yes, even developers—don’t want to make hard trade-off decisions, so they impose irrational demands through the imposition of corporate power structures. This isn’t merely a software development problem, it runs throughout Dilbertesque organizations.”
Consider also the fourth principle from the Agile Manifesto, clearly focused on eliminating the obfuscation of responsibility and the resulting moral hazard of isolating business people from co-creating the solution in question:
“Business people and developers must work together daily throughout the project.”
The quote from the history page and the principle targeting interaction above both take aim at one point and a corresponding corollary to that point:
- Morale hazards, uncertain, and obfuscated ownership run counter to the needs of a company in software development, and the corollary…
- Better and even magical things happen when we force people to work together with common goals, aligned interests and clear accountability.
Fast forward 21 years and the specter of the business analyst has risen from its grave in new clothing and with a new name: The Technical Product Owner. Make no mistake about it, the beast may be cloaked differently and have a different name, but the intention and the ill-fated (and sometimes unintended) outcomes remain the same. Let’s first look into some of the many reasons teams consider technical product owners.
Common Reasons Cited for a Technical Product Owner
- Reason 1a: Product owners need a technical resource to handle the technical aspects of the development process. AND/OR
- Reason 1b: The product owner and/or product manager jobs are too big for one person alone. AND/OR
- Reason 2: Engineers need someone to “bridge the gap” between a product owner who doesn’t understand the intricacies of engineering.
Answer: This stifles the magic that happens in experientially diverse teams. Having a role that makes communication easier means that engineers don’t “stretch” to better understand the product and product managers don’t “stretch” to gain the critical understanding of engineering necessary to do their jobs. Further, it has the unintended consequence of creating a moral hazard and obscuring ownership and accountability.
Further, as Marty Cagan points out, it is almost impossible to separate the product manager and product owner jobs successfully. Instead, think about creating smaller domains over which a PM/PO combination (without a Technical Product Owner obviously) is responsible. In doing so you will create more time and opportunity for the PM/PO to be successful.
Suggestion: Focus on growing people and their understanding to bridge the communication and interaction gap. Send product managers to an introductory engineering leadership course (similar to those offered by AKF in the CTO accelerator) and ensure engineers have a better understanding of the business for which they build products.
- Reason 3: A technical owner applies technical knowledge to strategic conversations about the product.
Answer: This is the responsibility of architects – not technical product owners. When architecture responsibilities are implemented properly, those responsibilities include pairing with product management to help inform the future of what is possible within the products a company produces.
Suggestion: Ensure you have a well trained and highly experienced architecture team working with product management to help inform roadmaps and possibilities.
- Reason 4: Product owners don’t have the necessary insight into technical requirements to properly groom the backlog.
Answer: Again, this is the purpose of communication and the appropriate construction of teams: product owners collocated with the engineers with whom they work. Teams that are sufficiently experientially diverse and communicating well will ultimately learn how to collaborate effectively. Further, in doing so, they will unleash the benefits of “cognitive conflict” – the academic term for the beneficial discussions that increase strategic and tactical options (think brainstorming).
Suggestion: Ensure that product owners are directly attached to the Agile teams that develop your solution – including sitting next to them if you have folks coming into your office. They should be involved in all ceremonies. Stress the need to communicate, and where communication is difficult due to technical terms have the team with which they are working whiteboard explanations to help grow the PM/PO. The same should happen for product concepts with the PO “teaching” engineers. Doing so increases the value of the entire team and eliminates the need for a technical product owner.
- Reason 5: The Product Owner/Manager is geographically separated from the engineering team - so we need another PM to help with ceremonies.
Answer: Don't allow separation of the teams. Whether this came about as a result of COVID or was an opportunistic hire, the PM/PO must work with the engineering team daily per above.
Suggestion: If you intend to hire folks within a cross functional delivery team, with members distant from each other and in other timezones, make clear that the team has the responsibility to meet together daily. Someone will need to make sacrifices in their schedule.
Let’s now recap the reasons you should NOT create a technical product owner role:
Reasons Not to Use Technical Product Managers
- Greater Distance Between Engineers and Customers
In Tom Peters’ book In Search of Excellence he outlines eight characteristics of excellent companies. The second is “Staying close to the customer”. Adding a technical product owner (or manager) adds one more hop between an engineer, the product, the market and the customer.
- Greater Distance Between Engineers and Business People
In the Agile context, the product owner is the businessperson. Adding a technical product owner reduces the frequency of interaction and increases the probability of incorrectly relayed information or loss of critical context.
Remember, the Agile Manifesto clearly indicates (see prior quotes) that this is something we want to avoid and in fact is one step closer to a waterfall model and its inherent moral hazards.
- Failing to “Grow Teams” and “Grow People”
If someone understands how to write software, they can easily learn and understand the business and the market. When you need a “crutch” – or someone to translate between the “business” and “engineering”, it’s an indication that you either have that wrong product managers/owners or the wrong engineers. Believe in the power of teamwork and invest in your teams such that disparate skillsets and perspectives can build upon each other; don’t hide the issue with folks meant to be translators or proxies.
Jim Collins, in his book How the Mighty Fall indicates a few more reasons why this failure to find and invest in the right people (people who will work together across the chasm of experiences). Each of these are further examples of how the technical product owner is a drug addressing a symptom rather than a remedy for the underlying problems:
- People increasingly think of positions over responsibilities. In this regard, the technical product owner helps solidify the old way of firewalling product owners and business people from the accountability and responsibility of building the right thing.
- A low number of the right people in the right job. Again – if engineers can’t grow to discuss matters directly with a business person or product owner, and if the product owner can’t do the same for engineers we simply have the wrong people in the wrong positions or we have the wrong expectations of them.
- Poor team dynamics. Here Jim is discussing the quality and frequency of interaction. Back to the Agile manifesto, clearly we will get less of that quality of interaction with key decision makers if we put an unnecessary (and costly) translation proxy between the product owner/business person and the engineering team.
- Highly Innovative Companies Don’t Do It This Way
As Peter Drucker points out, most innovation happens within startups and scaleups. Those companies don’t have the funds to afford “extra people”. Instead, they learn how to talk to each other and work together. Something magical happens when engineers and businesspeople work together – its the spark the fuels innovation. Adding a translator confuses the situation, increases moral hazards, and obscures ownership and accountability.
- Confusing Ownership and Accountability
We’ve made this point over and over. The more handoffs you have, the higher the probability that intent and outcomes get confused through the chain of outcomes. Further, the more handoffs you have, the more difficult it is to identify ownership and hold the right people and teams accountable. Part of our jobs as leaders, executives, and managers is to ensure accountability and ownership are clear. Don’t confuse them with a translation proxy ala a business analyst or technical product owner.