The brilliance of demonstrating benefits over features

I was recently checking out cameras on Amazon.com and came upon the Canon G16. As I was skimming through the voluminous information on its features, I saw a demonstration of value that genuinely impressed me. The feature being described, autofocus, has been standard on digital cameras for as long as I can remember. I take a lot of pictures and almost never focus the camera manually. Nothing remarkable so far. It turns out what differentiates cameras isn't whether or not they have auto focus, but how quickly the camera can focus on an image. Think about that for a second: how can you promote the speed of autofocus in print? Do you create impressive tables full of scientific statistics? Do you say that it's really, really, really fast?

The marketing folks at Canon came up with a simple solution to communicate the benefit (not just the feature) of autofocus speed in a way that will immediately resonate with their target market: non-professionals who take pictures. I would assume almost all of us (especially those with young children) can relate completely to the two simple pictures below. The message? Use our camera and you'll stop missing pictures. It's interesting to note that the message is communicated in a fraction of a second at a basically subconscious level.

What did I (re)learn?

• Listing tons of stats with decimal-precision and colorful graphs probably isn't the most effective way to communicate technical features to non-technicians (technical buyers love pages of stats, detailed scientific bench marking etc.)
• Exploring particularly frustrating aspects of a general problem can sometimes reveal a message that will resonate almost viscerally (not just logically) with your audience (and tip the scales toward "buy")
• Creative but simple approaches to demonstrating benefit and not features may run counter to our sometimes geeky intuition and instincts, but will almost always result in a more compelling message, especially to non-technicians.

Although I believe a marketing professional should be responsible for public-facing messages etc., we as product managers need to understand ideas like "benefits over features" as we a.) should collaborate with marketing on the crafting of messages b.) are often called upon to promote our product.

Next Post: Demystifying the Go-to-market for Product Managers

De-mystifying Go-to-Market Strategy for Product Managers

I've been a product manager for about 15 years, mostly in big shops with mature marketing organizations. Although it's clearly not fair, I've developed an aversion in that time to the seemingly non-stop  flow of buzzwords that the marketing field seems to generate. It was probably about 10 years or so that the term "go-to-market" was thrust on my radar by a senior manager in our product group. While I had certainly heard it before, I had discounted it as just more marketing babble (I realize many marketers have their own feelings about product management babble). Anyway, I asked what it meant and received an answer so nebulous that I wasn't sure if I was just too simple to grasp it or if my "jargon meter" was right on. Since then, I've come to embrace the critical role a go-to-market strategy (or simply "go-to-market") plays in ensuring product success. As a matter of fact, I would go so far as to say that a poorly conceived go-to-market may be the most consistent reason products fail, especially those from software startups.

Let's start with what I consider a reasonably good definition from Wikipedia: a go-to-market "refers to the set of integrated tactics which a company will use to connect with its customers/business and the organizational processes it develops (such as pricing and contracting) to guide customer interactions from initial contact through fulfillment." My cursory research uncovered all kinds of definitions, at times so broad that I couldn't distinguish a go-to-market strategy from what I've always considered a marketing strategy. In my opinion, a marketing strategy and a go-to-market  are related but different, the go-to-market describing how the target markets in the marketing strategy will be made aware of your offering and how they will get their hands on it. A marketing strategy is much broader, including researching market size, creating advertising etc.

Put simply, a go-to-market determines how people are going to find out that you have something they would benefit from buying and how they'll get it. There seems to be consistent blind-spot in human perception that I'll call the "Field of Dreams Syndrome", i.e., if I build it, "they"  will come. Very painful experience across multiple facets of commerce has demonstrated clearly that this is the case a very, very small percentage of the time. Oddly enough, I think this syndrome is related to an adage as old as time about love being blind. We often become so enamored of our own ideas and (our perceived) cleverness that we simply cannot imagine that others won't feel the same.

Perhaps a more intuitive way to understand go-to-market is to consider a fate that has befallen countless internet startups: They dream up a great idea, pull a few bucks together to develop it and then upon launching it realize that they have no idea how the customers they've dreamed of will discover their amazing site or app. Their "baby" is lost in a sea of other sites/apps and the "viral adoption" they hoped would happen is, in reality, a one-in-a-million proposition. A poor go-to-market can handicap any type of business. I know someone who developed a software solution that aimed to make it much easier for private doctors to run their practice. Although getting the solution built was no walk in the park, it turned out that the real challenge was getting in front of enough doctors to drive sufficient revenue to keep the lights on. It's remarkable and unfortunately very common for folks to focus on the problem their solving and the solution their providing while giving almost no though as to how people will find out about the value their solution provides and how they can get their hands on it.

Go-to-market is also highly relevant to existing products and is often revisited for each release. Just because you have established mechanisms for raising awareness and delivering your solution to customers doesn't mean they're optimal. For example, if your company's sales organization is struggling to get in front of decision makers in a given market segment, finding a partner that has developed close relationships to these people might increase sales.

Now that we know what a go-to-market is, how do you go about creating one? What's in it? As you might expect, there are multiple answers to these questions. In an upcoming post, I'll talk about defining a go-to-market, particularly as it relates to the participation of product managers (who, by the way, are NOT typically accountable for defining it).

In researching this topic, I found the first few slides of this presentation particularly concise and informative. As they say, a picture is worth a thousand words...

Next Post: Hitting the ground running as a new PM

You can find more information about me (including upcoming training dates) at www.prickril.com.

Hitting the ground running as a new PM

