What I look for in an SPM candidate

I recently wrote a post giving some tips on making the transition to software product management (SPM), particularly for people already involved in software product development. The resulting discussion got me thinking about what I’ve looked for in SPM candidates over the years. I’ve done at least my fair share of interviewing during my career for teams I was managing, teams I was on and other products’ teams as well. Below, I’ve tried to identify the characteristics I consider most important for an SPM candidate beyond basic professionalism and SPM experience. Although many organizations have guidelines for interviewing and hiring, assessing candidates clearly has a significant subjective element, so you should take this post for what it is: one person’s (educated) opinion about what separates a great candidate from the good, the bad and the ugly.

Smart > intelligent
This is clearly a matter of semantics, so I would first differentiate between people that are really intelligent (have high IQs, for example) and those who are smart, which to me means the ability to combine abstract knowledge, practical experience, common sense and guts to find the optimal solution quickly. Being an SPM means continually making critical decisions without having all the information or time you need. Gaps in the facts must be filled with a combination of judgment and intuition while the clock is relentlessly ticking. Smart people know when they don’t have enough information to make a decision and when they have just enough input to deliver an important decision in a time frame that’s relevant. Very intelligent people that aren’t also smart can overlook the importance of timeliness and wait too long to collect what they consider a complete factual basis for a decision. People that are intelligent and not smart can alienate others (sometimes inadvertently) by continually trying to prove how clever they are. Smart people understand that they don’t need to be the smartest person in the room to facilitate efficient interaction and get the job done.

I’ve interviewed and worked at multiple companies that think it’s clever to ask a few questions that test candidates’ raw intellectual horsepower. It was part of their culture. While I understand their intent, I’m not convinced a Mensa membership or the ability to calculate the probability of a particular poker hand will make you a great SPM. I guess these types of questions could be used to differentiate the top few candidates, but I always found the practice a bit misguided and sometime even inappropriate, particularly for senior positions.

In my experience, a great way to get smart about products is to spend time in the field delivering solutions under tight constraints. Consulting can be a great way to develop product smarts (I elaborate on this point below).

Experience over education
I’m a big fan of higher education, but I would much rather have someone who has proven themselves as a product manager, even in a limited capacity, than someone who has an Ivy League MBA but hasn’t spent months in the emotional grinder that software releases can be, maintaining their sanity and passion for the job. This criterion may not be encouraging to those without SPM experience, but the truth is all of us want to know an experienced contractor is at the helm before they tear up our bathroom for a remodel, regardless of their training pedigree or certifications. The same applies to a critical SPM job. A bit more latitude can obviously be given if the position in question is a bit more junior, e.g., owning a set of features rather than the whole product.

Resist rushing to a solution
I usually give at least one design problem to a candidate in an effort to assess how systematically and efficiently they approach the solution. One of my favorite scenarios is asking them to design an elevator system for a building with 10,000 floors. Technicians like developers and architects sometimes get carried away with a creative technical solution without doing the critical ground work required to identify the requirements and constraints that must be considered to identify the optimal solution. If a candidate doesn’t start with identifying key assumptions such as the nature of the building, e.g., commercial vs. residential, little else they say is likely to impress me. I look for candidates who dedicate at least the first 20% or so of their response to asking me questions. I then expect them to quickly identify all the key stakeholders. In the elevator problem for example, I expect them to identify the economic buyer of the elevator system and what their key motivators are. Inexperienced people will consider only the needs of the riders of the elevators, overlooking the fact that the people paying for the solution need to conserve physical space (which ostensibly impacts the profitability of a commercial building) and tightly manage costs.

Software life cycle knowledge
I’ve recently been involved in discussions on product management with folks outside of software. While many of the basic principles of product management are not dependent on the product domain/industry, an SPM needs to understand what it takes to develop software, the stages of development, the strengths and weaknesses of various development methodologies and other software basics. SPMs almost always have to lead by referent power (as opposed to explicit power), so the inability to relate to developers, understanding their agenda and pain, can be a lethal deficit. I think a superstar from non-software PM or a candidate for a relatively junior position could be hired on potential, but I still consider it a significant risk.

