« PR, blogs and Lisp hackers | Main | NIN - With Teeth »
May 04, 2005
Marketing, eh?
I used to think that marketing was a fancy name for advertising and promoting a product. The marketing department would come up with a catchy name for the product, design a slick advertising campaign, and wait for the orders to come in. I used to think that marketing was persuading customers, through advertising and promotional material, that they wanted the product. I used to think that the product was a secondary consideration to a marketing department; that marketing was used to persuade customers to buy products that they didn't really need. As such, I used to think marketing was a bit of a sham, something that could be eliminated if you just made good enough products.
I now think differently. The change was prompted by a book: Beyond Software Architecture, by Luke Hohmann. The book describes the relationship between marketing and the technical architecture. The two have strong influences on each other: good technical architecture makes marketing the product easier, and good marketing make software development easier. How? Well this is the secret that I learned: marketing is concerned with markets. Advertising is just a small part of it. It is concerned with defining markets, classifying markets, understanding markets. It is concerned about customer needs, customer goals, and customer fears. It is concerned gathering customer requirements, the ones that customers will part with cash to have fulfilled.
Beyond Software Architecture illustrates the various ways that marketing and software architecture interact. There are chapters on installation, deployment, upgrades, and configuration. Branding gets its own chapter, where there is a discussion on the effects that a name change can have on user documentation, source code control, and installation programs. There is a section on how the licensing model that you choose, influences the technical architecture, and vice versa. For example, you can sell plug ins to a software product if its architecture supports plug ins. Alternatively, licensing a product based on the number of transactions it handles, requires the architecture to be able to track such data.
I found the chapter on product versioning and release management particularly useful. There is stuff in there that would really have helped on my projects. Synchronizing releases with the market rhythm is something I will be doing from now on: it can help to prioritize features. For example, a number of customers may want some features, and classify them as high priority, but the market rhythm can tell you when they need the features. That is very useful information when creating a development schedule.
If you design software, I'd recommend this book as a way to learn how to create products that will sell. If you are in marketing, I'd recommend this book as a way to learn what software architecture can do to make your job easier.
Posted by JohnC at May 4, 2005 11:52 PM