01 The Problem 
The feature request system for Pushpay's mobile app product relied disproportionately on quantitative data, often lacking the context for which the feature was requested. 
Feature categories were broad in scope, emphasizing the ease of presenting monthly revenue amounts over actually defining jobs to be done. 

Employees had become accustomed to a culture of "adjusting expectations," neglecting to record pain points as potential feature requests. 

Proposed Solution
The feature request process has room to incorporate more qualitative data which will further define use cases for the product team, allowing them to better see the value and context of the changes our customers desired by letting the customers speak for themselves. Finally, I will address the employee culture which has become accustomed to assuaging short term customer concerns rather than setting them up for improved experiences in the long term. 

Results Summary

180% increase of feature requests submitted to date
3% increase in feature requests fulfilled by MRR for Q2

02 Refining Existing Data
The first step was to analyze our existing data and determine which categories were too broad. The general rule I used was if a category could not be resolved by a single job to be done, it would need to be broken up.
Pictured above is the old feature request reporting style. 
The previous method emphasized quantitative data, prioritizing a handful of broad categories which were sorted by total monthly revenue.
Categories like “Push Notification UX/UI” were impractical. And while they allowed us to easily say “there was a 4% increase in Push Notification UX/UI feature requests by revenue this month,” you may note this sentence is useless in terms of presenting an actual task for the product team to action.
While it is of course useful and necessary to track quantitative data, I knew what would really drive features forward was the customer's voice.
03 Customer Stories
I was able to restructure the feature request process to allow for more detailed information to be collected, and for myself to be able to speak directly to customers in order to ascertain more details as to what they were doing when they decided they wanted to reach out to us.
Increasing qualitative data required two changes to the current process:

     (1) Altering the way feature requests were recorded.

     (2) Changing the employee culture surrounding feature requests. 

Change (1): Emphasizing the Customer's Voice
The old method favored quick categorization over providing context. Broad categorizes served as “catch-alls," possessing a large revenue amount, but were useless on their own as they had multiple jobs to be done under the same title.
Instead I re-purposed an input field on our CSM software which would allow employees to record quotes, the situation, and the goals of the user. I reached out directly to customers when relevant in order to better understand the context, the expected behavior, and the emotions they were feeling when they encountered pain points. This made it possible to create customer stories surrounding specific features.

Change (2): Changing Company Culture
Feature requests were generally only logged when customers explicitly expressed the the desire for a functionality the product did not currently support. I immediately recognized that the amount of users who would take the time to clearly communicate these desires represented only a fraction of the opportunities we had to listen to user needs.
After interviewing members of the apps team, it became apparent that their customer-support culture was one that revolved around “adjusting customer expectations” in order to let our customers clearly know the limitations of the product. On the surface this may sound like transparency, but it leads to a stagnation of innovation via resignation to the status quo.

"On the surface this may sound
like transparency, but it leads to
stagnation of innovation via resignation
to the status quo."

Further investigation revealed that new customer-care providing employees often learned of feature limitations from other employees, but they were very rarely told why the product had that limitation. There was also seldom documentation available on the reasoning behind that limitation. This had the effect of employees not reporting feature requests as they simply assumed the matter had already been investigated and was unchangeable. They therefore did not file a feature request, and thus the product team was unaware of some of our customers' most desired features.
I set out to change this culture with empathy-driven approaches. I created guidelines for the apps team to follow when interacting with customers directly or indirectly, asking them to always be mindful of feature requests made in less conventional ways, and always consider filing a feature request if:

     The customer is experiencing a pain point. 

     We are having to adjust customer expectations of our product. 
04 Other Challenges
While implementing these changes the company consolidated its CMS platform, transitioning away from the software for which the majority of data related to feature requests was stored. This created a tight deadline for another member of the design team and myself to sift through the sunsetting CMS platform and ensure that there would be no loss of qualitative or quantitative data. 
The change also necessitated restructuring the Feature Request system from the ground up. It was my responsibility to define the new process which the service delivery team would follow, and to ensure it was both scalable and easy to learn. 
05 The Results
Though the software transition presented its own challenges, it made balancing the scales of incoming qualitative and quantitative data easier as I had more freedom to make changes to the process. Due to the greater emphasis on customer stories, and a greater awareness of best practices, the new feature request process had a number of immediate benefits including:
     Increasing clarity and productivity of my meetings with senior product members. 
     A sharp increase in app product related feature requests. 
     Empowering the apps team with greater control over the future of new features.

Thanks for looking!

You may also like

Back to Top