The most common dysfunction I have seen in media and publishing companies is the relationship between business stakeholders and the product, design, and engineering team. It is closely related to the IT culture vs. product culture problem. In most organizations, stakeholders treat PDE as a service bureau. They bring feature requests. PDE estimates them, builds them, and delivers them. Everyone goes through the motions of collaboration, but the underlying dynamic is one of client and vendor inside the same company.

This dynamic produces mediocre products, frustrated teams, and poor business outcomes. The right model is one where product and technology teams collaborate with stakeholders as genuine partners, combining the stakeholder’s domain expertise with PDE’s ability to research, design, and build solutions.

The Problem with the Request Model

When stakeholders bring feature requests to PDE, several things go wrong simultaneously.

The first problem is that the request often defines a solution before the problem has been fully explored. A sales executive who says “we need a dashboard that shows X, Y, and Z” has correctly identified that the sales team lacks visibility into something important. They may also have a good instinct about the solution. But when the request is taken at face value and the specified dashboard is built exactly as described, nobody has asked whether the dashboard is the best way to solve the underlying problem. The data might need to be surfaced differently. There might be an automated solution that eliminates the need for a dashboard entirely. None of those alternatives get explored because the solution was defined before the product and technology teams got involved.

I want to be clear: the problem here is not that stakeholders have bad ideas about solutions. In my experience, stakeholders often have excellent instincts because they live with the problem every day. The problem is with a process that treats their initial idea as a finished specification rather than as a starting point for collaborative exploration. Some CTOs and CPOs approach stakeholder relationships with the mindset that “stakeholders are right about the problem but wrong about the solution.” I have seen that mindset create as many problems as it solves. It breeds an adversarial dynamic where the product team dismisses stakeholder input and the stakeholder feels disrespected. CEOs notice this, and it erodes trust in the technology and product organization.

My approach has been different. I start from a position of genuine respect for what stakeholders bring to the table. They understand their domain. They talk to customers. They see patterns that the product team may not see. When a stakeholder proposes a solution, I listen with an open mind. Sometimes their idea is the right answer. Sometimes it points toward a better answer that neither of us would have found alone. The key is that the final solution should be shaped by collaboration, not dictated by either side.

Second, the request model creates a prioritization problem that has no clean solution. When ten stakeholders each bring three requests, PDE has thirty items to prioritize. Each stakeholder believes their requests are the most important. PDE has no framework for resolving these conflicts other than organizational politics: who has the loudest voice, the highest title, or the closest relationship with the CEO.

Third, the request model kills ownership. If the product and technology team is executing someone else’s vision, they cannot be fully accountable for the outcome. When the feature does not drive the expected results, the finger-pointing starts. “PDE built what we asked for but it doesn’t work.” “The requirements were unclear.” Both sides are right, and neither is accountable.

The Partnership Model

The alternative is a model where stakeholders and PDE are partners with distinct but complementary responsibilities.

Stakeholders provide: strategic context, business constraints, domain expertise, problem statements, and their ideas about potential solutions. A sales executive in the partnership model says: “Our renewal rate has dropped 8% this quarter. We believe part of the issue is that customers cannot easily see the ROI of their subscription. We have some ideas about how to address this, and we need the product and technology team to investigate this with us and help us find the best solution.”

PDE provides: user research, solution design, technical feasibility assessment, experimentation, and measured results. The product and technology team investigates the churn problem, talks to customers, analyzes usage data, considers the stakeholder’s proposed solutions alongside other options, designs the most promising approaches, tests them, and reports back on what worked.

The shared responsibility is: agreeing on which problems to prioritize and holding each other accountable for results.

In this model, the product and technology team is not waiting for instructions. They are actively involved in understanding the business, identifying the highest-value problems, and proposing approaches. And stakeholders are not micromanaging the solution. They are contributing their expertise and ideas while trusting the product and technology team to find the best path forward. The best outcomes happen when both sides bring their full intelligence to the problem.

How to Structure the Collaboration

I have used a framework at multiple organizations that makes this practical.

Quarterly business reviews. Each business function (revenue, editorial, marketing, operations) presents their top three problems to the PDE leadership team. Not feature requests. Problems. “Subscriber growth has stalled.” “Newsroom publishing workflow takes twice as long as it should.” “Our ad products cannot compete with programmatic alternatives.” PDE asks questions, probes for data, and identifies which problems they can meaningfully affect.

