In my previous article, I looked at what Digital Product Management (DPM) really is and why it matters. The key point is that DPM enables companies to go beyond simply seeing IT as an enabler of business strategy, to become an integral part of that strategy.
In this emerging scenario, business leaders must shift from viewing digitalization as a series of discrete technology projects to continuously interacting with technology to refine the business model, identify and meet customer needs. customers as they arise.
The management of technology thus becomes not only more critical but radically different. Organizations need to be able to identify the most important technology investments and prove the return they will bring. It’s a much more fluid and agile process – to use the lingo, it’s a move from projects to products, a move from completing a project to managing a technology-enabled stream of value.
As with all jargon terms, “product” is used in a specific sense. Products are not, as in normal speech, things that are produced but are actually more similar to capacities.
For example, a government department may not see itself as producing anything and therefore may not see the relevance of DPM in the way it manages value streams. However, by looking at what it does through the lens of funding, it becomes easier to identify what its products are in that specific sense. By asking what the organization funds, what the things it funds are called, and similar questions, it can identify what its “products” are.
As part of the same exercise, it is then important to determine whether the organization is in fact using product managers rather than traditional project managers. Typically, project managers work on specific tasks and then move on. In contrast, product managers are responsible for the indefinite, long-term maintenance 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 these steps, any organization can identify the products that make up its value streams.
In short, DPM definitely shifts the focus from achieving a defined goal (the project) to delivering the functionality the business needs. As these needs are constantly evolving based on changing customer requirements and competitor actions, there is no completion date and therefore the product manager has a long-term relationship with his stakeholders.
Funding is not something that can be agreed upon and measured, but is constantly reassessed as the product changes.
Perhaps most difficult of all, funding is not something that can be agreed upon and measured, but is constantly reassessed as the product changes.
I ended my previous article by explaining that one cannot simply requalify a project manager as a product manager because the two are very different and require different skills. The same goes for business leaders and other stakeholders. Let’s take a look at what these changes mean for each group.
The project management office:
The Project Management Office (PMO) or similar unit that houses the people who help manage IT and technology expenses. As the business world increasingly moves towards digitalization, DPM enables the PMO to evolve with the business, connecting it to business value streams.
As part of this evolution, the PMO will need to embrace both project management and product management, each requiring different skill sets.
While project managers look like an athlete focused on winning a specific race, the product manager is more like the manager of a sports team, looking at a much bigger picture: the whole season, then how to use the off-season to prepare for the following year. It’s an entirely different thought process, and it’s necessary to build lasting relationships.
As a corollary, product managers need consistent and scalable engagement models for stakeholders, including external stakeholders as well as internal stakeholders who provide funding.
Product managers spend a considerable amount of time marketing their products and need to communicate what their products offer in terms of value.
Arguably, DPM benefits this group more than any other because it aligns more with how they want to run the business.
DPM frees business leaders from the tedious cycle of budget approvals that characterizes the project mindset: products evolve over time, and leaders can cultivate relationships with product managers to ensure that they get the features or capabilities they need.
The main benefit for software developers is that they don’t develop in isolation only to find that half of their work is never used.
Because products are linked to their functionality, their evolution becomes much more transparent and the work of the developer is more meaningful. DPM also gives them a view of what’s coming up and how to prioritize their time.
Traditionally, internal customers – the individuals and business units of the organization who use the products – simply accept what they are given and devise workarounds where they seem appropriate.
In the DPM world, users take a much more active role, with a positive impact on the product, thus enhancing its usefulness.
All of the above shows the extent of change that is required – and driven – by DPM. These changes are profound, but the benefits are significant.
In my last article, I will look at what they are and how to add DPM into organizational value stream management.