In my previous article, I looked at what digital product management (DPM) actually is and why it is important. The key point is that DPM allows companies to move beyond seeing IT simply as an enabler of the business strategy, to becoming integral to that strategy.
In this emerging scenario, business executives have to move from seeing digitalisation as a series of discrete technology projects to a continuous interaction with technology in order to refine the business model, identifying and responding to customer needs as they occur.
Managing technology thus becomes not only more critical but radically different. Organisations need to be able to identify which the most important technology investments are, and prove what return they will deliver. It's a much more fluid, agile process − to use the jargon, it's a move from projects to products, a shift from completing a project to managing a value stream underpinned by technology.
As with all jargon terms, ‘product’ is being used in a specific sense. Products are not, as in normal speech, things that are produced but are actually more similar to capabilities.
As part of the same exercise, it's important then to consider whether the organisation is in fact using product managers as opposed to traditional project managers. As a rule of thumb, project managers work on specific jobs and then move on to something else. By contrast, product managers are responsible for the indefinite, long-term care of the product.
Finally, identify the stakeholders benefiting from the products, as well as the business unit/s responsible for its delivery. By going through all of these steps, any organisation can identify the products making up its value streams.
In short, DPM moves the discussion definitively away from achieving a defined goal (the project), to providing the functionality the business needs. As these needs are perpetually changing in line with shifting customer requirements and the actions of competitors, there's no completion date and so the product manager is in a long-term relationship with his or her stakeholders.
Funding is not something that can be agreed and measured, but is constantly being re-evaluated as the product changes.
Perhaps most challenging of all, funding is not something that can be agreed and measured, but is constantly being re-evaluated as the product changes.
I ended my previous article by arguing that one cannot simply re-label a project manager as a product manager because the two are very different, and require different skills. The same is true of company executives and other stakeholders. Let's look at what these changes mean for each group.
The project management office:
The project management office (PMO) or similar unit that houses people who help to govern IT and technology spending. As the business world increasingly moves toward digitalisation, DPM provides a way for the PMO to evolve with the business, connecting it to the enterprise value streams.
As part of this evolution, the PMO will have to embrace both project management and product management, each of which require different skillsets.
While project managers resemble an athlete focused on winning a specific race, the product manager is more like the manager of a sports team, looking at a much broader picture: the whole season and then how to use the offseason to prepare for the following year. It's an entirely different thought process, and it's necessary to build long-lasting relationships.
As a corollary, product managers need consistent, scalable engagement models for stakeholders, including external stakeholders like internal stakeholders that provide funding.
Product managers spend considerable time marketing their products, and they have to communicate what their products deliver in terms of value.
Company executives:
One could argue that DPM benefits this group more than any other because it aligns more with how they want to run the business.
DPM frees company executives from the tiresome cycle of budget approvals that marks the project mindset − products evolve over time and executives can cultivate relationships with product managers to ensure they get the functionality or capability they need.
Software developers:
The main benefit for software developers is that they don't develop in isolation only to find that half their work is never used.
Because products are tied to their functionality, how they evolve becomes much more transparent and the developer's work is more meaningful. DPM also gives them a view of what is coming down the line, and also how to prioritise their time.
Internal customers:
Traditionally, internal customers − the individuals and business units across the organisation who use the products − simply accept what they are given, and devise workarounds wherever they seem appropriate.
In the DPM world, users take a much more active role, with positive impact on the product, thus further enhancing its usefulness.
All of the above shows the extent of the change that is required − and driven − by DPM. These changes are profound but the benefits are significant.
In my final article, I will look at what they are, and how to add DPM into the organisation's value stream management.