Problem prioritization. The CTO, CPO, or CPTO, in consultation with the CEO and executive team, decides which problems PDE will focus on each quarter. This is a strategic decision, not a popularity contest. Some problems are more impactful than others. Some are more tractable. The technology and product leader owns this decision and communicates it clearly.

Product and technology teams own the solution, collaboratively. Once a problem is selected, a product and technology team is responsible for solving it. The product manager defines the approach. The designer creates the experience. The engineers build it. The team runs experiments, measures results, and iterates. But owning the solution does not mean ignoring input. A good CTO, CPO, or CPTO listens open-mindedly to ideas from everyone — the stakeholder who surfaced the problem, the CEO, even the newest team member. I have made it a practice throughout my career to welcome ideas about how to do my job better, regardless of who they come from. It does not mean I will always do what someone suggests. It means I genuinely consider it. The best solutions often emerge when a stakeholder’s intuition combines with the product team’s research and the engineering team’s knowledge of what is technically possible.

Monthly check-ins. Product teams share progress with the relevant stakeholders monthly. These are not status meetings where the team reports what they built. They are outcome meetings where the team reports what they learned and what impact they have measured. “We shipped three experiments. One increased conversion by 4%. Two had no measurable effect. We are doubling down on the successful experiment and killing the other two.”

Quarterly results. At the end of each quarter, PDE reports on outcomes against the prioritized problems. Did subscriber growth improve? Did publishing workflow speed up? Did ad revenue per page increase? This is how the organization holds PDE accountable, and it is a fundamentally different conversation from “did PDE deliver the features that were requested.”

What Stakeholders Need to Accept

This model requires stakeholders to adjust how they engage with the product and technology organization. Instead of bringing finished specifications, they bring problems and ideas. Instead of approving designs, they provide feedback and domain expertise. Instead of measuring PDE on whether their specific request was built, they measure PDE on whether the problem was solved.

The trade they are making is direct control over what gets built in exchange for better results. In the request model, they controlled the solution but were not guaranteed the outcome. In the partnership model, they contribute to the solution and the product and technology team finds the approach that actually works. Most stakeholders, once they experience the difference, prefer the second model. But the transition is not easy, and the CTO, CPO, or CPTO needs the CEO’s active support during the adjustment period.

What PDE Needs to Accept

Product and technology teams in this model cannot hide behind “we are doing user research” indefinitely. They own outcomes. If the team investigates a problem for two months and has no hypothesis to test, something is wrong. If the team ships experiments but never measures them rigorously, they are not earning the trust that empowerment requires.

A product team that dismisses every stakeholder idea because “we own the solution” is just as dysfunctional as a product team that builds whatever stakeholders request.

Empowered product and technology teams must also genuinely engage with stakeholder input. Empowerment does not mean isolation. A product team that dismisses every stakeholder idea because “we own the solution” is just as dysfunctional as a product team that builds whatever stakeholders request. The discipline is in listening carefully, evaluating honestly, and making decisions based on the best available evidence — which sometimes includes the stakeholder’s firsthand experience with the problem.

Empowered product teams must be disciplined about measurement, honest about what is not working, and willing to change course when the data says to. OKRs are one effective framework for this accountability. The partnership model only works if PDE consistently delivers results that justify the autonomy they have been given.

The Role of the CTO, CPO, or CPTO in Making This Work

The technology and product leader is the bridge between the two sides. Whether that leader is a CTO, a CPO, or a CPTO, they are responsible for:

• Making sure stakeholders feel genuinely heard and respected, even when the final solution differs from what they initially proposed
• Making sure PDE teams are genuinely investigating stakeholder problems and considering stakeholder ideas, not just building whatever they find interesting
• Resolving conflicts when stakeholders and product teams disagree on priorities or approaches
• Reporting outcomes to the CEO and executive team in a way that builds confidence in the model
• Adjusting course when the model is not producing results

This is not easy work. It requires the technology and product leader to be fluent in the language of business and the language of technology, to have the trust of both sides, and to be willing to make unpopular decisions when necessary. The best CPTOs, CTOs, and CPOs I have known treat stakeholders as valued collaborators, not as obstacles to be managed. That posture makes all the difference.

But when it works, the results speak for themselves. Products improve. Business metrics move. Talent stays because they are doing meaningful work. And the organization stops wasting time on the endless cycle of request, estimate, build, complain, repeat.