* The Business of Software

A community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

This community works best when people use their real names. Please register for a free account.

Links:

» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)

Moderators:

Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

E-Myth Revisited - does it apply to a mISV?

A few people have recommended the "E-Myth Revisited" book to me (and its on Joel reading list IIRC) and it gets very consistently good reviews.

http://www.amazon.com/Myth-Revisited-Small-Businesses-About/dp/0887307280

I struggled through the hubris, the excruciating dialogue and the Total Misuse Of CapiTAL LetTers and was distinctly underwhelmed and was left with...

"Work on your business, not In it."

Most of the 'wisdom' was about procedurising everything so it can be followed by anyone to create predictable results - McSoftware.

Struggling to see how that can be applied to an ISV? Or perhaps I've missed something?
Ryan Wheeler Send private email
Wednesday, October 19, 2011
 
 
It is one of the dullest books I have ever read. Or half-read - I gave up half way through. So there weren't any gems in the second half I missed then?
Andy Brice Send private email
Wednesday, October 19, 2011
 
 
Book worth its weight in gold. I tripled my business after implementing principles described in this book. Still growing.
Just 1/3 of the book is brilliant. 2/3 is annoying dialogs which can be skipped.
MK Send private email
Wednesday, October 19, 2011
 
 
@Andy - no.  You can distil it to a few pages (http://www.amazon.com/review/R3D7LOKOG9101R/ref=cm_cr_pr_viewpnt#R3D7LOKOG9101R) and I lost count of the times I literally threw the book at the wall.

@MK - I am intrigued! So what did you get from it? Was it that you need to put standard procedures in place for everything or something else?

If it was the standard procedure thing then how does that work with your business and the "knowledge work" of creating software?
Ryan Wheeler Send private email
Wednesday, October 19, 2011
 
 
Good book, but totally inapplicable to mISV's, IMO. It's for people running restaurants, motels etc., where replacing staff with robots is not too far off.
GregT Send private email
Wednesday, October 19, 2011
 
 
@GregT - if you've ever automated your build, you've applied the principles from the book. For example, if you made a list of tasks that could be outsourced and wrote detailed instructions for those tasks, you've implemented e-myth.

I agree with everyone that the book could be condensed to a few pages at most. As a former industrial engineer, I'd say there is nothing in the book that isn't a rehash of well known concepts. I'd only recommend it to someone who has never looked as their business as a series of processes, though. The bureaucratic version of the book is called ISO 9000. ;-)
Nicholas Hebb Send private email
Wednesday, October 19, 2011
 
 
Yeah, I read it some years ago and found it useless.

Look, I use function point analysis to accurately predict how long it will take to deliver a given new feature for a given set of developers, which enables me to know if it is worth the cost compared to implementing some other feature. How to do this is a process that is well documented. I have yet to find a single company other than my own that can predict reliably the time to implement completely new things that have never been seen before.

I bring this up to make this point: don't go talking to ME about process.

That said, coming up with the ideas and doing the work and choosing the features and listening to customers and understanding the problem domain and delivering awesome software that people love is because of me, and can not be outsourced because no one else can do that shit. Outsourcing product development is only going to work for you if your product was crap to begin with and no one cares about it.
Scott Send private email
Wednesday, October 19, 2011
 
 
@Nicholas - agreed, but I found the whole mindset of that book was  that your employees are automatons, to be managed within a set of rules and procedures that are as explicit as possible. Makes sense for isolated cases of software development, sure, but overall, more attuned to someone running a Starbucks.
GregT Send private email
Wednesday, October 19, 2011
 
 
"Outsourcing product development is only going to work for you if your product was crap to begin with and no one cares about it."

I like that one! I hope people don't read it as "to India" or "to China".
GregT Send private email
Wednesday, October 19, 2011
 
 
@Ryan Wheeler

I started to work ON the business, not IN the business. Main parts as Scott described are under my command, but others are automated as much as possible and have clear processes. We implemented Kanban, partly Agile, now working forward using TOC. This book was the start which changed look at the business. If you work IN the business - you are not businessman, you are craftsman, and this is not business you are running - it is a craft. And I'm still craftsman, because most important part of business depends on me. (I want to change that.) Principles in this book perfectly applies to mISV and during the short period of time allows to remove "m" from this term.
MK Send private email
Wednesday, October 19, 2011
 
 
I think it depends where you are on your journey with the ISV. I read it a few years ago and some of it really clicked with me. If I read it now then I'd probably not finish it.
Smart Company Software Send private email
Wednesday, October 19, 2011
 
 
@Scott, @GreggT -

Point of clarification - when I referenced outsourcing I was thinking in terms of outsourcing to a virtual assistant, not product development. When I think of mISV's, outsourcing development rarely crosses my mind.
Nicholas Hebb Send private email
Thursday, October 20, 2011
 
 
speaking from my experience:

biggest problem with most tech people going into business is not doing the craft, but starting from their craft. Instead of observing people and find a problem to solve, they (me) usually start with some tech and start to find a problem to solve with it. some are successful that way but most are not. Doing the work or delegating it makes very little difference for misv, (in my view). Problem in this space usually is trying to create a business around technology instead of behavior. Most respect machines more than people. Since usually people are the ones who pay...they fail to get traction. They could have the same attitude and outsource "Every Thing" and still fail. Notice this is different in say baking or fixing bikes. Your craft is already geared towards a particular problem/need. with software not so. your skills are just so much amorphous mud waiting to be applied to some domain. Unless you teach CS
cn Send private email
Thursday, October 20, 2011
 
 
I agree with cn. It's why I have been spending much of my time looking for problems people actually have--whether the possible solutions have anything to do with technological solutions. The rare technologists really have a head start when they have their head screwed on right, and they see, rather naturally and implicitly, what's really the larger issue to be concerned about. I have always tried to develop that within myself.
Li-fan Chen Send private email
Thursday, October 20, 2011
 
 
"I'd only recommend it to someone who has never looked as their business as a series of processes"

Unfortunately, that's nearly all small business owners.
Craig Welch Send private email
Saturday, October 22, 2011
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz