In a software project, the product owner is responsible for representing the interests of stakeholders and the business. The importance of this role cannot be overstated, since put in a more matter of fact way, the product owner is responsible for the success of the product. In this post, key candidate measurement criteria, garnered from the experiences of the author, are presented. These will help you avoid the nightmare scenario where vasts sums are paid devoid of any prior measures whatsoever, with purely subjective motivations such as “the guys have been working really hard” or “I have seen the user interface demo“.
Before proceeding to the key measurement criteria, we briefly address who the product owner may be and what the interests of the stakeholders and business may be.
Who Is The Product Owner?
The product owner, an individual, can either literally be the product owner or an appointed agent in a software development project using, as an example, a Scrum management framework. In a small to medium sized enterprise, the product owner may be an individual that has additional responsibilities, and in a startup, it is likely that a founder takes on the role, in which case, it would be investors that would in effect be ‘hiring’ their product owner.
Regardless of the structuring in the enterprise, as with any, if the individual with the responsibility is not held accountable for failure, or on the flip side sufficiently rewarded for success, then in the absence of extreme luck, you are doomed, if not in the short run, then most probably in the long run. Naturally, with accountability comes authority, and likewise, if your product owner does not have sufficient authority, formally, then in the absence of extreme luck…
What Are The Interests Of The StakeHolders and Business?
The interests of stakeholders and the business are naturally variable, but we can at the very least presume that the business has a short term or long term goal of profitability. In other words, the success of the product can generally be measured at the very least in terms of growth in profitability. It is worth noting, and this is by no means piercing insight, that without formal project parameters presented as directives by the stakeholders and the business, in the absence of extreme luck…
Key Measurement Criteria
The following criteria are in no way negotiable, and admittedly, the first, and most important, is difficult to measure.
1. Passion For Both Software Engineering and Your Business Domain
Although passion is subjective, there are ways to measure at the very least interest levels when it comes to both software engineering and your business domain. In a general sense, a person without passion, especially in a key position, is likely to demotivate the rest of the team.
2. Commercial Software Development Experience
If the candidate does not have any commercial experience whatsoever, not matter how good they look, whether on paper, physically or in terms of reputation, by hiring them into this key senior position you are taking a risk that is not worth taking. It may be repetitive, but again, if the candidate matches either of the following, do not hire them as your software product owner:
- No commercial experience whatsoever – please note that working at a foundation or not for profit organization does not count as commercial experience.
- No commercial software development experience – please note that university projects simply do not count, and again, developing software at a foundation or not for profit organization does not count as commercial experience.
The candidate should ideally have software engineering experience in an environment with mature software engineering processes, and in the first instance, the candidate should have some feel for what immature and mature processes are. It should be remembered that the product owner must look after the interests of all stakeholders, and if for example quality and ease of maintenance is an objective, you do not want an individual who has no idea how to measure the many different facets of software quality, and in the worst case, motivates for or authorises the payment for a project based on a variation of how hard he/she believes the team has worked or a simple user interface demonstration.
Although the following set of concepts are by no means all-encompassing, the candidate should understand and have at least some knowledge of:
- Either explicitly, or in principle, Capability Maturity Model Integration (CMMI)
- Technical debt  and the measurement thereof
- Continuous integration
- Usability measures
- Various sofware development methodologies and their strengths and weaknesses
You will notice that there is a focus on measures above, and this is key. Software development can very quickly degrade into a subjective discipline if left devoid of measures of success, and an entirely subjective process is not engineering, its flying by the seat of your pants. In short, there is simply no way a product owner can do their job without a strong software engineering background.
3. Suitable Personality Traits
Meticulous And Streetwise Leader With Some Charisma
You are unlikely to see this as a bullet point in a job specification requirement as it sounds a bit ridiculous, so lets cull the ‘Some Charisma’ requirement, and we are left with ‘meticulous, streetwise leader’. It still doesn’t sound kosher enough, but lets get to the semantics regardless. When it comes to the leader portion, you can look at the candidates CV for a past history in this regard. So we are left with the meticulous and streetwise requirements. When we say streetwise, it again comes down to experience, on the software development and product development streets, if someone tries to pull a fast one (e.g. try to leave an intellectual property clause out of a contract), your product manager should know the move.
Respectful To Specialist Engineers (And All Stakeholders)
Although the candidate should have a strong software engineering background, over time it is likely that there will be a widening gulf between the expertise of specialist software engineers and the generalist product owner.
You do not want someone who will belittle what they do not understand, and it happens time and time again, especially if the person does not have the required software engineering qualifications and experience to begin with. In the worst case scenario, your product owner will openly show contempt for, and blame failures on, technical team members and in particular developers, rather than investigate the root causes of problems and potential remedies (e.g. seeking the counsel of an independent engineering consultant). In this worst case scenario, your engineers will leave, and the better ones will go first.
Likely To Assume Responsibility For Failure
You want to avoid hiring the type of person who is likely to hide failure and not assume responsibility for it. Here we are entering the murky waters of professional integrity, and the potential for this post to degrade, ad nauseum, into a lecture on ethics. But on a serious note, how does one avoid hiring the kind of person who is likely to be dishonest, or in a different form, only report on successes, but not known failures in order to protect their own interests?
When it comes to this topic, while one can rely on one’s gut feelings, industrial psyhcologists and psychometrists are best placed to advise. Costs might become a consideration here, but one can apply testing on the short list and the money spent here may be some of the best dollars you have ever spent. Based on our own basic research we have determined that role play exercises, rather than questionairres (e.g. Myers-Briggs) are the best placed tools, but again, it is best that you consult with the experts in this domain.