Lost in space(s): Does product management address the problem or the solution space?

In discussions regarding the roles of various disciplines in product development, it's not uncommon to hear folks differentiate between the problem space and the solution space. While the distinction between these concepts is reasonably clear, mapping them to product development roles is not always as straightforward, especially as it relates to product management.

As its name implies, the problem space comprises the information relevant to a problem. In the context of product development, we can think of the problem space as the set of customer problems we plan to address with our product (a problem is simply an undesirable situation). Understanding the problem space is critical in the context of both new product introduction and existing products. Problem space understanding for new products helps ensure you are solving a real, as opposed to perceived, problem. It's also the first step in determining if you've identified a problem people or organizations are willing to pay to solve at a price point that can sustain your business. Understanding the problem space for existing products is important as typically, the problem space is not a static concept: it changes over time as markets evolve. I talk a bit about the risk of neglecting the problems space later in this post.

The solution space comprises all the products and solutions that can solve problems identified in the problem space. If I'm feeling pain around opening beer bottles, a bottle opener is a potential solution and thus included in the solution space. It's important to note that a given problem can often be addressed by multiple, wildly different solutions. A lingering but apocryphal legend contends that two radically different solutions were found for writing in zero gravity during the Space Race: a sophisticated pen with pressurized ink (NASA) and a pencil (Soviets).

Treating the problem and solution spaces differently is important or even critical as it can help avoid the common human tendency of conceiving of a solution and then trying to find a problem it can solve. This trap is especially evident in the world of software as development costs can be relatively low and production costs are almost non-existent (producing CDs/DVDs or placing an installable version on a server tends to be a fraction of what producing physical goods often costs). Separating the two can also inspire teams to find creative solutions to problems, sometimes at much less cost and effort than more obvious solutions.

Understanding the evolution of the problem space over time and the solutions available to your target markets can help you respond more effectively to customers' changing needs and the changing environment in the market. We need look no further than household brands such as Blockbuster or Blackberry to find companies that apparently didn't fully understand the problem space sufficiently and failed to develop new solutions that were compelling in a changing technological landscape. Blockbuster may have been focusing on making renting DVDs simpler and less expensive when their customers' real problem or need was watching movies at home with as little effort as possible.

If we consider the various disciplines involved in software product development, some are easy to map to the problem/solution paradigm. Engineering, for example, is primarily involved in the solution space, actually developing the solutions that are taken to market. Other disciplines such as marketing often span "the spaces", providing insight on problems faced in the market and describing the key characteristics of possible solutions, sometimes based on solutions already being offered. Understanding where product management falls relative to the product and solution spaces is the subject of more debate. There is a camp that is of the opinion that product management's sweet spot is in the problem space, leaving engineering to define the appropriate solution. Others feel it's critical that product management, especially software product management, keep a foot planted on both "sides". Based on my worldview and painful experience I am an unflinching proponent of the latter.

I see product management as a critical bridge between the problem and solution spaces. I base this assertion on a couple of assumptions:

1. First-hand, intimate knowledge of the problem space is required to define a compelling solution
2. The solution space must be continuously shaped by professionals with a functional, rather than a technical, perspective.

I think the idea of product managers helping to define the problem space isn't particularly controversial. Without a thorough understanding of the problem you're solving including empathy for the consumers of your solution, identifying the optimal solution becomes almost a matter of chance. In some organizations, marketing also plays a role in defining the problem space. However, in my opinion, detailed knowledge of the problem space is simply too critical for product management to consider "outsourcing" problem space definition entirely.

The second assumption is a bit less obvious. As I've described in a previous post, the functional perspective addresses solutions from the outside in, with relatively little regard for the technical implementation of the solution. The technical solution addresses how a solution is actually developed or implemented. Staying on track throughout a development cycle requires establishing a delicate, ongoing balance between the functional and technical perspectives. Product managers must define in detail what the solution must do. Development takes this definition as input and defines how it will be implemented, e.g., using which technologies. While most engineers are creative people with great ideas, their clear focus should be implementing things as quickly and robustly as possible, not defining how an application should behave. Since the UI is very often critical in terms of product usability and success, development should also get direction from another functional discipline: UX. If we take a simple example of a weather widget for the desktop, PM and UX should define its height and width, what information is displayed, what colors are used, customization options etc. Development's job is to create the widget with high quality and perhaps with enough flexibility that it can easily be adapted over time.

