Stop Copying the Feature List: A Competitor Teardown and Positioning Playbook for Vibe Projects

The products, companies, and people in this guide's examples are fictional; any resemblance is coincidental. The method and checklists can be applied directly to your own real competitors.

First, the rule: a teardown's purpose is not to copy faster

The most common way to fail at a competitor teardown is not tearing down too little, but changing nothing afterwards. Many people spend a weekend copying a rival's feature list into a neat comparison table, and then keep doing exactly what they were doing before, copying whatever feature the rival ships next. Three months later, the product has neither become more like the rival nor more like itself. It has simply spent effort in both directions.

So this guide starts with a rule: the purpose of a teardown is not to copy faster, but to copy less, and copy more accurately. There is only one question to answer: what has the rival already proven, and at which point should you be different from it? Every teardown activity serves that question. Any material that cannot help answer it is noise, no matter how thorough it looks.

Step one: define the arena before choosing rivals

Before doing anything, write your arena in one sentence, in this form: "for whom, in what situation, solving what problem." In our fictional example, Lighthouse Notes is a notes tool "for independent developers, when writing technical documentation, to organize ideas quickly." If the arena is vague, the teardown will drift: you will list every "notes product" you can find, only to discover they do not serve the same people at all.

Once the arena is set, three to five rivals are enough; more than that prevents real depth. Choose three types: direct rivals competing for the same users; indirect rivals solving the same problem in a completely different way; and the "substitute in the user's mind," meaning what users actually use when they do not use you. Very often that is not a product at all, but a spreadsheet, a chat group, or simply "deal with it later." Our fictional Lighthouse Notes chose three: Whale Notes, the direct rival with the fullest feature set; Paper Room, the indirect rival built around a handwriting and paper metaphor; and "making do with an Obsidian folder," the substitute in users' minds.

This selection method has one great benefit: it forces you to admit that your real rival may not be the big company you imagined. Many small products do not die because a giant beat them, but because users discovered that "making do works fine," and never came back. Putting the make-do option on the teardown list is the single most important step in this whole guide.

Step two: tear down the public surface, never guess at internal numbers

Independent developers have no budget for industry reports and no channel to a rival's internal data. The good news is that the public surface already offers more than enough, all of it free. In priority order: the pricing page, the changelog, the help documentation, job postings, and negative user reviews.

The pricing page tells you what the rival actually makes money from. Look at three things: what the free tier blocks (features, quantity, or number of collaborators), what differs between paid tiers (which usually reveals what the rival believes users will pay for), and whether there is an annual discount (the deeper the discount, the more it cares about long-term retention). In Lighthouse Notes' fictional teardown, Whale Notes' free tier blocks multi-device sync, which signals that it bets on "multiple devices" as its paid hook; Paper Room's free tier barely blocks features and only restricts export formats, signaling that it bets on "the longer you use it, the harder it is to leave."

The changelog tells you what the rival has been anxious about lately. Three straight months of sync fixes means sync is its weak spot; three straight months of AI features means it is chasing a trend, and possibly that its core features have nothing new to say. Help documentation tells you where it assumes users will get stuck: the places documented in most detail are usually the places the product is hardest to use. Job postings tell you what it plans to staff up for next: a sudden hiring wave in sales suggests a move to enterprise markets; a sudden hiring wave in compliance suggests entry into a compliance-sensitive industry.

Negative reviews are the most underrated material. Go to app stores, social media, and forums, and group a rival's one-star and two-star reviews by theme. You will end up with a list of "the three things users complain about most." That list is worth an order of magnitude more than a feature comparison table. Features can be copied; pain points cannot be copied away. Pain points are the reason users will pay you. In Whale Notes' fictional negative reviews, the top three complaints are: sync occasionally loses data, the mobile app opens too slowly, and exports come out in a mess. If your product can simply "not get these three things wrong," you already have differentiation, without building ten extra features.

Step three: build a comparison table that only records differences

The material gathered so far should land in a table, but the table has one hard rule: record only differences, never common ground. If every rival supports Markdown, folders, and search, those three rows do not belong in the table. Common ground is the price of admission; writing it down only tricks you into thinking you are about as good as your rivals. What belongs in the table is what each rival uniquely has, or uniquely lacks.

