It’s ALWAYS been the Problem

When I started working full-time with Agile development techniques in 2004 I also had the good fortune to start working with the concepts of Pragmatic product management. What quickly became apparent to me is that the two approaches in their respective fields were beautifully suited to one another.

By articulating the market problems, the nature of the people who have them, and the circumstances under which they experience those problems, Pragmatic product managers communicate to development teams what is really necessary to build great solutions; context. We've all heard the stories of how the software industry's predilection for waterfall methodologies from the 1970's through the 1990's led to an inordinate amount of 'failed' projects. Early proponents of agile development techniques ascribed those failures to the waterfall process itself, rightly arguing that performing development tasks (specifically testing) in phases and a lack of iterative feedback were the biggest causes of these 'failures'. However, I would contend that just as large a reason for those 'failures' was product management's inability to communicate what was actually required for those projects to be successful. Too much emphasis was placed on building to a specification which had often been created and disseminated without providing sufficient context to the people responsible for providing solutions. Because of this lack of context there was no framework for negotiation with a customer or stakeholders and therefore much of what was built was not actually required to meet the customer's needs. This resulted in unnecessary delays and cost overruns at a minimum and often the creation of ineffective solutions which quite rightly were considered 'failures' regardless of whether they met the specification. Even if the solutions were built iteratively, the focus on the specification, rather than the problems in context, might very well have led to the same ineffective solutions.

Many software development companies do not have the luxury of having real-time access to actual customers. Nor is the concept of building a product based on a single customer's requirements necessarily attractive. Instead these companies rely on their product management organizations to represent the needs of customers within a market. There is a hierarchy of proxy which is created as a result. The customer is a proxy for the market and the product manager is a proxy for the market. If the product manager is too busy performing strategic tasks and does not have time to fulfill his product ownership duties for the team then a proxy of a proxy is incurred with all the risk that entails.

All too often, agile projects rely on an internal 'product expert' to act as the team's Product Owner. The danger of this is that the product expert understands the existing incarnation of the product very well but may not have the viewpoint of a customer who has issues with the product. Properly implemented agile development techniques usually provide the transparent and tangible progress necessary to make informed business decisions. However, without a clear sense of the relative value of the problems to be solved it is difficult for the team to understand and embrace those business decisions. This is where the value of the MRD resides; providing the context necessary for a Product Owner to make sound decisions throughout the development process on behalf of the product manager.

In the end agile product ownership is a subset of all that a product manager is responsible for. From a Pragmatic perspective, product ownership entails the 'Product Planning' tasks of the product manager: Market Requirements, Road Mapping, User Personae, User Scenarios, and Release Milestones.

The Pragmatic Market Requirements Document (MRD) focuses on market problems, the people who have them, and the situations under which they experience them (scenarios). It also focuses on valuing/prioritizing those problems, people, and scenarios. Hmmmm ... sounds suspiciously like a good start on a backlog of stories! A story used in an Agile project usually takes the form of: A <type of user> needs to be able to <perform some action> in order to <get some value>. This is essentially a statement of the circumstances under which a user experiences a problem. I suppose technically it is an anti-problem as the real problem is the users inability to get the required value by performing the desired action. Nonetheless there is a direct correlation between the primary elements of a Pragmatic MRD and a product backlog used in an Agile project. Each scenario is prioritized using the following additional context: impact, frequency, and criteria. The value to the persona of solving the scenario, the frequency with which the persona experiences the scenario, and the value to the to the Product Manager /Business of solving the scenario, all provide valuable context necessary for establishing business priority. Once these scenarios have been prioritized, the product manager has a solid starting point for a product backlog. Further, the entire team has a solid understanding of what problems they are trying to solve and for whom, and what the relative value of those problems is to both the market and the business. With this context, the team is much better equipped to be able to produce solutions appropriate for the target personae and any decisions around solution options/modifications can be made in the context of the user and the business value.