More room needed to develop viable products step by step

The first text processor that I worked with has barely anything in common with those of today. You could type, edit and delete texts and it was possible to save and print files. The developers knew that their product at that point wasn’t complete yet. Yet, it was still a profitable product that users could use. Based on the experiences and wishes of these users, the product was further developed. That first ‘minimum viable product’ was an essential step on the road to the advanced programs that we now use every day.

Agile is not standard

I often use the above example to explain how we work in the RICHFIELDS project. This EU project is a building block for the design of a future research infrastructure for researchers in the nutrition, health and consumer behaviour domain. We do this in an agile way – step by step. This is not a standard way of working in projects such as these, in which the EU identifies clear deliverables. Researchers will generally try to discover in detail exactly what users want, after which a plan is formulated and then developed and implemented.

‘The smallest thing you can learn from’

In RICHFIELDS, we are far more involved with the users. These are predominantly researchers who work at knowledge institutes or companies in the food industry. Based on their needs, we develop a prototype that we call ‘the smallest thing you can learn from’. We are now concretely working on a sketch of the eventual landing page. Then we ask for feedback from the user: Which functions should be prioritised? And: what’s still missing? Users may wish to have a forum added, so that they can quickly contact fellow researchers, for example. Or they might be looking for standards for their own data collecting.

Getting a product on the market more quickly

We are not working towards one dot on the horizon in the next four years. Instead, we want to regularly present users with a design and discuss it. This allows you to develop a product step by step and increases the likelihood that it will meet the needs of the user. By immediately focusing on functions that are of value to the user, we are also able to put a profitable product on the market much quicker. After all, this is one of the conditions for the future research infrastructure: once EU project-funding has ceased, it must be able to support itself.

The quandary

The agile way of working, as is done in RICHFIELDS, allows us to focus on what is important to the user. However, further down the implementation process, we might face a bit of a quandary. We have to deliver what we have promised to the EU, yet we have to create room to be able to deviate from the original starting points. We need to prevent losing sight of the main picture and blocking off certain options. This might happen if we focus only on researchers in the public sector and only discover much later that the private sector has entirely different demands. You want to avoid this situation.

This is why I think it would be good if the EU and other clients would offer more room for step-by-step development in their assignment descriptions. After all, developments in the research sector happen at a rapid pace and that objective that we are focused on now, will have shifted and changed in four years’ time.

Want to know more about this topic? Visit Research infrastructure for health and nutrition on wur.nl.