Netcompany-Intrasoft · Current role
Connecting an EU institution and five delivery teams
I own the backlog across five Agile teams on a five-year programme to modernise the EUIPO information system with automation and AI. Requests from the client and questions from 50+ delivery people come through me. The clearest proof that this works is an AI capability that went from basic high-level requirements to production in three months.
- Company
- Netcompany-Intrasoft
- Client
- EUIPO, EU Intellectual Property Office
- My role
- Product Owner & Business Analyst, the single channel between the client and the delivery teams.
- Scale
- 5 Agile teams, 50+ people, 30+ releases
- Timeline
- Nov 2025 – Present
- Outcome
- Signs Comparer reached production in three months and passed UAT in a single cycle, and the client asked for the same working model on later projects.
The context
The client is the European Union Intellectual Property Office (EUIPO), the EU agency responsible for registering and managing trademarks and designs that are valid across every EU member state. Its information system is what examiners, legal staff and applicants across the whole of the EU rely on to handle those cases, which is the scale the modernisation programme has to work at, on a five-year plan rather than a quarterly roadmap.
What we are adding to that system is automation and AI, which changes how the institution's own people work day to day.
The core challenge
Two groups that both know a great deal about completely different things, and cannot afford to misunderstand each other over five years. My role sits between them.
Signs Comparer: a selected delivery, from basic high-level requirements to production in three months
Signs Comparer was the first project on the programme where I took full ownership of the delivery end to end. The results were strong enough that the client asked us to carry the same working model into the projects that followed.
Signs Comparer is an AI-driven capability that assists EUIPO examiners with trademark opposition and cancellation cases. This is judgement-heavy work, so the tool has to fit the way examiners actually reason or it will not get used.
My role on it was the same one I carry across the programme: analysis and clarification, so the team could build without guessing. There were many open points, and the client did not always know exactly what they wanted going in, so I drew it out by sharing development updates and UI proposals with the business users continuously, well before anything was final, and using their feedback to close out clarifications. Misunderstandings surfaced while a screen was still a proposal, not a built feature.
What that produced:
- A workflow that stayed exceptionally lean and closely aligned to real user needs.
- UAT completed in a single cycle with only minor issues, because the business users had already seen and shaped every screen by that point.
- Production in three months, a record for this client given the size of the programme.
The result that mattered most
Delivering quickly is one thing. More significant was that the client saw how efficiently it went and specifically asked that upcoming projects follow the same direction and working model. The approach outlasted the project itself.
What I own across the programme
The backlog, across five teams
Every work item in Jira that comes out of a product requirement is mine to open, write and track, across five Agile teams of 10+ people each. This is where a client's high-level specification, general and light on detail by design, gets turned through analysis and clarification into something a developer can build without guessing. I know what is in the backlog, what is coming next, and where each delivery stands at any given moment, because when someone asks, I need to have the answer.
At this scale, keeping the backlog accurate is what keeps five teams and the client working from the same picture of what matters next and what is already done.
Analysing requirements and carrying them to the team
I study and analyse all the SRS and product documentation closely enough to hold a clear picture of the system. New requests from the client come to me first. I analyse them, work out what they imply and carry them to the team, and when a developer's question is about something we specified, the documentation usually settles it straight away. Working closely with the Project Manager keeps the commercial and delivery views of the programme aligned.
Turning requirements into Jira items
Once a requirement is clear, I write it up as Jira work items with the detail a developer can build from, so the team can pick them up in a sprint without having to guess what was meant.
Daily stand-ups, questions and client feedback
I run the daily stand-ups with all five teams and the weekly report meetings with the client. I manage the sprints and the Jira boards, and keep the dashboards current so that progress monitoring takes a glance rather than a meeting. Release planning and delivery monitoring I handle in partnership with the Project Manager. For me, facilitating means making sure a difficult point gets raised early enough to do something about it.
Questions from the team come back the same way: I answer from what I already know, or I find the person who can. I then report back to the client, who gives feedback while the work is still in progress, so we can make improvements while there is still room to adjust.
Demos and client feedback
When a delivery package is complete I present the demo to the client. What comes back is the list of things we understood slightly differently from how they intended, and we make the corresponding changes.
Documentation
When a refinement or clarification changes what is true, I update the documentation. On a five-year programme, the documentation is what the next person inherits.
Where the product work sits
Passing a message along is straightforward. The value sits in the analysis in the middle: deciding what a request really means, what it costs, what it conflicts with, and what has to be true before it can be built. That judgement is the core of the role, and the meetings are where it shows.
Day-to-day responsibilities
- Client and stakeholders
- Client and stakeholder management and alignment, keeping expectations and reality in the same place.
- Client needs analysis and product requirements alignment, keeping what the client asked for and what ends up specified in the same place.
- Product demos and stakeholder feedback, and the modifications that follow.
- Daily stand-up facilitation and client reporting.
- Requirements
- Requirements analysis and clarification, including the questions nobody thought to ask.
- Translating requirements into Jira items that a developer can build from.
- Updating documentation based on every refinement and clarification.
- Delivery
- Backlog management, sprint management and progress monitoring.
- Release planning, delivery management and monitoring.
- Jira boards and dashboards management.
- Collaboration
- Cross-functional team collaboration with developers, QA, architects and the Project Manager.