Why each criterion receives its specific weight — and where the weights came from. Why each criterion receives its specific weight — and where the weights came from. The weights in the Proof of Usefulness algorithm were not assigned by committee consensus, philosophical preference, or gut feeling. They reflect the consistent findings of startup failure research — particularly the question of which early signals most reliably predict whether a project creates lasting value. This is what that research shows. Real-World Utility: 25% (highest weight) Does this solve a genuine problem? Is the solution practical and immediately usable? Does this solve a genuine problem? Is the solution practical and immediately usable? This is the foundational question. A project can have perfect execution, massive reach, and innovative technology — and still fail completely if it does not address a problem that real people actually experience. The 25% weight reflects a harder truth than it first appears: utility is not merely important, it is load-bearing. Every other criterion in the framework depends on it. Without genuine problem-solution fit, strong traction proves only that you are good at generating interest. Strong reach proves only that you are good at distribution. Strong technical innovation proves only that you can build impressive things nobody needs. Utility is not the beginning of a project's story. It is the precondition for that story having any meaning. Evidence of Traction: 25% (tied for highest weight) Can you prove people are using this? What independently verifiable signals exist? Can you prove people are using this? What independently verifiable signals exist? Traction shares the highest weight because it performs a specific function that utility scoring alone cannot: it converts subjective assessment into objective evidence. Any project can claim strong utility. Traction is where those claims meet the verdict of the market. Users either return or they do not. Revenue either exists or it does not. Communities either self-organize around the product or they do not. The pattern is consistent in startup failure research: early retention and organic growth are among the strongest predictors of survival. Projects where users return after the initial curiosity fades — and where new users arrive through recommendations rather than paid acquisition — demonstrate the compounding dynamics of genuine utility finding its audience. Audience Reach & Impact: 20% How many people genuinely benefit? What is the growth trajectory? How many people genuinely benefit? What is the growth trajectory? Reach amplifies utility but does not create it. The 20% weight positions reach as consequential without making it primary. Why does reach matter independently? Because impact scales. A solution that helps 10,000 people creates more total value than a functionally identical solution that helps 100 people — assuming the utility is real in both cases. Scale is not vanity; it is the multiplication of genuine benefit. The critical nuance is the distinction between reach and impact. A project with 100,000 registered accounts and 400 weekly active users has reach. A project with 5,000 registered accounts and 4,200 weekly active users has impact. Proof of Usefulness scores impact. Technical Innovation and Stability: 15% Is this technically novel? Does it operate reliably? Is this technically novel? Does it operate reliably? This criterion scores a deliberate tension. Innovation without stability frustrates users into abandonment. Stability without innovation exposes projects to commoditization. The 15% weight reflects that both matter — and that neither alone is sufficient. The stability half of this criterion is concrete: users will not build critical workflows around tools they cannot depend on. Reliability is not a differentiator — it is the prerequisite for any other differentiation to matter. The innovation half is more nuanced. "Technical innovation" does not require inventing new algorithms. Vercel did not invent edge computing. GitHub did not invent version control. The innovation is often in interface, accessibility, or integration — making genuinely powerful capabilities available to people who previously could not access them. Market Timing & Relevance: 10% Is this addressing a current need? How does it fit the competitive landscape? Is this addressing a current need? How does it fit the competitive landscape? Timing receives a deliberately modest 10% weight because it is the factor founders have least control over. Bad timing can doom excellent execution; good timing cannot rescue weak utility. Penalizing teams heavily for circumstances outside their control would be both unfair and analytically counterproductive. The more important use of this criterion is diagnostic rather than punitive. A project consistently scoring poorly on timing should prompt a genuine strategic question: Is the market not ready? Or are we mistaking poor utility for poor timing? "We were too early" frequently means "users did not find sufficient value." The distinction matters. Functional Completeness: 5% (lowest weight) Does this actually work, right now, for real users? Does this actually work, right now, for real users? The 5% weight is the most frequently misunderstood element of the framework. It is not a statement that working software is unimportant. It is a statement that working software should be the baseline expectation, not a competitive advantage. Every project should ship functional implementations. A scoring system that heavily rewards meeting minimum standards would be rewarding mediocrity. The low weight serves two narrower purposes: penalizing projects that cannot ship working implementations, and providing a modest boost for exceptional quality. Functional completeness is the entry requirement. It is not the destination. Reading the weights together The weights encode a specific theory of what makes digital projects valuable and durable: 50% of the score comes from utility and traction combined — solve real problems, then prove that people actually use the solution. This is the irreducible core. Nothing else compensates for weakness here. 20% comes from reach — scale genuine utility to more people. 15% comes from technical quality — build something novel that works reliably enough for users to depend on. 10% comes from timing — launch when the conditions favor adoption. 5% comes from completeness — ship things that work. In that order. Not the reverse. This is not philosophy. These are patterns. This is not philosophy. These are patterns. This is not philosophy. These are patterns. This is not philosophy. These are patterns. Sources Sources https://www.cbinsights.com/research/report/startup-failure-reasons-top/https://www.bls.gov/bdm/bdmage.htmhttps://www.bls.gov/opub/ted/2024/34-7-percent-of-business-establishments-born-in-2013-were-still-operating-in-2023.htm https://www.cbinsights.com/research/report/startup-failure-reasons-top/ https://www.cbinsights.com/research/report/startup-failure-reasons-top/ https://www.bls.gov/bdm/bdmage.htm https://www.bls.gov/bdm/bdmage.htm https://www.bls.gov/opub/ted/2024/34-7-percent-of-business-establishments-born-in-2013-were-still-operating-in-2023.htm https://www.bls.gov/opub/ted/2024/34-7-percent-of-business-establishments-born-in-2013-were-still-operating-in-2023.htm T﻿his post was AI assisted based on exclusive content from internal HackerNoon meetings, documents, code, discussions, and product development workflows for Proof of Usefulness. It was edited by HackerNoon staff. If you are interested in trying out HackerNoon's beta tool to turn your existing Slack, GitHub, Zooms, and more into quality public posts, book a business blogging meeting. T﻿his post was AI assisted based on exclusive content from internal HackerNoon meetings, documents, code, discussions, and product development workflows for Proof of Usefulness. It was edited by HackerNoon staff. If you are interested in trying out HackerNoon's beta tool to turn your existing Slack, GitHub, Zooms, and more into quality public posts, book a business blogging meeting. T﻿his post was AI assisted based on exclusive content from internal HackerNoon meetings, documents, code, discussions, and product development workflows for Proof of Usefulness. It was edited by HackerNoon staff. If you are interested in trying out HackerNoon's beta tool to turn your existing Slack, GitHub, Zooms, and more into quality public posts, book a business blogging meeting business blogging meeting .

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

This post provides insights into new product. 

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Proof of Usefulness Weight Distribution

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Everything You Need to Know About HackerNoon’s Proof of Usefulness Hackathon

The Noonification: How Often Do NFTs Pass The Howey Test? (1/13/2023)

Darwin's Hybrid Intelligence to Align AI & Human Goals for Startups & VCs

The Noonification: White Man (11/26/2022)

The Noonification: The Metaverse is a Sh*tshow (11/2/2022)

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

Everything You Need to Know About HackerNoon’s Proof of Usefulness Hackathon

The Noonification: How Often Do NFTs Pass The Howey Test? (1/13/2023)

Darwin's Hybrid Intelligence to Align AI & Human Goals for Startups & VCs

The Noonification: White Man (11/26/2022)

The Noonification: The Metaverse is a Sh*tshow (11/2/2022)

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps