While playing the software game was lucrative, this blog helps software companies sidelined by innovation to re-enter the game and to win.
Once upon a time it was lucrative to play the software industry game. We sold functionality at excellent margins. Annual maintenance was steady money for (rather) little work. Technology advanced at a manageable pace. The peer community dispensed recognition. Growth was steady and life was good.
But then the software game changed. In many niches FOSS has turned functionality into a commodity. SaaS upsets perpetual licensing, while annual maintenance is increasingly suspect. The community scattered as global players bought and consolidated. Innovation quickened. New business slowed.
Seth Godin’s book ‘All Marketers Tell Stories’ inspired me to share what I’ve learnt in 30 years of the software business.
Software companies often find themselves stranded on islands of excellence, serving a small group of customers but unable to grow. Opportunistic sales result in a few more islands from time to time.
It’s depressing to see companies with excellent technology shipwrecked. A love-hate relationship with marketing is often a contributory reason. We love having many qualified leads, but hate getting our hands dirty with marketing.
Why’s marketing hated like this? In my experience the cause is often the developer background of many managers. Developers equate lead generation with advertising. And developers hate advertising even more than marketing!
The Clang compiler recovers from unknown tokens using a spell-checker. Something small can be remarkable and worth spreading.
Being remarkable doesn’t always mean you have to develop something large. Sometimes remarkable is small, as this Clang example seen today on Hacker News demonstrates very nicely.
Clang is an open-source compiler front-end for C, C++ and Objective C. The project builds on the LLVM compiler back-end with the goal of replacing the GCC tool chain. Their worldview accepts that programmers can and do make mistakes. Amazing feats of Clang Error Recovery shows how they’ve woven this worldview into the compiler.
What caught my eye was how Clang recovers from unknown tokens. Instead of unhelpful error messages (like GCC), the Clang team chose to do something remarkable: they added a spell-checker to guess what you mean:
Software protection schemes annoy customers and don’t stop real pirates. Better to have a remarkable product and a story to spread.
So, it only took 2 days to hack the Apple iPad. Trusting DRM to work was unrealistic on Apple’s part. Even so, we in the B2B software business have our own blind spot when it comes to software protection.
Each of the software products I’ve worked on has included a protection system. Sometimes a hardware dongle, but more commonly software-based schemes linking the software licence to the customer’s hardware configuration.
We were scared customers wouldn’t pay if they didn’t have to. With licence fees starting at $10K for each developer seat, hundreds of thousands were at stake.
In a famine of qualified prospects, you’ll try to grab anything that appears edible. Lack of a reliable sales process is corrosive.
When prospects are rare you’ll do everything to win. Development adds features. Marketing invents ROI justifications. Prospects are too precious to waste; you cannot risk letting even one get away. You do whatever it takes.
Lack of a shared worldview is an increasing problem as you grow. Special cases abound; exceptions appear. Everybody is paranoid about saying no.
To see how sticking to a clear understanding of your worldview changes everything, take a look at 37signals. They are a 20 person company selling web-based apps for small groups and individuals. With more than 3 million users, they are very profitable.
As Blaise Pascal (sort of) said: it takes longer to write a long post than a short one; ‘Writing is rewriting’ is so true.
Today I’m looking back on Story Complete’s first month. This is the 17th consecutive day I’ve posted. While at first I found the daily schedule difficult, I’m hoping practice makes perfect.
Written preparation is often the path to success, whereby the writing part is essential. My daily schedule forces me to click that scary WordPress publish button. On the other hand, sharing my thoughts in writing helps me clarify what I’m trying to say.
Identify returning users as VIPs: those most likely to spread your story. Treating everyone the same is easy, but they deserve better.
Existing users are more likely to recommend you than new one, so don’t treat everyone the same. Existing and new users have different expectations, even though they share a common worldview.
A chainsaw cannot change itself depending on whether a newbie or an experienced lumberjack picks it up. Your software is not a physical product. It’s easy to support multiple expectations from a single code base, just as you do with i18n and L10n.
The German tax system is complex (it’s said 80% of the world’s tax laws are in German). As a result, a large vertical niche of tax return software exists.
You can’t spread your own story, just create a fertile environment, weave your story, give it its freedom and wish it a world of luck.
Stories are your best chance of getting your message to the people you need to hear it. Even so, the right story told to the right people is no guarantee your story will spread. You need 5 ducks in a row to have a chance of spreading:
Selling to developers who hate tools is a quick way to waste lots of money. We targeted the few whose worldview embraced tools.
As application tool vendors we convinced prospects with metrics and ROI. Adopting tools, we thought, was a no-brainer. Even so, selling to developers who didn’t want to use tools was difficult. Time and again developers successfully blocked tool adoption.
Our problem: their worldview didn’t include the idea tools are useful. Our solution: we focused on the 1 or 2 developers whose existing worldview did include a positive attitude towards tools.
Whether or not these developers had formal authority, we got our tool into their hands so they could reach their own conclusions. If they thought our tools worthy, they’d start spreading the word internally. Having someone who developers trust spread our story for us made all the difference.
