Think of it like this: We are a Product Experience Team (PXT)

Just go with me on this little journey. In my mind 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 work in way that will free teams to explore the new world of how Product Experience Teams (PXT) work 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 to be 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.


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) Ok, 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 below diagram 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.

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 sprinkle in at least four developers and bam! 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 below) 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 here


If I where to describe what my teams do everyday I would say 85% of their time is discovery driven. 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 when. 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 necessary if you are building these types of teams.

DISCOVERY DRIVEN: What does discovery driven mean? It is the study and practice of ethnographic techniques, combing over qualitative data from prototype observation interviews, aggregating qualitative responses from voice of customer sessions to define the next path forward and a deep review of quantitative data sets once the product has hit the streets at scale. This does not replace User Experience Design which embodies much different techniques but instead couples itself even tighter to the task flow diagrams, journey maps, hot spots drills and user story mapping practices. This also includes our development teams at a very significant level. We don’t think of development and product as a different group sitting on the opposite side of an aisle. Developers are all part of the ethnographic research with PXM and UX design in daily work. They 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. We have nine of these teams all cross-functional, co-located. Below is an example of what this actually looks like.

Here is a great story from one of our Product Experience Managers for a first hand account

The San Diego experience team.

Our product experience managers are the catalysts for joining the organizations 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 more important to begin aligning teams around these experiences to fully understand what customers are doing along their journey.

If you are in one of these organizations that receive “requirements” from above you in the organization it’s time to sit them down and educate them about the true value a PXT can bring. We will 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 will break the tie regarding what I would mostly quantify as a conjecture.

Thanks for spending some time reading through this and sharing it with folks. All of you are my inspiration and reason for writing


Enjoy what you’ve read? Good, because there’s an entire book full of this stuff. I’ve been working with two masters of product Martin Eriksson and Richard Banfield on writing a book that all product professionals can benefit from. Partly out of curiosity and on the back of our own experience, we’ve interviewed almost one hundred product leaders. Their insights and experiences will open up the conversation and take the lid off the mystery of great product leadership.

You can follow us at @rmbanfield, @bfgmartin, and @nwalkingshaw.

The Product Leadership book will be published by O’Reilly and on shelves in May 2017. You can pre-order the book on Amazon.

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

Family, Building Product, Running and Biking, CXO @Pluralsight,

Family, Building Product, Running and Biking, CXO @Pluralsight,