By John Westworth (opens in new tab)
Photo credit: iStock
Imagine this: Your company works long and hard on a new product or feature and proudly rolls it out to its enterprise customers, only to have them ask, “How do we turn this off?”
If not the stuff of nightmares, this is at least a scenario that can inspire some angst. So, why does this happen? And more importantly, how can you prevent it?
Laser focus on the needs of end users is a wonderful thing. But for our Enterprise customers, the end user is just one piece of a complex ecosystem of stakeholders who will be impacted by any updates or new offerings.
Expanding your view of who the customer is to include these additional stakeholders, understanding their concerns, and meeting their needs will increase the chances of your feature helping users and their organizations achieve more.
Who is involved in enterprise adoption?
We recently recruited some customers from our Compass program for a design sprint. While we initially scoped the sprint to think through how we could take a more experimental approach to developing features, our customers brought us back to basics. Developing usable and valuable features is not much use if the feature is going to be turned off as soon as it hits the enterprise environment. They implored us to think of the stakeholder cycles that each new feature must get through and ensuring features were also supportable.
To understand this better, we ran an exercise where customers provided a great deal of depth into the people and departments that are affected and involved when we release a new service, update or feature. Each customer listed the roles involved, what they did, their blockers and pain points, and what they needed to make their lives easier.
We learned that while the end user may be the person we’re solving the problem for, additional roles are also impacted, involved, and need to be consulted. These could include IT operations, Security and Privacy managers, and Change Management owners, just to name a few. Not giving those additional roles the tools, controls and content they needed results in features being turned off or not used—diluting the value of the services.
What do these stakeholders need?
In the chart below, I’ve listed a few of the roles that were highlighted, including their responsibilities and what they need from us in order to help them get an update to a user. Each organization will have roles responsible for these areas, but may use different titles or combine roles. Each role has the potential to block deployment of an update to a user.
How can you help stakeholders drive adoption?
Our discussions with customers yielded prescriptive recommendations for how to help them with adopting updates and new products:
- Roadmap: Create a single roadmap that is consistent and up to date with realistic timescales to allow organizations to plan and execute releases and not waste effort creating their own solutions. Create a tenant specific roadmap that lets organizations see the start and end dates of updates being released to their tenant.
- Non-functional requirements: Make nonfunctional requirements equal in priority to user requirements and create a bill of materials or update the “definition of done” to ensure you deliver not just the update, but the tools, content, and controls organizations need to deliver, test, secure, and manage it.
- Deployment timeframes: Give more control over how and when an update gets delivered to users to give time to plan, prepare and pilot. Distribute changes through the year to make them more manageable to consume. Provide a central repository of “what we’re working on” to ensure product teams are aware of each other’s work.
- Analytics: Supply more granular analytics to allow organizations to see who is affected by an update, who needs to be notified and trained, and if their change management process is working.
The need to involve the full range of stakeholders was likely the case before 2020, but recent events have exacerbated it. The COVID-19pandemic required enterprise companies to pivot quickly in deploying products and features to enable their users to work from home. Doing so has taxed their infrastructure and made it even more difficult for them to add still more updates to their systems.
So, the next time you are working on an update or product for an enterprise customer, think beyond end users. Consider the impact on the broader range of stakeholders and the effort needed for the entire organization to support it. If you can get to a position where customers can be comfortable with it right out of the box, you may never again have to face a customer who wants your shiny new update turned off.
What do you think? How can thinking beyond end users’ needs enhance your design and development process and make your organization’s products easier to adopt? Tweet us your thoughts at @MicrosoftRI or follow us on Facebook (opens in new tab) and join the conversation.
John Westworth is a Design Researcher in the Office Design and Research team. He is passionate about providing leadership to help companies implement change and manage transformation to use new technologies that impact how they work.