The clash between Digital Product Managers and CX practitioners

With the introduction of Agile, product managers are struggling with the demands that Agile places on their day-to-day involvement. Instead of throwing a project to the Design and Development Team (and only turning up for update meetings or reading weekly 1-page reports), they groom backlogs, make MVP prioritisation decisions, attend showcases or reviews, design walkthroughs and defect triaging.


Furthermore, when you throw CX into the equation, product managers have a hard time adjusting from the old ways to the customer-centric field research and user testing of CX. Product owners can get lost in their confidence about what they are building and whom it is for. Also, they often base their decisions on outdated information.


A modern product owner understands that CX not only is critical to the design solution. The CX team must understand the end goal of the product to do their job. It is a product owner's responsibility to create andmaintain the project's vision and goals. The hard part is when the CX team uncovers evidence-based inconsistencies and has difficulty convincing the product owner to make changes. The Agile framework embraces the change that improves the product value, but many product owners fear the cost and time requirements for these changes.


Product owners who have been promoted into a role that they neither understand (nor have the ethics to do so well) can be potentially dangerous. Their decisions are focused on their career progression and making their boss happy. They care very little about actual work, the team or the organisation's interests, relentlessly and ruthlessly delegating tasks and taking the credit. They also have the strange idea that developers were either trained at Hogwarts, and the code magically appears on command, or that coding is nothing more than 'bricklaying'. They also fear going over budget or being late on delivery. I'm not suggesting that budget and schedule should be ignored or abused, but those alone won't make anyone happy with the results.


Product owners can spend months working on a project plan (CapEx requests and project charters), supported with deep business analysis and financial justifications of ROI/C (return on investment/capital), NPV (net present value) and IRR (internal rates of return) to get funding – funding that is most likely highly constrained. At this stage, they have a pretty good idea of why the business needs to do a project – often without having met a customer along their journey. They have a track record of success, but as the financial market's disclaimer goes, "past performance is no guarantee of future results". The business world is constantly changing, especially in terms of customer behaviour and expectations.


By the time the product owner has encountered the CX and Development team, they have been through a lot. It could be years until they get the funding, recruit a team or start the project (especially on bigprojects). The technology may have changed in that time, along with customer needs and the competitive landscape. Agile is about managing project uncertainty and risk. My favourite Agile pithy saying is, "you can't chase a dog with a train". You can't lay tracks along a path of uncertainty, even if you know your destination. You must be engaged and pay attention. This is called adaptive planning. Experienced product managers appreciate and understand how good CX and Agile practices bring their vision to life early enough to identify problems and fill any gaps for improvement.


I believe that trust lies at the core of CX. And trust must be earned. The hard part for product managers is to get the right balance between trusting the team and staying engaged in managing risk and backlog grooming. Backlog grooming and prioritisation is a very powerful way of managing the value delivered by a CX/Agile team. Trust provides the product with the owner the strength to support and protect the team from corporate politics when things don't work out as planned (almost a daily occurrence in software development).


Another component of good product management is understanding and managing dependencies. Often, front-end development cannot be delivered if backend services are unavailable or unreliable. These backend services are usually not in the product team's control; solving these issues can take a lot of time and money. This will impact the prioritisation of the backlog based on the previously unidentified risks, especially if other infrastructure changes occur. The product owner is essential for negotiating a resolution of these dependencies. In extreme cases, this may require having the courage to put a project on hold.


What can you do to resolve this disconnect?


  1. Demonstrate control; by having a plan, having a clear process and aligning each task to a business outcome as stated in the project charter.
  2. Present research and testing-based evidence for all CX recommendations and decisions.
  3. Demonstrate the CX culture of validation and empathy for the user's perspective, shown in CX artefacts, like journey maps.
  4. Show you know what your competitors are doing; the marketing team can help with this research.
  5. Communicate frequently in person; collaborate, include and make sure your documentation, however minimal, supports your conversations. This gives your product owner something tangible to report up with.
  6. When presenting problems, issues and challenges, always offer a few options to resolve the issues.
  7. Watch your language! Don't use CX meta-language to sound smart and alienate your product manager or make them look ignorant. Make it as easy for them (as for your users).
  8. Show business acumen; respect for the time, costs, risks and stakeholder needs involved in delivering a project before anyone sees any benefits.


Most product managers are adaptable and grateful once they understand how CX supports them, but it takes a lot of negotiation and persuasion to give it a go. Once they experience the value, they do become CX evangelist and advocates.