Lighthouse Notes' fictional table has only four rows: Whale Notes has full-platform sync but a slow mobile app; Paper Room has the handwriting feel but no collaboration; the make-do option costs nothing but offers no reminders or version history; Lighthouse Notes itself currently has only "opens fast, writes fast." Once the table is done, the conclusion almost writes itself. Lighthouse Notes should not try to match full-platform sync — that is Whale's home turf, and matching it would not win. It should push "opens fast, writes fast" to the extreme, and add version history, because that is something the make-do option cannot offer, and something users never want to lose again once they have lost data.

The table has another use: whenever you consider adding a feature, first ask whether that row would appear in the comparison table. If the answer is no, because rivals have it too, then the feature is probably just admission price, and its priority should drop. If the answer is yes, and only you would have it, then it deserves a slot in the next release. Much of small-team feature bloat happens because nobody ever asked this question.

Step four: turn the conclusion into one positioning sentence

The teardown ends with one positioning sentence, in this form: "For (whom), in (what situation), better than (whom) at (what)." Lighthouse Notes' fictional positioning sentence is: "For independent developers, when inspiration strikes, faster than Whale Notes at writing it down, and never losing it." It mentions no feature names, only what the user feels in that moment: speed, and never losing work.

Once written, run a reverse test: read it to a friend who does not know your product, and ask which product they think it describes. If they immediately name a big company's product, your sentence is not specific enough. If they understand nothing at all, it is too abstract. A good positioning sentence should make someone say "oh, I think I need this," not "oh, I think I have seen this."

There is a second test: the sentence must help you say no. When Whale Notes ships a very cool collaborative whiteboard, can the Lighthouse Notes team look at the positioning sentence and say "that is not our business"? If yes, the sentence is alive. If every rival launch forces you to reopen the positioning discussion, the sentence is dead, and the teardown was wasted. The ability to say no is a small team's scarcest resource, and the biggest output of a good teardown report is the confidence to say it.

Step five: set a one-hour monthly review rhythm

Rivals move, and teardown reports expire. But independent developers cannot watch rivals every week, so the review has to become a fixed rhythm: one hour a month, doing just three things. First, scan rivals' changelogs for any signal of "two straight months talking about the same thing." Second, scan newly added negative reviews for emerging pain themes. Third, hold your positioning sentence up against the past month and ask whether you drifted away from it.

During review, resist one impulse: the urge to follow every new feature a rival ships. Before following, go back to the table and ask two questions: does this feature address one of the three most-complained-about things? Does it strengthen my positioning sentence? If both answers are no, write it down but do not build it. Much small-product feature bloat does not happen all at once; it happens one "looks nice" feature per month, until six months later the product is unrecognizable.

Finally, one red line deserves its own paragraph. Tear down public material, but do not touch what you should not touch. Do not buy a rival's internal data, do not use scrapers to bypass its anti-scraping limits for bulk collection, do not pose as a user to extract internal information from its support team, and do not lift its copy, interface, or brand elements wholesale. Lawful, above-board teardown is already enough to make good decisions. The small extra information gained by crossing the line is never worth the risk it brings. Your product should win on sharper positioning, not dirtier methods.

A checklist to tick off when the teardown is done

Is the one-sentence arena written? Are three to five rivals chosen, including the make-do option? Have the pricing page's three paid hooks been examined? Have the last three months of changelog themes been summarized? Are the three most-complained-about things from negative reviews listed? Does the comparison table record only differences, with common ground removed? Is the positioning sentence written and reverse-tested? Is the monthly review scheduled on a specific day? If all seven questions have answers, the teardown is complete. Whichever question has no answer is the homework to do next, not an excuse to copy ten more features.

A one-page teardown template: fill it in and you will not drift

