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?