Proposal: New Product Hunt scoring method

[hstove]

What is the problem you are seeing? Please describe.
Your Product Hunt score is based mostly on how well you launch. This incentivizes how well you can launch, but if you didn't get a great launch, you're stuck with a lower score until you re-launch again.

How is this problem misaligned with goals of app mining?
This doesn't support continuous improvement, which app mining should incentivize.

What is the explicit recommendation you’re looking to propose?
We're recommending two new metrics that factor into your Product Hunt score:

• Growth Score: based on the percentage of new upvotes you've received in the last month. If you had 100 upvotes last month, and 110 now, you'd get a growth score of 10%.

• Decay score: Your 'total upvotes' score, but with a monthly decay function of 90%. So if you have a total of 100 upvotes, and you launched 1 month ago, you have 90 total upvotes. The score is total_upvotes*0.9^months_since_launched.

** Describe your long term considerations in proposing this change. Please include the ways you can predict this recommendation could go wrong and possible ways mitigate.**
This encourages two things:

• Continuous promotion of your Product Hunt page, to get more upvotes every month.
• Incentivizing re-launching your app after roughly 6 months. Product Hunt requires significant changes in order to re-launch, so this incentivizes app makers to focus on big new features and product growth.

Additional context
We already have dry run results for what this algorithm looks like. In the public results spreadsheet, see the tabs for "April Dry Run" that include "New PH" scores.

[friedger]

This also gives new apps a boost on launch, which encourages new app developers to join the program.

[stackatron]

I'm proposing we do this for June scores.

[jyudkin1]

Apologize for typos and lack of clarity - Very long day!! (also much longer than I wanted, I typed one stream of thoughts)

Some issues and things to consider -

Growth Score: This then becomes a hustle score, has nothing to do with improvement or getting product market fit. This can be a function, but remember % increase will help users who launched with less fit on PH. User starting at 10 and jumping 10 votes, vs launching with 1000 and up 10.

If this becomes a meaningful way to improve ranking, incentives would make you want to launch with lower score, and increase over time vs optimal traction / score saturation.

Finally - Improvement of a product is not = more upvotes. I dont see a correlation of faster load times, or UI/UX improvements or wider browser compatibility to increase in upvotes naturally ( I am challenging whether or not this is the behavior of the PH community, I dont think so imo)

We've pushed a bunch of updates and improvements, and it doesn't seem to correlate (my past experience also confirms this anecdotally)

Lets also not forget that Launching on PH is like launching to the most willing group of people to try a new product and give feedback. It is all tech people, looking for new products, they know these are projects / ideas, literally the best group on the internet to launch to. PH = Early adopters willing to try, use, new and unfinished products.

Decay score: Seems like might be a bit of a challenge here for people focused on one problem / product. Totally get that we should be innovating - but I dont know if its good practice to swing for the fences every 6 months and decay at that rapid rate 10%. (dont you do this when things aren't working?) You should double, triple down on what works, full stop. Ride it until you growth slows.

Think about it - twitter has barely changed since launch. They just increased the character limit, added "photos" / Videos / etc... but really didn't have any of that stuff year 1 -3.....

Assuming an app launches with real Market Fit .... Engineering teams should be worrying about scale, debugging, fixing edge cases for browsers, etc. not pushing moonshot ideas / features.

I would hate to have to be forced to launch new BIG features and take focus away from existing features that need TLC.....

For example, forms.id has a lot of work to be done - should we build a totally new BIG feature or should we improve UI / UX and what is working? We have a lot to build, and worrying about launching something outside of our core product seems unhealthy.

So Decay makes sense, but what if everyone is focused on improving their product and not relaunching in 6 months ... do we all decay to zero in 12 months? 10% seems very aggressive here if this will be considered.

Finally - If you had a "less successful launch" - you likely will be working your tail off to nail your next one in 6 months (really short time in the grand scheme of things, we should be building lasting businesses and apps). This means testing with existing users, finding market fit, improving messaging, branding, features, and will likely be in a really good position to relaunch with the better (meaningful) iteration of your app.

Lets not think month to month - lets think years and decades, thats how long it will take to build this ecosystem.

[charlottelucyhall]

I'd tend to agree with jyudkin1 - I'm not sure I agree with continuously promoting PH to get upvotes. From my experience with PH which is fairly light (although I have used it intermittently for a few years), PH is geared around the launch - encouraging you to get the most upvotes for that day and week to be featured in the newsletters - once launched people voting on the platform move onto the next product.

Re-launching is a good idea but as Hank suggested - the product would have to have a significant new feature to be approved.

I wonder if there's another platform out there that looks at continuous improvement as opposed to one launch.

Saying that we worked really hard on our launch so 10% decay each month does seem quite a lot.

[jackveiga]

Think this is a good measure to implement. Have to agree that decay makes sense but 10% seems a bit extreme, although I do understand the logic behind growth 10% and decay 10% to try to reward both equally. Still, it's not entirely easy to grow on PH after the day that you launch, so it might make sense reward those that can grow but would not penalise the decay equally.

[GinaAbrams]

Thanks for the input @jackveiga @charlottelucyhall @jyudkin1 😃

Based on this feedback, we propose to do the following for next month:
Growth Score: based on the percentage of new upvotes you've received in the last month. If you had 100 upvotes last month, and 110 now, you'd get a growth score of 10%.

Decay score: Your 'total upvotes' score, but with a monthly decay function of 90%. So if you have a total of 100 upvotes, and you launched 1 month ago, you have 90 total upvotes. The score is total_upvotes*0.9^months_since_launched.

Going to close unless any other comments. We can continue to iterate on this in the future.

[jyudkin1]

@GinaAbrams What if it goes to zero? 10% would be a very aggressive and happen pretty quickly - not a problem if the intention is to force a second launch.

Would total_upvotes = current upvotes, mathematically account for PH growth / upvotes (growth metric)

Since total_upvotes is a moving number either decreasing, more likely increasing at a certain rate %

[GinaAbrams]

@jyudkin1 the intention is to incentivize launches every 6 months or so. Those can be cosmetic or UI improvements, but hopefully measure some indication of progress for the app. With this rate, apps will still receive ~50% of their score 6 months after launch.

Correct that Total_upvotes = current upvotes.