Method needs a fixed format on paper, or every teardown will produce something different and incomparable. Below is the one-page template our fictional Lighthouse Notes team actually uses. You can copy its structure and swap in your own content. Field one is the arena sentence, no more than thirty words; if it does not fit, the arena is not thought through yet. Field two is the rival list, three to five names, each followed by "which of my user groups it competes for"; any rival where you cannot write that sentence gets deleted. Field three is the pricing-page teardown: what the free tier blocks, what differs between paid tiers, and how deep the annual discount runs. Field four is the changelog theme: the one thing the rival kept talking about over the last three months. Field five is the top three complaints, each followed by "can my product avoid getting this one wrong?" Field six is the differences table: differences only, common ground deleted. Field seven is the positioning sentence: for whom, in what situation, better than whom at what. Field eight is the "will-not-build list": three features this teardown explicitly decides not to chase.

The will-not-build list deserves emphasis, because it is the most easily skipped and most valuable field in the whole report. A small team's time is never enough, and deciding what not to build protects the roadmap more than deciding what to build. Lighthouse Notes' fictional will-not-build list contains three items: no collaborative whiteboard to match Whale Notes, because the positioning sentence contains no collaboration; no handwriting brush to match Paper Room, because it would dilute the core feeling of "opens fast, writes fast"; no full-platform real-time sync, because that is the rival's home turf and the return on investment does not work out. Whenever someone in a meeting proposes "the rival shipped this, should we build it too," the team does not need to argue from scratch. It opens the will-not-build list: if the item is there, it waits; if it is not there, it gets discussed against the comparison table's standard.

One usage detail for the template: each review updates only three fields — the changelog theme, the top three complaints, and the will-not-build list. The other fields stay untouched unless the arena itself changes. This keeps review cost under one hour, and makes versions comparable over time: you can see clearly that three months ago users complained most about sync, and three months later about export formats, and that shift is itself a weather vane for how the rival's product is evolving. A teardown without a fixed template starts from zero every time; a teardown with a template iterates on the previous version, and gets sharper each round.

Three crash scenes: the easiest teardown traps

The first crash scene is treating a rival's roadmap as your own to-do list. In the fictional case, the Lighthouse Notes team spent two weeks reading Whale Notes' changelog daily, writing down every new feature, and ended with twenty-seven to-dos. On a calm review, twenty of the twenty-seven had nothing to do with the positioning sentence; they were there purely because they "looked cool." Worse, while chasing those features, the team slowed down its original advantage of "opens fast": adding an unwanted collaborative cursor cost four hundred milliseconds of startup time. The lesson: a rival's changelog is intelligence, not tasks. Intelligence must first pass the positioning sentence's test; whatever fails that test does not get built, no matter how cool it looks.

The second crash scene is looking only at the head, never the middle. Many teardowns stare at the industry leader, assuming the leader represents the direction. But the leader's playbook is built on problems it has already solved: brand, distribution, an installed base. It can win on scale. Copying its playbook means attacking its strengths with your weaknesses. What is truly worth learning often hides in mid-tier products: those with small user bases but one feature done extremely well. In the fiction, Paper Room has less than a tenth of Whale's users, yet its handwriting experience is loved deeply by a small group of heavy users. What Lighthouse Notes learned from Paper Room was not "build handwriting," but the strategy itself: make one single point so good that a small group of people cannot leave. A teardown list without mid-tier products has a crippled field of view.

The third crash scene is treating a low price as positioning. Following a rival's price cut with your own price cut, or matching a rival's free tier with your own free tier, is the most expensive way for a small team to follow. Price is never positioning itself; it is only one expression of positioning. If Whale Notes cuts its price, it may be lowering the trial barrier to push into enterprise markets. If you lack the same strategic goal, matching the cut only burns your own margin, and attracts users who are price-sensitive and picky about features. The correct response starts with a question: what goal sits behind the rival's price cut? Are my users leaving because of price, or because of something else? If the answer is the latter, cutting price is not only useless, it tricks you into feeling you have "responded" to the rival when you have solved nothing.

Put these three traps together with the five-step method, and the complete teardown posture becomes clear: one hour a month, watching the public surface, producing one page, guarding the positioning sentence and the will-not-build list. If one hour a month is impossible, make it one hour a quarter, but never let it become a one-off campaign done only when remembered. Regularity matters more than intensity, because rivals keep moving, and your understanding must keep updating too. One day you will notice that three months have passed without any rival launch knocking you off rhythm. That is when teardown has truly worked: not by making you run faster, but by stopping other people's rhythm from running you.