Heart And Star

A Practical Guide to the Heart And Star Framework

I've been using the Heart And Star framework for about four years now, mostly with small product teams who kept building features nobody asked for and wondering why retention tanked. The short version is that it's a dual-axis evaluation method for prioritizing work. You score every initiative on "heart" — does this solve a real human problem worth solving? — and on "star" — does this give the team a sustainable advantage or learning that compounds over time? Most teams I talk to only use one side of the axis. That's why they burn out or ship junk. The framework originated from Lean Startup and Jobs-To-Be-Done principles but was formalized enough to become something you can apply without consulting a PhD. The core insight most people miss is that "heart" and "star" are not independent. A feature can have strong heart — people genuinely need it — but terrible star potential, meaning it burns through engineering velocity with no compounding return. Conversely, something with high star but zero heart becomes an optimization exercise that nobody outside the team cares about. You want both. The sweet spot is where human utility and team leverage overlap. I ran into this exact problem last year when a health tech startup tried to build a symptom-tracking widget. Everyone on the heart axis loved it. User interviews were glowing. But when we plotted it against star, it collapsed. The tracking data never connected to anything else in the product. It was a standalone feature that required custom backend infrastructure for every new tracker type. We ended up scoping it down to a reusable pattern where all tracking widgets shared a single pipeline. Took two weeks instead of six, and the data actually fed into the recommendation engine. That's the difference between picking one axis and using both.

How to Score Heart and Star Properly

The scoring isn't a mystery but it does require discipline. Here's the mechanics: Heart scoring (1–5): Start by writing down the exact job the user is hiring your product to do. Not what they say they want — the actual job. If you can't complete the sentence "When ______ happens, the user hires our product to ______," you're not ready to score heart. A score of 1 means you're guessing. A score of 5 means you've observed at least ten real users doing this job and can describe the moment of frustration precisely. Interview data, support tickets, and session recordings all count. Vanity metrics don't. Star scoring (1–5): This is harder and where most people fumble. Ask these three questions for each initiative: Does this create reusable knowledge or infrastructure? Does it improve the team's ability to ship the next thing faster? Does it differentiate us in a way competitors can't copy in under six months? Score based on answers. If the answer to all three is yes, that's a 5. If the answer is "maybe, possibly, depends," that's a 3. There is no shame in a low star score — it just means you should either pair it with something higher-star or not build it yet.

The combined score lives on a simple 2x2 matrix. Top-right quadrant (both 4–5) gets immediate build time. Top-left (high heart, low star) gets held as a research project — it's valuable but premature. Bottom-right (low heart, high star) is usually a technical investment that needs a product wrapper. Bottom-left gets cut. I know people resist cutting things. They look at a 2/2 project and feel guilty. Don't. You have limited capacity and every "yes" is a "no" to something else.

Common Mistakes That Waste Weeks

The first mistake is scoring heart from internal assumptions. I've seen teams give a feature a 4/5 on heart because the CEO thought it was important. That's not heart scoring. That's hope scoring. Go watch actual people interact with the problem. It takes thirty minutes and it changes everything. The second mistake is ignoring star entirely and treating the framework as just a prioritization checklist. That defeats the purpose. The whole point is that star forces you to think about leverage. If you're not asking about compounding returns, just use a simpler method like RICE or WSJF. The third mistake is treating scores as permanent. They aren't. A feature that scored 2/3 on star when you first scoped it might score 4/5 once you realize the data layer you built for it applies to three other roadmap items. Update your scores when new information arrives. Stale scores are worse than no scores.

Heart And Star in Practice: A Real Example

Last quarter my team evaluated a billing redesign. Heart score was a solid 5 — people were actively churning over billing confusion, and support tickets were the top category. Star score initially looked like a 2 because it seemed like a one-off refactor. Then we noticed the billing system touched four different services and any change to it required coordination across three squads. Fixing it properly would mean building a unified pricing engine that every service could call. That jumped the star score to a 4. We moved it to the top of the roadmap. It took twelve weeks instead of the four we'd originally estimated, but it removed a coordination bottleneck that had been slowing every other feature for months. That's the kind of hidden leverage heart-and-star is designed to surface. There are edge cases where the framework breaks down. It doesn't handle compliance-driven work well — legal requirements aren't about heart or star, they're about obligation. In those situations, I recommend running a parallel track where compliance items bypass the matrix and go straight to a separate resource allocation pool. Mixing them into the same scoring system distorts both. Also, the framework assumes you can observe real user behavior. If you're building something in a domain where users can't articulate their needs — some B2B enterprise software, certain deep tech areas — the heart score becomes unreliable. In those cases, pair the framework with a discovery sprint before you do any scoring. One more thing. Don't let the matrix become a bureaucratic exercise. I've seen teams spend more time arguing about whether a feature is a 3 or a 4 than the feature is worth. If two people disagree on a score by one point, pick the higher one and move on. The framework is a decision aid, not a tribunal. The goal is shipping better things faster, not achieving perfect scores on paper.