Category: feature

Marketing, what marketing?

Someone asked me if there was a marketing department at this company, because they thought it was a bit implausible that there were that many engineers but no marketeers. Well, yes (you know who you are), but I’m not totally au fait with what they do.

Obviously I know about what they do: they redesign the website, they write blogs, they keep up a presence on twitter, they go to shows, they take out advertisements in appropriate places, they check whether it’s worth being in google AdWords, they buy lists of GPs, they talk to previous customers and so on and so on.

But I’m not sure what they actually do. Is this because I’m  incredibly lazy? Or incredibly uninterested? Or because the summaries that appear in the company newsletter are not terribly informative? Or because (whisper it) communication in this company is absolutely dreadful.

To be fair, communication in most companies is absolutely dreadful. People always thinks there are secrets going on behind their back. The urgent strategy planing meeting that had the head of marketing (Jeanette), Gavin and David in it and we never heard what decisions were made. This may, of course, be because no decisions were made, but I know that Jeanette was trying to get GandD to commit to what was going to be in the next product so she could splash out for ads in the Lancet…
And GandD wouldn’t bite.

Jeanette is one of those women who make me feel tired just to look at her. She’s slender and blonde and wears boots and looks amazing at all times. She can sell hot air to Parliament and bull terriers to babies. And she seems to be permanently on a motivational high. “Come on team, let’s see if we can get another ten orders by tonight” she’ll say, “Who’s with me?” And when she has a spare minute she’ll be running marathons for cystic fibrosis research or jetting off for a spa week on a Greek island to cheer up her sister-in-law.

Jeanette is busy seeing how we could alter the product so it would be suitable for care homes and private secure units. She’s looking at what regulation is coming out of the government about what these people will need and she reckons that there’s a huge untapped market.

And David agrees. There’s a whole lot of legislation that needs to be chewed down and flagged up, what your levels of staffing need to be, how many people you have on your books, where you can make things more or less efficient, how you rotate your on-call staff, how you can manage handovers effectively. We could integrate it with a little mobile note-taking system that doctors could carry with them when they go on call so they could…. And so it goes on. Questions of data security and encryption and touch screen infection issues….

And Gavin loves all that. He’s quite keen on encryption and security and new ways of setting it up. And can we get secured prescriptions sent directly to a chemist for an out of hours call… and so forth and so on. I don’t know the ins and outs of it. I would love to shadow a doctor or two and see what they actually did and what was really needed, but we don’t have time for that, says David, we know what they do, we know what they want, we just have to produce it. And if you developers weren’t so inefficient we’d have a product by now. Didn’t you estimate that it would be finished by September so we could test it in time for the New Year and it would be ready to go when people are spending their budgets left over from this tax year?

“Yes” says Ian, “But you’ve changed the spec four times since then.”

Why do I think it happens like that?

When you’re creating a new product, it’s like the band’s first album, or a first novel. You can put all your best work into it. All those hours of sitting in a back room, thinking of how it should work while you’re supposed to be doing something else. All those evening hanging out with your mates and discussing it (for a band) or those rich ideas that have bubbled up for years (for a novel).

Then comes the new release. It’s the follow-up; the second album that flops or the second novel that arrives with hype and leaves with its tail between its legs and an apologetic wet spot on the floor.
(Of course some of it is straightforward regression to the mean: great one time means more likely to be not so great the next.)

In both cases, you normally have a clue what it’s like when you make it, but it’s only when it’s bought that you really understand. People react to what you’ve done. And software is interesting, because it’s a tool. Users use it. They don’t just listen to it or read it. They want to make stuff happen with it. And what they want to do may or may not be what you think they want to do: or even what they think they want to do.

They find bugs. They find things that they want to do and can’t. And if you’re lucky they phone up the support desk or email in or write on forums so you can find out what their problems are.

So, in your second release you fix the bugs (obviously) and you add some of the features that youwanted to put in the first release but couldn’t, and you put in some of the features that you discover that users really want that you never thought about. And that is where it all starts to go horribly, horribly wrong.

Let us imagine our basic Dalek with exterminate facility. You have choices when working on the upgrade design:
a. add levitation to deal with the “cannot conquer a world containing steps” problem
b. assume that wheelchair access will become normal so that Daleks will learn how to campaign for it c. point out that Daleks were never designed to conquer the world, they were designed to be defeated, so use them in the way they were intended
d. redesign the sink plunger
e. offer people a re-badged helicopter that can carry Daleks

Gavin, obviously, wants to add levitation, because that is the correct solution and it has interesting coding challenges. David wants all the other things because they are fast and cheap and there is a massive mark-up on the helicopter. Nick would like to work on levitation because that is an interesting problem, but he designed the first sink plunger so he knows that he will be the sink plunger re-designer. Mr Grumpy and Jack are supposed to be fixing bugs. Both of them have a talent for introducing new bugs. This is because they don’t realise the side-effects of their fixes. Mr. Grumpy doesn’t always bother to find out how the code he is debugging is supposed to work, so he breaks other bits while getting the first bit to run smoothly. In Jack’s case it’s just because he writes it badly. Jiri has already started researching levitation techniques and has found an interesting paper that implies it can be done very efficiently if you can redesign the Dalek so it doesn’t require a sink plunger.

Ian tries to find out whether there is going to be levitation or not. He knows that Gavin and David are arguing about this and whichever one he meets in the corridor will tell him something different. He sits down and writes the spec as he understands it, so at least there is something for all the developers to do until the decision is made.

And I try and find out if users actually want levitation, or whether they really want to use the Daleks as pest controllers and would like a fumigation option.