Tim Lockie
My parents remodeled our living room one December when I was a kid. You know how it goes; the plan was to be done by mid-December, but we were still working on it two days before Christmas. I remember my brother complaining to me, saying, "Mom ruined Christmas," "Why are we working during our school break," saying the quiet inside thoughts out loud for the other three of us.
Not 15 minutes later, my mom breaks. Ugly sobs. Tears. Heaving shoulders. The works. Through the sobs, she said, "I ruined your Christmas," "You are all working on your Christmas break," all the stuff my brother had just been saying. And because my brother had been so mad, I was sure he would let her have it!
But nope, my brother crosses the picket line, puts his arms around my mom, and says, "You didn't ruin anything. We don't mind the work. We're going to have a great Christmas!"
I couldn't believe my ears! It didn't ruin Christmas! DIDN'T MIND THE WORK!!! All the fight was gone from my grinch of a brother, and his heart grew four sizes instantly. A Hallmark movie moment.
I didn't understand until I was older that my mom was making a request. And my brother's hard-hearted attitude heard the genuine, humble, authentic plea and responded. It was peak 'humaning'.
The power of Resquesting and responding
Requesting is one of our basic human community functions; helping is another. Requesting and receiving help from one person and hearing and responding from another.
If one example of requesting and responding is my mom and brother in that cold late December of my childhood, then the furthest, most opposite example is feature requests to IT.
It's not that the emotions aren't there. They are. People are so frustrated when they are making requests. And technologists are emotional on the other side as well. But our systems insulate the requester and the responder from ever touching the humanness of the request.
In this article, we'll discuss the mechanics of feature requests, the do's and don'ts, but at the core of our work in requesting is convincing our users that it will be taken seriously if they make a request. And teaching Drivers to respond respectfully, even when the request is dumb (because there is such a thing as a dumb request).
How to manage Feature Requests
Picture this: you’re a Driver receiving a feature request through your feature request process for a new field. You work hard on a new field and publish it only for not a single person to use it. So what happened, and what can you do? Conversely, you might receive a product feature request so baffling you have to take a step back and wonder - who thought of this? So, what happened there, and what can you do to manage product feature requests? Managing feature requests, whether good or bad, is a difficult task, and it all starts with shifting the perspective from a transactional tech issue to a person who has a need.
Collect the minimum, not the maximum
One of the biggest issues with feature requests is how to get them in the first place. Teams are concerned that there will be an avalanche of requests keeping them busy all the time. So Tech Stack focused non-profits focus on efficiency and collect all the request details upfront. Almost as a requirements-gathering process:
- What's your pain point?
- Where is it happening?
- What outcome did you expect?
- What happened instead?
- How important is this to your work?
- When do you need it resolved?
- Is this affecting others on your team?
The logic is straightforward - get all the information upfront so the IT team can do its work. The team can fix the problem without bugging the requestor; it saves time and is more efficient. It makes sense... if you're on the IT team. But if you're a normal non-techie user, the questions create a barrier to making a request.
Regarding getting requests, The Human Stack approach is exactly the opposite. Drivers focus on the humans more than the tech and see the balance that must be found between defining the request and keeping users engaged.
Drivers ask as little as possible so that users can make a request in less than 30 seconds and get back to work; just enough detail so the requestor will remember it when asked about it later. And Driver's follow up personally to make sure they understand the need. It isn't inefficient; it creates a connection between the need and the response.
Managing dumb Feature requests
Sometimes, end users don't understand the technology or what they need. This can be a difficult situation to be in. I know because in 2005 while working at a nonprofit, I needed to make a new web page for our recruiting process. When I went to make the page, I found out I didn't have the permissions to make the page. So, I used the feature request form to be able to make pages and waited. A little while later, I received a phone call from Bill, the IT Guy at headquarters.
Bill wasn't having it. He straight up told me that I didn't need the web page and that what I was trying to do was a dumb idea. In that one conversation, I lost all my respect for Bill (because he didn't respect me), and I moved from an engaged user to a reluctant user. He lost out on me being an asset and champion to the rest of the organization.
Check out this blog post for more information on The Human Stack Digital Maturity Model and engaged vs. resistant users.
Six months later, I'd have to admit that he was right
Six months later, I had to admit that Bill had been right about the page not being a good idea. He probably wasn't great about how he said it (terrible actually), but he was right that that page wouldn't have helped. I don't even remember all the details, but it would have just moved where the problem would be.
The receiving end of Feature requests
Years passed, and I started a consulting firm and set up the systems for teams that get feature requests. I found myself in Bill's shoes, and guess what? Requested features by end users are not always good. Just because they're new doesn't mean they're good!
One notable time, a client wanted a backup of their CRM because they needed audit records for seven years. So they requested a paper copy of their CRM, meaning they wanted us to go in and take screenshots of every single page, print every single page, and then ship the boxes (and boxes and boxes) of the screenshots to them. We declined (and showed them how to run a digital backup).
Why do Smart People make bad requests?
Bad requests are usually a combination of not knowing how to ask, not knowing the true problem, or trying to solve it using the understanding and available resources. We don't know what we don't know, so we don't know how to ask for help. End users are trying to solve problems using what they know about the technology. Often, they don't know much about technology (or don't trust the technology). But keep this in mind: even a bad request is engagement. And engagement is what truly counts.
What should you do when an end user submits a bad feature request?
So, what do you do when end users submit bad feature requests? The most important thing to do is to build belonging. All our suggestions are offered from a frame of creating belonging to increase engagement, encourage digital maturity, and drive digital culture.
- Be Empathetic
- Put Yourself In Other's Shoes
- Suspend Judgment And Be Curious
- Listen For The Why
- If It's Low Effort And Not Risky, Just Do It!
- Never Lose Respect For Your Users
1. Be Empathetic
Building belonging starts with being empathetic, and belonging is the base code of the human stack. Empathy aids in problem-solving by allowing you to be open-minded to why people are requesting these bad feature requests. Additionally, empathy encourages trust and respect, reduces tension and defensiveness, and allows you to understand where other people are coming from.
2. Put Yourself in Other's Shoes
When it comes to bad feature requests, empathy begins with putting yourself in the end user's shoes. Why are they submitting this feature request? Are they frustrated with a specific issue, and this is their best feedback process? You can think of the submitted feature request as user feedback - any submitted feature requests are user feedback that a particular feature is not working as well as it should.
3. Suspend Judgment and Be Curious
Perhaps you're pretty sure you know exactly why a given user has submitted a feature request. Or perhaps you've already come up with a better solution. Please take a moment and communicate with the end user to get information on why they've submitted the feature request.
Suspend your judgment during this communication and stay curious about the "Why" of why they've submitted the feature request.
4. Listen for the Why
Listening to "the why" is one of the most important things to do when "bad" feature requests are submitted.
This can tell you what a better solution might be, how to proceed, and how to fulfill their user request more productively.
Feature development works best as a collaborative process, and ensuring that you're communicating with relevant stakeholders (in this case, the end user!) and listening to their needs is incredibly important. It's incredibly important not just for the tech but also for building belonging.
5. If it's low effort and not risky, just do it!
Perhaps the end user is requesting an entirely new functionality that is not necessary - but if it's low effort and not risky, just do it! Don't risk losing a user engaging in the technology. There is a balance here - don't go around fulfilling bad feature requests that take lots of time and energy and risk alienating more users.
6. Never Lose Respect for Your Users
It's also important to never lose respect for your users. They are (in most cases) doing their best with the knowledge they have. Their "bad" feature request is them engaging with technology in a way that might be new or different for them. Avoid patronizing behavior when it comes to users' feature requests - patronizing can easily be or feel like losing respect for someone.
What to do when a good feature request isn't used?
Sometimes, existing product features are insufficient, and a new feature is needed. In this case, you'd hope an end user would request features to be added using the feature request form. When this happens, you complete the feature request only to find that no one is using it.
If a requested feature is beneficial or should be used for better system processes, you can do a couple of things.
1. Run a Report on Who is and Who Isn't Using the Feature Request
This should never be done to shame individual users but to help you identify where the issue originated. Is there only one user who doesn't use the feature request, or is it all users? If it's all users, perhaps the feature request needs tweaking, or there needs to be better training. If it's one user, perhaps they don't understand the feature's importance, and some education could be beneficial.
Perhaps it'll help you identify an issue you didn't even know existed! Once, we'd received incoming requests for a particular feature, worked on it, and added a new field. A particular user wasn't using the field. After a few weeks of watching the user not use the new field, we finally went to the person only to find that they couldn't even see the new field! It turned out that their permission settings differed slightly from everyone else and they couldn't see it.
2. Make a Weekly Check-In
After creating the report to see who uses the feature request, check in weekly with the team's supervisor to ensure everyone uses it. Creating some form of accountability is a great way to ensure the implementation of the new feature request.
3. Create a Team Goal
Create a goal for implementing the new feature request with the proper internal teams. If, for example, only 20% of people were using a new field in week one, make a realistic goal of 30% for the following week. Ensure the entire team knows the goal and emphasizes progress, not perfection.
4. Identify progress, not perfection
By identifying progress and not perfection, you can reward people for their progress using the feature request and positive reinforcement. Although you may not be 100% of where you'd like to be, you can still ensure that people making an effort are rewarded.
5. Refine the Solution
Sometimes, as good as it sounded, the proposed feature wasn't the best solution to the problem, and that's why it's not being used. Ensure that you're consulting relevant stakeholders as you refine the specific feature solution and get a detailed description of their requirements.
Additionally, make sure you remember that the fewer number of clicks will yield the best results. The more clicks, the more mental effort a person exerts. The best way to ensure the implementation of the feature requests is to make it easy to do.
Our Digital Guidance® Methodology
With our Digital Guidance® methodology, we create a way that guides feature requests to encourage more feature requests to be created. We see complaining, in this case through prioritizing feature requests, as a sign of hope. The goal isn't the perfect data or the perfect system. The goal is more engaged users.
We combine this methodology with data KPIs so leaders can set data entry or usage goals. This ties into four out of our six digital health vitals: accountability, system sustainability, utilization, and data quality. Take the Digital Health Quiz to learn more about the six digital health vitals and how they apply to your information systems.
Bridging the Gap Between Tech and Engagement
Navigating the maze of feature requests in the nonprofit space is akin to finding a harmonious blend between technology and the human touch. As we've journeyed through the dynamics of good and bad requests, the heart of the matter remains clear: engagement. Whether in the tech-heavy side or the human-centric arena, the intersection where technology meets genuine user needs is where the magic happens.
Remember, behind every feature request lies a user trying their best to navigate a complex digital world, sometimes with limited technological understanding. As stewards of these requests, our responsibility extends beyond the mere execution of tasks. It's about fostering a sense of belonging, validating the user's experience, and consistently striving for progress over perfection.
In a rapidly evolving digital age, nonprofits must embrace a mindset of continual adaptation, learning from both triumphs and missteps. And while the landscape of feature requests will always present its challenges, a consistent focus on user engagement, coupled with empathy and understanding, will ensure that we're always moving in the right direction.
And if you're ever stuck, act like my brother responding to my mom. I mean, skip the hug, but find your empathy and respond so that users feel heard, valued, and empowered to contribute to the collective digital journey.
