Me, a consultant: “So, what are we going to do about user adoption?”
Client: “Oh, that’s not a problem! It’s internal software, so the users don’t have a choice. They have to use it!”
Oh, dear product manager, if only it were that easy.
At VMware Tanzu Labs, I’ve worked on a lot of new software products for businesses and government agencies. We start from zero, doing discovery, deciding where to deploy, choosing our first features, and identifying our riskiest assumptions to make our product successful. And because we work in such fast, incremental cycles, it’s not long before we start rolling out to users … and, if we haven’t played our cards right, running into resistance.
The idea that focusing on user adoption isn’t necessary for enterprise software is, sadly, a fantasy. Office politics, fickle stakeholders, and wily users can all disrupt your go-to-market strategy. To mitigate these myriad risks, I suggest to my clients a two-pronged approach to user adoption: top-down and bottom-up, or, as I like to call it, the “user adoption sandwich.” This method ensures that you are addressing both ends of the equation, and it also fits into the balanced team framework we use at Tanzu Labs.
Top-down user adoption
The top piece of bread in the user adoption sandwich is getting enthusiastic buy-in from stakeholders and leadership. Remember, just because someone with a budget is paying for your team to create this product doesn’t mean that everyone is on board, or that they won’t change their minds.
Some things that can go wrong without a top-down strategy:
-
Supervisors will not enforce adoption of your product (or some will and some won’t).
-
Stakeholders will pull the plug on the product if they don’t like the way it is shaping up.
-
Competing products might come under consideration, in addition to or instead of yours.
-
Users will not be given the support they need to transfer their workflows and data over to your system.
How to assure top-down success:
-
Get clarity on the business goals your stakeholders and leaders have. Obsess over them.
-
Measure. Provide success metrics that show you are meeting the aforementioned goals.
-
If you’re not adding your stakeholders’ pet features, be transparent about why—and above all, make sure they feel heard about their concerns, and not that you are ignoring their needs.
-
While you don’t want features to go straight from your leaders’ mouths into your backlog, sometimes it’s worth it to deliver some low-hanging fruit just to appease a stakeholder. It’s not a good habit to get into, but it can be a pragmatic judgment call!
Bottom-up user adoption
Our bottom piece of bread is user delight. Shoving an unlovable product down users’ throats makes no one happy, and it can backfire. But creating a product that users can’t wait to adopt does half the work for you.
Some things that can go wrong without a bottom-up strategy:
-
Users complain to managers about your product until the managers push back on implementing it.
-
Users find workarounds to their flows that avoid having to interact with your product as much as possible.
-
Business goals around productivity improvements will suffer as users find the product more laborious to work with than expected.
-
Your own team's morale will sink as all your hard work is met with reams of complaints.
Assuring bottom-up success:
-
Do all types of user research: exploratory interviews, usability testing, beta releases. Take every opportunity to make sure you’re solving real problems in a convenient way.
-
Set up robust feedback loops, especially early on when you have few users and can interact with them individually.
-
Impress your users with how quickly you respond to their feedback. Delivering a next-day fix goes a long way toward showing them that you’re not like other teams they may have worked with in the past, taking their time and input and then not using it.
-
If you have early champions, it can be worth putting in an enhancement just because they asked for it, even if it’s not otherwise a priority. As with prioritizing some stakeholder requests, a small change can build a lot of good will.
Where the balanced product team comes in
Top-down, bottom-up: how do you make sure you are paying enough mind to both sides of the sandwich? Fortunately, the answer to this is baked into the balanced team model.
When organizations work with Tanzu Labs, they learn not only extreme programming for engineers, lean product management for product managers, and user-centric design for designers. They also learn how these roles fit together and play off of one another in a model called “the balanced team.” In this concept, product managers advocate for business benefit, engineers advocate for technical excellence, and designers advocate for user delight (and all roles are expected to exchange context and opinions on each other’s ideas).
In this case, placing the top slice of bread—the stakeholder and business needs—falls naturally to the product managers, while the bottom—user enthusiasm—is the domain of the designers.
This isn’t to say that each role focuses exclusively on one approach or the other. Rather, it allows each person to represent a different voice for the product, making sure no set of needs is drowned out in the daily hubbub of trying to release a new product. In this case, it means the designer’s job is to say, “If we don’t get user buy-in, we can’t win,” whereas the product manager reminds the team, “If the stakeholder doesn’t let us roll it out, we’ve already lost.” They then compromise on what features will solve the needs of each constituent most efficiently.
User adoption can be taken for granted with enterprise software, which is one reason so many internal software products fail to gain traction. Keep this two-pronged strategy in mind as you are researching, designing, and building your product, and nurture your relationships with your stakeholders and early adopters. Then enjoy the delicious achievement of a successfully rolled-out product!
