What does a patent drafter actually need from you before they can write anything?
A patent drafter cannot read your mind, and they cannot fill gaps with guesses. Every claim in a patent application traces back to something you told them, in writing or in conversation.
At minimum, a drafter needs four things: the problem your idea solves, the specific mechanism or method that solves it, how that mechanism differs from what already exists, and every variation you can imagine someone building around your core idea. Miss any one of those, and the resulting application either claims too narrowly (easy to copy) or too broadly (easy to challenge).
Most first-time inventors show up with the first two and skip the last two. That is the gap this article is about closing.
What is prior art, and why does it change how you brief the drafter?
"Prior art" is the term for anything that already existed before you filed, patents, published applications, academic papers, product listings, even a YouTube demo, that shows something similar to your idea. A patent attorney or drafter uses prior art to figure out what makes your invention different, because a claim that reads on existing prior art is the kind of thing that gets rejected or invalidated later.
If you walk into a drafting session with no idea what is already out there, the drafter has two options: do their own search (which costs you money and time) or draft broad claims based on guesswork (which weakens the application). Neither is ideal.
A rough sense of the landscape, gathered before the meeting, changes the conversation entirely. This is the kind of groundwork covered in more detail in how an AI prior art search tool can help independent product designers, and it is also the logic behind checking which databases get searched and how findings get cited before you ever sit down with a drafter.
How specific should your description of the invention be?
Specific enough that someone with no context could build a working version from your description alone. That is roughly the legal standard patent examiners apply, and it is a useful gut check for a first draft of your own brief.
Vague language like "a device that improves efficiency" tells a drafter nothing. Specific language like "a bracket that rotates 15 degrees to redistribute load across two contact points instead of one" gives them something to work with.
Include:
- The exact components or steps involved.
- How they connect or interact.
- What happens physically, chemically, or computationally at each step.
- Any measurements, materials, timing, or tolerances that matter to how it works.
If you have sketches, prototypes, or a working model, bring all of them. A drafter working from a single static drawing will describe a single static thing. A drafter working from three iterations sees the pattern underneath the iterations, which is usually the part worth protecting.
What if your idea has multiple versions or embodiments?
Bring all of them, even the ones you have not built yet. In patent language, each variation is called an "embodiment," and a drafter uses the full set to figure out what stays constant across every version, that constant is often the actual invention, not any single version of it.
Say your product could be made from plastic, aluminum, or a composite, and could be sized for a countertop or a full room. Tell the drafter all of that, even if you plan to launch with just one version. An application that only describes the countertop plastic version may leave the aluminum room-sized version wide open for someone else to build without infringing.
What business context should you include in the brief?
A drafter benefits from knowing more than the mechanism. Useful context includes:
- Who the end user is and what problem they currently solve some other, worse way.
- What you expect competitors or copycats to try first.
- Whether you plan to license the idea, manufacture it yourself, or use it as one feature inside a larger product.
- Your rough timeline: are you filing to hold a priority date before a trade show, a fundraising conversation, or a product launch.
None of this changes the technical claims directly, but it shapes how broadly or narrowly the drafter frames the application, and how they prioritize which embodiments matter most if budget or time is limited.
This is also where a business-first idea assessment earns its keep before the legal conversation even starts. Running the idea through a structured review, like the one described in what happens when you walk an idea through an AI startup advisory board, often surfaces the market angle a drafter should know about but a purely technical brief would never mention.
What mistakes make a drafter's job harder (and your patent weaker)?
A few patterns show up again and again:
Describing the benefit instead of the mechanism. "It makes charging faster" is a benefit. "It routes current through two parallel contacts instead of one" is a mechanism. Drafters need mechanisms.
Assuming the drafter remembers your last conversation. Put everything in writing, even if you already explained it on a call. Verbal details get lost; written details end up in the file.
Leaving out the failed versions. The prototype that did not work often tells a drafter exactly which feature is essential and which is incidental. That distinction shapes claim scope.
Skipping a prior art check entirely. Whether your idea may qualify for a patent is a question a patent attorney evaluates directly, not something this kind of check answers definitively. But knowing what is already out there before the drafting conversation still saves real time and money, because the drafter is not discovering the landscape for the first time during a billable hour. For a sense of what ongoing tracking of that landscape can look like as an idea evolves, see the best way to track the patentability of a new idea over time.
Treating cost as the first question. Drafting quality and application scope both hinge on how well-prepared you are walking in, not just on hourly rates. The cost conversation matters, but it belongs after the substance is clear, a point covered directly in why cost is the wrong first question when patenting an idea.
How long should a good invention brief actually be?
There is no fixed page count, but a workable brief usually runs somewhere between two and eight pages for a mechanical or product idea, longer for software or multi-component systems. Length is not the goal; completeness is.
A useful test: if a drafter read only your brief, with no follow-up call, could they write a first draft of the claims without guessing at anything material? If the answer is no, the brief is not done yet.
What should you do before you even talk to a drafter?
Three things, in order:
- Write down the mechanism in plain language, then again in more technical language, then list every variation you can think of.
- Do a rough prior art scan yourself so you walk in with a sense of the landscape, not a blank slate.
- Get a second set of eyes on the underlying business logic, not just the mechanism, so the drafter understands what is actually worth protecting and why.
That third step is easy to skip because it feels separate from the legal work, but it rarely is. A free idea assessment run before the drafting conversation, walking the idea past a Product Strategist, an IP Consultant, and a Financial Analyst, tends to surface the gaps in a brief before they turn into gaps in an application. The IP Education Center is a reasonable next stop for anyone who wants to understand the vocabulary, prior art, embodiments, priority dates, before their first real conversation with a drafter.
None of this replaces a conversation with a patent attorney about your specific idea. It just means that conversation starts from a stronger position.
