The Payoff Proposition
July 17th, 2009Brent Simmons writes beautifully about a frustration that most indie software developers can relate to: the payoff proposition. He highlights the all-too-common scenario where a user offers a cash bounty, $50 for instance, to add a particular feature:
“The developers I know would rather rip up $50 bills, long sequences of them, than do something that, in their best judgment, is against the best interests of the software and its users.”
This reminds me of a listener question from a soon-to-be-released episode of Core Intuition, the podcast I do with Manton Reece. The question asks, roughly, “how can managers who don’t code relate better to their programmer employees?”
Non-coder managers and customers have a lot in common: they have a great vision for the future of a product, with little understanding of the work it will take to get there.
This is no slight on customers, or managers. Puhleez, I need customers, and if everything goes right with my business, I’ll be a manager before too long.
The naivete of customers is not a problem in itself, in fact it can be inspiring and motivating. “Yes, that does sound impossible to me, but you’re right, it would be freaking awesome if I can make it happen!”
Freaking awesome is a far better motivator than a stack of bills. You have to give the developer some credit for knowing how to evolve a product. After all, you must like what they’ve done so far, or you wouldn’t be trying to hijack their development schedule.
It boils down to something Brent nails in his write-up:
“If it’s the right feature and the right time to do it, the developer will do it. If it’s not, then it won’t get done.”
This is harsh but honest. Developers are always making judgment calls, for better and for worse. Yes, these judgment calls sometimes consider monetary compensation. We have to make a living, so great applications are built by choosing features that satisfy the intersection of “freaking awesome” and “financially viable”.
If your payoff proposition is freaking awesome, then you won’t need to pay a developer to consider it. They’ll be overjoyed just to hear the suggestion. Otherwise, it will take a lot more than $50 to pull them away from what they know is best for the product. In the end, this is good for you. Not only do you get to keep your $50, but you get to enjoy a carefully-designed application, as well.
July 17th, 2009 at 4:48 am
Of course, as a non-coding manager, I can offer almost exactly the opposite perspective :)
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 :)
July 17th, 2009 at 9:39 am
I certainly would never want to insult my favorite developer(s) by offering them what amounts to a small bribe for a specific feature, but you and Brent both seem to be describing a world where if a suggested feature is indeed worthy, that inherent worthiness will always shine brightly in the eyes of the developers and good things will therefore surely just…happen.
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.
July 17th, 2009 at 12:06 pm
Freaking awesome!
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.
July 17th, 2009 at 12:30 pm
There are entire business models based loosely on what you call the Payoff Proposition. Open source projects like Drupal, RedHat, etc… offer many of the founding developers up to develop custom features for commercial usage in exchange for major moolah. So I’d offer that it is not always in the best interest of the developer to leave all of his new features to his unique discretion. In fact, I’d say the biggest issue with the $50 offer is the price; it’s way too low. You can always hire someone to write the feature(s) off a branch of your product if the price was high enough.
July 17th, 2009 at 12:41 pm
This isn’t just a problem for Indie coders vs managers of coders, it’s true of every design endeavor. Marketing folks are convinced they have the killer idea to increase sales without any appreciation of the engineering difficulties involved in designing, producing and monetizing it or conversely, the designers have this freaking awesome idea that the managers know will only be overkill for the intended market. It’s the “can do”, “should do” dichotomy.
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.
July 17th, 2009 at 2:26 pm
I think you’re all taking it way to literally.
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”.
July 17th, 2009 at 3:23 pm
Joe nails it. Most people who do that aren’t actually offering to pay $50 – it’s shorthand for “I value this feature” and in a world of free and inexpensive software, $50 is seen as a lot of money.
@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.
July 17th, 2009 at 4:20 pm
Re Ian Betteridge:
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.
July 17th, 2009 at 4:37 pm
The most important thing a customer can tell me is what the problem he is trying to solve is.
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…
July 17th, 2009 at 7:33 pm
I want to add to Ian’s comments. Once upon a time, I was on the taxpayers’ payroll functioning as the lubricant between management and the developers who worked for the usual gargantuan contractors. I had two things going for me. First, I’d coded just enough to know I didn’t want to do it for a living, but also just enough that I could converse with Actual Live Developers in something approximating their native tongue. Second, I managed to get managers out of the loop, for the most part, and compel developers to spend several days sitting with Actual Employees so they could have some insight into the things their code was supposed to do.
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.