When we started Thought Ensemble in 2008, we did a lot of consulting work in industries like information services and publishing. At that time, these industries were at the height of their disruption. Digital products, from both longtime competitors and newer startups, were arguably the biggest threats to these companies. A big chunk of our work back then involved technology organization transformation – helping our clients in these disrupted industries design and run organizations that could deliver digital products to market faster.
These days, practically every traditional industry has some need for digital products. More and more businesses are threatened by this type of disruption, as competitors are finding new opportunities to connect with customers and other external stakeholders using technology. It is no surprise that many of the business and technology leaders I’ve recently talked with are trying to create or improve a digital product capability within their organization. I believe there’s a lot to learn from the industries that went through this transition years ago, as well as from software companies that were built from the ground up with a product-centric focus.
In traditional industries, when the need to build digital products first pops up, the responsibility just sprouts up somewhere in the organization. Sometimes the expectation is that the IT organization should just take it on amidst the rest of their technology work. Sometimes it is assumed that IT doesn’t have the capability or time, so it is built within one or more other business areas. Often it is outsourced via the Marketing organization or another business function. It rarely ends up in any of those places due to intentional organizational design. I can’t help but think of the frog who finds himself in increasingly hotter water as I’m watching this evolution within many companies.
I believe getting this right – the choice about where digital products “live” – is going to be a make-or-break decision for many companies. While it is a little hard to generalize on this topic, because it does vary by industry and company size, the rest of this blog attempts to look at this challenge and evaluate the merits of potential organizational solutions.
The Challenge
As I’ve written before in related culture and role blogs, building great products is different than running a traditional IT shop. Building great products requires different roles, different capabilities, and a different culture than traditional IT. That doesn’t mean the digital product functions belong in their own group; just that they deserve focus wherever they happen to sit.
There are three primary roles involved in building digital products:
- Product Management – This is the person or group that defines what you want to build, at the macro and micro level. They engage customers to understand needs, survey the competitive landscape, and research market forces. Ultimately, they prioritize the features that will go into the product, building out a product roadmap and ensuring that it matches up with the overall business imperatives or strategy.
- Product Development – This is the group that codes, tests, and supports externally-facing products. Their focus is delivering high-quality products and features, fast. They execute on the product roadmap.
- Traditional IT – This is the group that builds and maintains all the internal applications for the company, in addition to keeping the infrastructure up and running. They focus on the overall technology architecture of the company, usually with an emphasis on optimizing costs and keeping information secure. They build out the capability roadmap and ensure that it matches up with the product roadmap.
Anyone who has done org design work with me knows that I’m a big advocate of “healthy tension.” Strategic priorities deserve a leader focused on them and sometimes these priorities (and their leaders) can be at odds. While the checks and balances across priorities can be good, the organization needs a design and supporting incentives that help work through conflicts.
With these definitions and the concept of “healthy tension” in mind, the following are a few organizational constructs to consider. Before reading on, please know, I am NOT a fan of cookie-cutter org approaches (I’m tempted to write a diatribe on how much I dislike cookie-cutter org approaches, but I’ll save that for another day and just say that these constructs are more of a way to start the conversation versus a hardened approach to executing an org design).
Option 1: Product Management in IT
The Setup
The initial thinking of many businesses wanting to build digital products is to assume IT will do it all. It is technology work after all, and the corporate IT organization has always handled everything related to technology in the past. So, leadership either creates a group within IT or (more likely) tries to weave the development of digital products into their existing IT project work. In both cases, they manage prioritization of work through their existing governance mechanisms (like steering committees) or through Agile development teams that are aligned around company priorities.
The Pitfalls
While I’ve seen this work before, there are a couple of potential gaps. One gap is that Product Management is not given the focus and professional handling it deserves. There is a lack of legitimate skill, or inadequate attention, given to surveying the market and spending time with customers in a way that will lead to true customer-inspired innovation and feature prioritization. Another gap is that Traditional IT tends to operate effectively within “projects” versus “products,” which means they are good at delivering a project on-time and on-budget but may not be as good at continually delivering new features to market and pivoting those features based on customer feedback. Finally, in some organizations, the incentives are so rooted in cost management versus revenue growth, it is impossible to get the leadership’s thinking shifted or the culture transformed to support this model.
The Successes
I’ve seen this structure work best in organizations who have mastered the fundamentals of IT, so they aren’t constantly pulled back into “lights on” kinds of conversations. It also works best in organizations who are already effectively using an Agile development methodology and allowing their developers to operate iteratively with their customers. Finally, it requires a level and type of funding that gives the CIO or CTO enough bandwidth to actually focus on digital products as well as the authority to bring in Agile experts and coaches to assist teams and products in transition.
Option 2: Split Between IT and Product Group
The Setup
Another solution is to create a Product Management capability somewhere outside of IT, but still keep Product Development within Traditional IT. Product Management could report up to a variety of types of business leaders – CEOs, CMOs, COOs, or P&L Leaders. It may be centralized into one group or decentralized into several. It generally has more influence and tighter alignment with the strategy the higher up and the more centralized it is in the organization.
The Pitfalls
In theory, this works well because there’s a focus on the “new” competencies of evaluating customer and market needs and building a roadmap around that. All the technical work is done within the group that should be the most capable to do it, and there are efficiencies to having it there. In practice, the challenge with this model is usually one of friction. Especially if Product Development is operating within the overall governance of the broader IT organization, Product Management can become frustrated that the Product Development group isn’t keeping up if they don’t know what’s going on behind the curtain of IT. And from “behind the curtain,” Product Development doesn’t get direct interaction with customers as much as they would if they were working closer to Product Management. Since Product Development is inside the walls of IT, they don’t always hear the customer message directly, and then can’t advise Product Management on what is possible technologically. And Product Management comes up with solutions on their own, and sometimes resorts to shadow IT and off the shelf solutions when Product Development doesn’t keep pace.
The Successes
I’ve seen this work well when there’s a concerted effort to define how Product Management and Product Development will work together. Ideally, both groups work on the same end-to-end process with clear roles and responsibilities and aligned incentives. Additionally, the relationship between the leaders is critical, because it defines how the two organizations work together. A good relationship is not defined by clear expectations on how tasks are thrown back and forth over a wall, it is about actually wanting to work together.
Option 3: Product Development in Product Group
The Setup
A final solution is to separate Product Development from Traditional IT and link it very closely with Product Management. In industries that sell digital products as their primary business (i.e. a software company) or industries that require digital products to be successful in their business (i.e. information services), this is a pretty common model.
The Pitfalls
There are a couple of downsides here. One is the required level of investment to get this model right. For a mid-sized company in a traditional industry, hiring a (typically pricey) leader and building out a separate Product Development organization may not be feasible. Related to that is an issue of efficiency. When technical decisions are decentralized, technology and integration costs may climb because no one is minding the corporate architecture. Another downside is that there can be significant friction costs between Product Development and Traditional IT. Finally, in this model, the Traditional IT group may be treated as a less strategic group, which can have cultural impacts. These impacts can significantly affect that group’s ability to attract and retain talent through the organization.
The Successes
I’ve seen this construct more often in larger companies with a bigger investment in digital products or in startups who need to be very focused on their digital product. The Product Development team can move faster, often operating under a different type of funding model that encourages failing fast. They can leverage lulls in product backlog to investigate new innovations. The best case is when that Product Development team actively includes IT in the innovation lifecycle. They get to better solutions and create a better culture.
Conclusions
Any of these organizational constructs can work, regardless of industry or company size. I’ve seen all of them work and all of them fail.
With this in mind, there are three guiding principles within org design that lead to success:
- Ensure the three disciplines (Product Management, Product Development, and Traditional IT) have clear leadership and defined objectives.
- Ensure the tension between the groups is “healthy” and that incentives are aligned to encourage collaboration.
- Choose the model that gets you closer to customer inspired innovation – remember why you want digital products in the first place.
I could probably write a book on this topic, but with that, I’ll wrap this blog. I am very passionate about this topic and would welcome a conversation about it anytime! Lots of people are going through this transition now, so if you are going through this, reach out to us or your network. There are many stories to share that could help you with your journey.
