[PetiteCloud] grate book on how to specify systems

[Michael Thoreson]

There are a few solutions to the typical tech support failures.

1) All tech calls get reviewed by a dev or dev team periodically.
2) Devs rotate from developing to taking tech support calls on a set 
rotation
3) A Dev or Dev(s) is available and dedicated to assisting tech support 
intake with any unusual problems
4) Don't train monkeys how to answer phones and read flow charts of text 
book answers and expect to solve problems.

Michael Thoreson,

On 14/02/2014 7:01 PM, Aryeh Friedman wrote:
> A little glue in the *RIGHT* places and a nice skin will win *EVERY* 
> time. The inappropriate marketing of any kind of product will always 
> fail. Namely no appropriate marketing is possible if the product 
> sucks. Only once you have a soild product can you start the real 
> marketing (this assumes your aware of marketing 101 and know that 
> without a market to market to no amount of marketing will sell your 
> product). But you need one more element here which is prove that your 
> product does in fact solve the actual problem the potential customer 
> has. Now that everything is in place we can start the real work of 
> marketing which is making the people who have the problem your product 
> solves know that you have the a solution (a good healthy multi-vendor 
> market should offer several solutions that are all appropriately 
> marketed). Thus the real job marketing of an appropriately product is 
> to just let people know about what your product is and what it can do. 
> If it does not do what they want or in the way they want then no 
> amount marketing will sell it to them if they are aware of a number of 
> competing solutions. If all these competing solutions depend on a 
> common enabling technology (like a cloud computing platform... in this 
> case it need not be petitecloud just the ability to manage instances 
> and such) then it is *CRITICAL* that every competitor have a fair say 
> in it's creation.... there is a problem here though if you allow 
> everyone to have an equal say then you end up with crap every time.... 
> there fore the only reasonable model I see for the above to work for 
> something like petitecloud is a democratic benevolent dictatorship 
> (the philospher king model)... namely we (the core team) will take 
> input from everyone and have open processes and all that but what is 
> actualy committed to code is our say and our say alone... same goes 
> for contributions we welcome all and except for cases of introduction 
> a requirement for radical refactoring we will take it (assuming it is 
> safe, stable and robust).
>
> A comment on "we don't support that feature"... here is a quote from 
> our business plan on that:
>
> All software companies to some extent have “technical support” 
> questions that must be answered (or people will simply stop buying 
> their products). This is usually delegated to a tech support 
> department. Having to deal with a “tech support specialist” of large 
> companies is one of the quickest ways to anger our target market. The 
> reason is despite how long we wait on hold (with the world's worst 
> music played in a tin can) or how many useless menus we go through and 
> have very carefully explained for the n^th time that we have already 
> read the manual and searched the online knowledge base it is still 
> guaranteed that an actual developer who can fix my issue will never be 
> told about the issue, thus guaranteeing it will never be fixed and 
> will eventually get buried so deep in the code base that it will be 
> impossible to fix. This entire process is alienating to freelance 
> developers because they often know as much, if not more, about the 
> product then the tech support people do.
>
>