In a drama worthy of Shakespeare, players in deep tech, such as artificial intelligence, block chain, big data, robotics, electronics, and photonics, often feel like they are arrayed against an army of foes.
In this series of articles, we will investigate some of the issues encountered by deep tech in trying to integrate IP strategy into their battle plans (or courting strategy as the case may be). In this first issue we will look at the Agile development approach, what challenges this brings, and how an Agile IP strategy can be transformed into a perfect bedfellow.
Agile development is sometimes described as a cult or manifesto for coders. Even though it dates back to 2001, it is still in widespread use today in the deep tech arena, and is gaining more popularity in wider business processes.
It typically relies on short sprints or iterations where everybody in the organisation is focused on implementing a feature or revision within a set timebox. In this mode, it is very hard to find focus or time to spend on IP or other “trivialities”: everybody is focused on the end goal for that iteration.
At the beginning of each sprint there is a goal, but by the very nature of this approach, goalposts shift drastically over the project. This means pinning down what the product will look like at the end is difficult if not impossible. Sprinting is very focused on getting customer feedback at the end of each sprint and feeding that back into the plan for the next sprint.
Overall IP strategy
The overall business goals in deep tech will typically be related to a successful exit or further investment rounds. In such a case, the IP strategy can often be focused on adding value to future investors or other stakeholders. Deep Tech IP is often shrouded in mystery as if there is some secret crystal ball. However, IP strategy is usually very simple:
What aspects will add the most value to your revenue projections?
Can those aspects be protected (and how)?
Who will try to copy it?
How will you stop the copiers?
Do you need to worry about patent trolls or infringing other patents?
Freedom to Operate
Freedom to operate (FTO) can sometimes be the last thing entrepreneurs want to know about. They are focused on getting their product to market and burn rate. However, stakeholders such as investors, and even government funding can often be tied to this thorny issue.
While stakeholders may insist on getting freedom to operate searching done, depending on the nature of the tech, the markets and even on the investors, it may make sense to delay or rethink what searching is most useful.
Sprints can change the nature of the product drastically, so figuring out what to search is tricky. Because FTO searching can be expensive, and relies on comparing the launched product with live patents existing at launch, it is often left until late in the process. However, this need not be the approach.
Early on in the project an overall FTO search can be done on the very broad premise. This will draw out any major roadblocks but won’t focus on finer details. This can be used to guide each sprint on general areas or features to avoid.
For each sprint, instead of an FTO search, a short landscape search may be better. This is more targeted at giving an idea of who has patented what in the area of the iteration. This can be used together with a SWOT analysis of your strengths, weakness, opportunities, and threats to help align IP value with the R&D development. At the end of the day, the vast majority of value that successful businesses accrue is intangible (whether measured in the balance sheet or through expert intangible valuations) and this should remind us all of the risks at stake.
Deciding what to protect, when and how, may cause endless hand wringing. This is particularly acute with an Agile approach since nobody knows what the product will look like at the end of the project. Alternatively, the founders may have heard through contacts that trade secrets are the way to go, or some rumour that software isn’t patentable.
The best approach (as with most things) is to be pragmatic and prioritise with your best guesses. For each sprint, a decision can be made about what might be patented during the sprint and at what stage. This will change according to where that sprint is, in the overall timeline. The organisation can include things to patent in the burn chart/story map but this can be updated as part of the Agile process.
During internal development, before the product has been launched, there is minimal practical risk of patent infringement. However once your product is out in the market, especially in the US, is it common in deep tech to get infringement warnings in the mail. Whether the threat comes from a trading business or a non-practising entity (patent troll), a pre-planned approach to a range of scenarios is a good start.
Often the key is acting quickly and confidently. This may mean calling their bluff straight away (where the patent in question was already known previously to be of dubious validity), not replying, entering a dialogue about collaboration instead, or even entering an early settlement at a much lower royalty rate.
The brand may be the last thing on engineers’ minds during each sprint, but while customer perception may be the focus of marketing or sales, it should be on the forefront of the whole team. Sometimes a pseudo internal brand for each sprint can help, which encompasses or represents the personas for the project or sprint.
At fulfilment or closer to product launch, these internal brands might actually provide some candidates for focus groups. Even at that stage it is important to think through perceptions of different cultures and implications of different languages or pronunciations of major target jurisdictions.
A final word
Buzzwords may be king, but in the end what matters is value. Simplicity is essential in the IP strategy and the simpler and shorter it is the easier it is for all the team to buy into it and integrate it into their tasks. The IP strategy can be a perfect bedfellow of Agile development.