CONTRIBUTOR
Over the last 20 or so years, the evolving role of the CIO, or chief information officer, has been a hot topic of conversation in most large enterprises. It’s a topic that doesn’t just affect those breathing the rarefied air of the C-suite but has concrete implications for everyone in the IT organizations these CIOs lead.
For these last two decades, most larger companies in traditional industries have vacillated between periods of enthusiasm for technology and so-called “digital transformation”—in which CIOs are viewed as wizards bringing new wonders, changing their entire business models and growth trajectories for the better—and periods of disillusionment, with late projects, missed requirements, user and customer dissatisfaction and cost overruns—in which the CIOs become scapegoats. In these latter times, they often are replaced by CIOs of a different stripe, often moved laterally from finance or general management roles and charged with cost-cutting and predictability as top priorities. Even if the existing CIO keeps their job, they’re often pushed to change the way they operate and lead. When this happens, the entire IT organization finds it needs to change its pitch and priorities to sustain funding for every project and every function, resulting in whiplash. That itself contributes to the perception, and often reality, of late and unfinished projects and unpredictable IT outcomes. It is usually at that point someone realizes the newly efficiency-focused organization is losing market share, brand perception or customers to competitors that are more technically innovative (often digital-first upstarts challenging incumbents in a given industry), and the organization pivots back to “techthusiasm” and a different kind of CIO again. And more whiplash. And so it goes.
During the periods of techthusiasm, some organizations replace or supplement the CIO title with newly coined titles such as CDO (chief digital officer), CAO (chief analytics officer, an uncomfortable namespace collision with the established corporate title of chief accounting officer), or chief experience officer (no one dares make that into a redundant CEO three-letter acronym).
In the disillusioned periods, the CIOs stay CIOs as long as they can hang onto their jobs. Title creativity is as suspect as any other kind of creativity.
Meanwhile the vicious cycle continues: techthusiam -> disillusionment -> retrenchment -> falling behind -> renewed techthusiam.
As a longtime CPO (chief product officer) for enterprise software companies whose customers predominantly have been these seesawing IT organizations, I’ve been seeing of late the start of a powerful conceptual shift that is the escape route from this vicious cycle.
So, what’s the magic shift in thinking?
If you’re in a traditional business in which the technology your IT organization delivers merely facilitates people doing their jobs and interfacing with each other and customers, your primary threat in the 2020s—especially with a pandemic interrupting face-to-face interactions—is digital-first, new entrants that conceive of their product as the software and the people as the behind-the-scenes back office and failover when the software doesn’t work. Every business is now a software business, and the software is now the product; some companies in a given industry just happen to be better software companies than others. Such digital-first entrants range from Amazon to Netflix to Workday to Sofi to Wealthfront.
However, you don’t leap from being ADP to Workday simply through what, so far, has passed for “digital transformation” led by a CIO, CDO, CAO or whatever another newfangled c-level tech title, as a peer to product leaders whose organizations came from the pre-digital business and look to the CIO, CDO, CAO, etc. to simply execute the technology support.
What do true software companies in traditional industries have in common? They have CPOs! (Chief product officers, not chief procurement officers or even chief pandemic officers.) Analytics and digital are not in their titles because these are assumed means at their disposal. (I’m considering taking on the excesses of our fetish for data in IT and software today in a future column. Send me thoughts if you have them.)
The role of the CIO was to deploy technology efficiently to support the company’s strategies and plans. The role of the CPO, as inherited from pure technology companies, is to develop and maintain a deep understanding of the customer and market and guide the delivery of products to best meet and monetize their needs, and to do so ahead of any and all competition. The traditional CIO derives the why and what from other parts of the organization and supplies the how. Transitional versions of the CIO and the CDO and other neologisms may start to encroach on the what. But the true CPO drives the why and what—and the how if they also have engineering, or collaborates on the how with a CTO or head of development if not. (My friend Kaj van de Loo has an excellent discussion on CPO vs CTO and the trend toward combining the roles here, implicitly focused on digital-first companies, here.)
Does this sound broad, even encroaching on CEO territory? Well, yes. It’s no accident that former product chiefs are the new CEOs of Google and Microsoft.
So, what does that mean for you if you are in an IT organization?
Well, first, while your organization may or may not change the actual title to CPO from CIO, it’s important for your career to recognize when the definition of their job becomes that of what a CPO would do in a “pure” software company. If you see the signs that the CPO is guiding the IT organization to become the experts on the market and customers and invent new digital-first products, that shift is underway. It’s good news for those in IT because it means you no longer are simply a cost center to be minimized and even offshored, but a driver of the business and value.
Once you realize you are now in a product organization and not an IT organization, you need to start thinking about what a (software) product actually is and how that differs from what IT delivered before.
IT traditionally operates on a project and service maintenance basis. Projects have a defined scope and concrete, finite objectives to be considered complete. They have beginnings and ends. Projects either result in the existence of a service that is operated and maintained on an ongoing basis or deliver a discrete set of changes to a service that already existed. Project teams form, deliver the project, and then break up and are reassigned to the next project. Much smaller maintenance teams (usually as low-cost and as low-skill as the organization can get away with) make sure that the resulting services stay alive and maintain agreed service levels and consistent, fixed functionality (until the next project to evolve the service is funded).
True products are quite different. Products have many years long life cycles, from inception through launch, constant active enhancements and growth, and then eventual an end of life. During these life cycles, customers reasonably expect new capabilities to increase and existing capabilities to evolve for better usability and effectiveness.
Products are not defined by a particular architecture or features but their mission on behalf of the market, users and customers. During a product’s life cycle, the product team may discover new feature ideas or develop new architectural implementations to replace or enhance old ones, all within the umbrella of the same product and mission.
Product teams maintain staffing levels throughout a product’s life cycle to continue delivering new capabilities and technical enhancements, not just keep the lights on. Every member of a high-performing product team takes the team’s mission as its own and strives to build holistic knowledge of the mission and the product and contribute new ideas and challenge existing ones—not just a defined role of a product manager or product owner or architect.
Product teams are acutely aware of competitive and substitute products and strive to become and stay their target customer’s first choice in the face of competitive product teams doing the same. Product teams regard selling, evangelizing and making their products available to their market as being as much a part of delivery as software development and integration. Product teams see opportunities to interact with target users and customers as invaluable two-way dialogue during which they get to show and get reactions to the shiny features they’ve built, as well as discover latent needs that drive ideas for new features and maybe even entirely different conceptions of the overall product.
In an IT organization that is transforming itself into a product organization, these ideas and this approach apply not just to teams working on “external” products for paying customers outside the organization, but also in equal measure to internal products that either serve internal end users, such as a finance or payroll system, or become services that developers on other teams incorporate into their products or platforms on which other developers build, such as a common identity service, customer data pipeline or private cloud. In today’s world, every such official internal service resides in an environment with competitive third-party services and possibly competing internal approaches, and in which what was state of the art yesterday is not viable today.
Conversely, a well-conceived, designed and managed internal product may turn out to be the basis of a massive external business. Witness AWS and countless DevOps startups that began with the old story, “We built this thing to support our social media/dating/gaming/whatever B2C startup, and it turned out to be something other companies wanted to buy more than people wanted what our startup was doing.” Managing internal services and platforms as products is the way to both ensure that the original mission is fulfilled while new opportunities are discovered, too.
I leave you with this link to a podcast featuring a small Brazilian fintech startup that I believe is one of the best recent examples of a true product team’s approach: Their level of customer intimacy enabled them to identify a new product that solved problems within the scope of their mission and on behalf of their target users that a lesser product team would not have done. How would this kind of product thinking apply to the products in your IT organization?
