Slashdot Mirror
It's Not About The Technology
20 chapters are written from the point of view of tech marketing executive, as Karamchedu tries to answer the question of why some products gain a loyal audience and enjoy commercial success, while the others are simply additions to the dusty shelves of history. Everyone has their favorite comparison, where a technically advanced product does not gain acceptance on the market while a supposedly inferior competitor is rolling in cash. Hey, IBM built an entire theory on how it was safe to let Microsoft sell its not-so-great DOS with IBM PCs in order to push the hardware from the warehouse while the company was preparing the next revision of state-of-the-art OS/2 -- which, of course, everyone will buy on the day of release in order to replace Microsoft's software.
History occasionally teaches tech marketers some curious lessons, and the conclusion that the author comes up is summarized in the book title. The title might sound like an insult to a design engineer, but in most of the cases the success in the market is not guaranteed by superiority of technology. Karamchedu is on the mission to find out why.
The first chapters take us through a conflict inside a company. Seldom will you find a high-tech startup where marketing people do not clash with engineers. Marketers promise the features to the customers in order to adhere to the mantra of "we listen to our customers," only to see feature requests denied by the engineers, since the budgets and deadlines are fixed. Marketers then complain to the executives about lack of response from the engineering staff and their inability to deal with the new features, while engineers fight back, claiming that the product is about to miss the deadline even with existing feature set and overworked staff.
Later, Karamchedu focuses on a second problem, peculiar to high-tech marketers: after being immersed in the technology world for too long, they cannot relate to the customers. Hence grandmas in Best Buy staring at the computer described as "P4 3.0 GHz 256 DDR 40.0 GB DVD/CD-RW" when all she wants to know is whether she can check email and view photos of the grandkids. Marketers forget to empathize with the customers. They spend too much time with engineering, and like to tell customers how the new microprocessor has a much wider front-side bus, or how their new piece of software supports dual-core systems, without really telling the customer how that will improve business processes or increase efficiency.
The third part of the book takes a look at a typical semiconductor company and tries to draw the plan of attack for a starting marketing executive. At this point the book turns into a manual on high-tech marketing, which the author hopes the readers will find useful, as there are no set rules and algorithms for launching successful marketing campaigns in high-tech world.
The book is quite insightful, but one can't help but feel that it is missing something. It will probably prove to be a valuable read to anyone facing the daunting task of marketing a high-tech product, but even though I got to the last page of the book, I found the title to be too terse and dry, lacking concrete examples and not quite coherent as far as the chapter-by-chapter arrangement. The preface and the author's description of the book are available online. It's also strange that in an attempt to write a textbook on high-tech marketing, the author decided to provide no case studies whatsoever. In Search of Stupidity from Apress is a great book about high-tech marketing, since it tells the story of a failed marketing attempt and also tries to figure out the reasons, but in It's Not About the Technology, Karamchedu just tells years of his personal experience, without references to specific companies or projects, which makes the book a compilation of abstractions on high-tech marketing.
In his spare time Alex enjoys reading technology and business titles. He also keeps a collection of free books for readers on a budget." Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Joel wasn't refering to ASP.NET, he was referring to .NET in general. If you check the article How Microsoft Lost the API War, you will see what he meant more specifically. He actually quite likes ASP.NET.
However, ASP itself wasn't soley responsible for the problems with cut-and-copy disease. It was a problem of developers thinking at page level versus creating an application that handled page generation. The problem could be prevented with ASP, although admittedly it did encourage that style of coding.
The television will not be revolutionized.
With a price tag of $70 I'm not sure who the author expects to read this book.
Many posters must be too young to remember Win16. Apparently on /. you have to name Windows 1,2,3.0,3.1, WinNT 3.x, Windows 95 etc. and remind them that Windows XP is NT 5.x!
You're probably frustrated in not knowing how 'solution' differs from 'products and/or services' and that's why you're dissing it. When you're just getting started, you may offer just products or just services or JUST 'products and services'. Further evolution may bring you to a level of capability where those monikers don't adequately describe your business offerings anymore. 'products' implies a thing. 'services' implies actions. Combine the two in an offering (perhaps a "project") and if you can identify the offering as solving a problem but the implementation is always slightly different but in the same category, it may better be described as a well thought out "solution" (as compared to perhaps someone with just technical skills who performs in a rather ad hoc manner). Another way to look at it is that products + services + well thought out, defined and evolved implementation applied to specific needs = solution. So, when used correctly, there is a difference. 'solution' implies an evolved offering with well establish ancillary and supporting consituents (perhaps, process, know-how, tested, optimized, proven, documentation, a workshop to do it in etc., or all those things and more as examples). Kind of like the difference between being prepared vs. just showing up. My guess is that IBM knows these distinctions and that you do not (did not until now?).
I've tried a lot of Java web frameworks, and I've never found one that's even close to ASP.Net. ASP.Net is very, very, very nice.
I suspect that JSF with a decent component library and good tool support could be as nice, but that doesn't exist yet. Maybe someday.