Seeking to boost value to business stakeholders, Equinix is adopting a product model for building solutions. But the evolution from traditional project management practices is complex, and fraught with nuance that can trouble the transition and outcomes.
Equinix is grappling with determining which department owns a given product, as well as what the product lead should be called, according to CIO Milind Wagle, who is leading the effort for the operator of data centers. “Roles and responsibilities in the operating model are getting tested,” Wagle tells CIO.com.
Such details — the department in charge and personal titles — may seem like simple enough hurdles to clear. But they are typical of organizations migrating to product-based operations, which require different governance than project management approaches do, experts say.
“The shift from project to product is a seismic shift,” says Gartner analyst Remi Gulzar. “It redistributes and obscures decision, rights, and accountability.”
Even so, CIOs hail product management for its ability to help organizations cultivate nimble operations capable of quick pivots. Lured by the promise of driving continuous innovation that will result in competitive advantage, 40% of large enterprises will manage internal business capabilities as products by 2023, according to Gartner research.
Project vs. product management
Project and product management have several differences and significant overlap. Projects tend to cover Big Bang initiatives, such as the implementation of a new ERP system or a major change in processes, such as swapping manual data entry with robotic process automation (RPA). Products may include digital business capabilities or value streams, as well as customer-facing products that are valuable to a defined customer segment, according to Gulzar. An internal product could include a workplace application that facilitates contactless transactions; an external product might include a mobile application designed to allow customers to purchase goods from your brand.
In traditional project management, funding is provided for the life of a project based on resources and time. Products are also funded for their life spans, but based on business need. Work on projects ends on a fixed date, while products are continually refined until they’re retired. Projects avoid change, while products embrace change as necessary. Projects are tracked by their variance, whereas products are clocked by the value they provide for the business.
As for development, most projects are still built using waterfall methodologies, with business writing specification requirements and handing them to IT for completion. Products are often built by teams comprising IT and business staff using agile software development. But in the evolving product world, ownership has become a sticking point for some organizations — as counterproductive as this may be.
In most project management models, the business stakeholder commands projects, lodging service orders with IT while determining delivery cycles. But this is not necessarily so in the product-centric model, where ownership is increasingly shared. In some scenarios, a product owner may be redeployed into IT from the business, bringing critical acumen and product knowledge, says Diana Bersohn, managing director of Accenture’s technology strategy and advisory practice. “The lines between IT and the business don’t matter as much anymore,” she says.
Ownership may seem secondary to achieving a desired business outcome, but it’s causing confusion among employees accustomed to working in project management constructs. And as it happens, the road to product management is paved with pitfalls. “A lot of people are struggling with this,” Equinix’s Wagle says, adding that CIO peers have shared similar concerns with him.
Top product management pitfalls
Companies that run breathlessly toward product management suffer some common missteps, says Art Hu, who is embracing a product-operating model as CIO of computer maker Lenovo.
Some teams run sprints without establishing a base, hacking something together that doesn’t result in a product. Product teams need well defined intent and outcomes, as well as guardrails to keep the scope in check. Without these, it’s a “good way to sprint yourself into a bunch of dead ends,” Hu says.
Another issue arises when either IT or the business builds a product without consulting each other. This can make governance hazy, an issue that is compounded as the engagement models expand to incorporate more stakeholders, each of which want to maximize effectiveness, Gulzar says. Left unchecked, this can violate enterprise guardrails put forth by the CIO.
How will you know if the partnership is simpatico? You should be able to walk into a product team meeting and not know who hailed from business and IT; all involved should be speaking the same language in a seamless, symbiotic relationship.
Case in point: Hu’s team worked closely with the business and finance teams to build a new global CRM system in Microsoft Dynamics. The cloud software began life as a project with a fixed budget and delivery date before becoming a product that is regularly refined and improved, in what Hu describes as a “learning journey” Lenovo teams are taking together.
Team members also gained so much knowledge and experience that they became known quantities across the business. “It had the net positive effect of allowing teams to build expertise and be recognized so that they could promote that transition” from project to product,” Hu says.
Ultimately, Hu says the most important aspect of product management is making sure everyone is clear on “why you are doing it,” or you can’t hope to achieve the desired outcome. Does it meet customer needs? Will it help achieve double-digit market growth? These are the questions you should be asking, rather than who gets credit, Hu says.
Product management requires adaptive governance
There is no clear path to success, but Gulzar advises enterprises to support product-centric operating models by replacing one-size-fits-all governance with adaptive governance that contextualizes decision rights while balancing product needs with enterprise goals. Ideally, CIOs will shift from a control-based model to one predicated on achieving desired delivery outcomes.
Gulzar further recommends that CIOs engage with product owners to create distributed decision rights that determine the use of technology on both enterprise and product levels. Moreover, CIOs should help product owners develop the skills necessary to balance product needs with enterprise goals and constraints, and lean on change management to help overcome natural tensions between IT, product management and the enterprise. Such an approach “offers a dialogue rather than closes the door,” he adds.
The bottom line
Regardless of the path IT leaders are taking to product-centric models, the CIO’s role has shifted to a business-minded one focused on co-creation with the business, Wagle says.
To fuel this shift at Equinix, Wagle is prioritizing a program to improve his leaders’ communications skills, ostensibly to “create mini-CEOs in the organization,” which will build credibility with the business. This will help IT become “drivers of transformation as opposed to implementers,” Wagle says.