Recently, I delivered a webinar on product definition. It was a popular topic, with almost five thousand people registered and over 2000 attending live. I also addressed some open questions in a podcast discussion with Patricia Kong, PO of Learning, here at Scrum.org. The topic attracts many as they adopt the Agile Product Operating Model (APOM). Defining a product is essential when your operating model is based on products. The discussions and questions following the webinar opened my mind to many interesting threads I would like to pull on.
To remind everyone of the fundamental hypothesis of the product-based approach:
Product replaces project as the fundamental unit of delivery. Organizations align their digital capabilities around products. Products rather than projects are funded. Product teams approach work in a more holistic, outcome-centric way.
Following a product-centric approach requires organizations to define their products, which is more complex than you may think. This is particularly true for IT organizations with external or internal products.
As part of my research for this webinar, I talked to several people involved in moving to a product focus in traditional IT organizations. They described the complexity of existing systems, processes (both external and internal), and partners as shaping their initial models. That was unsurprising; after all, their product approach will evolve with the organization's experience, and you can only change some things on day one.
However, what surprised me was the impact of power, authority, and status on how products were defined. It became clear from the discussions that just like legacy systems, an organization's existing power and political dynamics constrain product definition. For example, if an organization has a large team aligned to an existing legacy system and that legacy system is considered to be a crucial part of several value streams, even if it would make sense to distribute the responsibility for that legacy system into the value streams and make those value streams products, the reality may be something different. Existing “stuff,” including power and authority, needs to be considered when defining your product model, and over time, that can evolve. Still, you must consider the political element when building your first product model.
Many people have written about the importance of connecting products to external value. Should products only be defined in terms of external value? Can internal products or even sub-products used in other products be considered a product?
After the session, one interesting topic that came up was whether or not a database used in many external and internal products should be considered a product in and of itself. This question and subsequent conversations challenged many pre-conceived ideas about what may or may not be a product.
My instant reaction was no, but after really thinking about it, the answer is unclear without more context.
Let's walk through a sample question-and-answer session:
- Do users interact with the product via user interfaces or APIs? Because of shared data and data integrity rules, the database team abstracts the data interface for consumers.
- Does the ‘product’ have measurable value? Yes and No. When we did not centralize customer data, we were sued when two products provided different answers to the same question for one customer. But we are having difficulty putting a direct value on our service. We do, however, know how much we cost :-)
- Do you have a roadmap? Yes, we have a roadmap. We also have a transparent backlog that allows our consumers to make decisions when their requested feature is low in terms of overall priority. We also work to reduce dependencies by providing self-service features.
- Do you innovate? More would be great, but we have time to innovate and a vision for where to take this capability, including new internal customers.
- Do you have Product Ownership? Only technical ownership, no direct connection to the businesses that use our data.
It is clear that this team's work provides value, has a boundary, and has encapsulated its services/features. So, the simple answer of NO may need to be corrected.
I bet you all are asking. So, is it a product? Unfortunately, the answer is it depends. One level of operating as a product team provides them with a clear focus. Encapsulating the product reduces risk. It also might give some interesting opportunities for innovation. For example, they can offer reporting to their existing users or work with new customers via the company's partners. By positioning the database services as a product, you avoid the cost orientation by encouraging the team to think about value.
Imagine the conversation at Amazon when the cloud services organization wanted to think about their service as a product? Not too big a leap to see that product thinking can change how internal services think about how they organize and think about value.
OK, if they do treat it as a product, that means a few things in addition to a product roadmap:
- Operational roadmap–The SLA for the database would need to be managed and communicated. This might be a change for an internal service-oriented team that depends on the company's cloud infrastructure. Thinking about the product's service level will ensure that any product that depends on it can support its service level.
- The total cost of value—Taking ownership of the value (cost vs. benefit) equation can provide interesting insights into how the database is supported. Ultimately, this can help the team make choices about cost vs value. For example, when using a particular cloud service or monitoring tool. In many cases, these decisions and discussions are held outside the product team with people lacking the business context. This leads to mistakes and avoids opportunities for innovation.
- Governance and flow—I know that who owns what in a centralized IT organization can be a real headache because, without that knowledge, it is impossible to determine who needs to make decisions or be influenced in the decision-making process. By showing clear accountabilities, stakeholders will at least know who does what!
- Evidence-Based Management – By providing evidence-based information to stakeholders, the product team can increase the value being delivered and improve the professionalism demonstrated by the team. For example for the database example considering how much data is not being managed by their product could be unrealized value or partners building their own data.
The other interesting perspective is that if we don’t treat this as a product, do traditional project management tools around critical path and dependency management provide enough coverage? Perhaps? But do they help motivate the team, provide space for innovation, and increase the opportunity for value? Suppose this group is treated like a shared service and uses project management to provide transparency without a product mindset. In that case, we may lose an opportunity to innovate and inspire.
Of course the 3rd option is to take the database and make it part of the value streams that use it. Have each of them update the database. And that might be the right option but if their are regulatory needs or quality requirements on having the separation then this might not be the right option either.
The last point concerns the organization's value. Is this product core or context? The most telling and exciting area of opportunity is whether this product provides a strategic advantage. If it does, then it should be a product and managed accordingly. What is the cheapest way to offer the same service level if not? Can the service be bought? Can it be outsourced?
When I started the conversation about defining the product model, I thought that the product would be simple. Just like apples, when you are bobbing for apples, they would pop to the top of the barrel when you look at the work, existing systems, and organization. But the choices that you make and the boundaries you draw are much more complex and provide many opportunities for innovation and focus.
How many places do organizations have shared services that ultimately, if thought of as a product could become more valuable to the organization?
The one true thing is that as you move from project to product, you cannot just take your existing projects or initiatives and make them products. You need to take time to look at strategy, opportunity, and legacy before you decide on what your model is. And don’t forget that people are involved and be conscious of the impact of the model on their positions, authority or status!