Just go with me on this little journey. I have been thinking about all of my product, user experience and development friends. I wanted to try and provide some ammunition to a group of you who are still working in an environment that will not allow you to break free of old, stodgy ways of working. And start working in way that will free teams to explore the new world of how product experience teams (PXT) should operate and solve problems together.

It still comes back to a philosophical difference at the leadership team level.

Either you believe product is simply a hired gun to execute the leadership team’s vision, and you’re told what to do and how to do it. It then pours down those execution ideals to development teams and other parts of the organization to implement.

OR

You empower, trust and confide in the product organization to drive the company’s product strategy, execution and potential re-shaping of the company’s vision. Remember, vision can still come from the top, but like I have always said teams own and lead the implementation of the ideas. As leaders, we need to be open to how that could re-shape our first impression of what the vision was.

You build teams to get as close to the customer as possible. (I call these listening teams.) Teams bring together and involve the entire company in that tribal knowledge and findings from those efforts. But the most important part to get right is the user breaks the tie. We need to shelve our personal bias, eliminate unilateral decision-making power over features and experiences and let the user and their repeatable data teach teams how they use your product.

I refer to this as a product experience team (PXT). So, what’s this all about? For starters, please stop building teams around features. Build teams around experiences. Sure we have features in there, but that’s why we keep building crappy products because we focus solely on the feature not the experience journey the user takes through a product.

Just to be clear, in the diagram below you can place a persona, experience or a big idea in the middle. All of the practitioners clan up and work to find common ground and glean confidence by working together, having healthy conflict and solving complex human-centered product problems together.

In the chart below, “product experience” is a way of structuring a team around a persona. Each product team in my mind is what I call a product couple. Product experience manager, user experience designer, and sprinkle in at least four developers and bam! You’ve got yourself a PXT. (Side note: always try to keep the teams small.)

These individuals are all responsible for the experience inside the product. For example: the skills development leader team (see chart) is responsible for the “reporting experience” which has several different features within it. That way when they build the reporting experience they can think of all the ingredients that need to be in place to surprise and delight users. Is this making sense? If not hit me up on Slack here.

Developers are the technical side of the conversation and thinking we bring to building a product. This can all work in matrix organizations, or can report into one leader be it the CTO or CPO. The point is, they are one experience team. At Pluralsight, we have nine of these teams, all cross-functional, co-located.

Below is an example of what this actually looks like, and you can also check out this firsthand account from one of Pluralsight’s product experience managers. 

If I were to describe what my teams do everyday, I would say 85% of their time is discovery driven, which I’ll elaborate on more in my next post. We focus on the experience of the product and the direction it should take. The title we use to describe these individuals is a product experience manager or PXM for short. As for the other 15%, I would say that most of this is organizing, communicating and collaborating with different parts of the organization to inform them on what’s happening. A little project managerish if I am being honest, but I hate to say those words. Nothing against project management—I just don’t see it as super necessary if you are building these types of teams.

Our product experience managers are the catalysts to join the organization’s arms together to understand the human-centered connection between our product and the true reality of what is possible.

There needs to be a day where we stop aligning teams and organizations around features. Customers have experiences. Sometimes they use features while passing through your experience. It is much more important to align teams around these experiences, not features. This is how you’ll fully understand what customers are doing along their journey.

If you are in one of these organizations that receive “requirements” from above you, it’s time to educate your leadership team about the true value a PXT can bring. We can change their vision. We appreciate their ability to explain how they see the execution of that vision, but ultimately if we do our jobs right, the user breaks the tie.

If you want to join a group of people that love talking product, development or user experience feel free to join this crew of awesome people here, or check out this guide on how to keep your team and business innovative.

Get the guide: Finding your way in today's rapidly changing tech environment