Part II: We Just Undid Three Months of Dev work. Here's What We Learned.
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.
Lesson #3: The best features are ones that support better business decisions
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:
- front-and-center reports of signups, plan upgrade/downgrades, and cancellations. This data was always there, but making it accessible in a hassle-free way was a huge win for us. You will naturally optimize around what is easily accessible and visible.
- an affiliate program and corresponding administrative functionality, integrated with our signup system. This enabled us to pursue a whole new class of business relationships and revenue opportunities.
- feedback collection from users who cancel. A surprising percentage of canceling accounts will give you honest feedback on why they are quitting. The subjective feedback goes a long way in coloring your signup metrics.
Lesson #4: There is no substitute for talking to your users.
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.
Lesson #5: Be wary of “comfort work”
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.
Liked this article? Subscribe to our RSS feed or follow us on Twitter
