Hiring A Software Product Owner – Key Candidate Measurement Criteria

Measurable Engineering Excellence Should Matter To Your Product Owner - Not Simplistic Perceptions of Hard Work

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

Elementary Filtering

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.

Secondary Filtering

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:

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.

Broadbanding – pay plans that reward role based expertise

A few years ago, while on a real-world business mentorship course, our mentor suggested that we structure the pay plan of our sales consultants in such a way that if the person excelled they would be able to out-earn the top brass in the company.

This idea struck a cord with me, but I never knew what to call the concept or thought it through, thankfully Buckingham & Coffman have explained the concept of broadbanding in their book first, break all the rules.

Some of the key tenets of broadbanding are as follows:

  • It is an incentivisation and career path planning tool that managers use to focus employee energy at performing to the best of their ability within a role.
  • Excellence in a role is valued & rewarded to a higher degree than average performance in a role.
  • If you take on a new role that amounts to climbing the ladder, e.g. being promoted into management, you have to take a risk  and pay cut due to the overlap between bands and since you will initially drop to the bottom of the band of the role higher up on the ladder.
  • If you do climb the broadbanded ladder, e.g. into management, you stand a chance to significantly increase your pay if and only if you excel in that role since the ceiling of the band is higher.
  • With excellence in your role, you can earn significanly more, up to hundreds of percentages more, than your manager or others higher up on the ladder.
  • A broadbanded pay plan should take roles that are intrinsically more valuable than other into account. In other words, there is still some degree of hierarchy since some roles are simply more valuable than others.

I’m completely sold on the concept. I have always thought that it makes no sense, and is also unfair, to force say an excellent software engineer, who loves their job, to become a project manager, or any other manager, when they are worth their weight in gold in their role. It also makes no sense for their manager to possibly get paid more than them, simply because they have that title.

A key part of this of course is that one has to know what excellence in a role is, clearly define it, then identify it, to even be able to consider applying broadbanding. So in essence, while its a great concept, in my mind without the application of requisite performance management in an organization, at all levels, from entry level to board level, broadbanding does not stand a chance.