By Jason Fried · world.hey.com · @jasonfried on X · LinkedIn
Jason Fried argues that how fast a product is built, how many commits or people went into it, and how many hours were spent are all development metrics about the work, not the product. These measures say nothing about fit, quality, clarity, usability, or how customers feel using it. He compares this to judging a restaurant by its kitchen activity rather than the meal served. The core point is that the making is connected to the thing made but is not the same, and the customer-facing result matters far more. For product teams, this is a reminder to evaluate outcomes rather than effort signals.
01Key takeaways
- Judge a product by what customers experience, not by how hard the team worked to build it.
- Treat commit counts, velocity, and hours as internal process signals, not measures of product success.
- Ask whether the product fits its users, is clear, and performs well before celebrating build speed.
- Keep the team's effort visible internally but do not let it substitute for outcome evidence.
- Use customer experience as the primary lens when reviewing progress on a product.
02Key sections
- Effort is not quality
- Speed, commit counts, headcount, and hours worked do not determine whether a product is better or worse. These are signals about the process rather than the product.
- Back of the house metrics
- Development metrics and work styles matter to the builders but are not inherently important to the people using the product. They describe the internal machinery.
- What actually matters
- Fit, quality, clarity, usability, utility, performance, and customer feeling are the attributes that define a product. Development metrics say nothing about any of them.
- The restaurant analogy
- Reviewing a restaurant by counting cooks, shift length, or orders fired tells you nothing about the meal. Product evaluation should work the same way.
- Kitchen is not the meal
- The making and the made thing are connected but distinct, and the made thing matters far more. The blueprint is not the building.
03From the post
“The speed at which a product is developed doesn't inherently make the product better or worse. The number of commits doesn't make the product better or worse. The number of people or agents working on it doesn't make it better or worse. The number of hours you’re pouring into it doesn’t make it better or worse. Working on a weekend,…”
Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.