Category Archives: article

Deciding what features to implement

This is a guest post from roving software entrepreneur, Steve McLeod.

Each feature you add to your software product takes time to implement, adds ongoing complexity, and is hard to get rid of later. So you need to choose wisely when adding new features.

Here are some tips on choosing which features to implement.

Does your product really need new features?

This question might be surprising, but it is an important one to ask yourself. A software product is never completely finished. There is always scope for improvement. This makes it hard to know when to stop working on it.

If your product is mature and has stable revenue, there might not be much opportunity to increase sales. Adding new features would please some customers, but would not be a good use of your time.

Products that should be considered “done” can still have a large backlog. Don’t be fooled into thinking that your product will only be done once all existing feature requests are done.

Your product might have great potential to grow, but not by adding new features. Perhaps you need to improve your sales and marketing efforts. Don’t use your feature request backlog as an excuse to neglect the other important parts of running your product.

It’s okay to ignore your backlog

Feature request backlogs seem to never shrink. Implementing improvements leads to even more feature requests.

Looking at your backlog can be overwhelming. You’ll see feature requests that are years old. There are others that you intended to implement, but never did. It is okay to ignore these.

Don’t feel that the entire backlog consists of promises that must be kept. Some requests are no longer relevant. Some are from customers who no longer need your product. Some are simply not worth the substantial effort.

Keep your grand vision in mind

Prefer to implement highly requested features. But before you do, make sure each feature fits your long-term plans. Ask yourself:

  • who is your ideal customer? Is the feature relevant to them? For example, your enterprise customers might be asking for “single sign-on”, whereas you are more interested in working with small businesses.
  • will this be an ongoing cost- and time-sink? For example, a particular feature could require HIPAA (a US health industry regulation) compliance, while you have no interest in the extra workload and costs of HIPAA compliance.
  • does this proposed feature agree with your marketing angle?

Each new feature has ongoing costs

Remember that each additional feature comes with ongoing costs in support and complexity. Each new feature is an additional place for bugs to hide, adding to your future workload. Take these future costs into account when deciding if a feature should be added.

Features interact with each other, sometimes in unexpected ways. Even one additional checkbox in a settings panel can lead to ongoing confusion.

Be wary in particular of features that require integration with third party products. For example, many a product owner was burned when Twitter turned off some parts of their public API. Another example is my own experience adding support for connecting to customers’ email inboxes. I then found myself supporting not just my own product’s problems, but those caused by customers’ email service provider.

Sales-blockers are high priority

Not all feature requests are equal. Requests for feature A might come only from long time customers of your product, while feature B is requested only by your trial customers. It sounds ruthless, but you should prioritise the feature requested by trial customers.

When running a business, you do need to care for financial concerns. Take into consideration that:

  • A trial customer is likely to report a showstopper (for them). When you implement features requested by several trial customers, you are likely to increase revenue.
  • An existing customer is likely to report an inconvenience. You probably won’t lose the customer by delaying the improvement they asked for.
  • You need new customers to keep your business healthy.

It is important, of course, to care for existing customers. Don’t take this as an argument to ignore existing customers altogether in favour of potential customers.

Identifying and fixing sales blockers as a matter of priority is especially important for new products. It takes time to find the right balance of features a new product needs to meet the demands of the market.

Prefer the easy things, but not always

Let’s say you are deciding which of two features to implement next. Both feature A and feature B have been requested dozens of times. Feature A will take a week’s worth of work, and feature B will take a month’s work. Which one do you do?

Feature A, right? Maybe not.

Feature A is usually the correct choice. But you’ll be repeating this scenario over and over. Your product will gradually gain many relatively trivial features, while never getting the important features you need to create a compelling product.

Sometimes you need to do the hard work to add the features that are difficult to implement.

Listen to your customers…

Your customers are a great source of ideas for improvements to your product. As they use your product they discover what’s missing and what’s poorly implemented.

Therefore make it exceedingly easy for your customers to get suggestions to you. Consider adding a “Suggest an Improvement” link to your support page and to your help menu, if applicable. This makes it clear to your customers that you are actively seeking suggestions. My experience has been that customers notice these links and use them.

A “Suggest an Improvement” link can be as simple as a “mailto” link. A basic dialog or web form also works well. If you are seeking inspiration on how to do this, look at the “Report an Issue” form linked from the Google Chrome’s Help menu.

Another way to get customer suggestions is by asking them via a survey. This is okay, but it requires people to imagine back to when they last used your product. Us humans tend to be pretty poor at recalling things. It is much better to encourage customers to send suggestions as they encounter difficulties, while it is foremost in their mind.