I absolutely love this post by Rich Mironov on what to do as a PM when you assume responsibility for a product. I've done a fair amount of moving around in my career, between continents, companies and departments so wish I'd had this type of guidance much earlier in my career. The suggestions Rich makes seem right on to me. I heartily concur with the thought of learning your product, for example. One of the quickest paths to credibility with folks from development to executive leadership is knowing your product end-to-end better than any of them. Rich's post got me thinking a bit about the drill I've developed for taking over a new product. I thought I'd share a few of my hard-won insights.

Before You Accept the Position
You should do these things before you agree to accept the PM mission:

1. Understand precisely what management expects from you in your first 100 days.
Whether you're a product manager at a 3 person start-up or a head of state, this initial period often sets the tone for your first few years. Cogitate on these expectations thoroughly -- you'll spend your first couple of weeks (or more) determining how or if you can make these things happen. I would recommend asking this question explicitly of your to-be manager and his manager. If they can't provide you with a clear set of goals, you should proceed very cautiously or not at all; whether consciously or not, you might be being set up to fail.

2. Determine whether your product is "a star, a dog or a zombie" (to use Rich's terms).
Rich is right on about this, but I would suggest you do everything reasonably in your power to determine this before you start. Getting this information may require asking some inconvenient questions, particularly of senior leaders, one or more of whom may be in your prospective chain of command. You should be tactful but not shy about asking for this information. Execs and managers aren't the only source of information on this topic: the more junior the interviewer, the more likely you are to get an unspun perspective. Tread lightly as you research this topic, but make sure you have a good idea of what you're up against and be sure you're ready and willing to face it. It is not uncommon for a change in PM positions to belie deeper problems within the product team. Asking why the person previously in the position left it is a good idea. Tactfully asking others in the interview loop what they think of your predecessor and the PM team in general can also be enlightening.

3. Set expectations regarding your needs during your first few weeks.
If you set the right expectations, you can likely get things done in the first few weeks that you will never get done once you're sucked into the vortex that is most PM jobs. Tell your manager that you want time to learn how to use the product, including taking formal training if necessary. Tell her that you expect to participate in some sales calls and that you may need to travel to talk to customers and your counterparts in the field face-to-face. Realize that you're in stronger position to request these things while you're still being recruited that you will be on your first day at the office. Requesting reasonable investments that will accelerate your acclimation, far from alienating management, can demonstrate a maturity they will often respect.

During Your First Week on the Job

1. Talk to support and review customer tickets
I would suggest before you talk to anyone else, you spend some quality time with the support team, reviewing open tickets and understanding related trends. The number of customers that have opened tickets can give you a realistic picture of how many customers are really using your product, i.e., putting it through its paces in production rather than letting it collect dust (and possibly bad will) on a shelf. Looking for trends in tickets and talking to support professionals can give you a quick impression of the overall quality of the product, exposing problem areas. Getting insight into customers' experience with your product can also be helpful when you speak to them. If there was a relationship-impacting issue in the recent past (or an ongoing one), it's best to know before you get to the customer site.

I recommend that support is the first stop on your initial "good will tour" as understanding the support situation allows you to see through the sometimes distorted view of people within the organization who, over time, have developed a misinformed or even self-serving picture of the health of the product. As I alluded to before, if marketing or executive leadership tells you that 5,000 enterprise customers have bought the product, why have only 30 customers opened tickets in the last year? If development tells you they're on top of quality, why is there a huge spike in tickets after each release, including the reappearance of supposedly solved bugs. Why isn't the number of high severity tickets trending downward?

Arming yourself with data can dramatically increase the fidelity of your overall impression of the product. You should, of course, avoid using this information as a weapon as you talk with others, avoiding confrontation initially, actively keeping yourself in listening mode as you make the rounds.

2. Understand who your critical stakeholders are other than customers
While it's tempting to rush into dialog with customers, you should also do some deep thinking and exploration regarding other stakeholders that are critical to you success. Sometimes they are unexpected. Is your product on the forefront of company strategy or is it in a more supporting or even declining role? Product management of more successful, on-strategy products may be important allies -- develop relationships with them. Is sales highly incented to sell your product? Are they aware it exists? Is there an up-and-coming exec that has it in for your product or management? A change in PM sometimes creates the opportunity for a reset of previously rocky relationships -- take advantage of this "honeymoon period" and invest your time in the stakeholders that can contribute most to your and your product's success.

3. Ask development leadership specifically what they expect from you
Having helped implement product management and Scrum multiple times, I've been the subject of some mighty big expectations from development, some of which I wasn't even aware of when I failed to meet them! During your first week, sit down with development leadership, both those with explicit and referent power, and ask them directly what they expect from you short-term and longer term. If your plans don't align with their priorities, you've got some thinking to do. Disappointing or even alienating the development team from the beginning can be an unrecoverable (fatal) error. That having been said, you need to set realistic expectations about what you can accomplish and continuously manage their expectations. The best laid plans of new PMs can be set asunder once your business cards loose the "new" smell and you're pulled in a hundred different directions. If circumstances change and you can't deliver what dev (or other stakeholders, for that matter) expects, explain why priorities have changed and readjust expectations if you can.

What are some of your tricks and techniques for making the most of your first several days on the job? I would be willing to bet someone reading this can benefit from our input in the near future.

• Related Post: How to become a software product manager
• Next post: Demystifying Go-to-Market Strategy for Product Managers

You can find more information about me (including upcoming training dates) at www.prickril.com.

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?