No ADSL and my Mac - a reminder of how it used to be

The last two and a bit weeks have been hard: our broadband ADSL failed over two weeks ago. We’ve had a little intermittent service but not much to speak of. Lots of calls to the provider and them in turn with BT.

In my opinion BT are still a big bad monopoly. Turns out they only provide ADSL on a ‘best effort’ basis. No service level agreements. Anything they need to do takes 48 or 72 hours. Most of the delay has been my ISP arguing with BT and me waiting for BT to do something.

I know realise how dependent we are on broadband. Even our fridge started to run out of food because we usually buy our groceries on line and have them delivered.

Interestingly while a lot of my neighbours have wireless access all the networks are now secured. That is a change in the last year.

To make things worse I have no modem on my Mac. When I was buying it I thought ‘when do I ever use a modem?’ And talking of my Mac....

It is nearly two months now since I switch to a Mac. I’m still glad I made the move but I’ll admit there are a few things about the Mac which are annoying me - lack of short cut keys is probably the most obvious.

The Mac is simpler to use but a lot of this simplicity comes because you simply can’t do the things you can with a PC. The Mac makes a lot of assumptions about how you want to work. That makes it simpler but when there is something you don’t like it is hard to avoid. For example, I’d really like a bigger mouse pointer but I can’t find any option to change the size of the icon.

My productivity has definitely fallen. This is largely because I have to learn, or re-learn software applications. It is also because I have to hunt down software to use. I’ve had to give up BlogJet so I had to find another piece of blogging software. After looking around the net I chose MacJournal. Its good enough but it does blogging as a secondary function. It is really journal software. The people who made BlogJet have now produced a Mac product but this too seems aimed at those keeping a journal.

I tried to avoid this problem in part by buying Microsoft Office for Mac. But it turns out the Mac version is quite different to the PC version so I’m having to relearn a lot of it. I used to use Visio on the PC but there is no Visio on the Mac so I’ve had to spend time looking for a Mac equivalent.

So I’ve been evaluating OmniGraffle and ConceptDraw. Both lack the extensive sencils of Visio and some features but both have other features. Annoyingly neither integrates to Word very well. I can’t insert a picture the way I can on a PC, and if I export a graphic picture it tends to appear blurred in Word - at least when I print it out. If I want a good image I have to use Apple PICT format which apparently is an old Apple format. Seems Microsoft haven’t updated Word.

Which is why being on the Mac feels like going back 5 or 10 years. I’ll probably buy OmniGraffle quite soon but in the mean time I keep getting e-mails from OmniGraffle and ConceptDraw making me offers and asking my views. I mentioned the integration and graphics issues to Omni Group who surprisingly replied in person. That’s how I know the image and integration problems are Microsoft and Apple issues.

And while I’m talking about Mac software I should mention RapidWeaver from RealMacSoftware. This is replacing my old copy of DreamWeaver and CityDesk.

I could solve some problems - like the image problem - by dumping Office. Apple actually have a word processor of their own, Pages - although I didn’t realise it was a word process for six weeks. But Pages doesn’t integrate with Endnote the software I use for tracking references. So you solve one problem and get another.

Perhaps the reason this all feels like going backwards is because I have to find and learn new software. With only a couple of exceptions I haven’t done this for most of the last 10 years. The other reason is because I’m finding a whole new software ecosystem.

But actually all this gives me hope.

In the Mac world Office does not dominate. Microsoft doesn’t supply everything and there are many small software companies carving out their own niche. Pages may be trying to compete with Word head on but MacJournal and BlogJet prove that there is a living to be made from producing niche specific word processes. Just when I thought word processes were a commodity I find they are not.

That all gives me hope for the future - and makes me wonder if I’m missing a niche somewhere.

Book review: Crossing the Chasm

I wish I had read Crossing the Chasm (Geoffrey Moore, 1999) sooner. Not only does it give some good advice to technology (specifically software) companies but it also explains a lot about the technology and software market place. I guess I’ve known the basic argument Crossing the Chasm makes so I’ve never felt compelled to read it until recently. However I’ve missing out on so much more.

The basic premise is that for any technology product the buyers can be divided into five types. Initially the product sells to Innovators, then Early Adopters. While these groups will buy the product early they are quite small. Many companies sell to these segments and it looks like success but they are only addressing a fraction of the potential market.

The challenge facing a technology company is to break out of these two groups and sell to the much bigger Early Majority and then the Late Majority. These groups are so much bigger they represent the big money. (There is also a small Laggard group bringing up the rear but this is another small market so its not worth bothering with.)

