Part I: Building a People Platform for Continuous Change in Technology

This is the first part in a three part series that I will be releasing: LOOKING FOR PART II Click Here

I am providing a playlist. This is some of my favs while I wrote this:

Song One: https://itun.es/us/lX3w6?i=979074170

Song Two: https://itun.es/us/zqWfcb?i=1108804721

Song Three: https://itun.es/us/H7psab?i=1078525669

The Framework Behind Directed Discovery:

For years I have been walking into companies, listening to leaders explain the varying ways they have been working through innovation breakdown, delivery woes, and motivating teams to operate at a faster pace. I sit, listen, then ask them a couple of questions:

1. Are your product discovery and delivery teams empowered to change the company’s vision, strategy, culture and processes?
2. Does your product and technology strategy deliver creativity and innovation at a reasonable pace? If so, define reasonable to me.
3. Does it allow your team members to own the discovery and delivery of a new idea all the way down to the customer?
4. Have you built a framework that has measurements placed within the product to let the teams know when they are touching the fringes of personal confirmation bias?
5. How do you insert yourself into the process if you are a leader, manager, VP, director or founder?

The answers to these questions lead me to believe that most organizations are trying but failing. Many of you are using the word “Agile” to describe your process, but your teams are experiencing your “Agile” implementation as a tops down, sprint cycled, date driven, military drill. See this example (No,this is not a map of the Tokyo subway station. More sadly we have a large group of Enterprise consultancies selling this to large corporations)

I then make a comment: “You understand that your current implementation of software development methodologies and product development practices is surrounded by a singular software driven process.” The example I use often is Scrum (a methodology within Agile that somehow has become the core of discovery and delivery at some companies) along with Waterfall. I have sat in countless meetings where this is the default singular practice and I believe it’s killing your company’s ability to get out of its own way. Even more importantly, it’s not enabling your teams to own the innovation, plus-one improvements, and operational excellence that your company so deeply desires.

What I would be so bold to say to these companies is, the way you have implemented your process is just that: a manufacturer’s engineering practice. You have asked your product managers, UX designers, and project managers (if you have them, you shouldn’t) to default to this singular way of working. People rear back in a stupor, looking into my eyes that I would say such a thing. It’s harsh, but many of the software engineering practices were inspired by mechanical engineering, Six Sigma, Toyota Production System (TPS) assembly line like processes. These processes are optimized for predictability. Yes, with these less than 1% of parts in a billion produced fail. This, though, is not the time or place for using a single process at scale for the entire product experience team. The creation of a technology-driven product is continually evolving. Your product is not a Toyota Prius running down an assembly line which sees small iterations over years. Your product is an ecosystem of technology that changes on a quarterly basis, if not quicker. Your product’s success depends on a continuous creative iteration and delivery.

I argue, that to enable continuous creative iteration, you need something that provides guardrails to protect teams from too much innovation (creating a solution for a non-problem), over-engineering, and inserting personal confirmation bias in affordance choices. The process should also serve to keep founders, VPs, Directors, and other “boss” roles away from the “idea implementation steering wheel.” They can own the vision, but the team owns the implementation of the idea.

Now, for all of my Agile purists out there, I hear you and I am with you. The Agile Manifesto has been monumental. The issue I take is that companies do not follow the spirit of the manifesto. If they did, I would have let my point slide. But they haven’t, and it’s time to think bigger and better.

Eternally Optimistic:

The teams I am about to describe below are eternally optimistic, full of energy and possess an unquenchable appetite to seek to understand. They deconstruct problems, build the best idea for the customer, and have unbridled passion that needs to be reigned in at times. They start with a learner’s mindset. The best part, the individual personal bias is left on the side of the road as the user breaks the tie. Gone are individual contributors fighting over who has the better idea. It feels so pure. I implicitly trust these teams with any vision, strategy or idea because they know how sacred it is to respect and deliver something truly meaningful to the user. Their individual roles crossover and intersect naturally. It is not a rare sighting to see a user experience designer sitting next to a developer learning how to pair and code, or a developer interviewing, leading, and guiding a voice of customer discussion.

Currently, best practices look more like this: they encapsulate both discovery and engineering delivery. When discovery is applied the correct way, an entire product experience team can see from the origin story all the way to the first big idea stage. This involves the team creating the vision, strategy and idea implementation. These teams are actually shaping it. The delivery phase brings user experience and product management to the engineering table. I have seen a lot of success using a single-piece Kanban methodology. This way, user experience and product management have the opportunity to witness how engineers size stories, how the single piece workflow of Kanban breaks down into deliverables, and the time it takes to deliver those story’s steps and details. The real goal of this is for companies to make the journey from inflexible products, process and platforms and grow into a constant state of assiduous iteration.