I once interacted extensively for a period of time with a member of a team that defined methodologies for a huge software company. I was so impressed with his business insight and enjoyed working with him so much that I broached the topic of his working on my team as a PM. As we began talking about the the SPM team's relationship with the development organization, he bluntly asserted “I have no idea what developers do all day.” It was huge surprise to me and a deal-breaker in terms of any meaningful role on the team. I’ve seen SPMs that were such effective leaders or were so respected for their business or field knowledge that an understanding of the intricacies of software development wasn’t critical, but they are very clearly the exception (a single-digit number of people).

Self-assuredness bordering on arrogance
The most effective SPMs I’ve worked with had an air of self-assuredness that initially could be mistaken as arrogance. Let’s face it, getting a diverse set of stakeholders to buy into your vision and be convinced that you can actually deliver on it takes some chutzpah. I would also say that there’s a very fine line between strongly believing in yourself and being arrogant. Candidates that sing their own praises without acknowledging the contribution of others or don’t have a track record of successes to back up their attitude don’t get to far in interviews with me.

Ability to be self-critical
This may be a general criterion that I find important for any job candidate, but given the hubris one finds in many SPMs, being genuinely self-critical is particularly important for people pursuing this role. Being self-critical may seem on the surface contradictory to the idea of someone being self-assured (see previous point), but it is the “other hand clapping” that keeps successful SPMs grounded. I typically ask candidates what their biggest professional failure was milliseconds after enabling my highly tuned bullsh*t detector. I’m not looking for clever interview responses with transparent attempts to couch a strength as some sort of weakness, à la “Sometime I pay too much attention to detail” or “I sometimes work too hard”. I look for a bit of discomfort as they tell me about an instance in which they tried something ambitious and clearly failed. In general, the bigger the failure they’re willing to share, the more points they score with me. I of course probe further to convince myself that they learned from their failures and that failure is the exception in their career rather than the rule. It has become clear to me over the years that if you don’t have painful stories of failure, you either haven’t been tested in a sufficiently challenging environment or you have held back, avoiding the truly risky work that separates those who are attracted to the “bleeding edge” from those that are skilled at staking a safe, career-building course. As a job candidate, formulating a response that is sufficiently forthcoming without alarming the interviewer excessively is dicey. This is exactly what makes probing this characteristic so enlightening and valuable.

Consulting experience
I mentioned the importance of consulting experience in my original post but didn’t elaborate much. A few years in software consulting will almost inevitably take you through the entire development process multiple times in an environment in which effectively managing budget and scheduling constraints means the difference between a profitable engagement and a financial sinkhole that can damage the client, the reputation of the consulting organization and the engagement team. When college grads ask me what they can do to become a product manager, I invariably suggest they seek a challenging role in consulting first.

Heart
I realize this is an imprecise term, but I ALWAYS look for someone who has what I can only characterize as “heart”. People with heart will push themselves and the rest of the team to their limits not because they want to advance their career or because they seek personal glory, but because they have pride in what they do and desperately want to help the team win. People with heart have often overcome significant adversity in their personal and professional lives to get where they are and will keep swinging long after others have given up.

I once had to fill a position from a pool of internal candidates that was less than ideal. One of the rather meek members of the development team applied, generating all kinds of water cooler discussion and plenty of dismissive statements made directly to me. Although she didn’t have a track record as a leader and clearly didn’t have the full respect of her co-workers, I hired her because it was clear to me that she had battled those same perceptions throughout her life and had managed to keep her head above water, even in a very challenging professional environment (that shop was a real pressure cooker!). With a little conspicuous support and one-on-one coaching, she surprised everybody by growing into an effective and decisive SPM that was respected by the team and leadership. It was a pleasure to work with someone who was humble yet ambitious and was willing to bite off more than she could chew at times to make things happen. Remembering her inspires me to this day

Summary

I realize this post may alienate some people and that other folks have different priorities. Regardless, I hope sharing my personal priorities or even biases will encourage others to share what they find important in SPM candidates. I take hiring very seriously, considering it a critical process in any organization and one that surprisingly rarely gets the thought and attention it deserves. For every Microsoft or Google that has a highly effective and even grueling hiring process, there are thousands of other organizations that leave candidate selection to the subjective whims of a few people that conduct superficial and ineffective interviews. I'll post more on interviewing later.

Now that you know how I feel, what characteristics beyond basic professionalism do you look for in SPM candidates?