I found collecting and organizing feedback for my own product, Poker Copilot, to be a pain. So I launched a new product to help manage feature requests. It allows your customers to suggest and upvote improvements for your product.

…and not your competitors

You’ve probably already heard that you should “listen to your customers, not your competitors.” I’m repeating it, because forgetting this can be deadly to your business.

Feature-envy leads us to believe we have to add every feature our competitors offer. Like regular envy, it is best to ignore it.

When your competitor announces a new feature, it can be demoralising. You feel you are falling behind and unable to compete. If the feature looks impressive, you’ll be tempted to add it to your product as soon as you can.

But wait. Have any of your customers actually requested this feature that your competitor added? If not, it is probably because it is not all that useful to your customers.

Your competitor might eventually regret adding that feature, as it turns out that only a small but demanding percentage of their customers use it. By not adding it, you could be giving yourself an advantage.

I’ve discovered that customers often learn about the good features my competitors have. They then tell me that they want these features. Only then do I start considering adding them.

Small tweaks versus major features

I just recommended listening to customers. But be careful of only using customer requests as a source for improvements.

Your customers tend to ask for incremental improvements. Customers are more likely to ask for an additional option in a drop-down menu than they are for a innovative new way to view their data.

If you rely on customer suggestions alone, you’ll never get the innovative new features that can make your product something much grander.

Make sure you balance your customer-contributed requests with your own innovative improvements.

Beware of preferring “pet” features

I just argued in favour of choosing innovative improvements. However this comes with a warning. Innovation can be used to justify poor choices. When you are in charge of decisions for your product, you are in danger of choosing improvements that you find interesting instead of those that have a strong business case.

Be careful. You could spend months working on a feature that is not very helpful to your business.

This is the type of feature that only one customer requested, but because it sounds more interesting to you than anything else in your massive backlog of feature requests, you immediately start working on it.

My own experience with this: I added scripting to a product even though no-one had asked for it and my target customer was not the type of person who would be interested in custom scripting. When I announced the scripting feature, not a single person seemed to use it. I eventually got rid of it.

How do you decide?

The tips I’ve offered you in this article come from my own experience. Do you have tips of your own for deciding which features to implement? If so, please add them in the comments below. I’d love to read them!

Steve McLeod runs a small software company in Barcelona, Spain. His products are Poker Copilot, a desktop analytics app for online poker players, and Feature Upvote, a web app that allows your customers to openly suggest and upvote features they want to see in your product.

How much code can a coder code?

Lines of code (LOC) is a simple way to measure programmer productivity. Admittedly it is a flawed metric. As Bill Gates famously said “Measuring programming progress by lines of code is like measuring aircraft building progress by weight”. But it is at least easy to measure.

So how much code do programmers average per day?

  • Fred Brooks claimed in ‘The Mythical Man-Month’ that programmers working on the OS/360 operating system averaged around 10 LOC per day.
  • Capers Jones measured productivity of around 16 to 38 LOC per day across a range of projects.
  • McConnell measured productivity of 20 to 125 LOC per day for small projects (10,000 LOC) through to 1.5 to 25 LOC per day for large projects (10,000,000 LOC).

It doesn’t sound a lot, does it? I’m sure I’ve written hundreds of lines of code on some days. I wondered how my productivity compared. So I did some digging through my own code. In the last 12 years I have written somewhere between 90,000 and 150,000 C++ LOC (depending on how you measure LOC) for my products: PerfectTablePlan, Hyper Plan and Keyword Funnel. This is an average of round 50 lines of code per working day. Not so different from the data above.

I also looked at how PerfectTablePlan LOC increased over time. I was expecting it to show a marked downward trend in productivity as the code base got bigger, as predicted by McConnell’s data. I was surprised to see that this was not the case, with LOC per day remaining pretty constant as the code base increased in size from 25k to 125k.


Some qualifications:

  • I give a range for LOC because ‘line of code’ isn’t very well defined. Do you count only executable statements, or any lines of source that aren’t blank?
  • My data is based on the current sizes of the code bases. It doesn’t include all the code I have written and then deleted in the last 12 years. I have just spent several months rewriting large parts of PerfectTablePlan to work with the latest version of Qt, which involved deleting large swathes of code.
  • It doesn’t include automatically generated code (e.g. code generated by the Qt framework for user interfaces and signals/slots code).
  • I only counted code in products shipped to the user. I didn’t count code I wrote for licence generation, testing etc.
  • All the code is cross-platform for Windows and Mac, which makes it more time consuming to write, test and document.
  • Programming is only one of the things I do. As a one-man-band I also do marketing, sales, QA, support, documentation, newsletters, admin and nearly everything else. I have also done some consulting and training not directly related to my products in the last 12 years.