A power comes from the team seeing this entire process. The power: a team learns its nuances. Nuances are the sometimes small, sometimes big ways of working together. The team learns one another’s strengths and weaknesses. It also provides them the opportunity to break apart and solve problems as a group, so that everyone is part of the solution. Team members see the soft skills and the hard skills all together. Teams that can relate to one another move more quickly over time, and deliver at a blistering pace without even realizing it. To them, it is just a way of working. Better still, this embraces work-life balance, not an artificial pace stuffed in a sprint cycle on a scrum team (Scrum Theater I call it). Their pace expresses the excitement of loving the craft of developing an amazing experience.

Communication (Transferring Knowledge)

The way your team communicates is a major-make-it-or-break-it point that wraps around this entire way of working. All really great products live or die by communication. This goes both for communication within the team and inside the product. Even as I sit here writing this, I can’t help but think how badly I want to be by your side helping you understand my emotional approach to communication, and why it is so important. Because at the core of it, I only want great things to come to you, your life, your product, and your company.

Here are some simple concepts that have really worked for me. The first is this notion of relating. In the user experience world, we are used to considering the needs of the user. We must also apply this concept to how we approach communication. When you are trying to communicate something, I would ask you to also think about how people experience you. More importantly, think back to yesterday and the interaction you have had with your peers, family, and friends. Take a moment and think about how they experience you as a person. Then go ask them how they experience you. Don’t explain, don’t defend, just sit there and listen. I know this sounds nuts, but in order for really effective communication to take place in any situation, people need to have a desire to listen to you and what you have to say. A good exercise in being present is to listen intently to the person communicating with you, and then play back to them what you think you heard. This opens up a magical place where people want to co-create something with you and they will listen.

Now, you must remember this is two-sided. Some people have a listening problem. This is going to be a little deep so just go with me. Much of the reason communication breaks down and you have trouble transferring your idea, concept strategy implementation, or whatever you are trying to get across is because when people listen to you they have placed you into a listening bucket. For example, let’s say I am trying to communicate a new experience launching to the sales team. When people listen to me speak, in their mind they think of me as the “product guy.” They have me in the “product guy” listening bucket. This means when I speak in the context of sales or something sales related, people diminish the emphasis of what I am trying to convey. If I spend time relating or seeking to understand their context before I start to communicate what I want them to learn, they feel something different from me. Something powerful. I am no longer in the “product guy” bucket because they feel like I understand their world. This truth about communication is something that I learned over and over again working in the medical field as an EMT. When I arrived to provide assistance to someone having a medical emergency, it really didn’t matter that I could have made their situation improve. To trust me they first needed to feel heard. I first needed to listen, then use language backed up by action in a way that connected with them, not to them. When I did this their walls came down and patient care could begin.

Here is the challenge I give to you. In order for you to listen to the user and be the best practitioner possible, you need to master relating, co-creating, and delivering with your team. If you can’t do this well with your team, then what gives you the idea that you can remove bias from your mind while being present with the user during an immersion visit or interview?

I know that you probably weren’t expecting this section to talk about how to approach communication. You were probably expecting me to give you all the channels we communicate in so here they are. But honestly, until you grasp this concept above, no matter what channel you use, it’s kind of like talking to yourself.

• Slack: This is our number one line of internal communication. We have every channel known to man. I personally have a tightly curated list of under ten channels that really matter to my context at any one time.
• Town Halls: We are committed to these as a company. We have them every Friday and rarely miss them.
• All Hands Meeting: We have these once a quarter and they include the entire experience part of the organization.
• Family Lunch: These happen every Wednesday, and give our teams the opportunity to connect in a social way.
• Quarterly Off Site: This includes the product teams and leaders. The sole intent is to work on the business VS. in the business. This is also a big time for bonding.
• Email: This is used at a much lower frequency than Slack, and is mostly inbound communication.
• Jive: This is our company blog for internal communication.
• Weekly Leadership Meetings: I have a meeting with my experience team leaders and a separate meeting with the senior executive leadership team.

Applying Directed Discovery

When applied as a new concept, Directed Discovery takes a few cycles before it feels really, really good. Why? Because when you use it to build and release you are re-calibrating the nuances of the team. You are feeling out how the team works together. It takes time to dial in how well the team can build a discussion guide, conduct interviews, and most importantly, take the aggregated feedback and turn it into something someone loves. It’s also really important to know that each time I’ve implemented Directed Discovery, it fits a little differently. The goal of this framework is to provide the scaffolding that facilitates team creativity, but has enough structure and guardrails that lets the team know when they are off track. It feels like enough rope to hang yourself that you give it humble respect.

