Some products seem to fail at their primary requirements. What is the primary requirement of your product? Here are a couple of examples from everyday life. I hope these examples help you reflect on the primary use case of your product and how well it delivers.
Example 1: Salt Spreader
This past Sunday I arrived at church and found the parking lot to be one big sheet of ice. It was worse than a skating rink because the temperature was above freezing, so the ice was thick but melting and thus wet. Some cars were sliding around with no traction whatsoever. Worried about the others arriving, I quickly found the salt spreader, pictured here alongside the tool that I ultimately used to spread the salt. You see, the salt spreader (blue) works very well when you have traction; when you push the spreader, salt falls through a hole in the bottom of the basin and a spinning disk throws the salt horizontally and very effectively distributes the salt across a wide area. The trouble is that when the spreader is on ice, the spreader simply slides along the ice, the wheels don’t have traction, don’t turn, and therefore the spreading disc doesn’t turn. This renders the tool completely ineffective. I believe I could spread salt on a surface of dry pavement, and no doubt it would work to spread grass seed on soil. But that’s not the primary use case! Normally when you’re spreading salt, you’re spreading it on a sheet of ice.
Faced with this deficiency, I pulled out the large snow shovel, filled it with salt, poured concentrated salt on the ice, and then went back with a push broom and spread the salt.
The snow shovel became my salt spreader, and the spreader sat idle, no doubt completely ashamed of itself and resentful of the designers who failed to take into account the most common use case.
Can’t you just picture the design requirements?
- Spreader must carry two full bags of salt.
- Spreader must throw salt to a radius of 10 feet when pushed.
- Spreader must allow user to select salt concentration. (There is an adjustment to control the size of the opening in the basin through which the salt falls.)
- etc …
Provided with these requirements, the engineers noticed that they had a grass seed spreader that could be easily modified to spread salt rather than seed. The hole and spreader geometry were adjusted to handle salt, and voilá, the product is ready to ship!
All of the requirments for this spreader could be stated in a single use case or problem statement:
- Spreader must allow user to distribute salt at a 10 feet radius while the user pushes the spreader across a sheer ice surface.
Example 2: My sock drawer
How many unmatched socks do you have in your drawer? It absolutely mystifies me how this happens, but I have 25-30 single socks with no apparent matches. Somehow they disappear, and even when they don’t, I have arrays of similar-but-not-quite-matching socks, one array for each color; blue, black, beige, etc.
I don’t think I’m alone. In fact a search for “Lonely Socks Club” reveals that many people have written about the plight of the single sock that has lost its match. About 10 years ago a Canadian radio program had a feature where listeners could send in their unmatchable socks, and the radio host would diligently look through all the socks to match them up, and when matching socks were found, he would call the sock senders to piece together how these socks might have been separated. This segment was so popular that within a short time the radio station had to implore its listeners to stop sending the socks on threat of burning all socks. They ran a contest to determine what to do with the pile of socks, and the winning entrant proposed to mould the socks together into a couch!
All that to say that the lonely sock problem is pervasive.
So if you’re selling socks, what is your primary requirement, use case, or problem statement? Of course, socks need to be comfortable, withstand dozens of wearings without losing their ability to hug the calfs. But that ability is not a differentiator; it sounds like table stakes.
Color and fabric might be good buying features too, but all sock vendors have a variety of these.
For me, the primary requirement of socks is the ability to easily find its mate after the laundry is done!
I realize
d this when I bought the beauties on the left a few years ago. In the picture you can tell that I’ve nearly worn them out, probably because I like them so much. In all visible areas, they are plain black. But the toes, heels, and cuffs, are a distinctive color. I like to think of the color as my little secret under my shoes.
And if you don’t like that idea, on the right are some socks with a distinctive logo on the upper calf. Despite being plain black socks, I can always match these ones up without looking closely at the fabric.
So if you’re designing socks, here is your primary use case, after you talk about the “ilities” which in sock-land I suppose are wearability, breathability, and so on.
- User does laundry for 1, 2, or 5 people, producing a pile of socks. User wants to quickly match socks with identical matches without mistakes.
- User opens unsorted sock drawer in the morning, before putting on glasses, and before his morning coffee. The room is dark and he can’t turn on the light because someone else is sleeping in the room. User must be able to quickly find two socks that match. Bonus points for being able to identify whether the sock is blue, black, or some other dark shade, without benefit of good lighting.
When I shop for socks, I keep looking for socks that advertise themselves using the above use cases. I think socks with those features would outsell the competition, with little or no increase in manufacturing cost. Furthermore, the price sensitivity would also decrease, because I care more about matching socks in the fuzzy dark morning than I do about an extra buck for the pair of socks.
Does any of this matter for your product? Short answer: Yes.
When I was at Wily Technology (now part of CA), our systems management product had three fundamental capabilities that no competitor could match:
- Product worked in a production Java EE environment with near-zero impact on the running system.
- Never take the managed application down.
- Provide useful data immediately.
The early user interface was not as good as many competing products, and competitors had many other advantages. But these basics enabled our core buying use case:
- User has high-volume, high-value applications that exhibit problems only under real-world situations, and frequently only after hours or days of successful execution. The user must be able to monitor the running application in real time, under real-world production applications, and when problems occur, get diagnostic information quickly and easily. The problem may never be reproduced.
The company moved on to sell proactive monitoring and management, and this of course is necessary. (Monitoring commands a far higher price point and buyer profile than diagnostics.) But in the early days, and in fact for several years, Wily was the only player in the market that could satisfy the drop-dead diagnostic use case above. With that solved, buyers would spend big bucks to ensure they continued to have this ability.
In other companies that I wish I could name, I’ve seen products where we could do myriad impressive things, but we simply didn’t solve the primary problem, or enable the primary use-case of our buyers. That was, um, a much more difficult sale.
The trick is that you need to know what those problems and use cases are. Stacey at Pragmatic Marketing (channeled by Steve) wrote a great article about this point. Your job is NOT to gather requirements, but rather to observe them. The examples above show this clearly. If you talk to sock wearers (shouldn’t be hard to find a few), you’ll almost never get the differentiating use case that I suggest above! They’ll tell you about color, how the sock hugs the calf, stays up, but allows for circulation. I doubt you’ll have many sock-wearers tell you about the sorting problem.
What is your prospect’s primary use case or problem statement? Are you enabling the use case or solving that problem? Share your experience with us!
– Alan
PS: Win/Loss Analysis is a great way to start figuring out the primary use case of your buyers! Many of our readers complain that they are not allowed to do win/loss, or are simply too busy. If that’s your situation, here are some strategies that might help: