Author Archives: Andy Brice

How to notarize your software on macOS

Apple now wants you to ‘notarize’ your software. This is a process where you upload your software to Apple’s server so it can be scanned and certified malware free. This will probably become compulsory at some point, even (especially?) if your software isn’t in the Apple app store. Apple says:

Give users even more confidence in your software by submitting it to Apple to be notarized. The service automatically scans your Developer ID-signed software and performs security checks. When it’s ready to export for distribution, a ticket is attached to your software to let Gatekeeper know it’s been notarized.

When users on macOS Mojave first open a notarized app, installer package, or disk image, they’ll see a more streamlined Gatekeeper dialog and have confidence that it is not known malware.

Note that in an upcoming release of macOS, Gatekeeper will require Developer ID signed software to be notarized by Apple.

Documentation on notarization is a bit thin on the ground, especially if you want to notarize software that wasn’t built using XCode (I build my software using QtCreator). So I am writing up my experiences here.

First you need to ensure you have macOS 10.14 and XCode 10 installed (with command line tools) and you need a current Apple developer account.

Codesign your app with ‘hardened runtime’ using –options runtime :

codesign –deep –force –verify –verbose –sign “Developer ID Application: <company ID>” –options runtime <your .app file>

E.g.:

codesign –deep –force –verify –verbose –sign “Developer ID Application: Acme Ltd” –options runtime myApp.app

A ‘hardened runtime’ limits the data and resourced an application can access. I’m not sure what the exact ramification of this are. But it doesn’t seem to have restrict my software from doing anything it could do previously.

You can check the signing with:

codesign –verify –verbose=4 <your .app file>

E.g.:

codesign –verify –verbose=4 myApp.app

Now package your app into a .dmg (e.g. using DropDMG). Then upload the .dmg to Apple’s servers:

xcrun altool -t osx -f <your .dmg file> –primary-bundle-id <bundle ID> –notarize-app –username <Apple developer ID>

E.g.:

xcrun altool -t osx -f myApp.dmg –primary-bundle-id com.acme.myapp –notarize-app –username me@acme.com

You will be prompted for your Apple developer password (or you can include it on the command line).

You now have to wait a few minutes. If the upload is successful “No errors uploading ” will be shown and a unique ID will be returned. You then have to use this to request your upload be scanned:

xcrun altool –notarization-info <unique ID> -u <Apple developer ID>

E.g.:

xcrun altool –notarization-info xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx -u me@acme.com

You will be prompted for your Apple developer password (or you can include it on the command line).

Hopefully you will see “Status Message: Package Approved”. If the notarization fails, you should be sent a link to an online log file describing the issue. If the notarization completes successfully you need to ‘staple’ the results to your .dmg:

xcrun stapler staple -v <your .dmg file>

E.g.:

xcrun stapler staple -v myApp.dmg

The stapler outputs a log including some odd phrases. Mine included: “Humanity must endure”, “Let’s see how that works out. “, “Adding 1 blobs to superblob. What about Blob?” and “Enjoy”. Weird. Hopefully it will end with “The staple and validate action worked!”.

Finally you can unpack your .dmg into a .app and verify it with:

spctl -a -v myApp.app

E.g.

spctl -a -v /Applications/myApp.app

On macOS 10.14 (but not earlier OSs) it should say “source=Notarized Developer ID”. Your software should now run on 10.14 without a warning dialog. Congratulations!

It all seems rather clumsy. As you have to wait asynchronously for the unique ID to be returned from step 1 before you can complete step 2, it is not easy to fully automate in a script. This is a major pain the arse. If anyone works out a way to automate it the whole process, please let me know.

Here are some links to the various posts that I gleaned this information from:

https://cycling74.com/forums/apple-notarizing-for-mojave-10-14-and-beyond
https://www.mbsplugins.de/archive/2018-11-02/Notarize_apps_for_MacOS
https://forum.xojo.com/50655-how-to-codesign-and-notarise-your-app-for-macos-10-14-and-highe
https://forum.xojo.com/49408-10-14-hardened-runtime-and-app-notarization/11
https://stackoverflow.com/questions/53112078/how-to-upload-dmg-file-for-notarization-in-xcode
https://lapcatsoftware.com/articles/debugging-mojave.html

 

Qt is broken on macOS right now

Let me say up front that I am a big fan of the Qt framework. I have been working with it continuously since the late 90s. Both of my commercial products (PerfectTablePlan and Hyper Plan) are written on top of Qt. But Qt is quite broken on macOS right now. In fact I struggled to find a version of Qt 5 that supported recent versions of macOS and didn’t have a showstopper bug. I must have wasted a couple of weeks grappling with these issues. I am putting my notes here in the hope that they help someone else.

Here are the 4 bugs in macOS version of Qt that have causing me the most headaches:

Qt Version
bug v5.9.6 v5.10.1 v5.11.0 v5.11.1 v5.11.2
QFontDialog broken (link) ok ok ok ss ss
QStaticText::size() returns wrong value for rich text
with line breaks
ss ss ok ok ok
widgets such as QTableWidget do not repaint correctly (link) ok cwa cwa cwa cwa
default QComboBox size is incorrect (link)
ok ok cwa ok ok

Where:

ok = bug not present.

cwa = bug present, but can workaround.

ss= bug present, making release unusable for me (showstopper).

Consequently Qt 5.11.0 is the only usable release on macOS for me and I have to kludge my way around two quite nasty bugs. While the QStaticText issue is fairly obscure (but important for me), how in the hell did QFontDialog get completely broken without anyone noticing? And then not get fixed for two whole releases?! I also know other developers who are having to stick with earlier versions of Qt due to the bugginess of the recent versions of Qt on macOS. This isn’t good enough.

Thankfully the recent versions of Qt are much more solid on Windows.

30 tips for creating great software releases

If a film director is only as good as their last film, then I guess a software developer is only as good as their last software release. In more than 30 years of writing software professionally I have shipped my fair share of releases. For the last 13 years I have been shipping software as a solo developer. Here are a few things I have learned along the way. Some of them are specific to downloadable software, but some of them apply equally to SaaS products.

Use a version control system

I occasionally hear about software developers who don’t use a version control system. Instead they usually create some sort of janky system using dated copies of source folders or zip files. This send shivers down my spine. Don’t be that guy. A version control system should be an essential part of every professional software developer’s tool kit. It matters less which version control system you use. All the cool kids now use distributed version control systems, such as git. But I find that Subversion is fine for my requirements.

Tag each release in version control

This makes it easy to go back and compare any two releases. A bug appeared in the printing between v1.1.1 and v1.1.2? Go back and diff the source files related to printing and review all the changes.

Store your release binaries in version control

I store every binary I ship to customers in my version control system. Many people will tell you that you should only store the source in version control. Then you can use this to regenerate the binaries if you need to. This was sound advice back in the day when harddisks were small, networks were slow, version control systems were clunky (SourceSafe!) and developer environments didn’t change very frequently. But I don’t think it is valid advice now. Harddisks are as cheap as chips, networks are much faster and online updates mean your SDK, compiler or some other element of your toolchain is likely to be updated between your releases, making it impossible for you to recreate an identical release binary later on.

‘Test what you ship, ship what you test’

In an analog system (such as a bridge) a tiny change in the system will usually only cause a small change in the behaviour. In a discrete system (such as software) a change to a single bit can make the difference between a solid release and a showstopper bug. The Mariner I rocket was destroyed by a single missing hyphen in the code. So test the binaries that you plan to ship to the customer. And if you change a single bit in the release, re-test it. You probably don’t need to run all the tests again. But you certainly can’t assume that a small change won’t cause a big problem.

This issue often manifests itself when the developers test the debug version of their executable and then ship the release version. They then find that the two have  different behaviour, e.g. due to a compiler optimization, different memory layout or code inside an ASSERT.

Make each executable individually identifiable

As a corollary of the above, you need to be able to uniquely identify each executable. I do this by having a timestamp visible in the ‘About’ box (you can use __DATE__ and __TIME__ macros in C++ for this) and ensure that I rebuild this source file for every release.

Diff your release with the previous one

Do a quick diff of your new release files versus the previous ones. Have any of the files changed unexpectedly? Are any files missing?

Be more cautious as you get nearer the release

Try not to make major changes to your code or toolchain near a release. It is too risky and it means lots of extra testing. Sometimes it is better to ship a release with a minor bug than fix it near the release and risk causing a much worse problem that might not get detected in testing.

Test your release on a clean machine

Most of us have probably sent out a release that didn’t work on a customer’s machine due to a missing dynamic library. Oops. Make sure you test your release on a non-development machine. VMs are useful for this. Don’t expect customers to be very impressed when you tell them ‘It works on my machine‘.

Test on a representative range of platforms

At least run a smoke test on the oldest and most recent version of each operating system you support.

Automate the testing where you can

Use unit tests and test harnesses to automate testing where practical. For example I can build a command line version of the seating optimization engine for my table plan software and run it on hundreds of sample seating plans overnight, to test changes haven’t broken anything.

If you set up a continuous integration server you can build a release and test it daily or even every commit. You can then quickly spot issues as soon as they appear. This makes bug fixing a lot easier than trying to work out what went wrong weeks down the line.

But still do manual testing

Automated test won’t pick up everything, especially with graphical user interface issues. So you still need to do manual testing. I find it is very useful to see real-time path coverage data during testing, for which I use Coverage Validator.

Use third parties

You can’t properly test your own software or proof read your own documentation any more than you can tickle yourself. So try to get other people involved. I have found that it is sometimes useful to pay testing companies to do additional testing. But I always do this in addition to (not instead of) my own testing.

Your documentation is an important part of the release. So make sure you get it proof read by someone different to the person that wrote it.

Use your customers

Even two computers with the same hardware specifications and operating system can be set up with an almost infinite range of user options (e.g. screen resolutions, mouse and language settings) and third party software (e.g. anti-virus). Getting customers involved in beta testing means you can cover a much wider range of setups.

When I am putting out a major new release I invite customers to join a beta mailing list and email them each time there is a new version they can test. In the past I have offered free upgrades to the customers who found the most bugs.

Don’t rely only on testing

I believe in a defence in depth approach to QA. Testing is just one element.

Automate the release process as much as you can

Typically a release process involves quite a few steps: building the executable, copying files, building the installer, adding a digital signature etc. Write a script to automate as much of this as possible. This saves time and reduces the likelihood of errors.

Use a checklist for everything else

There are typically lots of tasks that can’t be automated, such as writing release notes, updating the online FAQ, writing a newsletter etc. Create a comprehensive checklist that covers all these tasks and go through it every release. Whenever you make a mistake, add an item to the checklist to catch it next time. Here is a delightfully meta checklist for checklists.

Write release notes

Customers are entitled to know what changes are in a release before they decide whether to install it. So write some release notes describing the changes. Use screen captures and/or videos, where appropriate, to break up the text. Release notes can also be very useful for yourself later on.

Email customers whose issues you have fixed

Whenever I record a customer bug report or a feature request, I also record the email of the customer. I then email them when there is a release with a fix. It seems only polite when they have taken the effort to contact me. But it also encourages them to report bugs and suggest features in future. I will also let them access the release before I make it public, so they can let me know if there are any problems with the fix that I might not have spotted.

Don’t force people to upgrade

Don’t force customers to upgrade if I don’t want to. And don’t nag them every day if they don’t. A case in point is Skype. It has (predictably) turned from a great piece of software into a piece of crap now that Microsoft have purchased it. Every release is worst than the last. And, to add insult to injury, it just keeps bleating at me to upgrade and there doesn’t seem to be any way to turn off the notifications.

Don’t promise ship dates

If you promise a ship date and you get your estimate wrong (which you will) then either:

  • You have ship software that isn’t finished; or
  • You miss your ship date

Neither are good. So don’t promise ship dates. I never do and it makes my life a lot less stressful.  It’s ready when it’s ready. I realize that some companies with investors, business partners and large marketing departments don’t have that luxury. I’m just glad that I am not them.

Inform existing customers of the release

There isn’t much point in putting out releases if no-one knows about them. By default my software checks an XML file on my server weekly and informs the customer if a new update is available. I also send out a newsletter with each software release. I generally get a spike in upgrades after each newsletter.

Don’t release too often

Creating a stable release is a lot of work, even if you manage to automate some of it. The more releases you do, the higher percentage of your time you will spend testing, proof reading and updating your website.

Adobe Acrobat seems to go through phases of nagging at me almost daily for updates. Do I think “Wow, I am so happy that those Adobe engineers keep putting out releases of their useful free software”? No. I hate them for it. If you have an early stage product with early-adopters, they may be ok with an update every few days. But most mainstream customers won’t thank you for it.

Don’t release too infrequently

Fixing a bug or usability issue doesn’t help the customer until you ship it. Also a product with very infrequent updates looks dead. The appropriate release frequency will vary with the type of product and how complex and mature it is.

Digitally sign your releases

Digital certificates are a rip-off. But unsigned software makes you look like an an amateur. I am wary of downloading any software that isn’t digitally signed. Apple now prevents you downloading unsigned software by default.  Signing is just an extra line in your build script. It is a bit tedious getting a digital certificate though, so get one that lasts several years.

Check your binaries against major anti-virus software

Over zealous anti-virus software can be a real headache for developers of downloadable software. So it is worth checking if your release is likely to get flagged. You can do this using free online resource virustotal.com. If you are flagged, contact the vendor and ask them to whitelist you.

‘The perfect is the enemy of the good’

Beware second system effect. If you wait for perfection, then you will never ship anything. As long as this release is a significant improvement on the last release, then it is good enough to ship.

Pace yourself

Creating a release is exhausting. Even maths, physics and software prodigy Stephen Wolfram of Mathematica says so:

I’ve led a few dozen major software releases in my life. And one might think that by now I’d have got to the point where doing a software release would just be a calm and straightforward process. But it never is. Perhaps it’s because we’re always trying to do majorly new and innovative things. Or perhaps it’s just the nature of such projects. But I’ve found that to get the project done to the quality level I want always requires a remarkable degree of personal intensity. Yes, at least in the case of our company, there are always extremely talented people working on the project. But somehow there are always things to do that nobody expected, and it takes a lot of energy, focus and pushing to get them all together.

So look after yourself. Make sure you get enough sleep, exercise and eat healthily. Also things may be at their most intense straight after the release with promotion, support, bug fixing etc. So it may be a good idea to take a day or two off before you send the release out.

Don’t release anything just before you go away

There is always a chance a new release is going to mess things up. If you are a one-man band like me, you really don’t want to make a software release just before you go away on holiday or to a conference. Wait until you get back!

Fix screwups ASAP

We all make mistakes from time to time. I recently put out a release of my card planning software, Hyper Plan, that crashed on start-up on some older versions of macOS. Oops. But I got out a release with a fix as soon as I could.

Treat yourself after a release

Releases are hard work. A successful release deserves a treat!


Anything I missed?

 

 

Chrome SSL certificate issue

The issue

Google have decided to “deprecate Chrome’s trust in the Symantec certificate authority (including Symantec-owned brands like Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL)“. This comes after “Symantec had entrusted several organizations with the ability to issue certificates without the appropriate or necessary oversight”.

