Product Ownership (3)

In this article I'd like to elaborate on point 2 of my take on good product ownership qualities.
The introduction can be found here, point 1 is here.

Point 2 is: "A good enough technical background"

I know this is a somewhat controversial topic amongst many of the people I spoke to, yet I still think it's an essential quality.

First of all, how do you define "good enough". A tricky issue and a very subjective matter in my opinion.
Secondly, all of us who have a manager that used to be a technical guru know that he generally misses the deep technical stuff. It's the reason why most technical managers still like to play with Lego, they make tiny constructions in their office with their pens and paperclips and a lot of them still love to write some piece of software at home. Given all this, I think it's fair to say that they just miss the "creating" part of software engineering. The technical challenges, coming up with solutions and riding the high waves of new technology and its possibilities. This is one big caveat, and I've seen a lot of product owners fail there! (and most people learn it the hard way)

Looking at the natural order of things, it feels normal in the early stages of a project for the development team to drive a lot of the priority settings. They know best what base layer is needed and which components take precedence in order to reach that first thin end to end slice of functionality. They understand what infrastructure needs there are and how low level components (generally those a user will never notice) need to be available before the first features can be built. (sidenote: I am not trying to say they will have a big design up front cycle, but just enough to understand the dependencies). Having a technically trained product owner will help the team out in defending this priority setting to the stakeholders, even though they may not always understand why there is such a need for a "non visible" component or feature.

This being said, that cycle can't go on forever. At a certain point (you'll feel it when it's there) this needs to change and the product owner needs to start taking charge of priorities, based on stakeholder requests. Here again, it takes a product owner with a technical understanding to see when a project is ready for this switch (it's more of a fade than a hard switch anyway). The risk of not having a technically skilled product owner is that the team will keep running circles around him and develop "cool" features (for developers) instead of listening to what the market is asking for. On the other hand, when a product owner is in his mind still too much of a developer, he'll happily agree to keep working on those cool features and start ignoring stakeholders and market demands. He'll drift away as part of the development team and that early stage cycle will never be broken.

So, how would one define the "good enough" than?

In my opinion, good enough means something along the lines of:

• able to understand technical problems and solutions to an extent that an autonomous judgement can be made on the progress of the development team. This generally requires a product owner who did do some development himself.
• able to grasp the complexity of a proposed feature and its underlying needs
• able to understand the high level architecture of a system
• able to place the development team on an equal level to other stakeholders and make a decision based on business demands rather than on "coolness"