Skype it simple!

I was reading the Skype forum to get an idea of what the main causes for complaint are related to the software, and I was surprised!
My broad take from the large number of entries was the following :
1) Useability : Skype desperately needs some enhancements in contact management (particularly)
2) Sharing the wealth : There has to be a way to enable some revenue sharing on a transaction basis, to encourage more 3rd party use.
3) Quality: Calls to mobiles are inexpicably crappy, and they're also overpriced! (by the way, it costs more to phone a Swedish mobile than one in Tanzania!)
4) Billing: More than anything, people want to pay money to Skype to get credit and SkypeOut.

Everything else is already announced as 'coming very soon' e.g. Call Forward, App2App API.

It seems that point 4 is being addressed, if painfully slowly, and I'm not sure that point 3 is within Skype's control (though they should be asking some hard questions to their interconnect partners).

The thing is that the useability changes are fairly minor, and this is probably their main problem.
Many products I have worked with suffer from release budget cutback, or Cuckoo syndrome. What happens is that a BIG list of desired changes is put into the pot and prioritised. Then some estimates are assigned to the features and after a lot of discussion a set of features to be developed in the next release is arrived at. Inevitably there is a biggy that is very important and very costly to implement, so the PM(s) look around for savings when the biggy consumes more than it's allotted share of the budget. The small changes get pushed out, because the focus is on development (at that point in the cycle), not user value.
I can guess that the Cuckoo for Skype is Video, and the small changes like contact groups are the smaller eggs that get pushed out.
Thing is, I think this is a mistake and it comes out of traditional release management approaches that tend to create monolithic budgets and ineffective teams.
What you need is disruptive development. Put together a crack team of people who really KNOW the code, and give them a list of UI nice to haves, but no budget or weighty design document. Chances are they will have done them all by next Tuesday, if they like the ideas.
If they don't like them, then maybe they needed more consideration anyway.
Assess the changes once they are done, and agree to any refinements. Release it and monitor community opinion, if the community don't like it, then change it! Quickly!
Not all changes, even if small, fall into this category, but there are a lot that do, and there is no need to get them bogged down in all the release planning overhead.
But remember, if you're going to use JFDI, use TFDI afterwards, otherwise you're just f****d.

No Need to Click Here - I'm just claiming my feed at Feedster