Feature prioritization: deciding what to build first
The founder arrived at the kickoff with a spreadsheet. Forty-one rows, one feature each, every row flagged “must-have.” She was building a booking and payments tool for a small chain of pet-grooming salons, she had real demand, and she had a budget that covered maybe eight of the forty-one. When I asked which eight, she said all of them were essential. That’s the moment feature prioritization actually begins, and it’s the moment most founders flinch.
Feature prioritization is deciding which features to build first, and which to cut or defer, when you can’t build everything at once. Every guide on the first page of Google will hand you a scoring framework for it: RICE, MoSCoW, Kano, weighted matrices. Those frameworks are real and they work, but they were built for product managers who already have a product, usage data, and a team. As a non-technical founder at the start, you have a wishlist, a fixed budget, and no data yet. Your problem isn’t the math. It’s the flinch.
Why the frameworks don’t fix your real problem
A scoring framework takes a list of features and ranks them by some combination of value and cost. RICE, the method Intercom popularized, multiplies reach, impact, and confidence, then divides by effort. MoSCoW sorts everything into must-have, should-have, could-have, and won’t-have. They’re genuinely useful once you have the inputs they need.
The catch is that the inputs are the hard part, and at the start you don’t have them. Reach and impact are estimates of how many users a feature touches and how much it moves a metric. You have zero users and no metric history, so every number you plug in is a guess dressed up as arithmetic. The framework then launders your guess into a confident-looking score, and you make a six-figure build decision on a number you invented. That’s worse than no framework, because it feels rigorous.
So the real work happens before the matrix. Prioritization at the start is not a calculation. It’s a decision about what you’re willing to ship without. Until you’ve made that decision honestly, no framework will save you, and once you’ve made it, you barely need one.
The founder’s prioritization method
Here’s what we actually run with founders before anyone opens a scoring sheet. Four questions, asked of every feature on the list.
First: does this feature make someone pay, or make someone stay? Not “is it nice.” Not “would a user like it.” Does it cause a person to put in a card, or come back next week. The grooming-salon booking flow made owners pay because it replaced a phone-and-notebook system that lost appointments. The loyalty-points module did neither at launch. One was day-one; one could wait a year.
Second: if you removed it, would the core job break? Every product does one main job. For the salon tool, the job was “take a booking and get paid without a phone call.” Remove online payments and the job breaks. Remove the staff-availability calendar and the job breaks. Remove the customizable email receipts and the job is fine, the receipt is just plainer. Features that break the core job when removed are not negotiable. Everything else is.
Third: is the demand real, or is it the loudest customer? Founders consistently overweight the one client who emails three times about a specific feature. That client is not your roadmap. They’re one voice, often the least representative one, and building their pet feature first is how you end up with software shaped like your most demanding customer instead of your market. Ask how many people have asked, unprompted, for the same thing. One is noise. Eight is a signal.
Fourth: can it wait until users tell you? The cheapest feature is the one you don’t build because real usage made it obvious you didn’t need it. If a feature isn’t day-one and won’t break the core job, the right move is usually to ship without it and let actual users tell you whether it matters. They will, and they’ll be more honest than your spreadsheet.
Run those four questions and the forty-one rows sort themselves into three piles: build now, build later, and probably never. The founder with the grooming tool ended with nine “build now” features, not forty-one, and the nine were the ones that made owners pay. We shipped in ten weeks instead of eight months, and the loyalty module she’d marked must-have never got built, because once owners were live, none of them asked for it.
The forty-one rows, sorted
It helps to see the method run against real rows, because the abstract version makes every feature sound equally important and the concrete version doesn’t. Six of her items, and where each landed:
Online booking with live availability went to build-now. It made owners pay (it was the reason they’d switch off the phone) and removing it broke the core job. Card payments at booking: build-now, same logic, since “get paid without a phone call” was half the job. A staff calendar with per-groomer hours: build-now, because a booking that double-books a groomer is worse than no booking.
Then the line moved. Automated SMS reminders: build-later. Owners wanted them and they reduce no-shows, but the tool worked without them at launch, and we could see real no-show rates before spending on them. Branded, customizable email receipts: build-later bordering on never, because a plain receipt does the job and the customization was taste, not revenue. The loyalty-points engine: probably-never, the single most expensive item on the list, marked must-have on instinct, asked for by no actual salon owner once they were live.
The point isn’t that loyalty points are bad. It’s that the founder had ranked them with the same weight as getting paid, because a wishlist flattens everything to “want.” The four questions un-flatten it. They turn forty-one equal wants into nine things the product needs to do its job and thirty-two things that can prove they matter later.
Every yes is a no somewhere else
The reason prioritization is painful is that founders experience it as addition. Each feature is a thing they want, and cutting it feels like loss. The reframe that helps is to see prioritization as subtraction against a fixed number.
You have a budget. Whether it’s what it costs to build the app or the weeks of your one developer’s time, it’s finite, and it buys a fixed amount of build. Every feature you say yes to is a feature, or a week, you’ve said no to somewhere else. The loyalty module isn’t free even if you love it. It costs the onboarding flow you didn’t polish, or the three weeks you didn’t spend on the thing that actually makes owners pay. Once a founder sees the list as a budget being spent rather than a wishlist being granted, the cuts get easier, because now they’re trading, not losing.
This is also the discipline that keeps feature creep from eating the build. Creep happens when new features get added without anything getting removed to pay for them. A founder who prioritizes by subtraction has a built-in answer to the mid-build “can we also add” request: sure, and what comes out to make room.
There’s one more trap worth naming, because it catches sharp founders specifically. Some features get prioritized not for a customer but for an audience: the slick dashboard that looks good in a fundraising demo, the AI feature added because a board member asked whether you have one. Wanting to ship something credible to investors next quarter is a real pressure, and sometimes the demo feature is genuinely worth it. But run it through the same four questions, honestly. If a feature only makes an investor nod and never makes a customer pay or stay, it’s a marketing cost wearing a product costume, and it should be budgeted as one rather than smuggled to the top of the build list.
When the frameworks finally earn their place
None of this means RICE and MoSCoW are useless. It means they’re downstream tools, and you reach for them at the right moment, not the first one.
The moment is when you have users. Once your product is live and people are using it, you finally have the inputs the frameworks were designed for: real reach, observed impact, evidence instead of guesses. That’s when a scoring matrix stops laundering your guesses and starts organizing your evidence. A founder with three months of usage data and a backlog of forty requests should absolutely run RICE on them. A founder at kickoff with no users should run the four questions and resist the urge to dress a guess up as a score.
The arc is simple. Before launch, prioritize by judgment, against the job and the budget. After launch, prioritize by data, with whatever framework fits your team. The mistake is using the second method when you’re still in the first situation. This is the same discipline behind shipping a real minimum viable product and knowing where to spend the polish on a minimum lovable product: decide what the first version is actually for, and let everything else wait its turn.
How to say no without losing the customer
The last fear founders raise is that cutting features will cost them the customer who wanted them. Usually it won’t, if you handle the no well. “We’re not building that” lands badly. “That’s on the list, and here’s why it’s after the things that get you live faster” lands fine, because it shows the customer they’re in a sequence, not in the trash. People accept being later far more readily than they accept being ignored, and a founder who can explain the order of the build sounds like someone in control of it.
The grooming-salon founder still has that forty-one-row spreadsheet. Most of it is in the “later” and “never” columns now, annotated with which real customer asked and how many times. It turned out to be a better roadmap than the original, because every item on it had earned its place instead of starting there.
FAQ
What is the feature prioritization method? It’s the process of deciding which product features to build first, and which to defer or cut, when you can’t build everything at once. At the start, before you have usage data, it’s a judgment call against the product’s core job and your budget rather than a scoring exercise.
What are the 4 levels of prioritization? The most common four-level scheme is MoSCoW: must-have (the product breaks without it), should-have (important but not vital at launch), could-have (nice if there’s room), and won’t-have (explicitly out of scope for now).
What are the four methods of prioritization? Widely used methods include RICE (reach, impact, confidence, effort), MoSCoW, the Kano model (basic, performance, and delight features), and a simple value-versus-effort matrix. They work best once you have real usage data to feed them.
What is the main goal of feature prioritization? To spend a finite budget and timeline on the features that actually make a customer pay or stay, and to defer the rest, so the first version does its core job well instead of doing many things poorly.