You’ll really feel the difference of Directed Discovery right after you ship your first release to live customers. Depending on how many users you release your new experience to, you know within a few hours if the team needs to sharpen their qualitative research skills and if they have left personal confirmation bias at the door. Observing the repeatable success of teams has convinced me over the years that building a great product will come from using Directed Discovery. The part I love the most is that Directed Discovery builds amazing teams and people. At its core, it builds an individual’s hard and soft skill muscle immensely. The by product of building these skills is measured by the outcome of the delivery. The productivity keeps rolling in such an effortless way. No kicking a team in the pants. They are intrinsically motivated to deliver.

Developing Your First Product Experience Team

Product management and software development should never be treated as two separate teams. When I say the words “product team” or “software development team,” most people infer that I am speaking about product management or engineering separately. I want to take this moment to be really intentional and tell you to delete this distinction from your mind. They must operate as one team. I recommend starting this practice as soon as humanly possible.

Team Composition

The composition of these teams is critical. The minimum structure of these teams is as follows: small teams comprised of one product manager, four to eight developers, and one user experience designer. To take it a little further, build out the team around your core competency.

For example, Pluralsight is a content-driven organization. Our team’s composition includes Product Management, Software Development, User Experience, Content, Product Analysis, and Data Engineering. This is a team that has complete autonomy, is cross-functional, and is co-located. We do not stand a team up unless this composition exists. They discover, build, and deliver on their own, to a production environment. These teams control their experience in its entirety. Hence the name Product Experience Team (PXT), for more, click here: http://bit.ly/2ehCSdt .

Organizational Design

Attacking organizational design to set teams up for success is one of the hardest parts of the job. Tackling this uncovers a lot of obstacles for many organizations. So before I dive in, I want to take a moment to recognize a tension that is one of the biggest blockers. Power struggle, or a need to feel in control of a domain that a leader is assigned to, is systemic in many organizations and will undermine teams all day long. But I’m optimistic the times are changing. Senior leaders are becoming more people managers than hard-skill managers. It’s true, our organizations are still a little hungover from our former command-and-control partying years, so we still have leaders who default to this behavior. You often see this show up in older companies with senior-level tenured employees, who still have this deep within their DNA. I am however, seeing positive signs this is shifting. I am seeing a deep desire of seasoned technology and product leaders in larger organizations to move toward people and culture management. They are showing a vested interest in making sure their leaders have the hard skills and soft skills necessary to make this the focus. That has certainly been one of my primary focuses.

My suggestion for structuring organizational design looks a lot like a bottoms up spiders web. In the past we tried top down but it didn’t give the teams enough power. We tried flat but we were missing strategic vision and communication components. So today, I am in the midst of trying a spiders web. Here is how it looks. It is built from the bottom up. As the Chief Experience Officer I am at the bottom because I am here to serve my leaders. The team that reports to me now is the firm tensiles of the webbing for structure because they support our teams. This includes the head of technology, head of product, head of content, head of experience operations, and head of product strategy. From there the web expands vastly with PXT hubs that can effect the entire shape and size of the web. All product management and user experience design are peers. We have equal partners or peers in the development, architecture and platform engineering.

If you are not evolving your organizational design then it’s a great indicator your product strategy is probably pretty stale. In my experience, most rigid organizational structures are built to create process for predictability. The problem with this is not only that it supports a command-and-control philosophy, it also must exist in a static state in order to provide data. I prefer a process that has the ability to evolve every quarter or year. I set the expectation that we should restructure as needed. Same with the discovery, delivery teams, and process. The spider webs organizational model I just shared will continue to evolve in order to better support our teams over time. This is not how we may operate a year from now. The scaffolding of supporting teams should remain but we may re-configure it depending on what we are working on. We will make leadership changes and team moves as needed. The decision to do so really comes from our teams, who have their finger on the pulse of our customers and know what they need to do to execute on a solution. My team isn’t making decisions based on a burndown chart or efficiency flow metrics.

Measuring Success

The way we measure success is customer happiness. We have an insane breakdown on Net Promoter Score (NPS). When we started working on the Pluralsight product our beginning NPS score was 42. This includes both B2B and B2C Web, native iOS, Android and offline desktop platforms. Today the aggregate platform NPS is 66 and we re wrote nearly all of it. We broke apart a monolith and completely changed our software architecture. We obsess over our organizational design delivering and enable the best experience for the customer. We fluidly move teams in and out of areas that need affordance or performance focus. We’ve killed ideas, invented new ones, built new teams, moved people around on teams, all depending on the needs of our customer.

LOOKING FOR PART II Click Here

If you want to join an amazing community of product, dev and ux designers click here

Product Leadership: How Top Product Managers Create and Launch Successful Products

Here is the link to the website as well. Enjoy!