Homepage / Checkbox Blog / Put down the compiler until you learn why they’re not buying.
Put down the compiler until you learn why they’re not buying.
I’m involved with several little companies right now. They all have the same problem, and they’re all avoiding the clearest, fastest path to fixing it.
Of course everyone wants “more sales,” but I’m specifically talking about the early stage of your company, when your v1.0 is shaky but has enough features that it should be more viable than it is. When your website copy is good enough that people are willing to sign up or download, but the sales aren’t coming in like they ought.
This problem is solved only one way: You need feedback from lost sales. Empirical data, not your own ideas about why people might not be buying.
You need to talk with the people who were interested enough to find your website, read your marketing copy, download your product, and then give up without even an email. That’s the low-hanging fruit; those are the people who are in your grasp, who should be buying today, but aren’t.
But I find that entrepreneurs — especially technical ones — fight me on this tooth and nail. And I’m not surprised because, as usual, I too used to hold the I-already-know-why, I-know-my-customers-better-than-they-do attitude.
Existing customers are telling us to do X, so we should do X. Customer requests are important and you must follow their lead, especially in the beginning. But what about the 98% of trial users who didn’t buy? It is they who hold the key to more sales! Existing customers bought in spite of barriers to sale, so they’re no help in identifying the barriers. Listen to them to increase your product’s value, but listening to them to increase sales is classic survivor bias.
We need to clean up the software before we can get real feedback. At Smart Bear, the first incarnation of our code review product was so hard to decipher, I can’t understand how we got customers. They used it in spite of the problems, not because of them. If you’re solving a genuine pain, people will try the software, complain about it, ask for features, and generally be engaged; if that’s not happening, you’re not solving the right problem or not making that obvious, and that is critical to getting revenue. Have you ever worked on a software project for many years and lived through a face-lift? After you’re used to the new look and creature-features, when you see the old version it’s so bad you get embarrassed, right? It’s the natural order of things. Polish isn’t important if you don’t have enough revenue.
I’m a user myself, so I know what’s missing. That’s great, but all that means is that you have 100 ideas for new features, but “more features” is almost certainly not the problem. It means you have a “vision” which is almost certainly not how your company is going to unfold. Often the real impediment to sales is as mundane as “New users are presented with a blank screen, so they don’t know what to do next, so they abandon the trial,” or “The installer doesn’t work properly under Vista, so people give up.” The fact that you’re a user yourself is the worst position for you to be in because you can’t be objective about the new user experience, and you can’t put yourself in the shoes of a user possessing below-average intelligence. Which half of them possess. There, I said it: Most of your users are dumb; almost all are dumber than you are. You are not a typical user.
Apple just knows what’s cool. So do we. This is a common misconception, easy to believe because Apple does keep product development close to the vest. However, it’s completely untrue. See the Venture-Hacks blog quoting Steve Jobs on the matter; then see their roadmap for collecting customer feedback and using it for repositioning, just like Apple does.
We can’t afford to delay the v#.# release. If you have no real evidence that revenue will suddenly improve with the next release, why do you think it’s important to release it? Just because it has “more stuff?” The only reason to be excited is because it’s different, and since the status quo isn’t working, you’ve got to try something different. But is that “stuff” why people are downloading but then abandoning? Until you can answer that question with empirical data, there’s no reason to believe the new stuff will be more compelling than the last stuff.
Getting revenue is a marketing/sales function; I need to be heads-down in the code. In a startup, it’s everyone’s job to get revenue. Sure, the usual day-to-day activities should be divvied up between founders; not everyone needs to write letters to bloggers and be glued to Twitter live-search. But if you don’t know why people aren’t buying, that’s the #1 feature you need to be working on. There’s lots of ways (see below) to change the product or website in under a day that will begin fixing the problem. Saying “it’s marketing’s job” really means “I’m not going to help get revenue.” Unacceptable.
Hopefully by now you’re convinced to get more feedback from lost sales, but how do you go about doing it?
Stay tuned! Next week I’ll post eleven specific ways to get more feedback, almost all of which take less than a day to implement.
Jason Cohen is the founder of Smart Bear Software, maker of Code Collaborator, the world’s most popular tool for peer code review and recent winner of the Jolt Award. Jason took Smart Bear from start to multiple millions in revenue and 50% profit margin without debt or VC, then sold it for cash. He is also the author of Best Kept Secrets of Peer Code Review, the most popular book (35,000 copies) on modern, lightweight methods for doing peer code review effectively without everyone hating life. He lives in Austin, Texas with his wife and new baby. Jason blogs about Startups + Marketing + Geekery and can be found on Twitter @asmartbear.