>> First, you frequently find that what he *thinks* the product in the
>> Internet video does isn't what that product *actually* does. Frequently
>> he asks us to do XYZ, when that's mathematically impossible.
>
> Then what you do is drill into details.

This guy seems to have a memory like a sieve.

He asks us to implement a feature. We tell him it can't be done. "Oh, 
can't you just do X?" "No, because Y, Z." "Hmm, but what about... oh, I 
guess you're right. Oh well."

Two weeks later... he asks for the exact same feature. And we repeat an 
identical conversation, again with the same conclusion. He understands 
that, no, what he wants us to do isn't technically possible. And yet, a 
few weeks later, he's completely forgotten that this conversation ever 
happens.

On the other hand, it means that next time he asks us to implement some 
whizzy new feature, we'll have forgotten all about it in a few days' 
time. ;-)

> Work up an actual estimate of the time it would take to do it.

Is there a way of doing that which is more accurate than sticking your 
finger in the air?

I mean, we all know what will take us ten minutes, and what will take 
months. But it's hard to be more accurate than that.

> Of course, eventually he ran out of patience for the work I was doing
> (because it was never finished), and he didn't renew the contract (but
> that was OK as I had another gig lined up), and looking at the product
> today, I see very little of what he actually paid me for, because the
> product functionality has changed completely.
>
> Oh, and 2 years later, they still don't really have a "version 1 release".

We release a fairly constant stream of updates and improvements. We do 
this by more or less ignoring everything that comes out of the MD's 
mouth, and just doing what we planned to do in the first place. ;-)

>> Then again, often a customer has no interest in buying our product, so
>> they will start playing a game of "Does it do X? Does it do Y? Does it
>> do Z? Oh, it can't do Z? Then we won't be buying it." Which our MD takes
>> as meaning "if only it could do Z, we could sell MILLIONS!" Erm, no, if
>> it could do Z, the customer would simply find some other excuse to not
>> buy it. There is a difference between a customer who can't use the
>> product without Z, and a customer who just wants an excuse to fob you
>> off with.
>
> It might not be good for customer A to have feature Z, but if it's a
> significant enough feature, it might entice a new customer.

Even if one specific customer really does want feature Z... Are they 
*actually* going to buy the product, or buy more of the product than 
they would have? Because if the answer is no, why are we disrupting the 
schedule to spend development time on this? If there's *lots* of 
customers that want a feature, then we should totally do it. But this 
business of developing something for one specific customer who may or 
may not even give us any money... that doesn't seem very profitable.

Then again, our business model is the extraction of money from people 
who, by definition, have constant budget cuts, so...

Post a reply to this message