Fostering a culture of outcomes, discovery, and experimentation
Note: this is the second part of a 5-part series on Product challenges. If you haven’t already read the first part you can find it here.
My second biggest product challenge is related to aligning the entire organization towards a culture of outcomes, discovery, and experimentation.
Let split that challenge in two:
- The product team
- The rest of the organization
1. Creating an outcome and experiment-driven product culture among product teams
Any modern product team with strong product practices will strive to achieve this kind of culture.
Regretfully, there are a few conditions that may prevent the blossom of these practices:
- Lack of alignment with product leadership
Of course, if you want to create a culture, it should be driven by top management. In this outcome driven world, Product Leadership places a major role. You need clear outcome-driven goals, an empowered trifecta of Product Manager / Tech Lead / Product Designer to make the decisions of how to achieve it, investment in experimentation and research tools, invest leadership time in insights review rather than status meetings, etcetera.
- Lack of “the right mindset”
Not all product teams are strong enough to understand the value of research and experimentation. Furthermore, exposing yourself to users is quite hard for some sort of personalities, and biasing what you hear from user feedback to support your own ideas is an easy trap to fall into.
Experimentation requires a very particular mindset, that is hard to achieve if it is not your defacto mode.
- The Feature Factory trap
The feature factory trap is why many product teams go back to an output based workflow that prevents discovery and experimentation.4 reasons why product teams can’t avoid the “Feature Factory” trapIt is easy to understand why product teams with low autonomy, hard delivery-date pressures from stakeholders, and…uxdesign.cc
I have previously written about 4 reasons why teams get into this trap and how to avoid them.
2. Moving stakeholders to an outcome mindset
Even when Product Management and Development is radically changing, the result of our work (the products) have been around for a long time, and many stakeholders are used to other ways of managing and working.
In a traditional environment, either some stakeholder or a committee will make decisions and translate that decision to the team for execution. Teams will work on “projects” rather than “products” and will have little room to think about what’s the best for the product. Furthermore, they will be measured or pressured for delivery (output), not for achieving the expected business result (outcome).
Here are 5 points to consider when trying to convince stakeholders:
- Delegate decision making
Asking stakeholders to “dispose” of that decision making power and translate it to the team is extremely hard. It requires that you build some trust, and that trust sometimes requires that you show the teams capabilities of good reasoning and decision making, as well as frequent results reviews to show progress.
- Running experiments with real users
A frequent challenge to start with experimentation is convincing the entire organization that you need to run tests with real users that may result in a “not-so-nice” experience in order to gain learnings. This actually is a good reaction, we want to care for the best user experience. But you need to convince that the learning you gain to create better experiences will outweigh the investment. (And of course, try as much as you can to avoid that experiments affect the experience).
- Avoid the feature factory
On the team related challenges, I mentioned the feature factory. From a stakeholder perspective, many times this is what they expect from the team. They want to request features and get a deadline on when it is going to be completed. It is hard to change the discussion to “tell me what goals you want to achieve”.
- Founding teams, not projects
Depending on the type of organization and executives you are dealing with, there are some decisions that are quite hard to explain, like investing in reducing technical debt. In reality what you should strive for is founding a team, and letting the team decide when is the best moment to invest in technical debt depending on the goals they have to achieve.
- High-level roadmaps
Of course, if you ask for decision making power and team founding, executives will want to see how you plan to achieve those results. But that also clashes with the idea of discovery, experimentation and continuous learning. Convincing stakeholders that we have a high-level roadmap, that talks about problems instead of solutions and that it may change frequently is another hard challenge.
I believe there are many more, but those 5 are probably among the most challenging ones.