The Next Feature Fallacy
andrewchen.co
andrewchen.co
It is very easy to say "I need to add/improve feature X, fix bug Y, or refactor Z" when what you really need to do is outbound sales activity, balance your books, or write blog content. You may already not enjoy those activities because they are some combination of hard, not fun, and something you don't really understand. Couple that with some engineering task of perceived equal importance, that you do know how to make progress on, and you can almost convince yourself its really not procrastination.
The best solution I have seen is to track progress on a macro level, so that product advancement is put on par with the other critical activities of the business. Having someone kick your ass when other areas slip is very helpful.
"Can I ask people to upvote my submission?
No. Users should vote for a story because it's intellectually interesting, not because someone is promoting it." via https://news.ycombinator.com/newsfaq.html
I'm working on a blog post about the problem of upvote begging. Usually, it's in the minority of users, although some websites don't explicitly enforce it well. (Case in point, Product Hunt makes upvote begging part of the status quo, which compromises the integrity of the site as a whole.)
Solve that, and you have much more traction to complain about what people should or shouldn't be doing.
Even then, two wrongs don't make a right. It comes down to luck, and sometimes it doesn't pan out. "Growth hacking" to correct bad luck is not necessarily ethical.
People are lazy, yes, but when there's monetary/reputation values tied to placement, the incentives change.
Anecdotally, new accounts are penalized too even if they vote from /newest (to prevent blatant vote manipulation via sock puppets)
That just seems like a silly thing to do. Especially since there's an obvious way around it.
This is the reason for the infamous IF YOU LIKE THIS VIDEO LIKE/SUBSCRIBE/COMMENT! phrasing that has plagued modern YouTube.
The comment is a tweet, which ordinarily is only seen by the user's Twitter followers.
For a sufficiently small community this assumption is fairly safe though even then not always true. As communities grow their population trends towards the average (for many characteristics) and the average human is more likely to be driven by the latter motivations than the former, at least as I understand psychology, though I would be very interested to learn otherwise.
tl;dr: I think the assumption that a submitter is motivated more by wanting to make a good contribution over having their HN submission 'win' is shortsighted.
This is why I left digg and reddit. The upvote circle of promotion with armies of article upvoters and comment upvoters/downvoters ruined these sites for me.
Example is sorting products by some variable or filtering products by some property. If I can't do that, that means I have to write a greasemonkey script and it is much easier to go to a competitor.
Bad salesperson: "Here's a laundry list of features that people say that they'd want in our product. Go off and implement them to make my job easier."
Good salesperson: "I have a firm commitment from Company Abc that they'll buy a 5,000 seat license if we implement this one feature. Is this a worthwhile investment?"
Conversely, the work to deep dive in to customer usage metrics that tell the story of how users use the app and reach their "Aha!" moment is comparatively dry and time consuming but nonetheless essential. We've set up a number of KPI reports which tell a detailed story of where our triallists and paying customers spend their time in the app and extract value.
We use a combination of Google Analytics and custom KPI reporting to watch customers use the app. We've tried 3rd party apps, like Intercom and Mixpanel but keep returning to google analytics.
So the good news is that we've identified key KPIs that tell us how likely a trial is to convert. For example, we know that a triallist that has logged in more than x times is > 90% likely to upgrade to paying. This is powerful, as we don't invest time attempting to sell to these. Likewise, we now automatically filter out customers that are not at all engaged with the app, and aim to sell to just those that sit between the two extremes. We've also taken the time to customise life cycle e-mails to triallists according to their levels of engagement. Again, very time consuming work but essential and very rewarding when the results are positive (more no/low touch upgrades = more £'s).
Obviously all traillists regardless of engagement level get top notch support. However I'm sure more sales intelligence could be shared with the support team as they're also key to the selling cycle, albeit in a more reactive manner. Support also need to feedback to the onboarding team, as support are front line for people who get stuck and frustrated as a result during a trial.
I could talk at length on this subject, conversion rate optimisation is something enjoy and definitely don't spend as much time as I would like actively working on...
The desired outcome is a certain number of engaged customers, but which part of the lifecycle to target deserves serious consideration, certainly beyond the all-too-popular default choice of "let's build a feature for a fully engaged customer".
For B2B, the only way I've seen features move any curve positively is A) if you have lost sales consistently due to a specific requirement[0], B) a customer pays you to build a feature[1].
Note also that sometimes features are a great way to introduce sticky-ness/price inelasticity in a B2B product: you just need a few people who really love a specific feature and that 15k/m customer wont think about switching.
Also, the 20% signup is pretty big based on my experience but maybe it's standard for freemium+ B2C startups? For B2B Saas, I've been happy with 5% with 8% being a cause for celebration after a bunch of copy/messaging tweaking. Am I way off here? Would love some pointers if so.
[0] Note that this has to be a overwhelming consensus amoungst your sales guys. It can't just be excuse du jour that's used when someone loses a sale. I would also suggest listening to some lost sales calls: it might help you ascertain whether the lost sales was due to the missing feature or if the feature was just cited as being the cause.
[1] Only build it if you see it being a useful feature for the market and not only that customer (so maybe integrating with twitter rather than the customer's specific DB or something) then it's always a good idea to build the feature. This is especially powerful if you are an underpriced new-comer trying to lure customer away from the big names.
I'd guess most of the apps I'm familiar with are around an order of magnitude lower, but none of them currently uses a freemium model. Some are considering shifting to one, and if it really does get this dramatic a bump in initial sign-ups in a typical case then that would be a good argument for doing it.
The attrition identified in the article may have less to do with having a killer feature, and more to do with how an existing feature is marketed to the correct audience.