Primary product requirements

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.Which one is the salt spreader?

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?

  1. Spreader must carry two full bags of salt.
  2. Spreader must throw salt to a radius of 10 feet when pushed.
  3. 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.)
  4. 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:

  1. 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

(These are not mine!)

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!

Easy to match!

I realizePlain but still easy to matchd 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.

  1. 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.
  2. 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:

  1. Product worked in a production Java EE environment with near-zero impact on the running system.
  2. Never take the managed application down.
  3. 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:

  1. 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:


17 responses to “Primary product requirements

  1. Excellent examples, Alan! How many of us have purchased a “salt spreader” product in the past? And, what happens after we realize it doesn’t achieve the intended goal? As a consumer, I feel ripped off…and make a committment to no longer purchase from the company who sold me a useless product. Discovering and capturing primary use scenarios enables products to be sold, used, and recommended. Missing the mark causes short- and long-term declines in customer numbers and revenue. Observe users to find core problems, and solve them. Seems simple, doesn’t it?

    • Seems simple, isn’t. 🙂 Great point about how the consumer feels. As I was spreading the salt with the broom, I was cursing the salt-spreader designer. Well, I was at church, so I wasn’t cursing. OK, I was.

  2. This is an incredibly important aspect of product management, that I often find missing. A large majority of product managers, especially in the software industry, are managing lots of features and requests, without thinking about what problem the feature is trying to solve. They try to prioritize them based on customers and potential revenue, and then plan product releases accordingly. Not only does this lead to products like the salt spreader, but it also makes the product managers life miserable. When managing market problems we can group multiple requests from customers and other market inputs into the problem the end user would like addressed. As a product manager I know my product and companies capabilities better than any one of my customers, and can more than likely come up with the best solution to their problem based on my core-competencies. This is a topic that could use much more discussion.

  3. Derick – I like to be the collector of market problems and have a design team focused on solutions. I believe design should report to PM. Is design part of your personal core competency?

  4. Yes, design is part of my personal core competency. In the past I’ve worked in systems engineering and product design. I’ve seen in many organizations a role created called product architect or solution architect that plays this design role reporting to PM. Basically they take a market problem and possibly a user scenario, and then they come up with possible solutions. Similar to a HOQ(House of Quality) approach. This set of potential solutions is then reported back to the PM, who then makes the ultimate decision. Sometimes they use some market validation techniques to ensure that the solution will actually solve the problem and deliver the expected value. These solutions then go into a detailed design phase performed by an engineering or development group.

  5. In that case I’m all in favor of what you’re advocating. I’ve seen very few PMs with full design skills, but a lot of PMs who treat design as a hobby, and I see it as a professional discipline, as I gather you do.

    Even a PM-design-hobbyist should do better designs than developers, assuming the PM has internalized the market problems.

    thanks for your comments.

  6. How much of the product strategy to you feel defines the primary product requirements? Getting to the initial requirements of
    1) Spreader must carry two full bags of salt.
    2) Spreader must throw salt to a radius of 10 feet when pushed.
    3) 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.)

    Makes some assumptions about the product strategy, the use case, the problem statement, the business opportunity, technical approach …

    How much of the product strategy is formally incorporated into the requirements?

  7. Alan: have you ever considered throwing all of your socks away and then going out and purchasing a large quantity of identical black socks. Yes, you’ll still have socks go missing, but you won’t care anymore because every time you lose two sock, you can match the two remaining socks up and you’ll be back in business.

    – Dr. Jim Anderson
    The Accidental PM Blog
    “Home Of The Billion Dollar Product Manager”

  8. Jim, that would be a solution, wouldn’t it. I could even go further and buy black, tan, and white, therefore allowing a little color variation but also solving one of my core use cases. I might just do that.

    Your question raises another interesting issue: when, as a PM (rather than a buyer, which your suggestion implies), can you assume a greenfield with no “legacy” products in the mix. In the case of socks, the trouble is that most people have an “install base” that they cannot or will not jetison. And of course I have 5 people in my house, including three kids, and I will not receive dinner in my house for a very long time if I chuck all their socks in favor of your monochromatic solution.

    On second thought, Jim,(with respect) your suggestion sounds like so many of the painful engineering discussions I’ve endured. My engineers often want to assume a clean slate, but rarely will our sales people find that.

    I heard the humor in your suggestion, btw. Just saying that while that approach may work for a certain persona (eg single male living alone with no interest in whether the socks make the man, and also enough disposable income to pitch all sock, and the mindset to do that), my sense (strictly opinion) is that the persona described is a small fraction of the market. It’s also unclear whether any sock vendor could win his business through differentiation, since he is simply looking for black socks.


  9. Val Workman: There was a comment from Derick Workman above too. I’m left assuming that there are two of you. If you’re both reading this blog, I’d hate to hear your arguments at home. If there is only one of you, well, I’ll assume there are two of you.

    Great question about strategy being embedded in the requirements. I think this is a topic for a future article, but in the mean time, here is my response:
    – I may not have emphasized this enough in the article, however, the problem statement / use case (Spreader must allow user to distribute salt at a 10 feet radius while the user pushes the spreader across a sheer ice surface) is sufficient to cover the requirements that you listed, and even goes further. Problem statements and use cases create a situation where engineers can innovate, not to satisfy *requirements*, which are an artificial construct, but rather to satisfy a user’s goals, which are real. So my first response to your question above is that I strongly favor problem statements over requirements, except in some cases of non-functional requirements such as the GSA’s accessibility requirements, which must be followed to the letter if you want to get Fed contracts. Even with that last caveat, Accessibility can be better satisfied if you also provide specific use cases for specific user types that go beyond the GSA requirements.

    – Yes, strategy is embedded in the requirements, problem statements, and use cases. Absolutely. In fact it is one of the primary embodiments of those. Another embodiment might be your approach to support calls, which may have elements of the product (Help menu links to the support website, as a simple example), but go beyond the product and into call volumes, support rep training, and so on. All areas of the business should take their lead from the strategy. Product requirements (in whatever form) embody a subset of the company strategy.
    – If your product requirements are not aligned with your strategy, then the requirements become the de facto strategy. This happens all too often. Michael Porter calls strategy a series of decisions and activities; we can determine the company strategy by watching what the company is doing. You may have a product strategy document that waxes vaguely about “usability”, but if your company doesn’t fund product design, then your actual strategy is probably not about usability.

    Hope that helps.

  10. A bit off topic here, but I have a suggestion for your sock problem. When a pair of socks wear out, throw ALL your socks out. Every single one. Then buy a whole new set – ALL EXACTLY the same.

    So, the primary goal of the user becomes “must be able to buy in bulk”. Having unique socks is a vanity – your time is more valuable than trying to match socks!

  11. Boy, we should use mundane objects like socks more often in our posts. It really fosters discussion.

    Nothing personal to those who’ve suggested it, but the recommendation to buy new socks all the same colour or of limited colours to eliminate the “lost sock” problem is akin to the situation where Technical Support suggests a customer reinstall their software when some strange problem occurs. It’s not an appropriate solution.

    Now were I a sock vendor, I’d absolutely love these kinds of suggestions. Making my product into a true consumable item will do wonders for my volume.

    But as a sock wearer AND a Product Manager (as many of us are), I have, while sorting out socks, wondered how to efficiently address this problem. My solution — and I fear only a software PM would spend any time thinking about this — is for enlightened sock manufacturers to put a variety of marks on soles of matching socks. e.g. something simple such as a diamond or circle with a letter in it or something else. That way, it becomes a very simple exercise to match paired socks — at least from that manufacturer.

    The value to me as a consumer is clear. And by solving the consumer’s problem — although not necessarily in a competitively sustainable way — it does help differentiate my offering and gain some customer loyalty.

    And to be perfectly honest, I think it’s much better than this solution

  12. Pingback: Socks in awe: Customer interviews vs. User observation « On Product Management

  13. Pingback: Usability is all in the details « On Product Management

  14. For the socks example,

    Just tie the two socks of a pair together before putting them into the box having all other socks. Thats it.

    Normally people don’t wash all the socks in one go. Also they will not be in a great hurry when then they takeout dried socks from washing machine. So at this time they just have to tie two socks of a pair together (one knot is enough) and then place it along with other socks. So when they want the socks they see pairs of socks always together.

    • Raghu – As a user without a great product to buy, I appreciate the work-around you suggest, but I still want more from the product designers and manufacturers. The point of this post was to show that product design can eliminate these problems and thus eliminate the need for work-arounds. Several others have suggested work-arounds. What I’m trying to point out is that the PM needs to observe the work-arounds, call them out as real market problems, and in doing so, find potential market advantage.

  15. Hi, Alan, thanks for a great and well-written post.

    I’d like to share a tool that formalizes the elements that you have intuitively identified.

    It’s called SSNiF scenarios, because a complete user story always has these elements: a Stakeholder (usually the customer) in a Situation, with a resulting Need, that is resolved by a Feature.

    To apply this to one of your examples: Stakeholder: someone living in a cold climate
    Situation: It gets icy, sometimes with very slippery wet ice
    Need: to spread salt
    Feature: (TBD; need an invention that spreads salt even on highly slippery surfaces. Spiked wheels for traction?Independent motorized spreader? Sled with separate lever to spread salt?)

    In the end the salt spreader might have two or three big SSNFs expressing its big-picture purpose, and perhaps twenty or thirty little SSNiFs to isolate each use case. SSNiFs scale well, so a sophisticated product would have scores of SSNiFs if needed.

    SSNiF scenarios can be tabulated, prioritized, and snapped together like Lego blocks to compose detailed requirements (with little SSNiFs) or even product visions (with big SSNFs).

    What’s also nice is they are explicit about the problem, they state WHY the problem exists and for which sub-group of customers. They also cleanly separate the problem from the solution, so that if a better F comes along to resolve the SSN, then it’s a better solution.

    SSNiFs make a great output of ethnographic research, because they are actionable.

    For the rundown on SSNiFs, including free templates, please see:

    Thanks for listening and if you find this technique interesting, please pass on the word!

    Best regards,
    Philip Haine