🎙️ Podcast Link 🎙️

They say you should see the forest for the trees 🌲🌳 – to understand the larger context rather than getting lost in the details without grasping this vital bigger picture 🧩

That’s what today’s hashtag#HackingAcademia video is all about 🎥: the types of context-setting questions you can ask in early-stage discussions with an industry or government organization that has approached you about a working on a problem or opportunity they have🤝

Context like financial 💰, historical 🕰️, or delivery-related 📦 information is critical to making sure that the detailed conversation that follows is actually productive. Without context, you risk wasting a huge amount of everyone’s time ⌛ going down paths that context would have immediately ruled out as viable.

These questions also increase the chances that the organization finds a good solution, whether or not that includes you. The goal isn’t to win the project. The goal is to help them get a good outcome, and sometimes that means you’re part of it.

So what kinds of questions help build this context? 🤔

❓ Why are we sitting here? Why is this not already a solved problem, and how do you know that / how have you come to that conclusion?

❓ Most problems aren’t unique. Others have tried, maybe solved, or abandoned similar issues. Why?

❓ Is this a case of “more resources will fix it,” “we have a solution but want it cheaper,” or “we need major breakthroughs to make any progress”?

❓ Is this a one-off problem or a recurring one? That affects the solution space and which partners might be relevant and commercially interested 🤖

❓ Who cares, and who pays? Are people already throwing money at this out of self-interest, or is it more of a greater-good or government issue? 🏛️

❓ Why aren’t startups all over this already proposing solutions? Are there big barriers, or is the perceived incentive just not strong enough?

❓ Even if the core problem is solved, how will the solution be delivered reliably in a form the partner can use? Can the university do that entirely by themselves? Does an OEM or external provider need to be involved as well?

❓ How much is currently being spent on this problem? Are they trying to reduce that spend or get more value for the same amount? A $100k per year problem is very different from a $100M one 💵

❓ What assumptions or outdated beliefs are they operating under? In fast-moving tech spaces, (gently) making sure their understanding is current really matters 🔄💡

industry #government #startups #solutions #translationalresearch #commercialresearch #research #university #academia #technology #solutions #ideation #problemscoping

Full Video Notes

If you work in a topical research field which has lots of potential applications out in the real world and you have built up a reasonable public profile, you will inevitably get a significant number of regular requests to chat about how what you know, or what you can do, or what your team can do might be able to solve some problems for a potential industry, government, or even startup partner.

From my perspective, this is one of the great pleasures of being in academia. It is the ability to occasionally use your skill set or your experience that you have worked so hard to develop to try and help someone with a real-world problem, issue, or opportunity that they have.

Early on in your career, this is very exciting and you might do just about anything possible to try and land that first one or two projects with industry or government working on a more applied problem. As you move on in your career and become more senior, however, you generally try to become a little bit more discerning with your project choices and what you actually commit to, both in terms of your own workload and capacity, but also in terms of delivering the best possible outcome for your potential partner.

When a partner comes and talks to you, the aim really should not be to guarantee that you walk out of the room with a project. In most cases that is not going to be an optimal outcome for either yourself or for the partner.

There are a few typical outcomes. The first, rare but much desired outcome, is where the problem set they have come to you with is a perfect match for your experience and your current capacity, and you do indeed do a project together. This is going to be the minority of situations.

The second situation is that they have clearly identified a problem that is possibly somewhat technically related to what you can do, but you are not anywhere near the best fit for it. In those cases, you try to work with them to refer a colleague or someone else you know who does have the right capacity and would be a better fit for that project.

A third potential outcome is that it becomes very clear that there is a total mismatch between what they are interested in doing and what you or any of your colleagues could bring to the table. In that case, it is still an interesting conversation, and you have to remember that even though this particular problem has not worked out, they may come back in the future with a different problem that is more aligned with what you want to do.

Finally, and quite often, especially with relatively inexperienced people in the room, what comes out of these discussions is that by talking through the problem set they come to a very different realization about what they want or do not want to do. Often this requires going back to the drawing board and thinking about it quite a bit more.

One of the traps that these initial meetings can fall into is diving straight into the so-called weeds of the problem and working through very detailed technical solutions without really considering the broader context. The general context around finances, the nature of the problem, and a range of other factors is incredibly critical. I would argue that it is often more critical than the details of the specific technical problem.

The technical details are obviously important as well, but if everyone in the room does not understand the key pieces of context, the discussion will often bog down in details and not actually be very productive.

So what are some framing questions that you can ask to help define the context and refine the scope of what you are talking about in one of these meetings?