Given that I probably spend less than half my time developing (I have never measured the ratio), my productivity seems fairly good. I think a lot of this may be the fact that, as a solo developer, I don’t have to waste time with meetings, corporate bullshit and trying to understand other people’s code. Also writing desktop Windows/Mac applications in C++ is a lot easier than writing an new operating system with 1970s tools.

50 lines of code per day doesn’t sound like a lot. But the evidence is that you are unlikely to do much better on a substantial project over an extended period. Bear that in mind next time you estimate how long something is going to take.

If you have data on LOC per day for sizeable projects worked on over an extended period, please post it in the comments. It will only take you a few minutes to get the stats using Source Monitor (which is free).







Choosing a market for your software

The efficient market hypothesis states that “asset prices fully reflect all available information”. If the efficient market hypothesis is true, then you would expect actively managed funds (where fund managers pick the stocks) to do no better than index funds. That does seem to be the case:

“Numerous studies have shown that index funds, with their low costs and ability to closely mimic the returns of markets both broad and narrow, steadily outperform the returns of most actively managed funds.” Wall Street Journal

Unless you have some sort of insider knowledge (which it might be illegal to exploit), you might as well invest in index funds or get your cat to pick your stocks as pay someone else to do it.

But I am interested in a different sort of market efficiency. If you have to pick a vertical market to start a software business in, does it matter which vertical market you pick? If the market is perfectly efficient for businesses, then each vertical will have a level of competition proportional to the size of the market. In that case you should have an equal chance of success whether you decide to write a game, a developer tool, an anti-virus product or a CRM system.

From lots of reading and talking to other software business owners I have come to the conclusion that the market is highly inefficient for businesses. The market vertical you pick has a big effect on your chances of success. It seems to me that the three worst verticals are: games, developer tools and consumer mobile apps.

Games are fun! Writing a game sounds like a blast. Much more exciting than writing software for boring businesses. It has also been getting easier to write games due to the ever improving tools. Consequently, the market for games is totally saturated. The outlook for independent games developers looks grim. Today on the Steam platform there are 12,971 games listed. Even some of the big and famous games developers only seem to survive by forcing their staff to work vast amounts of unpaid overtime.

Pretty much every software entrepreneur has considered creating a software development tool at some point. I know I have. It is a market that we all understand (or think we do). But consequently it is saturated. Software developers are also pretty horrible customers. They are used to using lots of free software. And that tool you spent years developing? They think they can write something better over a weekend.

“Thousands of people used RethinkDB, often in business contexts, but most were willing to pay less for the lifetime of usage than the price of a single Starbucks coffee (which is to say, they weren’t willing to pay anything at all). … Developers love building developer tools, often for free. So while there is massive demand, the supply vastly outstrips it. This drives the number of alternatives up, and the prices down to zero.” Why RethinkDB failed

I wrote back in 2010 what a horrible market the iPhone app store is for developers. Since then the number of apps has increased tenfold to 2.2 million, the average paid app price is a measly $1.01 ($0.48 for games) and some 90%+ of apps are free or freemium.

You should be wary of markets with no competition. But the really high levels of competition in these three markets drives down prices and makes it very hard to get noticed. Obviously not everyone in these 3 markets is failing. It is possible to create a product in one of these markets and be wildly successful (Indie game developer Notch of Minecraft fame springs to mind). But I think the odds are very much stacked against you.

So what market should you pick to maximize your chances of commercial success? Aside from the obvious factors (e.g. something you are interested in and knowledgeable about, something that solves a real problem etc) I suggest avoiding anything considered ‘sexy’ by other developers.

Here is a radical idea – create a software product aimed at women. The vast majority of software is written by men and consequently it tends to cater for men. 50% of the world’s population are women and they buy software too!

Just because a product is not in a ‘sexy’ market doesn’t mean that it has to be boring to create. I have found plenty of interesting usability, optimization and visualization problems to solve while developing my own seating planning and visual planning software products.

Here is a thought experiment. Imagine you are talking to another software guy at a conference and explaining what you product does. If your imaginary software guy says “that sounds cool”, then it’s probably a tough market to create a commercial product in. But if they look a bit surprised or their eyes glaze over, then you might be on to something.

Giving a shit

Sturgeon’s law states that “90% of everything is crap”. He was probably an optimist. Here are some recent examples of the sort of crap I come across day to day:

The school selection website

My wife and I had to select which secondary school we want out son to go to, an important decision for our family. We had to do this via a website created on behalf of Swindon council. I won’t bore you with all the painful details, but only an impressive combination of incompetence and apathy could have produced something so egregiously awful. At the end of the process we got an error message and the promised confirmation email never arrived. We were left feeling confused and angry. Every other parent we spoke to had a similar experience.


Feast your eyes on my local ATM:


Yes, that’s right, the buttons aren’t correctly aligned with the screen, so they have added some shonky visual cues in a feeble attempt to compensate for it. They failed – I have pressed the wrong button more than once. If they couldn’t move the buttons, why didn’t they just change the text positions in the software? I would like to know what sort of horrific set of bad decisions and sloppy planning led to this laughably bad design.

The in-flight meal

Check out this British Airways in-flight meal I was served:


Behold, the cutlery is in a sealed plastic bag in the pasta. To get at your cutlery you have to open a slippery plastic bag covered in sauce with your fingers, which are now also covered in sauce. Who could have possibly have thought this was a good experience? You might as well just eat the pasta with your fingers. Or stick your face in the plate. Maybe the subliminal message is: if you won’t pay for business class we are going to make you eat like an animal.

You don’t have to look very hard to find crappy design. Badly designed parking buildings, confusing ticket machines, painful to use Sat Navs, packaging that is almost impossible to open, web forms that won’t let you use a space or a dash in a telephone number. I could go on, but I’m sure you could come up with plenty of examples from your own life. The most frustrating thing is that these issues could have been avoided with a little bit of thought and care. I doubt it would have added more than an extra 1% more effort or cost to get them right.

Crappy products and services make everyone’s life worse. Hold yourself to a higher standard. Take pride in your work. Do usability tests. Get feedback from your users. Fix things that are broken. Keep improving. Above all, give a shit.

How to make difficult decisions

When you run a business (even a small business like mine) you have to make a lot of decisions. Many of these decisions are complicated and have to be taken with incomplete information. But you can’t take too long over them, or you will never get anything done. Here are 3 techniques I use to help with difficult decisions.

Break it down

This is a very simple method for breaking a difficult decision down into smaller parts using a spreadsheet.

  • Decide the criteria that are important for the decision. Add a row for each.
  • Add a weighting column. Assign each criteria a weighting in the range 1 to 10, depending on its relative importance to you.
  • Add a column for each option you are considering.
  • Set each criterion/option cell a value in the range 0 to 10, depending on the extent to which the choice for that column fulfils the criteria for that row.
  • Calculate the weighted sum for each column.
  • Choose the outcome with the highest weighted sum.

Here is an example for choosing between 3 different types of hosting:

making difficult decisions

It’s not particularly scientific, but it does force you to systematically break down the problem into smaller parts and justify your decision.

Take the long view

It sometimes helps to stand back and look at the bigger picture. I can think of no better way to do that than to ask a hypothetical (hopefully elderly) future me, lying on my deathbed, which option they approve of. For example, given the choice between adding an innovative new feature to my product or improving the conversion funnel by a few percent, I think future me would be happier that I chose to add the innovative new feature. It is also a useful reminder that many decisions probably aren’t all that important in the grand scheme of things.

Flip a coin

Sometimes you need to make a decision, but you don’t have enough information or the time taken to get that information is going to cost you more than making the wrong decision. In that case, don’t agonise over it. Just roll a dice or flip a coin and move on.

Hammer For Mac static website generator

I prefer static websites to a CMS for simple product websites because:

  • Static websites are fast.
  • I have more low-level control over the HTML/CSS.
  • I don’t have to worry about the very-real threat of a CMS being hacked.

Obviously writing every page separately in raw HTML/CSS would go against one of the cardinal rules of development, Don’t Repeat Yourself. But you can avoid this using a static website generator such as Hammer for Mac.


Hammer uses a simple syntax embedded in HTML comments to ‘compile’ a website from source files. I have now used Hammer to create several static HTML/CSS websites, including my and websites.

I like the simple syntax of Hammer. For example:

I can put the HTML for a page header in an _header.html file and then each page just needs to start with:

<!-- @include _header.html -->

I can define and use variables:

<!-- $current_year 2016 -->
<p>Copyright <!-- $current_year -->.</p>

And I can let Hammer work out relative paths:

<img src="@path image.png" />

If Hammer can’t make sense of a source file (e.g. it can’t find the image file), it generates a compilation error.