What does that mean for me?

If you are affected by this then your website SSL certificate won’t work for Chrome version 70 or later and visitors are going to see an ugly warning like the one below.

ssl error

Not good! The first beta of Chrome 70 is expected in September.

How do I know if I am affected?

  • Start Chrome.
  • Navigate to the https version of your website.
  • Go to Developer tools (View>Developer>Developer tools from the menu bar) and look at the Console.
  • If you see something like the below, then you are affected.

ssl cert

My https://www.perfecttableplan.com website was affected (it uses a Geotrust SSL certificate provided by my ISP, 1&1). But my https://www.hyperplan.com website was not affected (which uses a Godaddy SSL certificate).

On my Windows development machine Eset anti-virus seems to override the SSL certificate used by Chrome, so the console message did not appear. But it did appear in Chrome on my Mac. So you probably want to check from more than one computer.

What can I do about it?

Get your certificate re-issued. This was fairly straightforward with my hosting provider 1&1.

Final thoughts

As an owner of a small software business I spend too much time dealing with annoying crap like this. Symantec, I have always hated your bloated software. But now you officially suck.

Also, is it any wonder digital certificates are such a rip-off when one company is allowed to own so much of the market?

 

Getting Qt 5.9 working on Windows (eventually)

I have had Qt 5.5 and 5.6 installed on my development machines for some time. Now that I have purchased a new Mac development box (an iMac with a lickably beautiful 27″ screen) I thought it was a good time to update to a more recent version of Qt. I went for Qt 5.9, rather than Qt 5.10, as 5.9 has been designated as an LTS (long term support) release. Upgrading turned into a real chore. I am quickly writing it up here in the hope that it helps someone else, and as a reminder to myself a few years down the line.

I like to build Qt from source. Because then I know it was built using the same compiler, headers, SDK etc as I am using to build my product. And I have more control over how Qt is configured. Also I can patch the source and rebuild it, if I need to. But I have had problems building Qt on Mac before. So I decided to install the pre-built binaries on my new Mac. I installed the latest version of XCode and then the Q5.9.4 binaries. This was a couple of big downloads, but it all went pretty smoothly.

I successfully built Qt 5.5 from source on my Windows machine previously, so I decided to try that for Qt 5.9. I have Visual Studio 2010 installed. This isn’t supported for Qt 5.9.4, so I downloaded Visual Studio 2017. I unzipped the Qt source into C:\Qt\5.9.4, ran ‘x86 native tools command prompt for VS 2017’, made sure Python and Perl were in the path and then:

cd C:\Qt\5.9.4

set QTDIR=C:\Qt\5.9.4\qtbase

set PATH=%QTDIR%\bin;%PATH%

configure -opensource -confirm-license -opengl desktop -nomake tests -nomake examples -no-plugin-manifests -debug-and-release -platform win32-msvc -verbose

nmake

Note that you are told by the nmake script to do nmake install at the end of this. But it tells you somewhere in the Qt Windows documentation not to do this, unless you have set the prefix argument (confusing, I know)

The build failed part way through making qtwebengine. Something to do with a path being too long for Perl or Python (I forget). It seems to be a known problem. Odd as the root path was just C:\Qt\5.9.4. I don’t need qtwebengine at present, so I deleted everything and tried again with -skip qtwebengine:

configure -opensource -confirm-license -opengl desktop -skip qtwebengine -nomake tests -nomake examples -no-plugin-manifests -debug-and-release -platform win32-msvc -verbose

nmake

It seemed to complete ok this time. But using this version of Qt to build Hyper Plan I got an error:

Unknown module(s) in QT:svg

On further examination the SVG DLL  had been built, but hadn’t been copied to the C:\Qt\5.9.4\qtbase\bin folder. Similarly for a lot of the other Qt DLLs. I couldn’t find any obvious reason for this looking through logs, Stackoverflow and Googling. I could possibly do without the SVG functionality, but I wasn’t sure what else was broken. So I decided to give up on bulding from source on Windows as well.