The first is very simple: why are we sitting here? Why is this a problem or potential problem that we are talking about? Why is it not already a mature and solved problem that we do not even think about anymore?

This will reveal more about the nature of the problem. It will reveal whether the people you are talking to have done their research, looked at existing solutions, and determined that they are insufficient, or whether they still need to do that search. It also establishes the maturity of thought around the problem.

Whenever you are sitting in a room discussing a potential problem and some research-related solutions, there should be some awareness and humility that this conversation has quite possibly happened hundreds or thousands of times in other rooms around the world. Not always, sometimes there genuinely is a niche application, but often it is something that has at least been thought about and potentially addressed elsewhere.

So what is the precedent? What do we know about other people who have this problem? How have they gone about solving it? Or have they given up and it is still a problem to be solved, and if so, why did they give up? Why did they decide it was not worth pursuing?

A very important concept to get to early in these meetings is defining what category of problem this is. One category is a problem that essentially boils down to resources and efficiency.

One way to get at this is to ask the question: if your operational budget was five times as large as it is now, and you had to spend it on this problem, would that solve most of your problems overnight? That is not particularly attractive because you are spending a lot more money, but is that the nature of the problem? Does more money lead fairly directly to a good solution?

More money does not always equal a simple solution. There is another class of problems where even if there were more resources and funding, that would not solve the fundamental issue. In those cases, some form of new technical innovation is required, and that cannot be compensated for by simply throwing more money at more people.

Another important contextual question is whether this is a widely and regularly repeating problem, or a once-off problem that, if solved, will never be touched again. This matters because it affects how much resourcing can realistically be thrown at the problem and how many other people are potentially interested in solving it.

If you are in an area like robotics or technology, this also affects whether there are existing software packages, algorithms, sensors, or hardware that you can buy off the shelf and leverage. It affects the level of potential commercial interest in solving the problem.

Solving a problem entirely from a research environment is not always realistic. You often want to partner with providers of sensor technology or compute technology. Their willingness to partner with you depends partly on the scale of the problem and partly on how regularly it occurs. Is this an ongoing market opportunity?

Who cares and who pays is another important question. There are problems that are widespread and cost systems billions of dollars, but where individuals or organizations do not directly want to fund solutions, perhaps because there is an expectation that government should handle it.

This matters because it affects how resourcing can be raised. If it is something government is expected to take care of, broader public good considerations come into play. If it is something where individual organizations see a direct financial opportunity or cost, it becomes much easier to raise money from them.

Another way to get at the context of the problem is to ask why the sector is not already drowning in startups trying to solve it. This is not always relevant, but it often gets to the heart of whether this is a well-known problem and whether the market is accessible.

Is the problem locked behind closed doors? Is it a highly restricted industry? Or is it an industry where it is simply difficult to monetize a solution, even if the solution would be technically excellent?

Even if the problem is interesting and aligns well with your skills or your team’s skills, you still need to think about how the partner would actually leverage the solution. Often they will need something closer to a commercial-grade solution with checks and balances built in, and universities are not always well set up to deliver that on their own.

Is there a spin-off or startup? Is it a licensing play? Do you need a third party or an OEM to deliver a usable product? There are exceptions, such as small ad hoc projects where taped-together solutions are acceptable, but often some degree of productization is required.

Many large organizations cannot hold intellectual property or do not have internal technical teams to further mature the technology. You may need to find other ways to address that.

Another key contextual question is financials. A partner may have a current solution that is inadequate but good enough for now. It is useful to ask how much they currently spend per year to address the problem, and whether they want to keep spending that amount or reduce it.

This helps identify whether the problem is primarily an efficiency play, doing the same thing for less cost, or whether they are willing to spend the same amount to get a better outcome, such as better accuracy or better detection.

The magnitude of current spending also shapes what solutions are feasible. A problem that costs $100,000 per year to address is very different from one that costs hundreds of millions per year.

Finally, when a partner describes the problem, it is important to check and double-check the assumptions they bring into the meeting. They may have some understanding of the solution space, some of which may be accurate, but they may also be operating under misconceptions about what technology can or cannot do.

Technology changes quickly. An option they ruled out three years ago may now be feasible. Gently probing why they have made certain assumptions can reveal outdated thinking.

There are cases where you want to remove constraints and encourage unconstrained thinking. But for most early-stage discussions with industry or government partners, getting a mutual, crisp, and correct understanding of the context, what has already been tried, why there is not already a solution, and what the financial and practical constraints are is incredibly important.

That shared understanding is key to shaping productive discussions, whether they result in a project with you, a referral to someone else, or a return to the drawing board to rethink the problem entirely.