Selling Less is More
It may be either a sign of laziness or of wisdom, but I’ve had a few conversations of late where I’m deliberately selling my clients on fewer and/or less complicated features.
On the surface this is bad salesmanship: I bill by the project, and of course the price tag for a given project grows with my estimate of the complexity of what I’m building (and hopefully the value gained by the client, as well). The more features a client is certain they want, the more features I get to build and charge accordingly for that work.
So what’s up with my recent kick of advising fewer features? Turns out it’s mostly situational with a dose of outside wisdom. The projects I’m thinking of are both of an “expand in a new direction” variety: one is a pilot program to prove a new concept in their e-commerce, the other is to make a hub for a community to interact online in a way they haven’t before.
The dose of outside wisdom is the 37 Signals bit on the Race to Running Software which states simply “get something real up and get it up quickly”. Both of my clients found it refreshing to hear things like “Tell you what, it’s just the pilot: we can leave the customer address book feature out for now, and add it in later if it turns out to be important.” and “Let’s see what your users do with just the ghetto-fab system of posting comments. Then we’ll know what they’re bumping up against, if anything. If it suffices, we’ll have saved ourselves a lot of extra work.”
Planning to build non-critical stuff up front involves a lot of guesswork and creates a bigger gap between speculation and real world feedback.
Would I like to be hired to build the customer address book feature? Sure, it’s a tidy little feature that would be really slick and is clean to implement. But let’s wait to see the first 5 repeat customers who place orders shipped to more than one address before we build it. That will save time and money while we focus first on getting the system ready to launch at all.
It’s simply having an eye on the prize. And I’m talking business win, not a juicier contract.
Next: Augmenting a Team vs. Being a Separate One
This is Programmer for Hire, a series of essays and explorations on the art of being a great programmer doing on-demand custom software development.