Most media and publishing companies think they have a product culture. They do not. They have an IT culture with product titles. The distinction matters more than most executives realize, and misdiagnosing it is one of the most expensive mistakes a company can make.
I lead the technology and product organization at the Wall Street Journal as its first CPTO, and before this I held CTO and other technology leadership roles at The New York Times, Conde Nast, Knight Ridder, and other media companies. In every case, one of the first things I have had to assess is whether the organization has a real product culture or an IT culture wearing product clothing. Whether I am running the engineering organization, the product organization, or both, the diagnostic is the same.
What IT Culture Looks Like
In an IT culture, the technology and product team exists to serve the rest of the business. Business stakeholders define what they want. The technology team builds it. Success is measured by whether the thing was delivered on time, on budget, and to specification.
This sounds reasonable. It is also a trap.
In an IT culture, the question is “Did we build what they asked for?” In a product culture, the question is “Did we solve the problem?”
Here is what happens in practice. A business stakeholder has an idea. They write a brief or a requirements document. That document goes through several layers of review and approval. It eventually arrives at the product or engineering team, who are expected to estimate the work and deliver it. If the finished product does not match the stakeholder’s expectations, someone gets blamed — sometimes the product team for defining the wrong requirements, sometimes the engineering team for building it wrong, sometimes both. If it does match but users do not adopt it, nobody is blamed because the requirements were met.
The product and technology team in an IT culture spends a large portion of its time on intake: fielding requests, estimating work, negotiating priorities, managing expectations, and explaining why something will take longer than the stakeholder assumed. The CTO, CPO, or CPTO in this environment is essentially a general contractor. They take orders, provide estimates, and deliver builds.
What Product Culture Looks Like
In a product culture, the technology and product team owns outcomes, not outputs. They are responsible for understanding the user, identifying opportunities, and building solutions that deliver measurable results. Business stakeholders provide context, constraints, and strategic direction. They do not write requirements.
The difference is fundamental. In an IT culture, the question is “Did we build what they asked for?” In a product culture, the question is “Did we solve the problem?”
A product team in a product culture spends its time on research, experimentation, measurement, and iteration. They talk to users. They instrument their products. They run experiments. They kill features that do not work and double down on features that do. They are accountable for metrics like engagement, retention, conversion, and revenue impact.
The CTO, CPO, or CPTO in a product culture is a strategic leader. They work with the CEO and the executive team to define what the company’s technology and product strategy should be, and then they build an organization that executes on that strategy. They are at the table, not waiting for instructions from the table. Whether the product and technology functions report to one leader or two, the culture is the same: the team owns outcomes, not outputs.
How to Diagnose Which Culture You Have
I have found that a handful of questions reveal the answer almost immediately.
Where do product ideas come from? If the majority of the product roadmap originates from business stakeholders rather than from the product team’s own research and discovery, you have an IT culture. Product teams should generate ideas through user research, data analysis, and market observation. Stakeholders should provide strategic context, not feature requests.
How does the team spend its time? If the product and engineering team spends more than a third of its time on intake, estimation, stakeholder management, and status reporting, you have an IT culture. In a product culture, most of the team’s time goes to building, measuring, and learning.
Who is accountable for results? If the technology team is accountable for delivery (on time, on spec) but not for outcomes (user adoption, revenue impact), you have an IT culture. Product teams should own the full lifecycle: discovery, delivery, and measurement.
How are conflicts resolved? If a business stakeholder can override a product decision because they have a higher title or a louder voice, you have an IT culture. In a product culture, decisions are made based on data, user research, and strategic alignment. A VP of Sales does not get to redesign the checkout flow because they have an opinion about it.
What happens when something fails? In an IT culture, failure means the project was late or the stakeholder was not satisfied. In a product culture, failure means the solution did not solve the user’s problem. The first is about process compliance. The second is about impact.
Why Media Companies Default to IT Culture
Media companies have a structural reason for this. The newsroom is the core of the business. Editors and journalists are powerful stakeholders with strong opinions about how technology should serve their work. In many organizations, the technology team has historically been a support function for editorial, not a peer.
This history creates muscle memory that is hard to break. Even when a company hires a CPTO and declares a “digital transformation,” the underlying dynamics remain. The newsroom still expects the technology team to build what it requests. The revenue team still expects the product team to implement its campaigns. The CPTO is given responsibility for outcomes but not the authority to actually drive them.
One structural approach that helps is having the technology and product leader report to both sides. At the Wall Street Journal, I dual report to the editor-in-chief and am a member of the newsroom leadership team, while also reporting to the business side. I had a similar dual reporting structure at The New York Times. This is uncommon — most CTOs and CPOs in media companies report exclusively to the business side and interact with the newsroom at arm’s length. But the dual structure means I sit in the editorial leadership meetings, understand the newsroom’s priorities firsthand, and have staff on both sides of the house. The newsroom sees me as one of their own, not as an outsider imposing technology on their workflow. That changes the dynamic fundamentally.
Breaking the IT culture pattern requires the CEO and editor-in-chief to genuinely believe that product and technology are strategic functions, not service functions. It requires the CEO to back the CTO, CPO, or CPTO when a stakeholder’s request conflicts with the product strategy. It requires changing how the organization measures success. None of this is easy, and most companies underestimate how long it takes. I wrote about what it takes to be effective as a CTO in this kind of environment, and the CEO’s role is a major factor.
The Cost of Getting It Wrong
Companies that operate in IT culture while believing they have a product culture produce a predictable set of outcomes. The product roadmap is reactive rather than strategic. The best product and engineering talent leaves because they want to work on problems, not on orders. The technology stack accumulates technical debt because stakeholder-driven projects optimize for the next feature, not for long-term architecture. And the company falls behind competitors who actually empower their product teams.
I have seen this play out at multiple organizations. The companies that made the transition to a real product culture did so because leadership committed to it at the top and sustained that commitment through the inevitable friction of change. The companies that did not make the transition continued to hire talented people into a system that prevented them from doing their best work, and then wondered why the results were not better.
How to Make the Shift
The shift from IT culture to product culture is not a reorganization. It is a change in how the entire company thinks about the role of technology and product.
Start by changing the relationship between stakeholders and the product team. Instead of bringing requirements, stakeholders should bring problems. “We need a new homepage widget that displays X” is a requirement. “Our homepage engagement has dropped 15% in six months and we believe readers are not finding the content they want” is a problem. The product team then owns figuring out the solution, which may or may not involve a new widget.
Invest in product discovery. Give your product managers time and tools to do user research, competitive analysis, and data analysis.
If your product managers spend all their time in Jira managing tickets, they are project managers with a product title.
Change your metrics. Stop measuring the product team on output (features shipped, stories completed, velocity) and start measuring them on outcomes (user engagement, retention, conversion, revenue per user). Output metrics tell you how busy the team is. Outcome metrics tell you whether the work matters.
Give your product and technology leaders real authority. Whether you have a CTO, a CPO, or a CPTO, they need the ability to say no to a stakeholder request that conflicts with the product strategy. If they cannot, you have not actually empowered them. Your technology and product leaders need the CEO’s explicit backing to make hard calls, and the CEO needs to sustain that backing when stakeholders complain.
This is hard. It takes time. But the companies that do it build better products, attract better talent, and ultimately serve their users and their business more effectively than the ones that do not.