The problem facing companies is that selling to the Early Majority segment requires a different approach and different strategy to selling to the Innovators and Early Adopters. In fact, while selling to these two groups can be profitable continued success here can harm your attempt to break into the Early Majority. This is where the Chasm comes from. Moore says that the difference between the first two and the third group is a Chasm, it is absolutely massive.

What Moore does is explain this problem and sets out a solution to overcoming it. The solution will be familiar to anyone who has followed my arguments on product management. The argument is also familiar from a bunch of other books too. The familiarity of this argument can probably be traced back to Moore anyhow. And the solution is...

To decide who you want to be your customers. To understand their problems. To craft a product that directly addresses your customer problems. To designate yourself the market leader in the field and make you solution utterly compelling.

It might seem an odd idea to declare yourself the market leader but what Moore says is: find a niche with your customers, define the niche so that you are the only people in it, then the niche is yours. It doesn’t matter if the niche is small to start off with - in many ways the smaller the better. The trick is to win one niche, one vertical market, then move onto the next. Over time you roll up the markets one by one.

I’ve worked with many software technology companies and I’ve seen many of them try to do this. Some successfully, most less so. Some of them knew they were following Moore's advice but I think most of them were following it by default; i.e. they find their product fills a niche but don’t set out to do that. In these cases the companies have trouble moving from one niche to the next.

The main problem I see with companies following Moore’s advice is the need to say No. To select and dominate a niche companies need to focus on this niche. Most companies find it impossible to say no to a potential sale. The company’s software can be used for many things, the idea of turning a potential sale down is just not possible. Consequently they end up being all things to all men. Sure they take the sale for good reason - its money - but the short term fix damages the long term strategy.

And there you go. There is the link. You need a strategy. You need your sales-force and your development efforts to follow the strategy. Not to sell outside the niche and to develop products with features which directly assess the niche. Once again this is the role of product management. You need someone to do this.

So, if you are in the tech business, and especially if you are trying to create a successful technology company read this book. It is well written and easy to read. It might not be the strategy you follow but you should at least understand it. If you don’t follow Moore’s strategy you should know why you are not and why your strategy is right for your company in your market.

Software requirements and strategy

I have been on holiday for the last week so it has taken me some while to get around to linking my last blog entries. Still here it is, better late than never.

A few weeks ago I wrote about the role of requirements in software development, and then I wrote about business strategy. What might not be obvious is that: in order to have product requirements you need to have a product strategy, and a product strategy needs to come from corporate strategy. If you lack either you might still go through the motions of developing software but it is unlikely that it will meet market or business needs, and it is unlikely you will have a successful product.

This happens in all industries but is particularly important in software development because software products are usually the realisation of strategy, so:

1. In order to properly and coherently create a software product you need to have a product strategy. You need to know how the product is going to make you money.

2. In order to have a coherent product strategy you need a coherent corporate strategy. Because the product is the implementation of your corporate strategy.

It doesn’t matter much if your local shop lacks a strategy. People still come and buy things, the shelves are restocked and people get paid. But if you have no strategy for your software why would people buy it? What good does it do them?

You might sell a few copies but without further development the product will rot and sales will dry up. Bugs will become apparent, new operating systems will appear, new applications will emerge that you need to interface to and competitors will match your features. Fail to answer these issues and people will stop buying your software. Things change whether you want to or not. And they change much faster in the software industry than in the corner shop industry.

So you need to move your software forward, keep it fresh, release new versions. And that means you need requirements. But you can only create requirements if you know what your company is trying to do. Otherwise you will end up filling you software with a bunch of features which seem like a good idea to someone but don’t add up to a coherent package.

Now as I said before, it is not enough to have corporate strategy, or even a product strategy. You need to have one that can be communicated and understood by everyone. And you need to actually communicate it and keep on communicating it. Part of the way you communicate it is through product features and updates.

So, you need people who’s job it is to turn that strategy into product features. Those are the people who need to have the ongoing dialogue with customers, the market and developers. These people may be called Product Owners, Business Analysts or Product Managers, what ever, someone has to decide what is in the product and the code developers are not the right people.

Now the difficult bit. Too many companies don’t have a strategy, or they have one they cannot, or will not, communicate. They fail to employ the people who will turn that strategy into reality. So it looks like they are busy but the people doing the coding are directionless.

If you want to play the software business game then don’t leave home unless you have:

        1. A strategy you understand
        2. People who can make it a reality

To do anything else means you are heading for a software failure.

Unfortunately very few software development books, courses and methods address these issues but I am convinced these problems lie at the heart of many, maybe most, software development failures.