
The Macintosh Way was the first book written by former Apple evangelist and marketing specialist Guy Kawasaki. Subtitled "the art of guerrilla management", the book focused on technology marketing and management and includes many anecdotes culled from Kawasaki's experience during the early development of the Macintosh.
That anecdote prompted me to do the same (in corporate battlefields). Works great.
F1 is Crossing the Chasm 3rd edition: https://www.amazon.com/Crossing-Chasm-3rd-Disruptive-Mainstr...
Moore's analytical framework is technology adoption life cycle.
The story of tech marketing is strong, ... so strong that tech marketers usually see themselves perpetually stuck at crossing the chasm (like approaching an asymptote or limit).
Even when the actual marketing problems another problem in the same book.
Pro Tip: Cross check compelling conclusions with DATA.
Using Moore-tinted-glasses to express what others have said: * What word of mouth communities exist in your current users? * Talking to users, what do they say your product's killer functions are? * What burning business process, are your early adopters finding you to solve?
F2 = Utterback's MASTERING THE DYNAMICS OF INNOVATION uses the "dominant design" analytical framework.
Utterback-tinted-glasses: * What product functions/components could you add, that would trigger an infrastructure swap out (Moore concept) to your solution? Search "Dodge all metal" for a great plot of this * Retrospectively, what functions have new entries to your product category, added? These are usually different for each new entrant. For bonus points, look at the functions entrants thought would work, and then check if the company is still around. Utterback tracks components of dominant designs, over product category maturity. =Handy way to think!
F3 = Kawasaki's MACINTOSH WAY, ART OF THE START 2nd edition, and SELLING THE DREAM
Kawasaki's analytical framework has two elements:
First, product superiority. Gather product superiority component by component into a product that is Deep, Indulgent, Complete, and Elegant. Products are packages of components, and even when the individual components are not category leading (original Mac's speed, RAM, ...) the resulting package can be superior by assembling a piquant component set. Original Mac's 1 leading component was the graphical user interface at a consumer price point.
Second, cause. What is your cause in developing the product? For that cause, what kind of product would stake out the moral and functional "high ground."
Cause is a combination of left brain with right brain. Engineers often have secret causes that they pursue throughout a career. Ex., DBA colleague who wants to build categorical databases. Yes, you got that right, Haskell does not go far enough! But more to the point, what motivates why you do what you do? That fuzzy thing, is the root of a cause. SELLING THE DREAM has examples: Macintosh enabled making beautiful documents at the desk. Stanley Marcus' autobiography said ~ "The business was built by going to Paris fashion shows, and substituting conservative fabrics into those designs." Cause guess = fabric substitution.
Kawasaki-tinted-glasses: * Are your current users using the product because of the code you've written? Or because they like your cause? * What natural allies does your product's cause have? Have you broken bread with these allies and seen if they know about you, like you, would somehow have good ideas for you? * Is there any possible way you can build your cause without taking VC money? If so don't take VC money!
My take on it is that Microsoft was at first enthusiastic enough about OS/2 but IBM doomed it, first and foremost through their "the PC AT is the last personal computer you'll have to buy" message to their customers, something they used to be able to do when they controlled a lot more of the business computer market and "no one ever got fired for buying IBM." Forcing OS/2 to run on the 286 was Not Even Wrong, for example in protected mode a 64KiB segment change incurred a hit of many cycles (40?), Intel did not understand how people used the 808x and only fixed that with the 386.
But did your people "high up in Lotus" mention how the mid-life kicker for 1-2-3 using expanded memory (https://en.wikipedia.org/wiki/Expanded_memory) was coded by people against orders who'd left the company by the time it was rediscovered and made into a product?
That the Jazz office suite for the Macintosh was developed using assembly "for efficiency" but without a LAN or other means of close collaboration, every week people would hand in floppy disks for a complete build and thus a great deal of duplication made it very much less efficient? And in general how poorly that software development model worked? I see in Wikipedia "in Guy Kawasaki's book The Macintosh Way, Lotus Jazz was described as being so bad, 'even the people who pirated it returned it'."
I was working in the Boston are in the 1980s and knew a lot of people who'd worked for Lotus or coworkers or friends of them, so I got takes from their very beginnings, which was a handful of people writing in close collaboration 1-2-3 in, yes, assembly language.
Rereading just now, I'm amused that was the only Gassée lesson I remembered.
I like Kawasaki just fine. The followups I'd read didn't really land like Macintosh Way did. But I see now that he kept writing, all of which are rated highly. So I retract my judgement. YMMV.
The Macintosh Way (1989)
Database 101 (1991) -- pdf does not include free disk inside, wow I'm old
Computer Curmudgeon (1992)
What the Plus! Google+ for the Rest of Us (2012)
http://www.yousendit.com/download/WUJZZUNndWNlaFRMYnRVag
edit: added link to the download page, for the G+ averse
Unfortunately the 3 old books are quite badly jpeg-compressed pdfs instead of proper text.
