In my conversations with colleagues and developers, I often mention “Reaching Demand.” While this phrase carries a lot of weight, it isn’t too hard to understand.
This phrase was introduced to our company from Richard Tripp, as a component of his POV Method. He explains this on his blog, here.
To add onto his explanation and make it even more accessible, I want to break it down for you.
When a customer says, “I want ______ in your app,” you can’t take that only on its own. It’s not that the customer is wrong; it’s that you can’t build every feature for every customer.
Detecting and separating Aspirational Demand from Reaching Demand will allow you to prioritize and discover what benefits the customer is trying to get to.
A common feature request I heard a lot was this — “I want Twitter integration.” I asked them why, and I would hear any number of responses that would eventually lead to a dead-end. Of all the people who I gave my business card to and instructed them to show me how adding an [ambiguous] Twitter integration would help them get more leads, sales or save time — or other business uses, I received zero responses to my inbox.
Seriously, zero. The sample size was about 20 over the course of six months.
The sad thing is, I was serious. I really wanted to go to battle for them, but evidently, they didn’t find it important enough to write a short email telling me how it would help them. I knew a few ideas on what might help them, but I am not the end-user and really couldn’t go to battle since users didn’t find it important themselves.
Alas, I had just encountered Aspirational Demand. It’s fantasy. It’s an idea and nothing more.
Sidenote: It’s probably a good time to let you know that we do have some basic Twitter integration built into our software for sharing out marketing campaigns and landing pages easily. More recently, we added support for Twitter Lead Generation Cards, for Twitter Ads. These enhancements happened independently of the example described above.
Now, let me tell you about another feature customers asked for. It was Gmail integration. They could easily articulate why and how it helps them in their business. It’s what you predicted: They use Gmail to stay in touch with customers. They wanted to cross-reference customer data to the inbox (akin to Rapportive) and run actions, add tags or see other past activities. This helps them save time, qualify leads and eventually generate sales.
Bundled in this feature request was details about what they were already doing. They often already had Rapportive installed or had Microsoft Outlook with our other Sidebar plugin running. Nearly all customers could describe the process to look a customer up and tend to their needs with our software.
Gmail also proved to be the number one email provider and a huge hit among small businesses, so it would be imprudent to ignore this. A third-party integration authored by AutomationCore was a hit in the Marketplace and something that customers were rejoicing about — and even paying for.
This is an example of Reaching Demand. It’s real and can be demonstrated repeatably.
Full disclosure: Infusionsoft eventually acquired GmailCore from AutomationCore and is available under the Infusionsoft Sync for Gmail product at no charge to Infusionsoft users.
So, what’s the differences between Reaching Demand and Aspirational Demand?
I’ve emphasized the most relevant differences between the two.
Reaching Demand
- A user has taken action to achieve the outcome they desire.
- A user can demonstrate the problem/pain clearly and consistently.
- A user might even be using a competitor’s software to achieve this task.
- A user could describe the cost to their business (or quality of life).
Aspirational Demand
- A user is not taking any action towards the outcome they desire.
- A user is unclear about how their idea will improve their business (or quality of life).
- A user may drive the discussion towards feature comparisons from competitors.
- A user may only have cursory knowledge of the impact of their idea.
Now, not every person is accustomed to having this information extracted from them. It’s important to assure users that you just want to better understand their request. Truthfully, it’s your responsibility to draw out these concerns and ideas from users as to ascertain the larger benefit they are reaching towards.
The cost of not acquiring the proper intelligence is infinite. You not only harm user trust, cost thousands (or millions) of dollars, you could be pivoting towards a market that doesn’t exist. Even if you developed said features, it’s likely they would remain unused. What good is a feature if no one uses it?
I’m not suggesting to ignore aspirational feature requests. Those are valuable, too. But don’t act on them right away. If there’s a means for R&D to explore the viability of these ideas, market and customer fitness, then go for it. In the age of software development, you must prioritize features against business impact. It’s prudent to design your product around the benefits seen by the most users — not just the loudest.
Reaching Demand: Identifying Features & Benefits People Will Actually Use
— by Joe Manna