I download the Qt 5.9.4 binaries for Visual Studio 2017. This seemed to go ok, but then I discovered that I could only build a 64-bit application from these. No 32-bit version was available for Visual Studio 2017. Many of my customers are still on 32 bit versions of Windows. So I need to be able to ship my product as a 32 bit executable + DLLs[1].

So I uninstalled Visual Studio 2017 and installed Visual Studio 2015. I then got an error message about Visual Studio 2017 redistributables that I hadn’t uninstalled. So I had to uninstall those and run a repair install on Visual Studio 2015. That seemed to work ok. So then I download the 32-bit Qt 5.9.4 binaries for Visual Studio 2015. I had to download these into a different top level folder (C:\Qtb), so as not to risk wiping existing Qt installs that I had previously managed to build from source.

Eventually I managed to build Hyper Plan and PerfectTablePlan on Mac and Windows. What a palaver though! Qt is an amazing framework and I am very grateful for everyone who works on it. But I wish they would make it a bit easier to install and upgrade! Has anyone actually managed to get Qt 5.9 built from source on Windows?

[1] I don’t bother shipping a 64-bit executable on Windows as the 32-bit executable works fine on 64-bit versions of Windows (my software doesn’t require excessive amounts of memory). I only ship a 64-bit executable on macOS as almost no-one uses 32-bit versions of macOS now.

Tracking your sales pipeline

The purpose of marketing is to generate prospects. People who are interested in your product and might buy it. The purpose of sales is to try to convert these prospects into customers. The key difference between these activities is that marketing is one-to-many and sales is one-to-one. Each sales prospect is going to have different questions depending on their requirements, timescales and budgets.

For low cost products there is generally very little selling. You simply can’t afford to spend significant amounts of time engaging with someone who may or may not buy a product with a $30 lifetime value. But for higher price products (typically B2B), sales becomes more important. Sales activities might take the form of answering questions by email or phone, video conferences, quotes, online demonstrations and perhaps even site visits.

Many of my customers purchase from my website without any active selling. But organizations who wish to buy more expensive licences typically have questions about licensing, pricing, functionality, upgrading etc before purchasing. I characterise the stages of selling to these companies as:

  • Enquiry – Someone has expressed an interest in one of my products and typically has questions about functionality, licensing and/or pricing. Initial contact is usually by email.
  • Qualification – I answer the prospect’s questions. If my product isn’t a good fit for their requirements I let them know, as I don’t want to waste my time or theirs or end up with unhappy customers.
  • Quoted – If the prospect looks like a good fit and is still interested I send them a quote.
  • Verbal agreement – The prospect expresses an interest in buying the product. There may be some negotiation over number of licenses, discounts, payment methods, tax etc.
  • Won/Lost/Cold – I either win or lose the sale, or the prospect stops responding (goes cold).

This step-by-step process is known as a ‘sales pipeline’ or ‘sales funnel’.  Different companies use different terminology and a high-value enterprise sale would probably have more stages. But the process is the same in principal – your marketing (SEO, PPC, word of mouth etc) feeds people into the pipeline at one end and a certain proportion will drop out at each stage. Some will end up as customers.

You can take a very ‘hands-off’ approach to sales and only respond to communications that the prospect initiates. But this is not going to get you the best conversion rate from prospect to customer. People are busy and have lots of conflicting demands on their time. One of your response emails might get lost. Their initial contact might leave the company. It seems a pity to let a prospect slip away, just because you can’t be bothered to send a few follow-up emails.

I don’t really want to do a 30 minute online demo if I think I am only going to sell $50 of software (unless I think the feedback might be particularly valuable). But the more a sale is likely to be worth, the more effort I am prepared to put into it. I have found that I can make a pretty good guess at how much a sale is likely to be worth based on the organization they belong to and the initial questions they ask. And these guesses becomes more accurate as they travel along the pipeline.

