Features and Customers
Last month I had the pleasure of meeting Bob Walsh at the European Software Conference. The evening after the conference, a bunch of us had dinner at a Mexican-Italian eatery near the Dom in Cologne.
During our conversation, Bob mentioned that EditPad Pro has been his favorite text editor for quite some time. He said that he got the impression that for the version 6 upgrade, I seemed to have focused on “ticking all the boxes” when comparing EditPad Pro with other popular text editors. Fact is, I hardly ever look at competing products.
My vision is that if I spend too much time looking at other products, I’ll just end up with copy-cat design for my own. It’s easier to design something new when starting with a blank slate than with starting with how things have been done before. At least it is for me. Just like it’s easier to learn a new habit than to unlearn a bad habit.
So how did I decide what to put in EditPad Pro 6 and what not? Easy: customer feedback. Many years ago, I spent an afternoon or two to hack together a simple bug and feature tracking database. It’s just four tables for products, versions, and issues in a master-detail relationship. The fourth table is the reason I rolled my own instead of using an off-the-shelf product. At the time, I couldn’t find anything that could keep a list of customers for each issue being tracked. So if Joe requests feature X, I email Joe a boilerplate “thank you for your feedback”, enter issue X into the database, and paste his email as a vote for issue X. That gives me a good idea of how many people care about X. That in turn allows me to estimate a cost/benefit ratio of implementing X.
It’s not a democratic system where issues with most votes get implemented. Reproducible bugs always get fixed, even if nobody complained, or “Just Great Software” wouldn’t be what it says on the box. Major new features or UI redesigns always get pushed ahead to the next major upgrade. While new features sell, product stability sells too. But when deciding what we have time for, and what needs to wait, customer feedback is a very useful metric.
Of course, Bob wasn’t completely off the mark. EditPad Pro 6 did add a lot of features that are, in some form, available in other text editors. Our customers have seen or even used those editors. “Product Z has X. When will EditPad have it?” is a very common request. But instead of just downloading product Z and plagiarizing the whole feature, I look at why the customer wants the feature. Most customers motivate their requests. Entering the relevant details into the feature tracking database helps to improve the feature’s design. E.g. when people were requesting built-in FTP for EditPad, it was obvious that the need was speed and convenience. The power of a stand-alone client wasn’t needed, because everybody already has one. Hence EditPad 6 got FTP as a sidebar that can stay connected to multiple servers for quick online editing. While that certainly ticks “FTP” on the feature matrix, such comparisons don’t show how happy people are with the feature’s implementation. E.g. had EditPad Pro 6 implemented FTP in a modal dialog, it would have been even less convenient than an external client. (Not that I ever considered such horrible design.)
The cherry on the cake is that collecting email addresses as votes gives you a very valuable means to contact your customers. When a new release fixes a bug or adds a feature that Joe emailed us about, Joe will get an automatic email saying the latest release implements X. Even though the message isn’t very polished (and it apologizes for being so), customers really appreciate this bit of attention.
My recommendation is to worry about making your customers happy rather than ticking all the boxes. Word-of-mouth is far more powerful than a doctored comparison from your marketing department hat.