“Teamwork begins by building trust. And the only way to do that is to overcome our need for invulnerability.”

Patrick Lencioni

  1. Honest, open, transparent conversations about what it takes to build and maintain a first in class digital offering 

  2. Clear expectation management of how the work gets done and who gets to make which decisions

  3. Appropriate allocation of resources

When I ask leaders to describe how their product management operates, I typically hear something like this:

  • [Organizations underestimate the importance of the digital product experience in the first place]

  • The importance of a good digital product experience is recognized but is met with unrealistic expectations and chronic under assessment of efforts/resources needed

  • PM is seen as a service function of the core product (i.e. the content) and its creators as opposed to serving the customer first

  • Management operates with a “waterfall” mindset while PM thinks it is (supposed to be) working “agile” (the constant disconnect leads to immense frustration) 

As reasonable and straight forward as this sounds, what I typically encounter instead are variations on the same set of structural issues:

  • New features and functionalities (especially those that sound innovative) are prioritized over core/baseline functionality and stability 

  • “More is more” assumption prevails over lean UX/UI and clear user promise

  • Over emphasis on planning and perfection (safety) versus an incremental approach that regularly delivers to customers and utilizes their feedback

All of those issues lead to raising levels of frustration and to decreasing levels of trust within the organization. However, it is precisely trust in people and their capabilities that is the cornerstone for effective and efficient product development. To build great products that serve users in a highly competitive and fast paced attention economy organisations need to be agile and agility requires trust.

In order to identify the root causes of the observable problem (system behaviours), I personally like to follow the OSTO model. It treats the company/department/team as an evolving and complex organism while at the same time following a very straight forward systematic approach. This aligns also with my belief that transformation processes are never finished but evolving and that organisations ideally build constant evolution into their routine business practices.

If any of the above sounds familiar, I recommend conducting a thorough analysis of the current system (people, product, processes)