My Top 5 challenges of Product Management and Development — Part II

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.

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.

That’s it for today! I would love to hear feedback (or claps!) and your tips on some of these challenges.

If you enjoyed it and want to receive more tools & tips to improve your product, you can subscribe here and join hundreds of readers of my Lean Experimentation blog!

--

--

--

Working on online products, currently as Director of Product at XING. Passionate about technology and amazing web/mobile products.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

3 simple steps to ace the start of your new product role

Breaking Into Product Management

MVP Development — Refining The Plan

What Is The Purpose Of Hardware Prototyping?

Agile Team’s FAQ

The Five Agile Meetings Explained

From Screens to Experiences

9 Essentials for effective Product Management while WFH

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Nacho Bassino

Nacho Bassino

Working on online products, currently as Director of Product at XING. Passionate about technology and amazing web/mobile products.

More from Medium

The Exploration Process From the Perspective of a Product Manager

Thoughts on Product Strategy: Part 1

Pushpa, Pushpa Raj.. The Product Manager — The Product Head

What is product management? A PM explains