Most engineering teams don't think about patents while they're building products. They're focused on getting a new feature working, solving a performance problem, improving reliability, or shipping the next release.
But those are often the same activities that produce patentable inventions. A team might develop a new synchronization approach after discovering that existing methods can't meet its requirements. Or a manufacturing team might discover a way to improve production yield that eventually becomes standard practice.
The problem is that much of this work never gets flagged for patent consideration. Engineers move on to the next project, and potentially valuable inventions go unidentified. By the time the company evaluates its intellectual property portfolio for fundraising, due diligence, or a potential acquisition, some opportunities may already be lost, especially if the underlying technology has been publicly disclosed.
So how can companies identify potential inventions as they're being developed, rather than identifying them months or years later? Here are 6 places to look during the product development process.
1. Technical problems that required an unconventional solution
Some of the most promising invention candidates emerge when engineers discover that the standard approach doesn't work for what they're trying to build.
But solving a difficult engineering problem doesn't automatically make the solution patentable. The question is what the team actually did differently, and whether that approach was already known or would have been obvious to someone working in the field. The team's reasoning often reveals where a potential invention lies.
Questions to ask in retrospectives and engineering reviews:
- Which existing solutions did we try, and why did they fall short?
- What did we build instead, and how does it differ technically?
- Did any temporary workaround become a permanent part of the product?
2. The technology behind new features and performance improvements
Product teams tend to describe their work in terms of outcomes. For example, a new feature might enable real-time collaboration or an updated device consumes 30% less energy.
Those achievements may be commercially important, but they aren't the inventions themselves. Consider a team that reduces a device's energy consumption by 30%. If the improvement came from switching to a more efficient commercially available component, there may be little to investigate. But if the engineers developed a new control method that changes how the device manages power across different operating states, that method could be worth evaluating for patent protection.
The same distinction applies to features. Real-time collaboration is an established capability; a particular method for resolving conflicting changes under poor network conditions might not be.
It's also worth preserving performance data and comparisons with previous approaches. If the company eventually pursues patent protection, evidence of an unexpected technical improvement may help support the application.
Questions to ask after launches and performance gains:
- What specifically made this improvement possible?
- Did we develop the approach ourselves, or adopt an existing one?
- Could the underlying technology apply beyond the feature where we first used it?
3. Innovations in internal tools, testing, and manufacturing
Not every potentially patentable invention makes it into the final product that customers see. A new testing method that catches defects earlier or a calibration process that improves sensor accuracy can deliver substantial business value without ever appearing on a feature list.
That makes this work easy to overlook, particularly when patent reviews focus on product roadmaps and talk mostly to product managers. Manufacturing, QA, infrastructure, and other technical teams need to be part of the conversation.
Patenting an internal process isn't always the right move, though. Patent applications generally become public, so if a company's competitors would have difficulty discovering or reverse engineering an internal method, keeping it as a trade secret may offer better protection. Either way, the company needs to identify the innovation before it can make that decision deliberately.
Questions to ask operations and infrastructure teams:
- Have we changed how we test, calibrate, manufacture, or deploy in ways that cut cost, defects, or downtime?
- Which internal processes would be hardest for a competitor to recreate?
- Would we rather patent this, or keep it confidential?
4. Technical advantages that differentiate your product from competitors
Sales teams and product managers usually know what makes customers choose your product over alternatives. Tracing a competitive advantage back to its technical basis does two things at once: it surfaces potential patent candidates, and it tells you which ones are worth protecting.
Questions to ask in sales debriefs and win/loss reviews:
- What do customers say they can't get anywhere else?
- What do competitors have the hardest time replicating?
- Which technical decisions make those advantages possible?
5. New methods for integrating systems or technologies
Integration work is especially easy to dismiss as routine engineering. Teams often describe it as "connecting two platforms" or "making things compatible," which undersells the problem-solving that went into it. But patentable inventions can involve combinations of known elements, provided the combination meets applicable requirements.
Simply connecting existing systems or using a combination of standard APIs usually isn't enough, and even a useful combination may be considered obvious in light of existing technology. Generally, when it comes to combining technologies, the patent office will look to whether an average person with skill in your technical field would have a "motivation" to combine those technologies.
Questions to ask in design reviews:
- What existing integration methods did we try first?
- What limitation forced us to build a custom approach?
- Does the combination produce an unexpected result that neither part could produce on its own?
6. Engineering records where all of the above leaves a trail
The five examples above rarely announce themselves in a formal product review. More often, they're documented in places (e.g., a GitHub pull request or technical postmortem) that nobody responsible for patents routinely examines.
These records can reveal inventive work that never went through the company's invention disclosure process. They also help companies look beyond whichever projects or engineers happen to get the most attention during patent reviews.
Useful sources include:
- Code repositories and pull requests: Changes that introduce new technical methods, algorithms, or architectural approaches, particularly when the discussion explains why the previous implementation was insufficient.
- Architecture and design documents: Records of technical alternatives, design constraints, and the decisions that led to unconventional implementations.
- Issue trackers and engineering discussions: Difficult problems that required custom solutions, including workarounds that eventually became permanent.
- Postmortems and testing reports: Technical changes developed to address recurring failures, improve reliability, or overcome performance limitations.
- Lab notebooks and R&D records: Experimental approaches, prototype iterations, and discoveries that may not have made it into the final product.
Reviewing existing engineering materials reduces dependence on engineers remembering to report every potentially inventive development. For companies with multiple teams working across different projects, that makes invention identification far more systematic.
Invention identification checklist for engineering teams
| Where to look | Key question | When to ask it |
|---|---|---|
| Unconventional solutions | What did we build when the standard approach didn't work? | Retrospectives, postmortems |
| Features and performance gains | What actually made the improvement possible? | Feature launches, performance reviews |
| Internal tools and processes | Which internal processes would be hardest to recreate? | Operations and infrastructure reviews |
| Competitive advantages | What can't competitors replicate, and why? | Sales debriefs, win/loss reviews |
| System integrations | Did connecting these systems require a new method? | Design reviews |
| Engineering records | Which documents explain a departure from convention? | Ongoing review of repos, docs, and trackers |
| Public disclosures | Is anything about to go public that hasn't been evaluated? | Before launches, conferences, publications, and open-source releases |
Can public disclosure or selling an invention affect patent rights?
Yes, and timing is where most invention-identification efforts succeed or fail. Under U.S. patent law, certain inventor-originated disclosures may qualify for a one-year grace period. However, many countries, including those covered by the European Patent Office, require an invention to be new at the time of filing and provide little or no protection for inventions the applicant disclosed beforehand.
That means a conference presentation, research publication, open-source release, or product demonstration could affect a company's ability to obtain patent protection, depending on what technical information it makes public. A product launch can count too, if the release reveals enough about how the underlying technology works.
Commercial activity creates another potential risk. Under the U.S. on-sale bar, selling or offering to sell an invention can affect patent rights even if the technical details remain confidential.
Companies considering patent protection should evaluate relevant inventions before disclosing them and, where appropriate, file an application first. This matters most for startups planning to expand internationally and for companies developing technologies that may attract licensing or acquisition interest.
Find more patentable inventions with Patentext
Identifying patentable inventions across multiple engineering teams can be difficult, especially when the process relies on engineers to recognize and report potential inventions themselves.
Patentext helps companies find promising inventions within their existing technical work, without requiring engineers to prepare formal invention disclosures or sit through lengthy meetings with patent counsel.
With Patentext, companies can:
- Identify potential inventions from existing engineering materials: Use technical information from sources such as GitHub and Google Drive to uncover promising innovations that were never formally disclosed.
- Capture and develop inventions without lengthy disclosure meetings: Build on existing documentation and technical context, reducing the administrative burden on engineering teams.
- Evaluate inventions before committing to filing: Review potential inventions, assess their relevance to business and IP priorities, and decide which opportunities deserve further investment.
- Manage the invention pipeline in one place: Keep track of what has been identified, what is under evaluation, and which inventions are moving toward patent protection.
- Move forward with patent drafting and filing: Work with USPTO-registered patent practitioners through Patentext Services when an invention is ready to become a patent application.
By making invention identification a continuous part of product development, companies can find more opportunities to protect valuable technology without adding another cumbersome process for engineers.
Explore Patentext for growth-stage companies.
This article is for informational purposes only and doesn't constitute legal advice. Patent laws are complex and vary by jurisdiction. For personalized guidance, consult a qualified patent attorney or registered patent agent.

