When developing a large product, especially for enterprise customers, it is tempting to do some engineering specifically to land (or keep) a big customer. This, on its face, sounds good, right?
“The customer is always right.”
Marshall Field – Wikipedia
I think this makes sense in a department store. However, when dealing with large enterprise software, the customer is sometimes wrong. They will want a feature that might not be good for the business. This happened to me many years ago at Remend. One big customer can derail your whole product this way. Here are a few reasons why it might be a bad idea:
- The feature is divergent from your vision and will confuse the market
- The feature is hard to achieve
- The feature is only is usable by a couple of customers
- The feature will delay a different feature that is much more strategic
Additionally, when you do something “quick”, you take on technical debt. Sometimes it makes sense, but often that technical debt will cost you much more than whatever money you got from that one prospect or customer.
Natural Acts
A “natural act” of engineering is when a little feature is:
- Already on the roadmap, just lower
- Aligned with your vision
- Possible to do without too much technical debt
- Productized for broad use cases
That last one is a key attribute of a natural act. A single hack feature for one customer can usually be expanded slightly and made abstract so that other customers can benefit. A natural act would be to switch priorities of two features on the roadmap that you were going to do anyway.
Unnatural Acts
An “Unnatural act” of engineering is when:
- Development will cost more than the feature earns
- Technical debt will be crippling
- Morale takes a serious hit
- Other priorities experience large setbacks
An unnatural engineering act sticks around for way longer than you expect. It might be years with the same rickety hack that was made to get a customer from ages ago.
Some unnatural acts can be accomplished by professional services in an enterprise capacity. These are sort of good in the sense that they achieve the goal. The downside is that those PS hacks stick around and might be broken by future development. It’s a fine line between professional services hacking together an answer to close a deal or keep a customer vs that same hack causing the customer to be unhappy in the long run.
An example of that is Marketo’s Traffic Cop implementation. This was invented by a marketer to use the system in ways that it was never intended. The implementation was useful and eventually became “nurture programs” when they were built by product. However, until then, the traffic cop made everyone miserable. it crashed the servers non-stop with infinite loops of trigger storms. (Don’t ask – it was a nightmare!) Also, customers complained that they were spending all their time messing with traffic cop and thought the product was “not easy”. I think it hurt the company tremendously even though it was useful to the power users of a few companies.
The lesson is that unnatural acts are usually bad ideas. Make sure to abstract the functionality and support it for real. It takes a little longer, but it will ensure the health of your business long term.
Whatya think?