A common mistake is to confuse the functional and. technical perspectives with levels of detail. I've heard more times than I can count that product managers define products at a high level, with development filling in the details. The truth is, there are varying levels of detail from both function and technical perspectives. I contend that product managers need to define products with a high level of detail but from a functional perspective. Although in some cases development has sufficient awareness and willingness to define the details correctly, more often than not their technical perspective will result in solutions that aren't optimal for the non-technicians that must use them (assuming the primary users aren't developers or architects). Product management and other disciplines such as UX must provide continuous guidance and advocacy for stakeholders at a level of detail that ensures that the product doesn't end up being something only a developer would love. Once again, I speak from painful experience on this topic.

In my experience, the key to defining compelling solutions that meet or exceed business objectives over time is creating a bridge between the problem space and solution space, not lobbing requirements over the chasm and hoping technicians build what you expect. I've seen this approach fail (first hand) so convincingly that I now reject it prima fascia. In my experience, product management must build this bridge and straddle it, continuously shaping the solution based on their evolving knowledge of the problem space, their experience and their knowledge of stakeholders.

It is also important to create the right balance between the functional and technical perspectives. Marketing should help define the problem space but at the level of high level requirements. PM (with the help of others like UX) should focus on what should be built, freeing engineering to focus on how the solution should be implemented.


Next post: Hitting the ground running as a new PM

Nail the Press Release BEFORE you start development

I read this brilliant post by Werner Vogel what seems like ages ago (2006) and have been both inspired and haunted by it ever since. I've been inspired by its simplistic genius. I'm haunted because I haven't consistently implemented one of the ideas it contains to the fullest extent possible: creating a press release before you begin development on a release. Contemplating how you'll position a release in the markets you serve ahead of time can help you:

• Determine if you're delivering sufficient scope to seem compelling (right number and quality of "top level" features)
• Gauge the excitement the release is likely to generate (if you're not familiar with the Kano Model, you should be!)
• Better manage changes to scope during development

I would recommend enlisting the help of marketing to draft the press release. I don't think it's critical that all i's be dotted nor t's be crossed, so a list of bullets representing the key message would be sufficient. That having been said, spending some time wordsmithing the press release will make it easier to put yourself in the intended audience's shoes -- an important element of this exercise.

Once drafted, you should socialize the press release with other product stakeholders, including senior management to ensure they are on board with your approach and priorities. If your product is part of a portfolio, you should consider sharing the press release with other product managers. There's a reasonably good chance you'll get different feedback on the release with this format than you might from a simple set of bullets on a PowerPoint slide.

Finally, revisit the press release with marketing during the release to assess the impact of scope changes on key messages. Unfortunately, in my experience, these checkups have always been an exercise in assessing how de-scoping features will affect the overall message. One of the most painful experiences of my career was watching scope dwindle to the point that a press release was barely possible. I must admit, thinking about the press release made this dip below critical mass fairly obvious to all involved (including development, who seemed satisfied with the huge progress they had made on features that we couldn't position with customers).

Is product management itself the most overlooked product in our community?

I've spent considerable time lately thinking about the effectiveness of product management in product development organizations, particularly in the IT industry. In attempting to define a comprehensive framework with which to assess product management organizational maturity, I am struck but the lack of thoughtfulness and rigor many organization apply to product management itself (I am as guilty as anyone). As with all corporate functions, the outputs of product management can be viewed as a product: PM organizations have a mission, stakeholders and a valuable  "offering" that deserve to be conceived, designed and delivered in a way that maximize the conspicuous impact of PM on delivering great products. You can think of the product vision, requirements and specs as a multi-faceted product or even as a portfolio. I don't think it's a secret that our discipline suffers from a general lack of understanding about to what we do and a sometimes nebulous set of expectations that have left some questioning our contribution to the businesses we serve.

Although I've found the exercise of defining a PM maturity model fascinating at an abstract level, it's left me wondering if, in practice, product managers and their leadership have taken the time to assess the direct value they generate (and the perception of that value) to the extent they have the products they take to market. I can't help but think that if we applied many of the same principles and effort to our "offering" as a discipline as we do to our products, our contribution  would be better recognized and our professional standing among other product development disciplines and executive leadership would improve.

This may be a radical or at least counter-intuitive thought, so let me restate it as simply as I can: We product managers deliver value to others involved in product development. The value we deliver to the organizations for whom we work is a product and should (at least some of the time) be thought of that way.

Here are a few questions product management organizations should be asking themselves:

• Do we know who all our internal stakeholders are, the influence they have on our ability to add value and what they expect from us?
• Are we seen as a high performance team delivering the business insight technicians are expecting more and more of?
• Is there "pull" (in the Lean sense) for our "product"
• Are we positioning our contribution in such a way that others see its value clearly?
• Do we understand the work product we deliver and are we continuously looking for ways to improve it to add even greater value?

It seems ironic and a massively wasted opportunity if we can't focus our PM skills on the work we deliver to the product development organization and make those "customers" happy.

What do you think? Have you thought about the overlooked product you must deliver to others before you can ship the obvious product you the whole team works so hard to ship?

What artifacts are required for software product development?

It’s painfully clear to anyone who has spent much time in software development that there is no shortage of software development methodologies and frameworks, many of which define artifacts that should be produced to provide the necessary information and context to software product stakeholders like customers, executive leadership and engineering. Scrum defines the product backlog for example, a compound artifact comprising user stories describing what the product should do in such a way that development can build it.

The sheer number of artifacts with names like marketing requirements document (MRD), product requirements document (PRD), functional specification and backlog can be daunting to organizations interested in adopting product management or to professionals considering a career as a PM. A common question from neophytes is “What artifacts do I need and what should they contain?”. Frustratingly, you will likely get a different answer from everyone you ask as almost all reasonably mature organizations define their own set of artifacts that are used to capture information about the market, the problem space, customer requirements and functional descriptions of the product that engineering will build. These artifacts may be described as part of an internal methodology, often based on standard approaches such as waterfall or Agile/Scrum. Most people who have joined multiple PM or development organizations during their career have experienced the sometimes steep learning curve associated with understanding which artifacts must be generated in that organization, what they contain and who is accountable for them.

I was recently faced with the problem of assessing the completeness of a product management organization's artifacts. One way to approach this problem is to find or concoct a reference set of artifacts and do a compare/contrast with those of the organization. However, because of different development methodologies and development practices, there isn't a reference set of artifacts that I believe would be appropriate for every organization.

I decided to approach the problem by taking a step back and defining the types of information an organization would need to do a reasonably good job of planning a release. This thought exercise led me to distinguish between information one would need that is specific to the release such release scope and information that by its nature impacts multiple releases, a roadmap for example. I call these "categories" of information "release-specific" and "multi-release", respectively.

It turns out the list of types of information required was much larger than I anticipated (around 25 and counting). In a series of posts, I'll share what I consider the key release-specific and multi-release information types. Beyond getting feedback on this approach and its contents, I'm hoping this list will allow others to:

1. Validate a set of artifacts for completeness
2. Define a sensible, complete set of artifacts if your organization is just beginning the product management journey.

I will also try to map the types of information to standard artifacts types you find in many organizations and in PM literature. This should also give you an idea of what you’re likely to encounter, in one form or another, in many, if not most, big shops. It is worth noting that the set of artifacts defined by an organization and their content depend on many factors, including the product’s life cycle stage. For example, an organization may collect different types of information at differing levels of detail depending on whether the product is being introduced to market or is stumbling toward sunset. Organizational accountabilities, the size of the organization and practices that have developed organically over time may also influence how many artifacts are created and what they contain.

Critical Multiple-release Information

In this post, I’ll focus on non-release-specific information that contributes to planning a release. As I mentioned previously, my analysis revealed a far greater number of "information types", but these are among what I consider the most important. These types of information provide important context, guidance and constraints for release-specific documents. Multi-release information is often refreshed as part of the release planning process to ensure they reflect the current environment in which the product is being developed.

1. Problem space

The problem space is a mental representation of the current as-is state and the state that represents a solution. A product team should clearly understand the problem space they’re addressing or run the risk of solving the wrong set of problems. The problem space requires the product team to understand customer pain, the forces shaping it and the nature of the desired future state. The problem space itself is so fundamental that it is often insufficiently articulated, leading the team to inadvertently attempt to solve fabricated problems or address pains that are not compelling or, in the worst case, even real.

For example, vehicle airbags address the problem space of passengers being injured during collisions. Understanding the problem space instead of focusing on existing solutions lead engineers to develop airbags instead of simply trying to continuously improve seat belts.

Often Included In

The problem space may be articulated in an MRD or a strategy document. Often, organizations do not capture this information at all.

Accountabilities

In some organizations, a mature marketing organization may be responsible for defining the problem space as the problem space is not product-specific; in others, this is the domain of product management.

2. Business Motivation

Organizations and products need to define their “motivation” (à la the OMG Business Motivation Model), including the vision, goals and objectives. The vision is a desired future state that inspires stakeholders. The vision is “amplified” by goals that are decomposed into measurable objectives. Misalignment between the organizational and product motivation models must be rationalized over time and the model adjusted as necessary. If the organization and/or the product haven’t defined where they’re going, how they plan to get there and how they’ll measure success, there’s a better than average chance they will spend much of their time thrashing, following multiple paths to nowhere. For an overview of the OMG Business Motivation model, see my previous post or the OMG spec.

Often Include In

The vision and other components of the motivation model are often captured a vision paper or as part of a strategy paper.

Accountabilities

Executive leadership is responsible for the company’s motivation; product managers own product motivation. In my experience, the latter sometimes has to put gentle pressure on the former to get a motivation model that is detailed enough that concept-by-concept alignment can be done.

3. Market Information

The market is the often complex environment in which the product will be sold and consumed. It comprises sellers, buyers and so-called market forces that shape needs and influence buying decisions. Markets are often segmented to form groups with similar pains and needs. Segmentation typically results in the identification of the target market, i.e., the segment of the market you will pursue with the product. Information about markets and related trends typically influence multiple releases, although some information and the associated assumptions change or are invalidated during a single release.

Often Included In

Market information is often captured in an MRD or a strategy document.

Accountabilities

In most mature organizations, marketing is expected to provide market information to the product management organization. In practice, many SPMs find themselves "rolling their own" when it comes to acquiring the necessary market insight.

Product Alternatives

Many organizations focus on competitors, but the truth is that competitive offerings are simply a type of alternative available to potential customers of your product. In my career as an SPM, customers building their own solutions was often our biggest competitor, i.e., customer alternative.Truly innovative ideas may face no competitive offerings, but it’s critical to remember that customers still have options (like doing nothing).  The competitive environment can be considered part of market information but can be so voluminous and rich that I call it out separately here. I find Porter’s Five Forces to be a valuable model for assessing competitive forces in a chosen market.

Often Found In

Information on competition finds its way into a variety of artifacts like strategy documents and MRDs. Although it typically has multi-release implications, competitive information should be refreshed during release planning, even if only to validate that they environment hasn’t changed significantly. Many organizations do a poor job of assessing customer alternatives beyond competition.

Accountabilities

Information on alternatives, particularly competitive information, are often the accountability of either marketing or product management. Accountability within an organization often depends on factors such as skill set and available resources

Business Justification

A business justification enumerates and compares the business benefits expected from the product with the investment required to bring it to market. Although the basic relationship of these variables is at the heart of most commerce, plenty of products go to market with poorly conceived business justifications or no real business justification at all. Business justification is more common in products that are being introduced to the market. In that respect, their content is relevant to multiple releases.

Artifacts

Business justifications often take the form of a business plan, although this term connotes more rigor and formality than is sometimes necessary. Regardless of where you park the information, you should demonstrate that there’s a solid business reason for making an investment in your product.

Accountabilities

The business justification is often captured in a business case or sometimes in a strategy document.

Roadmap

Roadmaps capture the evolution of the product over multiple releases. Traditional roadmaps define a set of milestones representing release dates and enumerate the features and functions to be delivered. You should think of the roadmap as providing detail on how the vision will be realized. Delivery models like SaaS are changing expectations relative to roadmaps in that theoretically, features can be released as they become ready, rather than packaged up and released together

Artifacts

The roadmap can be captured in a roadmap document or is sometimes included in a vision document or strategy document.

Accountabilities

The roadmap is the clear accountability of the product management organization in my opinion. Although it is sometimes delivered by marketing, I question this practice as marketing doesn't typically develop and release the software. Marketing often plays an important role in tailoring the roadmap to various audiences.

For the sake of brevity, I've omitted many other important types of information. I'll address others in future posts. What do you think of this approach? Is your organization capturing these types of information in your artifacts?

PM Around the World

I spent about half my career as a product manager in the US, my home country. In 2007, I moved to Germany and have lived here (happily) ever since. My perception that our discipline is a bit less mature on this side of the pond was to no small extent shaped by the fact that I came to help establish product management at a large software company. Since then, I’ve had this nagging feeling that product management isn’t as well established in Europe as it is in my homeland, although one has little trouble finding PMs here. 6 weeks ago or so, I started this blog. The Blogger stats on the location of visitors would seem to confirm my suspicions, although my findings are far from scientific (I was a point or two away from flunking statistics in college).
 

I expected a large percentage of traffic from the States but was a bit surprised at the massive proportion. I also expected Israel to be disproportionately represented (I have some experience with Israeli software firms and sensed that product management is well developed there {I also read Mr. Steinhardt of Blackblot’s stuff regularly}). I can tell from comments and forum activity on LinkedIn that India has plenty of (very thoughtful) PMs.

Although I’m not completely surprised at the geographic distribution, I’m also not sure exactly how to interpret the massive preponderance of hits from North America. Does it mean that product management simply hasn’t caught on in much of the rest of the world? Is it because I blog in English and promote my blog on LinkedIn (also in English)? Does it mean there’s less software development going on in other countries? Once, while poking around for PM jobs in Brazil (where I’ve also lived and worked), a recruiter told me that there simply wasn’t sufficient software product development there to sustain much of a PM community. I hope it's obvious that I'm not trying to draw scientific conclusions from anecdotal data, just curious if it conforms to other people's assumption about PM mind share around the globe.

Pondering the meaning of the numbers reminded me of conversations I’ve had with European headhunters and others regarding American- vs. European-style PMs. The perception seems to be that American PMs are more empowered and assertive. Conversely, European PMs are expected to do product definition work with more constraints and guidance from above. I realize these are generalizations, but they don’t seem to be way off the mark based on my experience.

What do you think?

Project to Product: An Introduction

I’ve recently stumbled upon a few companies that are thinking seriously about or are in the process of making the transition from a software services/project-oriented business to a software product business. I must admit during most of my career this type of evolution was not on my radar at all. I was a consultant for several years in the 90s, but for a major software vendor (IBM/Lotus) building customer-specific solutions on top of an established software portfolio. I didn’t have much insight into more traditional consulting firms that develop client-specific software from the ground up as part of consulting projects. It turns out that transitioning from a services organization that delivers software assets as part of a project to a company that ships products can be far more challenging than it might first appear. This change also raises plenty of fascinating questions about all kinds of software development topics, including software product management.

As these consulting/services organizations rationalize software re-use over time, they sometimes reach the conclusion (for various motivations I’ll address later) that they would like to ship “proper” products rather than customer-specific software assets. Although transitioning from a services-based business model to shipping products can affect virtually every aspect of a development organization, I’ll first focus on product management in future posts after laying a little ground work. Truth is, this topic is so complex and rich, I could probably write for months on the topic.

One of the things I’ve noticed in each of the companies that I’ve observed is the immediate struggle with terminology and concepts when the idea of developing products is broached. You might assume most people who develop products could understand the idea of a software project readily. Software releases have historically been managed as projects after all. You might also assume that folks delivering custom software projects for specific customers “get” products. I mean they buy products of various types regularly, including software products, right? However, in each of the cases I’ve seen, it was painfully evident that this assumption is completely wrong. In particular I’ve seen significant difficulty with project-oriented professionals understanding what a product is and what the implications of product development are to a software development organization.

Let’s quickly take a step back and define a key term: product. Although there is no shortage of definitions of this term (just ask Google), in my mind, a piece of software classifies as a product when it is delivered in the exact same form to multiple customers and is managed throughout its life cycle at these customers. That means no customer-specific versions or forking the code for every new customer project. Every customer over time has essentially the same executables and calls the same support line if (let's face it, when) there's trouble.

It is also helpful to define the term “solution”. I consider a solution an aggregation of products, services and other solutions that solve a customer’s problems. Solutions are important because services-oriented companies typically don’t deliver a software product alone -- they sell products as part of broader solution that often includes a significant amount of consulting and customer development work.

So what might motivate and organization to deliver products? Here are the ones I'm most familiar with:

Profitability
After years slugging it out in competitive situations for each project and developing software that only a single customer can use, the idea of building something once and selling it to a number of customers that is often an order of magnitude greater than the current client base can sound very attractive. It seems attractive on the revenue and cost sides (developing one thing instead of many things at least seems cheaper). In a future post, I’ll articulate the key differences between a services-oriented approach and shipping products, including the revenue model.

Valuation
Some companies would like to go public or get acquired. Typically, a company selling products is valued much higher than a services company as the latter has a built-in constraint on revenue: the number of person hours available to bill (these firms, of course have other ways to generate revenue, but the number of billable hours for a given workforce and "cost plus" pricing are clearly constraints). My cursory research shows that, ceteris parabis, a product company is valued at a much higher multiple (of revenue) than a services company.

Support Cost and Complexity
Once custom solutions have been delivered to multiple customers, often with slightly different versions of the same code base, organizations realize that the cost of supporting all these versions and managing the concomitant development complexity is unbearable. The notion of having a single software product that evolves and is managed holistically can be irresistible to these firms.

Customer Perception
Some firms feel pressure to move to the product paradigm because their customers want the perceived security of buying a product rather than what they perceive as a bespoke solution cobbled together during a project. Products have track records and other customers that can share knowledge and experience. The upshot is, organizations with products are often perceived as being more mature and thus more reliable.

In my next post on this topic, I'll discuss the perennial challenges or hurdles I see these organizations facing as they attempt to make a profound change to their organization, its process and roles.

Do you know of organizations considering making this change or already engaged in it? What was their motivation?

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?