Software product development is always a fascinating arena – not many are consistently successful here – maintaining versions, managing release management, supporting ever increasing feature requests, keeping up with technology, competition and on top of it upfront investments as a bet of strength of idea and implementation always makes this exciting but a challenging line of business .I had always been fascinated how small and niche boutique type product development companies manage this - these companies by defintition always live on the edge - with genrally no committed customer lockins and competition always trying to be smarter and big companies bundling these features as part of their standard offerings, integrating their products with various version of enterprise software, managing demands customers make during rollour and support - mindboggling that small product companies could sustain success and grow - a true wonder indeed. Joel Sposky writes on some of the issues faced by his team during the release upgrade of FogBugz, a project management software. I always liked Joel’s sense of humor and his ability to convey powerful ideas in a simple way. The four part article makes interesting reading and am highlighting a few things that look significantly insightful or downright funny.
In Part I he writes on how the redesign work started with customer requirements in mind by listening to customers and not competitors.
In Part II he explains the appraoch behind implementing automated response system - I sort of liked this humorous piece therein:"It's sort of like translating from English to Japanese. Train stations in Tokyo, make announcements in Japanese and English. You would hear four or five minutes of nonstop Japanese and then the English translation would be "The train to Osaka is on platform 4." It seems that in Japanese there is simply no way to say something that simple without cosseting it heavily in a bunch of formal etiquette-stuff. And it turns out the same thing applies to email messages, even in English. The moral of the story is that given two email messages with the same semantic content, the terse one is more likely to come across sounding rude. But given the amount of email correspondence we have to deal with here, we don't have time to be Emerson on every customer support email".
In Part III he writes about,an Innovative approach taken to support running the product in Unix.
In Part IV he writes,"A ridiculously small portion of the energy it takes to make a commercial software product actually goes into the writing of lines of code and estimates, that out of every 100 calories expended by the Fog Creek team:
- 25 calories are spent on customer service
- 55 calories are spent on debugging, beta testing, and minor tweaks
- 8 calories are spent on marketing, including the Fog Creek website
- 5 calories are spent reading college kids' resumes and interviewing said college kids
- 5 calories are spent on code that never ships, such as the online demo and the online store
Leaving just:
- 2 calories to spend on actually writing new lines of code that ship to a customer Joel writes that this helps explain why so many software companies started by programmers fail: programmers are really good at writing news line of code, they might be good at debugging, but nobody ever taught them how to do marketing or customer service, and they are probably horrible at graphic design.
These distribution - Joel am sure is applicable to Small enteprises- In big enterprises, 50 % time would go to meetings, review and demos!!
I sort of like his view about what infulences customer choose a particular product against a competing product.
Before a consumer will buy your software product, they'll evaluate all kinds of things to decide if it's a real product that will meet their needs:
- They'll evaluate the quality of your website.
- They'll look for discussion groups to see if people are actually using the product, and if the people who have problems are getting prompt resolutions.
- They'll look to see if there is a third-party support infrastructure, like books.
- They'll evaluate your reputation.
- They'll search the web to see if you have positive buzz.
- They'll see how long you've been around, and they'll try to evaluate whether you're profitable and successful and likely to stay around to continue supporting the product.
- Oh, and if they have a few minutes left over, they might actually look at your product itself to see if it works.And that explains why people buy overpriced but useless shelfware that costs $millions and doesn't really work. They rationalize that if they install it, they'll be shielded from criticism and other mercurial notes of anger.
Category:Software Product Development.
|
