Design thinking and science

What if we are solving the wrong problems?

In many academic research settings, work begins with a hypothesis or a research question relevant to a future benefit to the society. A PhD student, postdoc, or investigator frames a technical question, develops methods to explore it, and arrives at conclusions. This is a well-established and valuable way of doing science.

In areas like robotics, we are often motivated by open, physically grounded challenges such as interaction, manipulation, and locomotion. These problems are inherently complex and not yet fully understood. We design and test new robots to explore these questions, and in doing so, we sometimes produce systems that are elegant from a kinematics or dynamics perspective and worthy of high impact publications. Yet, despite their scientific value, they do not always translate into real world use or solve the problems we originally set out to address. For instance, in many so called bio inspired robotic studies, the final system may resemble the original biological inspiration in form, but falls well short of matching its functionality.

If we step back and reflect on why we do this work, the aim is usually to create outcomes that are genuinely useful. That outcome might be a deployed system, or it might be a deeper theoretical understanding. Both are valid contributions. But this raises a broader question: what kind of science actually leads to meaningful impact, and under what conditions?

In industry, the approach usually starts with a clearly defined problem. From there, investigation is directed toward identifying what is missing to solve that problem. If that gap is filled, there is a clearer path to impact. This alignment between problem definition and outcome can keep a team focused on efforts that matter.

This is where design thinking becomes useful. Among several frameworks, the double diamond offers a structured way to navigate this space (see figure below). The first phase is divergent: discovering what the problem really is. This means opening up the problem space, understanding the context, and identifying the factors that define it.

Take agriculture as an example. As a roboticist, rather than developing a sophisticated technology only to later find that it does not work in the field or is too costly to scale, it is more useful to step back and first ask what the actual problem is. That requires engaging with the ecosystem, observing and speaking with stakeholders. And importantly, the farmer is not the only stakeholder. There are equipment manufacturers, service providers, fertilizer and chemical suppliers, irrigation specialists, agronomists, policymakers, and others. Agriculture operates as a networked system.

If we only speak to one group, for example farmers, we may miss the larger opportunity. A farmer might say they cannot afford new technology, which is a real constraint. But that perspective alone may not reveal opportunities where technology could reduce costs, improve yield, or enhance quality and consistency, ultimately increasing income. To see that, we need to understand how value flows across the entire ecosystem.

This is why engaging multiple stakeholders is critical. Structured conversations, guided by approaches such as those in The Mom Test, help uncover genuine pain points without biasing responses. Through this divergent phase, we build a richer picture of the system and identify where meaningful problems lie.

The next phase is convergent. Here, we narrow the broad set of observations into a smaller number of well-defined problems or opportunities. The aim is to identify interventions that create value across stakeholders, solutions that are economically viable, environmentally responsible, and practically adoptable. Ideally, farmers benefit, service providers benefit, governments see value, and there is a sustainable business model.

At this point, we move from understanding the problem space to defining a specific problem we are well positioned to solve. This is where our own strengths come in, our technical capabilities, our tools, and our scientific perspective.

After defining the problem, or a small set of problems, we move into a second divergent phase: exploring different ways of solving it. This is where scientific thinking naturally fits. We can frame hypotheses, run question driven investigations, and systematically explore alternative solutions.

Take a simple example like hydration in agriculture. Suppose we focus on a specific crop such as chili, grown in a particular region, for instance parts of Sri Lanka such as the North Central or Northern provinces. Even in this seemingly simple case, the problem quickly expands. What counts as enough hydration? How often should irrigation happen? How much water should be applied each time? And how should it be delivered, through surface flow, spraying, drip irrigation, or injection at specific points in the soil?

Once we ask these questions, a range of technical challenges emerges: controlling pressure, scheduling irrigation, placing delivery points, and adapting to soil conditions. If there is established knowledge, we can implement it directly. But often there is room for exploration. That is where controlled experiments become valuable, testing different hypotheses across groups of plants, comparing yield, consistency, and water usage.

From this, we begin to quantify the problem. We can estimate the cost of intervention, infrastructure, and water usage, and compare that with gains in yield and quality. This allows us to build a basic business model: what is the investment, what is the return, and over what time horizon can that investment be recovered? It also helps identify the minimum viable scale, how large a farm needs to be for the intervention to make economic sense.

Hydration is just one example. The same applies to weeding: manual, chemical, mechanical, laser based, or hybrid approaches. Each option opens up a design space with different trade offs. The key point is that this phase of exploring solutions should be done efficiently, often through pre prototypes or simple prototypes rather than fully developed systems.

This phase of divergent thinking, combining technical and business perspectives, helps us filter out solutions that may be scientifically appealing but not viable in practice. For instance, I might be tempted to design a tree climbing robot to harvest coconuts, with sophisticated signal processing to detect ripeness. However, when we factor in the cost of intervention, added logistical complexity, and the expected commercial return, it becomes much easier to identify which solutions are genuinely viable and worth investigating deeper.

Once we identify options that are technically viable, economically reasonable, and potentially scalable, we move into a convergent phase again: defining the actual solution. That solution is then implemented, and importantly, implementation itself becomes a source of learning. We begin to see how stakeholders respond, how the system behaves in practice, and where assumptions break down. This naturally feeds back into the earlier phase of problem understanding. In that sense, the double diamond is not a one-off process. It is iterative.

What is interesting, though, is that this process can be improved as shown in the figure below. There is value in not strictly separating problem exploration and solution exploration. In practice, early, even rough solution ideas, mock ups or quick pretotypes, can be introduced during the problem understanding phase itself. This allows stakeholders to react to something tangible much earlier allowing us to understand how the intervention changes stakeholder behaviour.

For example, in a conventional approach, we might identify weeding as a key problem in a crop like cinnamon, design a robotic solution, and only then present it to farmers. At that point, rejection can happen for reasons that were not visible during the initial analysis, such as cultural practices, workflow incompatibility, or economic concerns. By contrast, if tentative solution ideas are introduced early in conversations, we can surface these constraints much sooner.

In that sense, it becomes useful to embed solution-oriented thinking within the problem exploration phase. This creates a more iterative, almost agile process, where understanding the problem and shaping the solution evolve together. However, unlike a purely agile approach, which can sometimes become ad hoc and inefficient, the discipline of divergent and convergent thinking still matters. We still need space to explore broadly before narrowing down.

Ultimately, what matters is not whether we follow a rigid framework, but whether the process ensures that our solutions are grounded in real problems, and that there is room for divergent and convergent thinking. This process will also unify your team around shared understanding, and achieve stakeholder buy-in early in the engagement process.

Scientific investigations, whether hypothesis driven or question driven, become far more useful when they are embedded within a well understood problem context. Otherwise, we risk developing solutions that are technically sound, even elegant, but not practical or impactful in the real world.

The stories of my startups, Permia Sensing and EvoTouch, did not follow this way of thinking. I began as a curiosity driven scientist exploring embodied intelligence, and only later recognised the commercial opportunity. Looking back, if I had applied this framework from the beginning, I would likely have reached the spinout stage much earlier.