The "Piles" of Software Product Management

I often see people publishing lists of “pillars” related to a topic, implying that they’ve identified critical underlying concepts or ideas. In this post, I would like to introduce some ideas on software product management (SPM) that I think are even more fundamental than pillars. I call them “piles”. In case you’re not familiar with the term, a pile is a post that is driven through soft ground to more stable layers to support a structure (like a building). These ideas are so fundamental to me that  I often have difficulty discussing software product management theory with people who haven’t been exposed to them. 

Pile 1: Functional vs Technical Perspective

I find it very difficult to have a meaningful conceptual discussion about product management without establishing the difference between functional and technical perspectives. Taking a functional perspective means observing something based on it’s exterior characteristics or how it functions (like a customer does). One can have a deep functional understanding of an object or piece of software without knowing much at all about how it works “under the covers”. For example, I know how to use my laptop but can tell you very little about specifically how it stores data, displays images on the monitor, communicates with a wireless network etc.

By contrast, the technical perspective involves understanding how something works. Someone with a technical perspective sees my laptop as a set of interconnected components leveraging several different technologies to achieve some end.

The distinction between these two perspectives is critical to me because I believe that in the context of a software product, there should be separate accountabilities for each perspective. That means making one person ultimately accountable for the functional view of the product and another accountable for the technical view. In practice, people like software product manager and UX professional are responsible for defining what should be built. Development should be concerned with how to build it. While there is often a gray area between what is purely functional and purely technical, understanding the difference between them can help avoid conflict between functional and technical professionals by providing a framework for sensibly dividing labor and accountabilities. 

Pile 2: The why, the what and the how

We can assess virtually any activity in terms of why we’re doing it, what we should do and how we are going to do it. This paradigm is often referred to as “they why”, “the what” and “the how”. “The why” refers to our motivation for doing something (like building a product). I believe the why is the domain of software product managers. “The why” is often captured as a vision or strategy. “The what” describes what it is we will do or build. SPMs, with the help of UX and other functional professionals, are responsible for defining what a product should do. “The what” is typically captured in requirements, feature specifications and roadmaps (among other artifacts). “The how” represents how “the what” will be implemented. Technicians like developers and architects should be responsible for “the how” and given the freedom to make decisions regarding implementation. Both “the why” and “the what” can be though of as being functional in nature. “They how” is clearly technical (see Pile 1).

Understanding this paradigm can help you avoid the tendency (particularly in software) to immediately jump to “the how” based on some rough idea of a requirement without making sure we do due diligence on “the why” and/or “they what”. This “race to code” often results in features that don’t adequately address stakeholder requirements (although they might look great and function well). 

Pile 3: Requirements vs Features

I’m consistently amazed at how often the terms “requirement” and “feature” are used interchangeably. The distinction between these concepts is fundamental to product management

• A requirement is a statement of need. Period. “I need a place to put my cup while driving that will prevent it from spilling its contents.” is a requirement. It cannot be tested. It simply is. Requirements can be decomposed into almost infinite levels of details. For example, I might extend the “cup requirement” to include the size of cups (specified in centimeters of width)
• A feature is a characteristic of a product from the perspective of someone observing it. Features meet or satisfy requirements. For example, a cup holder could satisfy the requirement stated above. Features can be specified (described) and implemented (so they can also be tested!).

If we consider software product development artifacts, a single entity called a requirement may contain the statement of need and some level of specification regarding the feature or features that will satisfy it. Regardless, understanding and respecting the conceptual difference between this terms has important implications for SPMs. In general, SPMs should gather requirements from stakeholders, avoiding feature requests. Understanding what people’s needs are rather than how they imagine their needs being fulfilled allows SPMs to conceive of creative solutions to customer problems that also support other product goals, like minimizing the cost of development. In the future, I’ll write a post dissecting the use of requirements rather than features as the “currency” in interactions with stakeholders.

It is very likely that I will refer to these piles in future posts and very likely elaborate on them. Do you have piles of you own you can share?