The most common and most expensive mistake in patent drafting. And you will never know it happened until it is too late.
Read the claims in your most recent patent. Not the abstract. Not the summary. The actual claims — the numbered paragraphs at the end that define what you own.
Now ask yourself: do those claims describe your product, or your competitor’s product?
If the answer is your product, you have an expensive diary entry. Not a business asset.
The Default Process
Here is how most patents get written.
The inventor — usually the CTO or a lead engineer — sits down with the patent attorney. They describe what they built. The architecture. The data flow. The algorithm. The manufacturing process. The specific implementation decisions they are proud of.1
The attorney listens, takes notes, and drafts claims that describe what was just explained.
The claims read on the company’s own product. They describe the company’s own architecture, the company’s own data pipeline, the company’s own manufacturing line.
The patent issues. Everyone celebrates. The plaque goes on the wall.
And the patent is commercially worthless.
Why This Happens
It happens because the attorney is doing exactly what they were asked to do.2
The inventor described what they built. The attorney wrote claims around what was described. Nobody in the room asked the question that actually matters:
What does the competitor’s product look like?
Not your product. Theirs.
A patent does not exist to document what you built. It exists to constrain what your competitor can build. If the claims describe your implementation — your specific database schema, your specific sensor configuration, your specific API architecture — then a competitor who builds something functionally equivalent but structurally different walks right past your patent.3
They compete with you. They take your customers. They sell the same solution. And your patent does not apply to them, because their implementation is different from the one your claims describe.
The patent was never pointed at the right target.
A Patent on Your Product vs. a Patent on the Problem
Think about it this way.
You solved a problem. Your competitor needs to solve the same problem. The question is: did you patent your specific solution, or did you patent the problem itself — at the level where every reasonable solution falls within your claims?
Edison did not patent a light bulb. Twenty people had patents on light bulbs before him. His patent was on the carbon filament — the specific technical breakthrough that made incandescent lighting practical. Every competitor who wanted to build a commercially viable light bulb needed that filament. The patent sat on top of the bottleneck.
If Edison had patented “a glass enclosure with a wire connected to an electrical source,” the claims would have described his product. And every competitor would have designed around them.
The difference between a patent that changes competitor behavior and a patent that sits in a drawer is almost always this: does the claim describe the implementation, or does it describe the constraint?
How to Spot It in Your Own Portfolio
Pull up any patent in your portfolio. Read Claim 1 — the independent claim. Ask these questions:
Does the claim describe steps or components that are specific to your implementation?
If the claim recites your specific database structure, your specific communication protocol, your specific manufacturing sequence — it is an implementation claim. A competitor using a different database, a different protocol, or a different sequence is not infringing. They are competing with you freely.
Could a competitor solve the same problem a different way and avoid ANY (just one) element in the claim?
If yes, the claim is a speedbump, not a wall. Patents only have value when they cover the best way to solve a problem — the way competitors must use. A patent on one approach among several equivalent options is a patent on nothing.
Does the claim describe what the end user does, or what the product does?
A heat-moldable shoe insert where the claims describe the consumer heating it, molding it, and inserting it — the infringer is the customer, not the competitor. A software patent where the claims describe steps performed by the user in a browser — the infringer is every person who visits the website. Are you going to sue your own customers? Your attorney wrote claims they could get allowed. Whether you could ever enforce them was not their problem.
Can you name the specific competitor whose product infringes this claim?
Not “someone might infringe this someday.” A specific company. A specific product. Today. If you cannot point to a real product on the market and say “that product performs every element of this claim,” then you do not know whether the patent has value. You only know it was granted.
The Attorney Cannot Fix This
This is not an attorney competence problem. It is a structural problem.
The attorney’s input is whatever the inventor tells them. If the inventor describes their own product, the attorney writes claims on their own product. The attorney has no independent knowledge of the competitive landscape. They do not know what your competitors are building. They do not know which features matter commercially. They do not know which technical approaches a competitor cannot avoid.
And they are not going to conduct that research, because it is not what they are paid to do. Their job is to draft claims that the patent office will allow. Claims that read on the inventor’s disclosure are the fastest path to allowance — because the disclosure provides the support the examiner requires.
The incentives all point in the same direction: describe what you built, draft claims around it, get the patent allowed, send the invoice.
Nobody in that process asked whether the claims would ever matter outside the four walls of the patent office.
What the Competitor’s Attorney Sees
Here is the part that should keep you up at night.
Your competitor has a patent attorney too. And when your patent publishes — which it will, eighteen months after filing — their attorney reads it.
If the claims describe your specific implementation, the competitor’s attorney does a quick analysis and tells their client: “This patent does not cover our product. Their claims describe their architecture, not ours. We are clear.”
The competitor keeps building. Keeps selling. Keeps taking market share. Your patent did not change their behavior by one degree.
Worse: your patent publication taught them exactly how your product works. The detailed description — the part your attorney needed to support the claims — is now a technical manual available to anyone with a search engine.
You paid $50,000 to publish your trade secrets and got a patent that does not apply to the one entity it was supposed to constrain.4
The Fix Is Upstream of Drafting
The fix is not better claims. It is better instructions.
Before the attorney writes a single word, someone needs to answer:
- Who are the specific competitors this patent should target?
- What does their product look like? What technical approach are they using — or will they be forced to use?
- What is the bottleneck they cannot design around?
- If they tried to avoid this claim, what would they have to change — and would that change be commercially viable?
These are not legal questions. The attorney cannot answer them. They are business and competitive intelligence questions. They require someone who understands the market, the technology, and the competitive landscape — and who can translate that understanding into instructions the attorney can execute.
When that upstream work is done, the attorney becomes enormously valuable. They take a clear competitive target and draft claims that read on the competitor’s product — claims that survive design-around attempts, that hold up during prosecution, and that have commercial teeth when it matters.
Without that upstream work, the attorney is drafting in the dark. And the default — describe what the inventor told me — produces patents that describe your product, not your competitor’s.
The Test
Next time a patent application is on your desk for review, do not ask “is this a good patent?”
Ask: whose product do these claims describe?
If the answer is yours, send it back. The claims need to be rewritten around the competitor’s product — the product that generates the revenue you want to protect against, the product that competes for your customers, the product that takes market share if it is not constrained.
If nobody in your company can answer that question — if nobody knows what the competitor’s product looks like at the claim level — then the problem is not the patent. The problem is that no one with business judgment is directing the process.5
And every patent you file without that direction is another $50,000 diary entry.
Further reading
- 1. The Invention Disclosure Meeting Is Where Patent Value Is Decided — On the default disclosure meeting dynamic — and how to redirect it before drafting begins. ↩
- 2. Your Patent Attorney Makes More Money When the Patent Application Is Bad — The structural incentive that produces implementation claims by default. ↩
- 3. Stop Patenting Your Invention. Start Patenting Your Competitor’s Product. — The full version of the central argument here — with worked examples of what ‘patent the competitor’s product’ actually looks like in claim drafting. ↩
- 4. Are Your Patents Excellent — Or Just Expensive? — A diagnostic for separating portfolio-wide value from portfolio-wide cost — and the questions a CEO should be asking on each patent. ↩
- 5. Fractional Chief IP Officer — The role that supplies the upstream business judgment this post calls for — without the cost of a full-time hire. ↩