Because everything is text based I can easily manage all the source in a version control system. Also, if I have to move away from Hammer, it should be relatively straightforward to change the syntax to another static generator (or even write a replacement for Hammer!).

Overall I like Hammer. But it does have a number of shortcomings:

1. The user interface is very limited. Hammer shows you a list of source files and you can click on a source file to see the compiled version or edit the source. But the source files are listed in the order they were edited and you can’t filter or sort the list. This seems such a simple and basic feature, that I can’t understand why the developers have omitted it.

2. Hammer takes a dumb, brute force approach to compilation. If you change any file in a source folder, it recompiles *everything*, without checking if other source files include that file. This is a pain if you have 100+ source files. Surely it wouldn’t be that hard to work out which files depend on which and only recompile the files that need recompiling?

3. You can’t nest variables. For example you can’t do this:

<!-- $current_year 2016 -->
<!-- $copyright_message Copyright <!-- $current_year --> -->

This might sound minor. But it limits the expressiveness of variables significantly.

4. The vendor doesn’t do email support. If you want to communicate with them you have to use Slack or Twitter. I am old fashioned, I like email.

5. It only runs on Mac OS X (the clue is in the name).

At one point Hammer looked like abandonware, but owner sold it to and active development has resumed.

Currently Hammer is priced at £15.39 (and presumably some round number of US dollars). That seems way too cheap. I wish they would price it a bit higher and fix some of the issues above.


Updating the PerfectTablePlan website

I created the website for PerfectTablePlan back in 2005, using a dreadfully buggy piece of software called NetObjects Fusion (NOF). The sorry story of why I ended up using NOF is told here.

Until recently the front page looked like this.


I had done a fair amount of A/B test tweaking and it converted visitors to downloads and sales relatively well compared to other downloadable product websites. But it had that ‘designed by a programmer’ look and it wasn’t responsive, so it didn’t work on well on mobile devices. My software only runs on Windows and Mac, but I still want to appear in mobile searches. The HTML generated by NOF was also pretty horrible. Frankly, I was a bit embarrassed by it when I looked at websites for other products. I kept on meaning to update it, but there was always something more urgent or (to be honest) more interesting to do. I finally bit the bullet and had it redesigned in 2015. The front page now looks like this:


The process was:

  1. I wrote a specification for the new design.
  2. I ran a competition to design a new home page based on the spec.
  3. I selected the winning designer and paid them to design 3 additional pages in the same style.
  4. I paid to code up the 4 pages in responsive CSS/HTML.
  5. I poured all the old content into the new design. Being careful to maintain the existing page names, titles, text and images etc, so as not to lose existing organic traffic.

The whole process didn’t cost a great deal (somewhere around $2k), but it took quite a lot of my time, spread over 5 months. Especially the final step. This wasn’t helped by the size (some 128 pages were converted) and general cruftiness of the old website, and my lack of knowledge of CSS and responsive design.

I didn’t want to be locked in to a CMS, so I used Mac static website generator Hammer4Mac to generate the HTML. It goes without saying that I wrote a program to help me pull all the content out of the old website and into Hammer4Mac! While Hammer4Mac isn’t without flaws, I found it a vast improvement over NOF and the new website is now much easier to update and maintain than the old one.

The new website went live on 16-Dec-2015.

So how much difference did the redesign make? Here are the changes based on comparing 25 weeks of data before the change and 25 weeks of data after the change:

bounce rate +1.5%
time on page +16.0%
traffic +6.5%
        desktop traffic -2.2%
        mobile & tablet traffic +40.0%
completed installs +1.4%
sales transactions +11.4%
total sales value +21.8%
visit to sale conversion ratio +4.6%
average order value +9.4%

The increase in mobile traffic as a proportion of total traffic is pretty clear from analytics (the dip in December is seasonal):


I believe  a 21.8% improvement in sales is a lot more than I would have got by spending the same amount of time and money improving the product itself, which is pretty mature after 11 years of work.

Overall it looks pretty positive. But, as analytics data is fairly dirty (e.g. due to analytics spam) and I didn’t run a split test, I can’t definitely say that the changes above were due to the website changes. I wasn’t able to compare all the above data with the same time period for the previous year due to some missing analytics data. But the sales data for 25 weeks before and after 16-Dec in the previous year was:

sales transactions -9.9%
total sales value -2.7%
average order value +8.1%

Which implies that the sales changes are unlikely to be due to seasonal factors.

Best of all, I never have to use NetObjects Fusion again!