Yesterday I wrote about the very cool work that Stu Maschwitz has done with Penultimate in film storyboarding. His post was also quoted by John Gruber of Daring Fireball, who observed that going beyond a specific need to a broader problem is a “good way to think about making feature requests.”

I’ve thought about this for some time, and I’d like to say a little more about the way that I listen to users, and by extension, how you can have a more powerful impact on the development of Penultimate and your other favorite apps.

The software ecosystem is splintering as we speak, into a huge constellation of relatively small shops producing mobile, desktop and web software that’s accessible to a very broadly-based mass market. This is unprecedented in the history of software, and one of its consequences is that end users often have a remarkably direct line to the ears of the people who make the software that they use every day. It’s both rewarding and useful for me to hear from passionate users like Stu— we get lots of email and feedback on our community page every day. 

Very often, feedback is framed in terms of a “feature request”. This is a shopworn phrase that encompasses messages like “Hey, I would like Penultimate to do or have thing XYZ”. (In our case, XYZ is something like “more pen colors”, “text input”, “handwriting recognition”.) Here’s the problem with requests like this: they don’t tell me everything that I need to know. My responsibility as a product manager is to tease out the actual problems that are behind the request, not just build the features. 

I’ll give you an example from Penultimate. Early versions of the app had the eraser function, but the eraser was a fixed circular size (about the size of a fingertip). I got lots of feedback asking for selectable eraser sizes (small, medium, large). That was the feature request: “add other eraser sizes.” But more eraser options, as such, was not what these users were really asking for, which was usually a way to do detailed erasing in small areas. Instead of complying with the letter of the request, I like to think I did one better, which was to make the eraser size dynamic. There’s still just one eraser, but if you’re working in a detailed area, it’s tiny. If you make huge swipes, it’s large. 

In software design, there’s a phrase for this sort of thinking that I much prefer: “use case.” Although it’s inside-baseball terminology, the distinction is important. A use case describes what the user wants to achieve, not the specifics of how they achieve it. Use-case-based design means you dig at what people are trying to do with your software, and use your knowledge about what is possible to try to solve their problems. (Or, in some cases, decide those problems are just out of scope for what your software does.)

I often reply to users by email or on Twitter asking for more context for their requests, and I’m often surprised by what I hear. Someone else’s distillation of a use case into a feature request is not necessarily obvious until I ask. The real risk of granting only “feature requests” is that I’ll end up with more clutter in my software, yet not actually solve my users’ problems, or not solve them as elegantly as possible.

Other examples: Penultimate has a single-button export-all-to-iTunes feature, and a single-button create-and-open-notebook feature, because “back up all my notebooks” and “let me start a new notebook quickly” were important use cases that came out of user discussions.

So! Now for advice to users of Penultimate or any app: when you give developers feedback, be sure to include how you use the app and what you’re trying to accomplish. Explain the “why”, as well as the “what”. Tell me about your workflow, and where the app falls down in that workflow. You may find you get both a better response from developers, as well as a greater likelihood of having your actual problem solved.

I’m hard at work on the next update to Penultimate, and looking forward, as always, to hearing your use cases.

Ben