Users First
Our user-centred delivery approach requires engagement from users! We need to conduct research with them to understand their needs; we need to put prototypes in front of them to get feedback and adjust our product accordingly and we need them to actually use our product and get value from it to help achieve the organisational outcomes that justify developing the product in the first place.
Marty Cagan talks about Four Big Risks when developing products.
- Value risk — relating to whether users will choose to use the product
- Usability risk — whether users will figure out how to use the product
- Feasibility risk — whether the product can be built given engineering, time and resource constraints
- Business Viability risk — whether our product works for the various aspects of the organisation
Engagement from all your users is essential in mitigating these risks.
Helping Yourselves
Many things that might help your users be less busy are likely out of the control of your product team.
Your product team may not be able to hire more people and train them to do the work the users are doing or there may be a long lead time to doing so. You may also not be qualified to do the users work for them — which rules out the option of helping reduce their workload temporarily by taking some of it on yourself.
You might not have any control over the users’ workload and how that work arrives with them. There may be annual, seasonal, monthly, weekly or daily workload peaks and the best you can do here is be aware of them and avoid placing load on your users at these times.
Other product teams might be seeking engagement from the same user base or there may be wider business changes, such as ways of working changes, going on that each compete for the user’s time. Here, a portfolio function may be able to help by prioritising demands on users.
However, there are ways where product teams can definitely help themselves to get more engagement from users:
- You can be really easy to work with — fitting your product work around the user’s availability — and taking only the minimum amount of time from them (including handling all administration in meeting set up, rescheduling etc. for your users)
- By making your requirements of users really clear to them — so time demands are minimized and frustrations eliminated. By showing why you need their time — to test and improve your product — and actually iterating your product based on feedback. I’ve been in the position before where I’ve given time to a product team to test their product — at the risk to my own work — only to find my feedback ignored and me disregarded as an ‘atypical user’ <- don’t do this!
- My having a clearly-articulated value proposition — why are you asking them to use your product, what’s in it for them and for the organisation. How does it fit with other aspects of their work and other products and services they use?
- By having testimonials from other users — talking about how much time using your product has saved them — remember, your users are busy so time-saving should be of interest to them
- By getting managers and stakeholders on-side — so they allow time for their teams to adopt the product — by showing value, or prospective value from user research, prototype testing and other early evidence of value and by ensuring your product is aligned to organisational incentives
- Finding champions for your product, helping them to communicate with others and spread the word
- By engaging with e.g. change teams, improvement functions, trades unions and others with an interest in the users, their busyness and well-being. Introduce your product, hear any concerns, and address them before widespread adoption is required
- By providing easy on-boarding, to reduce friction in adoption. Iterating your on-boarding approach to improve it as you learn more and as you would do for any other part of your product
- By making it easy to be successful with your product the first time its used — first impressions count
- By having wider change management if needed — to support and encourage users to adopt your product and to keep them using it
- By acting quickly when issues are highlighted and responding thoughtfully when improvements are suggested
- If you are able to segment your user base, is there a way of protecting a segment of it from wider business changes so they only have their regular workload plus your product adoption to worry about rather than a whole set of things e.g. could you pause ways of working changes in a geographic region?
- By collecting and communicating positive stories of product adoption, sharing these with other users, managers and stakeholders to build excitement around the product
I hope some or all of these ideas help you when working with busy users. Please let me know how you get on and whether you have other suggestions in the comments below.
Thank yous
Thank you Tom Dolan for a productive conversation on this topic.
Thanks to everyone who responded on this Twitter thread, lots of good ideas — https://twitter.com/markdalgarno/status/1630869946434551808
“Twitter request from the other for other’s ideas on increasing adoption from busy users.”
