"We need to build a single coherent customer experience. Everyone I talk to says that their part of the experience is working well but our users still have so many steps to do simple things."
The executive I was talking to had a point. Tasked with increasing the proportion of digital customer interactions, the result was a lot of activity across the product teams yet the changes were limited to small improvements across isolated parts of the customer journey. The experience for the end-user was still disjointed and time consuming.
Building elegant digital experiences turns out to require more than a great UX strategist or hands-on Product Owner. There are many systems involved, each with a different owner or manager. Some systems are behind the scenes - in theory - while others are third party systems we appear to be powerless to control. The role of the Product Owner or product manager is confusing. Check out our blog post on this topic HERE.
We avoid this by elevating the discussion to focus on the expectations on a (usually fictitious) CEO of the Product. If we had a single role responsible for the success of the product - a CEO of the Product - what questions might the CEO ask? What expectations might they have beyond a strategic direction for the product or a detailed requirements definition? These questions lead to five areas of responsibility which, when managed together, increase the chance of building elegant product experiences. We have captured these areas of responsibility in the Product Management Wheel. Let’s learn more about it.
The Product Management Wheel
The wheel visualizes the activities necessary to take ownership of and influence a large-scale product experience. The activities go far beyond understanding the market and setting a product vision and roadmap (that strategic direction we expect of the product manager), and the tactical focus on delivery of high quality, relevant product features to the market (the tactical delivery of the Product Owner).
And therein lies the problem – if we look at creating a coherent and aligned customer experience as a strategic visioning or tactical delivery problem, we miss the scale of the challenge. Digital products are complex. There are many systems – from authentication, to product data, to web, mobile or kiosk clients. There are habitual ways of working - informal agreements on how products and systems are stitched together, who has authority over what part of the product, and which parts of the system are easy to change and which aren't worth the effort. These habitual pathways have formed to make working together easier - short cuts that decrease delivery times and reduce complexity in getting something done. Typically, these compromises were hidden behind loading scripts on a web application or separate systems to serve digital customers in different ways.
As we shift to a primarily digital experience, we see these compromises as jarring reminders of a previous way of thinking. If you've ever had to login to an application multiple times on multiple different screens or found yourself eight or nine clicks into a journey that feels like it should be simpler, you are beginning to see the outward expression of these internal ways of working. Decisions that are made to make working together internally easier without recognizing the impact these decisions have on the overall customer experience.
Let’s start with the five domains closest to the CEO of the Product: Business and Market, Know Your Customer, Delivery and Execution, Adoption and Activation, and finally Communication and Analysis.
Five Product Domains
Elegant product experiences depend on the fundamentals of understanding your market and your own business. We define two domains - Business and Market and Know Your Customer - that help define a product opportunity and a target market. Within a market, the CEO of the Product must know their customer. A deep understanding of the market, the capabilities of their company, and the needs and pain points of the customer leads to the definition of a potentially successful product. Note, we are continually learning and fine-tuning our understanding through some form of experimentation and continuous customer dialogue, captured here under UX & Design.
Given a great product idea, the product team executes on that idea. While delivery of the idea is at least in part driven by continuous experimentation and customer feedback (as noted above), how the product is taken to market is as important. Adoption of a new product or new features of your product or service is often taken for granted or considered late in the development cycle. Pricing strategy, go-to-market strategy, adoption and activation strategy all combine to help build the success of a new product. This leads to two domains around delivery - Delivery and Execution and Adoption and Activation.
Finally, the CEO of the Product must manage stakeholder expectations. Everything from identifying and getting buy-in (and funding) to the opportunity to progress updates or tracking against projected financials. While this has a lot to do with communication and relationship skills, there is also a strong element of data analysis and data-driven decision-making. Hence the final domain - Communication and Analysis.
Understanding the Product Domains
Business and Market
Identifying the right product in the right market begins with an understanding of the market (including the regulatory environment) coupled with the exceptional capabilities your business can harness.
The regulatory regime can provide opportunity. Either a change that opens up a market to new entrants with valuable transferable expertise or a shift that allows innovators to enter a market by ignoring regulatory frameworks. In China, the EV (electronic vehicles) market has quickly become the largest EV market in the world. BYD, the (currently) dominant Chinese EV manufacturer started life as a battery manufacturer. Whereas the fintech sector is driven by small, nimble entrants that fly below the radar of the regulatory authorities (at least to start with), giving them an advantage over the larger incumbents in niche areas.
Recognizing an emerging market opportunity is the starting point, not the goal. The key is to combine a market opportunity with the capabilities you - and only you - can bring to the table. Silicon Valley startups have been adept at bringing together their capabilities for creating and scaling digital experiences with traditional markets. On a recent Definitely, Maybe Agile podcast, Peter Maddison and I discussed the $25B mistake Nike made moving away from their core capability (a distributed sales organization with a marketing narrative built around the iconic Nike story telling) to a purely digital ecommerce approach focused on ad conversion.
Succeeding in a competitive market often requires you to bring an exceptional capability into the mix. Change is everywhere, and bringing a digital mindset to a traditionally non-digital experience, for example, creates opportunity... if you have the right capabilities.
Know Your Customer
I hope we can agree that customer-centricity is accepted as a pre-requisite to successful digital products. Unfortunately, while learning about the customer is important, we often don't have the tools in place to drive success. This starts with instrumenting our interactions - gathering data and learning how our customers use our products. This isn't a call for broad data grabs, but the recognition that if we can't see what is happening, we cannot create a stronger customer experience.
As we develop our instrumentation, we can start building a model - or a number of models - describing how we believe our customers behave. Great models start by understanding how our physiology works, how we subconsciously make decisions and the outside factors that influence those decisions. These can be turned into behavioural nudges or tailored customer experiences.
We see this all the time, although we may not be aware of how we are guided through our day-to-day experiences. A great example is described by MenTour Pilot, explaining how airport design is used to manage the passenger experience. What stands out is how understanding psychology leads to both calming effects - a valuable and appropriate use of customer insights - to the maximization of dollars spent in airport stores - a common use of customer insight we are becoming more and more aware of.
Finally, building on our data-driven behavioural models, we can start optimizing the customer experience. UX optimization is much more than maximizing the conversion of an individual button through A/B testing. Localized optimization is a starting point - and often necessary to start correcting the unintended consequences of the habitual ways of working your organization may have inherited. If your user journeys are not optimized, build the organizational muscle. Your development teams can own this local optimization easily if they have the right skills and space to work.
The complete picture requires a broader perspective, starting with a model of customer behaviour. Given a model, we can hypothesize how a change might influence customer behaviour. This is how the airport designs (or store layouts, such as the Apple Store experience) achieve their power. By using an iterative and incremental approach to experience design based on running many tests to validate ideas and deepen understanding.
Delivery and Execution
Every product lead has had to speak to what will get delivered when – and with most digital product delivery teams using agile delivery methods, this means lean product development. That is, incremental product delivery, which allows frequent updates to (and therefore feedback from) our end-users.
Perhaps surprisingly, we also recognize the role a digital product manager plays in setting expectations around technical quality. I have this conversation a lot. We want our delivery teams to own technical quality – so what role does the product manager play here? Should they care if it’s not their responsibility?
Yes, they should care. We want the product manager to expect high quality, to expect frequent and low-cost deployments, to expect rapid feedback on quality through automated testing and a robust CI/CD (continuous integration/continuous deployment) pipeline. While technical expertise is not needed, knowing that there will be conversations about the trade-offs around speed or capacity and technical quality, and embracing them when they come, gives permission and recognition to the delivery team that quality is expected and appreciated.
The product manager also directly influences delivery and execution through cross-team collaboration to pre-emptively manage dependencies and align multiple teams around common objectives.
Not so much dependency management during the sprint - this we can (hopefully) leave to the teams to coordinate. But rather dependency management between the product backlogs we are managing across a larger value stream or product.
If I consider my backlog in isolation, I can focus my team on delivering what I care about. However, if I have any dependencies on other teams (and therefore their product backlogs) I had better manage the dependencies proactively with the other Product Owners.
Adoption and Activation
The goal of the Product Owner is to maximize return-on-investment (ROI). This is achieved by building or enhancing features and getting them in front of customers as rapidly as possible. This assumes that users will find these new or updated features valuable. However, this assumption is often flawed.
A "build it and they will come" mindset may have worked for baseball - but even that story was fictional. The concepts of Product-Market Fit and Minimum Viable Products (MVPs) come from the need to validate whether or not the features - the ideas the Product Owner selects to increase ROI - actually shift customer behaviour in the right way.
This is the Adoption and Activation domain. It includes getting new products or features adopted by the end-user – they have other options – and making sure the results are positive. Sales go up. Engagement goes up. Recommendations or referrals go up.
This can be a sales enablement or traditional go-to-market strategy. How do we position the product? How do we price it? How do we get our sales teams or channels to talk about the product and bring the right users to the product?
However, in the case of internal systems and services, or service add-ons to an existing customer relationship, the focus can be on adoption and replacement of existing channels.
Perhaps we are undergoing a digital transformation and have new HR/financial systems rolling out time sheets and hourly work management tools to a distributed non-technical workforce. Just because we have the digital solution in place doesn't mean the non-technical workforce will start using it.
In this case, we need to manage the change – it’s part change management and part onboarding. We need to understand the existing user experience and figure out how to draw users to a new or updated user experience (adoption) and help those users realize the benefits we offer (activation).
Building the right features and getting them (rapidly) out of the door works if and only if users get benefit. Few products or services attract users without requiring some effort on how to support a change or transition.
Communication and Analysis
Any major initiative requires a broad supporting cast of people and departments across the organization. We want to manage relationships upwards and outwards within the organization. Credibility helps build trust, so we need to understand the numbers behind our product and the market, and how we get the product into our customers' hands.
We need to be able to point to data that shows where we perform well (or not), and perhaps point to areas where the data does not help us. Where we can navigate through sensing alone, relying on experience, intuition and anecdotal data rather than statistically significant results.
This requires presentation skills and, often, storytelling skills (that oft overlooked skill of executive leadership). This is the pure art of communication - the use of narrative to help bring a cautious executive leadership team around. Being able to visualize numbers and trends in a way that clearly communicates results or opportunities. Creating buy-in and competing for limited funds or resources.
Finally, we consider stakeholder management - leadership and influence, if you like. How to work within your political organization. How to understand the executive landscape in terms of decision-making, influence and impact. How are decisions made - are they made in a committee, or do certain individuals hold sway over those decisions. Who drives which decisions? Who might veto decisions and why might they do so?
Any successful product or service succeeds because of a broad base of support. This base of support needs to be recruited, sold on the opportunity, informed of progress, and generally nurtured over the long term.
The Product Team
The Product Management Wheel describes five domains any great product leadership team will have to manage. But the expectation that a single lone product manager or Product Owner can take all these responsibilities on is asking a lot. Rather, we want to build a product team with the right capabilities. Each member of the team might take ownership of a different domain, or the product team may delegate or partner with other teams across the organization to cover all the domains.
It is common to see great technical products built by a triumvirate - the technical lead, the design or UX lead, and the product lead for example (the proverbial three-legged stool of product management). Using the Product Management Wheel, we can see that as powerful as this model is (and it is powerful), there is more to consider. How do we define and manage our adoption and activation strategy? Do we have enough understanding of our business and market? Do we need to lean on or borrow communication and analysis skills?
The Product Management Wheel reminds us of the skills we need to be able to draw on. A powerful use of the wheel is to check how we address the different domains. Are there responsibilities that fall outside of our existing product team? If so, do we have reasonable expectations around this - or are one or two roles overloaded or inexperienced in critical areas? Perhaps we are dependent on support from adjacent departments. Are our incentives aligned? Strategically, are we primed to work together, delivering aligned strategies, or at odds through competing strategies that pull us apart? This creates an understanding of where we are strong (or not) or which relationships to build and nurture.
Conclusion
We hope you find the Product Management Wheel as valuable as many of our clients have. In our experience, start by sharing the Product Management Wheel (download a PDF version of the Product Wheel HERE) to start a conversation on your team and share your experiences. If you are looking for a guided introduction, a product discovery exercise, or to learn about how other organizations have used the Product Management Wheel, please get in touch at hello@incrementone.com.