A patent is not a business strategy

When someone has an invention, the conversation can reach “Can we patent it?” remarkably quickly. I have learned to slow down one step earlier. What, exactly, has been invented? How does it work? Which part matters to a product someone might use?

In my 2017 public writing at Ossia, I described a role that connected invention capture, patents, trade secrets, outside counsel, and the CTO’s office.¹ Much of the useful work was in those connections. An invention had to travel between people who understood different parts of it, without losing the technical detail that made it worth protecting.

That experience is why I think of intellectual property as business infrastructure. It helps an organization preserve knowledge, make decisions, work with partners, and negotiate from a better understanding of what it has. The filing is one important output. It is not the whole system.

Understand before introducing¶

In advice I gave an inventor in 2020, I emphasized understanding the invention before making introductions and taking confidentiality constraints seriously. The practical reason still holds. An introduction can create momentum without creating understanding.

The inventor may know a mechanism in exceptional detail but describe it in language a potential partner cannot evaluate. A business person may hear a broad application and miss the narrow technical contribution. Someone needs to connect the mechanism, the evidence, and the proposed use before the room fills with assumptions.

This does not require turning every early conversation into a legal seminar. It requires knowing what can be discussed, what remains uncertain, and which questions need qualified counsel. Commercial urgency is a poor excuse for being vague about the thing being offered.

Five questions that should not collapse into one¶

Question	Evidence needed
What is the technical contribution?	A precise explanation, alternatives, and supporting work
What rights have been sought or granted?	The actual documents, claims, jurisdiction, and status
Can we build and use the intended product?	Technical feasibility and the relevant legal and operational review
Will someone pay for it?	A customer problem, credible value, and a route to adoption
What can a partner receive from us?	A defined combination of rights, know-how, hardware, data, and support

A positive answer to one question does not settle the others. The USPTO makes a basic distinction explicit: a patent grants a right to exclude within its scope; it does not itself grant permission to practice the invention.² That alone should prevent a patent count from becoming a shortcut for commercial readiness.

A published application, an issued patent, an inventor credit, and ownership are also different facts. I want the public work record to preserve those distinctions rather than blending them into a larger-looking number.

Two entries in the record¶

In August 2022, I joined Michael Wolf on The Spoon Podcast to discuss patents and portfolio strategy for food-technology startups. The dated conversation belongs in this notebook because these are questions I have been working on with other people for years.

A more recent example is the June 2026 publication of the SignAiture application naming Zifu Wang and me as inventors.³ Its subject is product-quality classification using sensor data and AI. The distinction matters here: the application describes an invention, while the original spectroscopy figures show a bounded experimental record. Neither should borrow authority from the other to claim more than it establishes.

Filing is not the same work as drafting¶

One distinction I have made in inventor advice is between getting paperwork filed and doing the substantive work of describing an invention. Both matter. They solve different problems.

The substantive task includes explaining what makes the system work, understanding variants, identifying what may be essential, and checking that the document communicates the contribution. The administrative task includes meeting procedural requirements and managing the record. Speed in the second does not guarantee quality in the first.

For a business, the corresponding discipline is to connect technical work with product plans and partner questions. Which implementation is a customer evaluating? What does the team know that is not obvious from a diagram? What changes if a competitor uses a different architecture? Which choices preserve useful options without consuming resources indefinitely?

Those questions deserve recurring attention. A portfolio can grow while becoming less connected to what the company actually builds.

A protected idea still needs an operating system¶

In the spectroscopy work, the commercial question depends on measurement validity, calibration, sample preparation, references, and deployment. A rights document cannot supply the missing experiment. Conversely, good experimental work does not automatically make the knowledge easy to transfer into a partnership.

The business needs both. The team has to know what has been demonstrated, what it can deliver, what a partner needs to contribute, and where responsibility sits after the prototype leaves the lab.

A license may be only one part of that arrangement. Depending on the project, a partner may also need integration help, evaluation hardware, manufacturing knowledge, training, and a way to resolve problems. If those dependencies are omitted, the transaction can look complete while the product remains impossible to deploy.

This is why I like repeatable evaluation programs. They turn general interest into specific work: a use case, a defined test, feedback, and a decision about what happens next. The IP discussion becomes more useful when it is attached to that path.

Protect the ability to do useful work¶

There is a version of IP strategy that sounds like collecting weapons. There is another that treats every protection decision as a distraction from building. Neither describes the whole job I have seen.

Useful protection can support investment in work that is expensive to develop and easy to copy. It can make a collaboration possible by clarifying what each party brings. It can also become costly theater if the organization never asks how the portfolio relates to its actual opportunities.

My preferred question is concrete: which future decision becomes better because we did this work? A clearer negotiation, a more credible partnership, a preserved option, a more precise technical record, or a deliberate choice to stop spending can all count.

The patent matters most when the organization knows what to do with it. That requires technical understanding, commercial judgment, and people who can carry the work between them.