Here’s part of what I learned: The gap between users and coders is typically so huge that they do not know how big it really is. A user will complain, for example, about some twisted and complicated current procedure and exclaim the life would be so much better if the developer would write some software to make it go away. So, the developer, quite oblivious to the fact that he or she doesn’t really understand the world of the user, writes code that does what he thought the user wanted done. Only, it doesn’t. By the time anyone discovers this, the budget is depleted and management is in no mood to listen.

Lesson: In that kind of environment, developers need to spend much time with a few users who are both very capable of explaining their job to laypeople (the developers) and who have the patience to listen to developers explain what is and is not possible.

As a project manager and as a developer, I’d give good money to have clients that can tell me this rather than just tell me their solution.

Rob…

Coders working on a project often have pet features that they’d like which bear no relation to the needs of the customer, and as a manager you have to fight tooth and nail to keep them out, to retain the bigger picture of what the project is actually for.

(As an aside, the Agile project management mind-set really doesn’t help with this. Coders and designers often see Agile as an excuse to iterate for iteration’s sake. Personally, I hate Agile :) )

This reads, to me, like you’re saying that coders and designers should be insulated from customers because Agile projects are too hard to manage. Is there some reason you can’t use the development method you prefer, and still get coders in front of customers?

Having both been a developer and a manager of developers, I have to say that this “coders just want to do what *they* want” mentality represents a serious management issue. If you get good coders, manage them well, and let them see how real users want to use their software… well, then what coders want tends to be a lot closer to what your users want.

If you keep coders insulated from customers, then coders will write software that *they* find useful – and unless your users are other coders, that’s not a particularly fine recipe for success.

@jcburns – those people are called Product Managers.

And as one, I’ve usually dealt with development by saying “Customers really want Feature X… after digging into why, I think the problem(s) they really want to solve are…” and then dive into a discussion. The developer gets an understanding of the underlying issue that the customer faces, I get information about solving that issue and the product might, if we implement the feature, be better. You never just take “I want Feature X” statement at face value though – you always dive behind it and figure out WHY they want that feature. You might decide that their solution is the best one… or you might come up with a better solution that will make even more sense.

The $50 offer isn’t about $50. It’s a statement from the customer as to how important a feature is to them.

There’s a HUGE difference between “I’d like to see this feature” and “I’d pay $50 extra for this feature”.

Used wisely, it is something for you to consider BECAUSE of the value to a customer. You will, of course, have to determine if it has similar value to a lot of customers, but it’s a lot better starting point than “please add this pet feature [but I wouldn't pay $0.01 more for it]“.

I’ve never seen anyone make that ‘offer’ who really expected it to be considered as a bona fide offer. It’s simply their way of saying “not only do I want this, but I really, really want it – to the point that I’d pay a lot more money”.

Indies (and small companies) have the advantage of a single judge of what goes and what stays but they aren’t infallible in that judgement. We’ve all abandoned (or not upgraded) software that was overdeveloped, i.e., feature bloated.

Some years ago now, I designed the controller for a small (basically one-man) company who could never resist making a sale by adding a feature – the Payoff Proposition. It took a lot of arm twisting on my part to convince him that the motherboard had to be redesigned to accept special feature plug-ins or he’d have a nightmare servicing and keeping track of these features.

In a way, making an application scriptable or publishing a plug-in API is an equivalent for software designers. The core programming remains intact and features are added and sold separately.

It might be nice to see a status board with a list of requested features and a way for voting to take place. “Top 5 Most Requested Features” and you log in to vote so only valid customers get a say.

Um, well, what if it doesn’t? What if the suggester is (sadly) inarticulately trying to describe something useful? Or, what if the developer comes at their product from such a different (inside) perspective that their reaction is “well, if that guy knew the software as well as I did, he’d just see that the way I have chosen is the superior one?” (I feel like I’ve seen this kind of tunnel vision or ‘backwards-facing insider vision’ from time to time from all sorts of developer types.)

It’s at those times I see the need for what in the land of journalism we’d call an ombudsman (an idea and term itself borrowed from Old Swedish bureaucracy)—someone who can take the inarticulate, half-formed shouts from the outsiders and slickly aggregate and translate their needs into the binary language of moisture vaporators that developers understand, so that everyone benefits from the idea’s uh, freaking awesomeness.

I think it’s worth saying that while your perspective and Brett’s are pretty close to the mark for what you might call one-man software – where it’s the owner, originator, and (often) only coder on a project. When it’s your software and your company, you’re pretty close to the metal and you know the customers really, really well.

In larger projects, with bigger teams and coders who are employees rather than owners, that’s often not the case. Coders working on a project often have pet features that they’d like which bear no relation to the needs of the customer, and as a manager you have to fight tooth and nail to keep them out, to retain the bigger picture of what the project is actually for.

(As an aside, the Agile project management mind-set really doesn’t help with this. Coders and designers often see Agile as an excuse to iterate for iteration’s sake. Personally, I hate Agile :) )

(As a second aside, if you’re working on a project for a client, all bets are off. Preventing feature-creep by the client is one of the core skills of a client-facing project manager. Clients often don’t understand that “can be done” doesn’t always mean “should be done”.)

And after two asides, I’ve totally lost my thread, so I’ll leave it at that :)