Note that I am not trying to cajole or pressure the prospect into buying. I am simply trying to provide them with the information they need so they can make the right choice. If I don’t hear anything for a while I will email them something along the lines of:

Did you make a decision regarding purchasing ? Please let us know if you need any further information. We would be happy to call if you would prefer to discuss it on the phone.

If they reply that they aren’t interested or don’t reply after 2 or 3 emails from me, then I stop chasing them. No need to be an asshole about it.

I’m confident that I could increase my conversion rate by following up prospects by phone, instead of emailing them (most B2B prospects include contact details in their sig or are easy enough to Google). But that isn’t something I can summon up enthusiasm for, so I don’t do it. If I was less secure financially, I would be on the phone a lot more.

The issue is then, how to track the various sales prospects so you can follow them up as appropriate? Initially I just tracked sales by having a ‘prospects’ folder in my email client. I would put email from prospects in this folder. Occasionally I would go through the folder and email prospects who hadn’t replied in the last few weeks. If they didn’t reply to a few emails I would move them out of the ‘prospects’ folder. It wasn’t very efficient and there were all sorts of questions I couldn’t easily get answers to, including:

  • What stage was each prospect at?
  • How long was it since I last contacted a prospect?
  • Was there anyone I needed to follow up today?
  • How many prospects were there at each stage in the pipeline? What did I think those prospects might be worth?
  • How were the sales divided into industry sectors (e.g. businesses vs charities vs government)?
  • What proportion of sales was I winning and losing?
  • How did the sales breakdown between new customers and upgrades? Direct sales and resellers?

But it just so happens that my own Hyper Plan product is excellent as sales pipeline software.

I now add a card into Hyper Plan for each prospect that I think might realistically purchase $200 of software or more.

sales pipeline software crm

Store any data about your prospects in custom fields.

I can then very easily slice and dice the data in any number of different ways. For example:

sales pipeline software

Active prospects are automatically arranged by sales pipeline stage and coloured by estimated value. Won/Lost/Cold cards are hidden by a filter. The card with the red highlight is overdue a follow-up call.

sales pipeline visualization

Active prospects are automatically arranged by when we last contacted them (column), when they last responded (row) and coloured by sales pipeline stage.

sales pipeline chart software

Charting the number of prospects at each stage of the sales pipeline.

Sales pipeline statistics software

Charting the number of prospects at each stage of the pipeline, by sector.

This has given me a lot more insight into how I am doing at sales and made me a lot more organized at following up prospects.

A few random things I have learnt about sales over 13 years of running my own software business:

  • Some organizations will buy on the same day they first contact you. Other may take years. Generally the bigger and more famous the organization and the bigger the order, the longer it takes.
  • Organizations sometimes ask for changes to my licensing agreement. I always refuse as it just isn’t worth the expense and stress of getting a lawyer involved. They usually buy anyway.
  • Don’t give additional discounts to ‘value subtracted resellers’. It almost certainly won’t make any difference to whether they purchase or not.
  • Sometimes it is quicker and more effective to talk on the phone, rather than sending lots of emails. But I will generally ask if it is ok by email, before calling.
  • Trying to get video conferencing to work so you can demo your product can be a real headache. Every organization seems to have a different preferred video conferencing solution.
  • Once you are confident your product is the right one for a prospect ask for the sale (‘close’). ‘Would you like to talk about licensing?’ is a not-to-pushy way to move the conversation onto money.
  • You don’t have to be dishonest or pushy. Just give prospects the information so they can make the right decision.
  • Prospects generally won’t tell you that they aren’t interested. They just stop replying to emails.

Hyper Plan is available for Windows and Mac. The Home edition, which has everything you need for sales pipeline tracking, is just $40. Download the free trial and start tracking your sales pipeline.

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.