01
Product ownership
Collecting and structuring requests from stakeholders, turning business needs into requirements and user stories, contributing to backlog prioritisation, and coordinating the work with development.
From digital platforms to B2B product
I had two quite different product experiences at Cerved. First as Product Owner of the company's digital ecosystem — institutional sites, product and service sites, and the digital experiences around them, all running on a shared web platform, each with its own audience and its own business goal. Then as Product Manager in the Smart Lending business unit, on CEBI Suite — a long-standing B2B product used by banks for the management and analysis of company financial statements.
The distance between the two is the point of this page. One is a shared digital platform, where the work is coordinating different needs on common foundations and a change is visible the day it ships. The other is a mature product, where a change has to hold together with a financial domain, business rules, integrations and years of decisions taken before I arrived. Going from the first to the second is what turned design and digital delivery work into product work for me.
Chapter 01
Cerved digital ecosystem
Product Owner · Web & product experiences
Cerved's digital ecosystem wasn't a single website. It brought together the company's institutional presence, the sites for products and services and the digital experiences around them — different audiences, different business goals — all running on shared foundations: a WordPress multisite platform with common templates and components.
The challenge was supporting specific business and product needs without turning every requirement into a one-off solution. Every decision about a template or a shared component was a decision about several sites, and several stakeholders, at once.
My role sat between business, product, design and development: I was responsible for turning stakeholder requests and needs into work a development team could actually pick up.
02
Platform evolution
Evolving the WordPress multisite platform — templates, shared components, common functionality — and coordinating new features and changes across different sites and products, keeping consistency while still supporting specific business needs.
03
Stakeholder management
Working with different business and product stakeholders, clarifying needs and constraints, turning loosely defined requests into buildable work, and mediating between business needs and technical feasibility.
04
Design background
Bringing my UX and service design background into product decisions: structure, content and user experience, working with Figma, shared components and development where relevant.
A different kind of product
Moving from the digital ecosystem into CEBI changed the scale and the nature of the product problems I was dealing with.
Instead of coordinating digital experiences across different stakeholders, I was now working on a B2B product with a deep financial domain, established users, complex dependencies and years of existing product decisions behind it.
Chapter 02
CEBI Suite
Product Manager · Smart Lending business unit
I worked as Product Manager inside Smart Lending, the business unit serving banks, on CEBI Suite: a long-standing Cerved product, B2B, used by banks for the management and analysis of company financial statements. It handles the financial information banks use to assess companies and support credit analysis.
It's software with a heavy domain component, and a mature product: existing functionality, business rules, integrations and users who have been working with it for years. Understanding the product means understanding financial statements, how analysts actually work and the rules the sector runs on — the interface is the smallest part of it. Every evolution has to keep continuity and compatibility with what banks already do with it every day.
My role
Product Manager between business, development and the sales and stakeholder side. Concretely:
Direction
- Understanding business and banking needs
- Product direction and prioritisation
- Release and roadmap planning
Definition
- Clarifying requirements and business rules
- Turning initiatives into actionable stories
- Assessing complexity and dependencies
Delivery
- Working closely with development
- Following initiatives through delivery
- Managing cross-product dependencies
Product operations
- Evolutionary work and recurring activities
- Bugs and ad-hoc requests
- Contractual and regulatory needs
- Alignment with related products and systems
Working with a mature product
CEBI Suite taught me that product management isn't mainly about deciding what to build next. In a mature banking product, any decision touches things that were decided long before I arrived:
- functionality already in use, and the habits built around it
- financial data and the business rules that interpret it
- integrations with other systems, in both directions
- contractual commitments and regulatory requirements
- recurring processes with their own calendar
- several stakeholders, each with a legitimate view
- technical constraints and a legacy architecture
The challenge is often not finding the ideal solution, but finding the right evolution without breaking what already works.
Part of a wider banking ecosystem
CEBI wasn't an isolated product. It sat within a broader information ecosystem supporting banks in the analysis of companies.
SIEF
Economic & financial information
Sistema Informativo Economico Finanziario.
SIAM
Company information
Sistema Informativo Anagrafico delle Imprese.
SIRC
Credit risk information
Sistema Informativo Rischi di Credito.
What Cerved taught me
01
Think beyond the interface
Coming from UX, my instinct was to solve problems on screen. Product work made me look past it — at business value, technical constraints, dependencies and where the product is going over the next years, not the next sprint.
02
Make complexity visible
In a mature product most of the work happens before anything reaches a user. Understanding dependencies, constraints and implications — and making them explicit, so that others can see them too — is a large part of arriving at a sound decision.
03
Balance what's valuable with what's possible
Every decision had to hold together user and business needs, technical feasibility, contractual commitments and the capacity actually available. Leaving any one of them out of the picture makes a plan that doesn't hold.
From design to product
Cerved was the step where I moved from an interaction and service design perspective into Product Management. The design background still shapes how I approach a problem — I start from the person and the situation — but the role increasingly became about deciding what should be built, what should not, why, for whom, and how it could realistically be delivered.