>> 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.
>
> He might also be looking to see if he gets a different answer.

I... don't think he has sufficient brainpower to attempt such a thing. I 
get the impression he's just very excitable and easily distracted.

> I might counter it by saying "we talked about this a couple weeks ago -
> here's a summary of the conversation."  Do it enough times, and he'll
> remember.

Heh, perhaps.

>>> 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?
>
> Of course there is.  Google "PMP" and "project estimation".  Software
> companies do this all the time.

Hypothetically we *are* a "software company". Oh and hey, we do have 
planning meetings. Trouble is, the estimation process is roughly 
"everybody picks a number, and we see if the numbers look similar". That 
still doesn't seem very scientific. Then again, when you're asked to 
produce a new feature and you have no idea what libraries might be 
available to help you or what OS-specific hiccups will trip you up, what 
more can you do?

(We do seem to consistently over-estimate how long anything related to 
C++ will take, which is... surprising. You would have thought we would 
be *under-estimating* that.)

>> 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.
>
> Depends on whether it's a useful feature or not in the context of the
> software.  Depends on if your salespeople can use it as an additional
> hook with other customers.  That's what product management is all about -
> gathering requirements from customers (and prospective customers),
> turning those into requirements, and then building a plan for creating
> the product.
>
> Do you have a product manager?

Our entire company is ten people. We don't have a lot of anything much.

Realistically, it is quite hard to figure out what customers and 
potential customers *actually want*. I'm sure most companies have this 
problem. Then again, most companies probably have a marketing department...

There are some specific features which the MD is *desperate* to have, 
that (as far as we can tell) no customer has ever been remotely 
interested in. And that's what kind of amuses us sometimes.

>> Then again, our business model is the extraction of money from people
>> who, by definition, have constant budget cuts, so...
>
> Which seems to still work pretty well - from a sales perspective, the way
> you sell to customers like that is to show them that by spending money,
> they save money.

My point being, if they have no money, it doesn't MATTER how much money 
they could be saving. We are not getting a sale. End of.

Post a reply to this message