Why are your Internal users not helping you build your Product?
When building systems for internal users, a Product Owner’s pain is often getting users involved in the building process. They may seem uninterested in attending your user testing sessions, only offering feedback through complaints about broken features and pain points, most of which comes after new feature release. How do we end up in this situation? Is there a proven way of involving your users that is scalable and not so time-consuming? Let us delve into some factors that influence how internal users respond to internal product teams.
User’s Perception of Value
When users say they are too busy to review a delivered feature, are they really busy? Or they do not see value in the features you want them to test? They could be wondering why you are not delivering this other feature that makes more sense to them. Perception of value is a measure that cannot be overlooked. This could be through a feedback session where we gauge whether the users actually see value in the Projects we have prioritized and sort of see how much they agree before the delivery work begins.
Deadlines and Threat of consequence
This does not sound good when trying to build a good relationship with your users. However, your users are human and we all allocate our time to what we see as valuable. Interestingly, we also respond best to deadlines and threat of consequences. It is common for users to fail to prioritize a product review activity because of other pressing engagements that have a deadline and threat of consequence attached to them. Deadlines are used everywhere, and for one main reason. They work.
We need to figure out how to demonstrate value and at the same time use deadlines/threat of consequences to elicit the right response from our users. It is not just about throwing a deadline that scares your users into submission, it is about having a release process that has timelines built into it. Timelines that have been agreed upon by all the users through a collaborative effort. A release process that clearly outlines the consequences of each activity delaying.
Effective Communication Elicits the Expected Response
Are we talking to our users or are we talking with our users? Product owners should measure how much their end users are aware of what is being delivered. You might think you are doing a good job communicating, but are you effective? We have many channels and methods at our disposal and no one size fits all. The key is to be able to determine which channel or method best gets the message across to a specific set of users. One channel or method can work well when communicating with people in your product team but will it be as effective when communicating with your users? There are many good ways to communicate but the effective way is the one that elicits the required response.
Make use of one of their own.
People will listen to you but they will believe and follow one of their own. Your users are more likely to actively participate in what you request of them when the drive is from within. This is the thinking behind having champions within teams for different initiatives. They drive their team members to participate. The champions can be appointees or volunteers. For user testing and feedback we could have a Test champion. The product lead will work closely with each champion.
Make the Process Clear to all.
Most product teams have defined processes that guide the software development and release. This is clear to the Product team members but not always to the users. Yes they understand you are building something that benefits them but do they understand your process and what their input is? Help the users understand their role by showing them how they fit into the bigger picture and they will make it a priority giving you the support you require.
Keep it simple
When asking users to perform a system activity, they always tend to follow the path of least resistance. Whatever you ask of your users should be as simple as possible. Your users understand the system but not as well as you and your technical team. Chances are that this is just one of the many systems they use in their daily tasks. They log in, do the minimum required, and move on to the next system. Time taken to complete a task might be their top priority. Try answer this question; how easy is it for your users to do what you are asking them to do on your system? This directly affects their responsiveness.
Have you thought of incentives?
This had to come last due to the controversy that often accompanies it. Offering a free incentive to a user to encourage them to participate is a practice that is widely frowned upon. Largely due to its ability to skew the feedback in your favor, not to mention the budgetary implication. Companies are known to reward members of project teams after each completed project, including users who participated. These users feel appreciated and are more likely to react positively when called upon. With incentives, one can really get creative when selecting what to offer. Examples include Branded merchandise, a team dinner or hangout and many more. Get something that fits in your budget. What matters is the act of rewarding, not the reward itself.
If your current user engagement approach has not been yielding desired results, take some time to rethink with these factors in mind.
Do you need to hire top developers? Talk to Andela to help you scale.
