As I mentioned in my last entry about Business Patterns for Software Developers, the audience at BCS Edinburgh asked several good questions. One of these questions was:
“It strikes me that many of these patterns are more broadly applicable and could be applied outside the software industry. Why have you limited them?”
This is true, if you look at the pattern Customer Co-Created Product you will see it is illustrated with a picture of a Boeing 777. Or look at Single Product Company you will find a picture of a Model-T Ford. Many of the patterns use examples drawn from outside of software, and many of the patterns are applicable in other industries.
This in fact is a question that has been asked many time during the writing and reviewing of these patterns: “why limit them to software?”
There are really four answers: my knowledge, customer segmentation, brevity and application. Let me explain each one in its own right, although in truth the four as interlocked.
My knowledge: I first earned money from selling software in 1986, over 25 years ago. I know the software industry. I’ve worked in other industries (electricity supply and investment banking to name two) but I was always on the software side so I was still in the software industry. I know about this industry so I write about what I know.
This isn’t to say I don’t know about other industries. As I said, I’ve worked on the edges of other industries; I’ve read about other industries, I’ve spoken to people form those industries and studied them on occasions. Ultimately its all business. Still, by writing about what I know best, the area my knowledge is concentrated, I believe I write better and add more to the debate.
Customer Segmentation: A book is a product like any other, now its published it needs to sell -Yes! Buy Business Patterns today! Even better write me a review 🙂
I consciously decided to target this book at a specific audience, the audience I know best. This shouldn’t be a surprise, the book contains a pattern called Customer Segmentation which says exactly this.
Brevity: By sticking to one domain, an industry I know well, by addressing specific readers, I can write less. I can assume more about the readers existing knowledge and I can write less. Had I tried to write a pattern like Product Roadmap and cover other industries I’d need to generalise it more, add more words, in the process I’d loose the applicability….
Applicability: By applicability I mean I try and make the patterns applicable to the software industry, I try to write about concrete steps you can take in the industry to build these patterns. I might not always succeed but I’m sure if I’d tried to write in more general terms I would have been even less specific. Ultimately the book would have ended up being any other abstract book on business.
This lesson was brought home to me when I wrote my first business patterns: The Porter Patterns. These patterns are not in the book. If you want to read them you can download The Porter Patterns for free from my website – as you can the earlier versions of all the patterns in the book.
The Porter Patterns are based on the work of Professor Michael Porter. He proposed several generic models are analysing businesses – Cost Leader, Market Niche, etc. etc. In analysing these models I realised: they don’t tell yo what to do. The models describe businesses strategies but they are pretty useless at telling you which one is right for your business today.
You could add in Porter’s Five Forces Model but even when you do this there is no advice on what you could do. Because I believe Patterns should help you decide what to do I deliberately moved away form this approach and have not included these Patterns.
So there you go, I am sure that many, if not all, the 36 patterns in Business Patterns for Software Developers are applicable outside of software but I leave it as an exercise to the reader to make the necessary additions.