The Next Feature Fallacy(andrewchen.co)
andrewchen.co
The Next Feature Fallacy
http://andrewchen.co/the-next-feature-fallacy-the-fallacy-that-the-next-new-feature-will-suddenly-make-people-use-your-product/
45 comments
While I thoroughly enjoyed this blog post, this seems to not be in the spirit of Hacker News: https://twitter.com/andrewchen/status/605422107028131840
"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
"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
Upvote begging (and knowingly using the /newest trick) is pretty unethical, although fortunately uncommon in HN.
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.)
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.)
It's common because the likelihood of escaping /newest on the basis of "intellectually interesting" alone is miniscule. The traffic just doesn't work that way.
Solve that, and you have much more traction to complain about what people should or shouldn't be doing.
Solve that, and you have much more traction to complain about what people should or shouldn't be doing.
What? No it isn't. (See my submission history for URLs to minimaxir.com, and I have negligible influence in the tech world)
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.
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.
On the other hand, we can't act like the front page is a meritocracy either when there is a significant element of luck involved. Would be be "growth hacking" if I analyzed upvoting patterns to determine the "correct" time to make a submission to maximize the chance of hitting the front page? Don't I gain an advantage over someone that sees an interesting link and just immediately submits it to HN?
I'd be interest to know if "upvote begging" actually works beyond a small amount of users who see the "beg" and know the person "begging". I'm not so sure the majority of people bother going on to a site to upvote something just because they were asked. People are extremely lazy.
Unfortunately, that's impossible/infeasable to prove quantitatively without access to the raw data. In the HN case, however, I've seen a number of submissions which get 10+ points in a few minutes (which will get you on the front page quickly), but the submission was on the second or third page. A quick Twitter search shows they were asking for upvotes.
People are lazy, yes, but when there's monetary/reputation values tied to placement, the incentives change.
People are lazy, yes, but when there's monetary/reputation values tied to placement, the incentives change.
what /newest trick? do upvotes count for more if they're made from the new page rather than the front page? (and if so, does it track state when you click through to the comment page first, then open the article in a new tab, read it, and then upvote from the comment page?)
The inverse: upvotes are penalized if the voter comes from a direct link from a non-HN source (e.g. Twitter), so people direct others to vote via /newest.
[deleted]
So, I see a submission I think is interesting and direct link it from my Twitter account; the submission is penalized on every upvote it receives through my link?
That just seems like a silly thing to do. Especially since there's an obvious way around it.
That just seems like a silly thing to do. Especially since there's an obvious way around it.
Wouldn't you in that case link directly to the article and not the comments section?
Not if I wanted to get people to engage in the discussion about the submission. Most of the time I'm just as or more interested in the discussion than the article. It's why I participate instead of using HN as a news feed.
Interesting. How smart are they about this? My HN flow involves always voting from the comments page, even though I got there from the front page or /newest. Does that mean I'm triggering the penalty?
Edited parent post for clarity.
Anecdotally, new accounts are penalized too even if they vote from /newest (to prevent blatant vote manipulation via sock puppets)
Anecdotally, new accounts are penalized too even if they vote from /newest (to prevent blatant vote manipulation via sock puppets)
While vote begging has been around since the first site that supported comment voting, the "Like this on Facebook" thumb-up icon really entreched this in people's minds as a common and accepted thing to do.
I am afraid it does not work that way in practice. I have been using HN since its inception, or very close to it, when it was all about startup news and products. Yet I rarely visit the New posts page. If everyone were like me, the front page would be static. Heck I do not even go past the first 30 links. There is a lot of great content I am sure that never makes it to the homepage because it is not getting upvoted. Asking for upvotes is unfortunately the solution to this issue until we have built systems which are intelligent enough to surface quality content even when it is not being upvoted. In theory some content should find their way into the top 5 links as soon as shared, but that is not the case. Waiting for upvotes is like saying "If you build it they will come." They won't unless you market and yell it.
I try to go /newest on once a day, i.e. "do my duty". I don't spend a lot of time there, but I do scan through everything. I've definitely gotten to see some cool things because of it.
When I see this I immediately flag the submission.
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.
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.
Is it not reasonable in many cases to infer that the promoter isn't intending people to up vote if they're not interested in the article?
Only if we assume all submitters only submit because of how interesting / important / relevant an the submission is, and are not influenced in their decisions by imaginary internet points, pride in getting to the front page, etc.
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.
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.
That is not a reasonable inference, even if there wasn't an explicit call-to-action. (Otherwise, why make the comment?)
This is the reason for the infamous IF YOU LIKE THIS VIDEO LIKE/SUBSCRIBE/COMMENT! phrasing that has plagued modern YouTube.
This is the reason for the infamous IF YOU LIKE THIS VIDEO LIKE/SUBSCRIBE/COMMENT! phrasing that has plagued modern YouTube.
> Otherwise, why make the comment?
The comment is a tweet, which ordinarily is only seen by the user's Twitter followers.
The comment is a tweet, which ordinarily is only seen by the user's Twitter followers.
A much more common thing to see is a link labelled "Discuss on Hacker News". I assume that this would be considered fair promotion?
Does anyone has any metric about Ad revenue on a top HN item?
I agree the call to action was very specific ("dear HNers"), but I think we all assume that authors promote their own writings via many channels.
Promoting their own writing is perfectly fine. Promoting a HN submission which is likely irrelevant to said writing is not.
It doesn't say "check out my essay" it says "upvote my essay on HN".
Isn't asking people to upvote your article is a clever "hack"?
The other side of the coin is that there are many products that lack that one feature that makes me not use them or makes me less interested in using them.
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.
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.
The challenging sales cycle (if there is one) is this, "If this feature were added, would you commit to using this product?" that question is hard to ask and answer in a web based freemium world. In the enterprise sales cycle I've seen customers decline to buy 'for lack of a feature' and having that be a way to say "no" without explicitly saying no. When I worked closely with the enterprise account teams at NetApp that was always something to consider.
That's a good way to qualify features, too, so you don't end up building a Franken-product full of half-baked ideas from people who aren't even paying customers.
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?"
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?"
I like: "Dangling by a Trivial Feature" http://prog21.dadgum.com/160.html
And related, removing a feature will almost certainly cause you to lose some users. And since users are hard to acquire, this is a big deal.
We've been guilty of this over at http://www.staffsquared.com. It's far too easy, and sometimes fun, to build better/more features than the competition. It's equally difficult for the sales department (and me at times!) to say "no" to new feature requests from potential customers.
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...
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...
If people who have logged more than x times are 90% likely to upgrade, why spend any time on them?
Interesting insight with the "engagement wall" concept, but I wonder if following this idea means you spend more time in "viral" features without adding meat to your product basics. In the long run, you really want engaged customers rather than casual customers (unless perhaps you can monetize the casual users somehow).
I think the point is to add features to the part of the lifecycle where you're bleeding the most users.
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".
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".
I recommend a few tablespoons of salt with regards to this advice if you are a B2B Saas/have a sales team. First experience is definitely important, but features will always be something businesses will consider when deciding which product to go with.
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.
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.
Does an average web app really get 20% of visitors signing up, or are we talking about a subset here, such as web apps running a freemium model? If any of the (commercial) web apps I've worked on could get 20% of visitors to actively start a sign-up process and 80% of those to complete it, everyone involved would have been celebrating for weeks.
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.
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.
A 2% conversion rate is actually pretty good.
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.
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.
It's drop dead hilarious that he ends with a solicitation for contacts for his newsletter. I'd venture that his visit/signup/onboard curve is more severe than the one he shows.
So I get the takeaway to be: abandon all hope if you don't hit and capture that big, first-day spike. Just move on to the next thing.
Yep, unless you are planning on catering to the long tail from the beginning.
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.