October 20, 2009
Two weeks ago I covered some of the business lessons learned from a large (~3 months) investment in new features, and the hard decision to roll them back. I discussed how you will underestimate the ongoing cost of complexity in your product, and how cool new capabilities don’t sell themselves.
Continuing this week—more insights gained from undoing development work.
In cost-benefit terms, there are some clear winners in our recent feature development: the winners are the features that support better business decisions and enable more business development. For us, this meant:
We launched a major development initiative based on our internal ideas of what users wanted. In retrospect, we should have spent much more time speaking with customers and vetting the ideas. The closer you get to your product, the easier it is to fall into this trap. Two examples of thinking that lead us to assume too much:
A. Extrapolating feature needs from a competitor’s offering … “Competitor X does feature Y. We should do feature Y, since there’s obviously a demand for it.”
Well, maybe. Company X may already “own” that feature in customers’ minds. Or they may be losing money on the feature. The existence of a competitor in the space isn’t necessarily a good argument for entering that space yourself.
The lesson: do some more research before committing serious development resources.
B. Assuming users will invest in more complicated features.
We assumed that if we offered the capability to report structured data into Scout, plugin authors would create more sophisticated plugins. Signup numbers didn’t bear out this hypothesis. Why? Too much complexity. Building and debugging plugins to report complex, structured data wasn’t something you could easily pick up and see immediate results. It was too involved for all but the most dedicated plugin authors to utilize.
The lesson: complexity can change the game. If you’re asking a lot more of your users, do a gut check and have some more conversations.
We all tend to see challenges in terms of our own skillset. If you’re a good developer, you will think of product solutions to growing your business. If you’re good at business development, you will see business development solutions. That’s not a bad thing, but part of the challenge of building a business is to expand the domain of solutions you are comfortable trying.
It’s easy to be biased toward development work because that’s what you know best.
So, are you getting a warm, comfortable feeling for the execution of the solution? Then do a quick sanity check. You may be guided by your comfort with the execution rather than how appropriate it is for your problem.