How should a SaaS startup decide which features of an established competitor to match?

Illustrative situation: a support-software startup fills in its fourth security questionnaire of the month. The sales lead forwards a list of “they have it, we don’t” items from calls and RFPs, 30 of them by now. The roadmap for the next 2 quarters is turning into a copy of the incumbent. The scene is invented. It shows the decision this guide helps with: which gaps to close, and which to leave open on purpose.

Humbleteam, a digital product design agency, publishes this guide. It covers five decisions a missing feature can get, a triage sheet, decision rules, how small a match can be, an invented worked example and how to answer a buyer about a gap you will not close. Sources are described as of November 11, 2026.

Why is feature parity the wrong goal?

The incumbent’s feature list was not built for your buyer. Clayton Christensen, Michael Raynor and Rory McDonald wrote in Harvard Business Review that incumbents improve products for their most demanding customers and exceed the needs of some segments. Their offerings often overshoot what less demanding customers require, which leaves room for a “good enough” product. That theory is about disruption, and not every startup is on that path, but the narrower point holds: the incumbent having a feature does not prove your buyer needs it.

Features also cost more than their build time. Jakob Nielsen wrote for Nielsen Norman Group (NN/g) that feature interactions grow by the square of the number of features. Des Traynor of Intercom lists “our competitors already have it” among the arguments used to sneak features into a product, and answers: “That doesn’t mean it’s a good idea.”

Still, some gaps do lose deals. The work is finding out which.

Which five decisions can a gap get?

Match: build the smallest version that removes the objection. Beat: build it and be clearly better on what buyers compare. Route around: do the same job another way, through an integration, an import or a simpler flow. Defer: not now, with a review date and a trigger. Decline: not planned, with an honest answer ready. An import counts as a route when the gap is really about moving data in, and our guide to switching costs and migration UX covers that design.

Noriaki Kano’s model helps separate match from beat. NN/g’s summary of prioritization methods describes Kano’s must-be items as basics users assume exist: having them adds little satisfaction, but without them customers are disproportionately dissatisfied. Performance items raise satisfaction in proportion to the investment. Users may not even notice when attractive items are missing. A must-be gap is a candidate to match, a performance gap where you can pull ahead is a candidate to beat, and an attractive gap is a weak reason for a parity sprint.

Categories move over time. A 2013 review of Kano research by Lars Witell, Martin Löfgren and Jens Dahlgaard reports Kano’s finding that the TV remote control was an attractive attribute in 1983, a one-dimensional (performance) one in 1989 and a must-be in 1998. The authors add that evidence for this life cycle is still limited. So give every decline a review date.

What goes on the triage sheet?

One row per gap. Merge duplicates first: “SSO,” “SAML” and “log in with our company account” are one row.

Evidence strength, in our definitions: strong means a buyer named the gap as the deciding reason, or a security review failed on it. Medium means it came up in several sales calls but never as the reason. Weak means one person, one checklist row or a guess from inside the team. The column plays the role NN/g gives the confidence score in the RICE method: how much validation sits behind an estimate. Deciding reasons come from buyers, not reps; our guide to running win-loss interviews covers how to get them.

The Kano questionnaire, as the same review describes it, asks about each feature twice: with it present and with it absent. On a sales call that becomes “How would you feel if the product had this?” and “How would you feel if it did not?” A buyer who expects it and could not buy without it has named a must-be.

Which rules decide each gap?

Write the thresholds before you look at the rows, so the loudest gap does not set them. The numbers below are examples. Set your own from your deal volume.

Basecamp’s Getting Real says the team’s first answer to a feature request is “not now,” and a request that keeps coming back earns a deeper look (Start with no). NN/g warns that without a clear time box, teams overload the must-haves. A defer needs a date, or nobody comes back to it.

How small can a match be?

A match only has to remove the objection, so it can be much smaller than the incumbent’s version. Write the objection in the buyer’s words, then the smallest version that answers it, then the check.

• Objection: “Your product fails our security review because it has no single sign-on.”
• Smallest version: login through the buyer’s identity provider, a setting that requires it for every user, and a setup an IT admin can finish without a call. Automatic user provisioning waits.
• Check: the next 5 security reviews pass the single sign-on row. If a different row fails instead, such as provisioning, it becomes its own gap on the sheet.

If the objection survives the release, the gap was standing in for something else, often trust or switching risk. Recode it rather than extending the feature.

Illustrative worked example: a support inbox against a help desk suite

Everything here is invented. The startup sells a support inbox to teams of 50 to 500 seats; the incumbent is an established help desk suite. Over 2 quarters the startup lost 14 deals to the incumbent, worth about $290,000 in annual contract value. The team pulled every “they have it, we don’t” item from loss notes, call notes and 6 RFPs, merged duplicates and ended with 30 gaps. One deal can name more than one gap.

The result: 3 match, 2 beat, 6 route around, 7 defer and 12 decline (3 + 2 + 6 + 7 + 12 = 30). Seven of the 12 declines appeared only as RFP checklist rows. One came from a single prospect that wanted on-premises hosting.

Single sign-on meets the match rule twice. Buyers found the incumbent’s reports slow to set up, so the startup ships ready-made reports instead of a report builder. The phone channel’s job is to see calls in context, so an integration with the buyer’s existing phone system covers it, if 3 buyers confirm that in test calls. Multi-brand help centers get a review next quarter, or sooner after 3 lost deals in the target segment.

The last row shows why the sheet counts lost deals. By RFP rows, custom ticket states outrank single sign-on, 5 to 4. By lost deals, it is 0 against 5. No result is claimed; the team re-sorts the sheet in one quarter.

How do you answer a buyer about a gap you declined?

Say no plainly, name the job, and offer a route if one exists. Do not give a roadmap date nobody has committed to, or mark “partial” on an RFP row you do not support. In our view a plain no costs less trust than a missed promise.

For a declined gap: “No, we don’t support custom ticket states. Teams track stages of work with tags and saved views, and we can show you a setup. If custom states are a hard requirement, we may not be the right fit today.”

For a deferred gap: “Not today, and it is not on a dated plan. We review requests like this every quarter, and yours is logged with your use case.”

On an RFP, write “Not supported” plus one line on the route, and log the row on the triage sheet for the next review.

Where does this method fail?

• Compliance and procurement must-haves. If a buyer’s security or legal team requires a control, no integration or simpler flow replaces it. Match it, or stop selling to that segment for now.
• One loud prospect. Traynor calls the request from a customer threatening to quit “feature blackmail.” One account is a defer at most, unless it is your whole segment.
• Copying what the incumbent’s own users ignore. You cannot see their usage data. The often-quoted claim that 64% of features are rarely or never used comes from a 2002 conference keynote, and Mike Cohn, after checking with the Standish Group, reported that it rested on four internal applications. It is not a benchmark. Ask your buyers the two Kano questions instead.
• Counting checklist rows instead of lost revenue. An RFP may be written around the product the buyer already knows, so weigh each row by the lost deals behind it.
• Small numbers. 14 lost deals show patterns, not rates, and the thresholds here are our examples, not standards.
• Other causes. A win-loss study may show that price, sales process or switching risk mattered more than any gap.

What can you produce now?

1. A merged list of every “they have it, we don’t” item from the last 2 quarters.
2. A triage sheet filled from lost deals, not opinion.
3. Written thresholds for the five decisions, agreed before the sort.
4. For each match: the objection, the smallest version, the check.
5. A review date and a trigger for each defer.
6. A written answer for each decline, ready for sales and RFPs.

Then pick the first match and write down which security review or lost-deal reason it should clear.