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?