From User Needs to Working Prototypes: Agile Management for Robotics and IoT Labs

· 5 min read

As AI increasingly helps us develop documentation and project deliverables, scientific laboratories have an opportunity to rethink where their effort creates the most value. Preparing a report, structuring a specification or summarising progress can become easier. Turning research into a useful solution still requires understanding the people who will use it and testing whether it addresses their needs.

For me, a laboratory seeking scientific and societal impact should begin with end users: their goals, needs, working conditions and constraints. From that understanding, the team can define a solution and organise its research around a coherent prototype, even when several funded projects contribute to its development.

This is the management idea I want to develop through pikachuPM, which I created for the research project management needs of TRIBE Lab at INESC TEC. The approach below combines documented software capabilities with proposed working practices.

Start with people and the decisions they need to make

A farmer may ask for an autonomous robot. Further discussion may reveal a more specific need: inspect a crop frequently enough to identify a problem before intervention becomes expensive. That understanding changes what the laboratory should investigate and which prototype is worth building.

I propose starting with a shared description of the user, the problem, the current workaround and the outcome that would make a difference. Observe the work where it happens. Ask who operates the equipment, who maintains it, who uses the data and who decides whether adoption is worthwhile.

Translate those conversations into testable requirements. For example: “As a field technician, I need to identify missing sensor readings before deciding whether to revisit a site.” Agree on acceptance criteria with users and refine them through trials.

Give the solution continuity across projects

Funded projects provide resources, partnerships and contractual commitments. A laboratory also needs a technical direction that lasts beyond an individual funding period. I propose making the solution or prototype the continuing reference point, with each project mapped to the capabilities, experiments and milestones it supports.

Consider an illustrative crop-monitoring platform: one project supports navigation research, another contributes sensing, and a third enables field validation. A shared roadmap can help these contributions become an integrated system.

Maintain a prioritised prototype backlog while preserving each project's scope, deliverables and reporting obligations. Costs, contributions and evidence must remain traceable to the appropriate project. A common technical direction does not make funding interchangeable.

A technical lead can maintain coherence while project leaders and researchers negotiate priorities against commitments and user value. Conflicts should become explicit decisions about capacity and sequencing. The number of active grants should not automatically determine how many disconnected prototypes the team starts.

Use agile cycles to reduce uncertainty

The Scrum Guide offers useful principles of transparency, inspection and adaptation. I would begin with short cycles organised around a clear experimental or integration goal, while stating which agile practices the team adopts.

A two-week cycle might investigate whether an integrated sensing and navigation system can collect usable observations on a representative route. The team selects realistic work after accounting for supervision, procurement, equipment access and other commitments.

Research cannot promise a discovery on a fixed date. It can commit to a sound experimental process and a reviewable result. A negative finding can guide the next decision when its method and evidence are preserved.

Let AI support documentation grounded in evidence

I see a useful role for AI in preparing drafts from approved notes, structuring test procedures, comparing requirements and organising material for deliverables. The opportunity is to connect those documents to the same evidence used by researchers and technical teams.

Begin with verified records: decisions, experiment configurations, versioned code and measured results. AI can help transform this material into a draft; the responsible researcher checks accuracy, references and interpretation before it becomes an official output. Handle confidential material consistently with the laboratory's obligations.

This is a proposed use of AI alongside the process, not a claim that pikachuPM already automates these activities. The time saved should create more room for experiments, integration and conversations with users.

Connect daily work through pikachuPM

The repository documents prototype hierarchies, user stories, sprint associations, Kanban-style tasks, project links and doctoral progress tracking. These provide a basis for connecting daily work with longer-term technical and scientific goals.

For each work item, I would record the user or research need, responsible person, dependencies, completion criteria and expected evidence. Link the work to its prototype and relevant project commitments, so researchers can see both the scientific question and the shared capability they support.

Make hardware dependencies visible. A missing component, an unavailable test site and an unresolved scientific question require different responses. Record the blocker, next action and coordinating person. Reserve shared robots and integration windows before committing dependent work.

Review evidence and return to users

A completed task should leave something assessable: tested code, an identified hardware configuration, a documented experiment, a dataset or a demonstrated capability. Define the evidence before execution and preserve the context needed to interpret it.

At reviews, examine what the team learned and what it means for the solution. Invite end users at meaningful checkpoints to test assumptions about usefulness, operation and maintenance. A successful demonstration is one step towards adoption; it does not establish long-term reliability or value by itself.

The Agile Manifesto principles support sustainable work, technical excellence and regular reflection. Protect concentrated research time, keep coordination focused on decisions and use retrospectives to improve the process.

What progress should mean for TRIBE Lab

In the context of TRIBE Lab's work in robotics and IoT for agriculture and forestry, I would ask: are user needs better understood, are important uncertainties being resolved, can results be reproduced, and is the integrated prototype becoming more useful?

Publications, deliverables and doctoral milestones remain essential. Their relationship to a coherent research and technical direction should be visible. Task counts and completion percentages alone cannot capture scientific quality or impact.

My proposal is to start with one user problem, one prototype roadmap and a small team. Connect the relevant projects, run short learning cycles and inspect the evidence together. pikachuPM can help organise those connections; laboratory leadership and researchers must make the choices that give them purpose.