Matheus Leite
Product Designer
UNDERSTAND THE PROBLEM. THEN BUY THE SOLUTION.
I designed how Secil's Digital Transformation explores a problem with the people who live it, before any solution is on the table.
01. THE SITUATIONSecil is a Portuguese cement and building materials group with operations in eight countries across Europe, Africa, the Middle East and South America. Its Digital Transformation started in 2023 with a digital discovery led by McKinsey, which mapped the biggest opportunities in Cement and in some corporate areas. Aggregates, Concrete and Mortars were left out of its final report.
In 2024 the transformation opened up to the whole company, with people from the core business as Product Owners. As an industrial company, Secil doesn't build digital products: it buys, licenses or subscribes to them. Misreading a problem meant paying for the wrong solution. Discovery was step 2 of our product process, but nobody had written down how to do it.
I CREATED THE STRATEGIC DISCOVERY MODEL SO THAT EVERY DIGITAL PRODUCT GROUP UNDERSTOOD THE PROBLEM BEFORE SECIL INVESTED IN A SOLUTION.
Strategic Discovery came before any vendor, contract or investment. It had a name, but no method.
02. THE CHALLENGE
STRUCTURED ENOUGH TO GUIDE. FLEXIBLE ENOUGH TO FIT.
Product Owners came from the business. They knew the plants, clients and processes better than anyone, and that was the trap: they went into interviews already holding the problem and the solution. They had no research background, no common way to record what they heard, and no clear way to turn it into a decision.
The model had to guide someone doing research for the first time, and still fit a safety discovery in a plant and a sustainability discovery in head office. It also had to convince engineers, who asked why at every step. I used that as a test: if a step couldn't explain itself to an engineer, it didn't belong in the model.
Problem first, solution later: the hardest habit to change in people trained to solve.
03. THE JOURNEYSTRATEGY
The method, the trade-offs and how it spread across Secil.
MODEL
Four steps and six templates shared across product groups.
outcome
The numbers, the lessons and where the model stands today.
STRATEGYFILL THE GAP.
DON'T ADD A LAYER.
A new process would have meant new meetings, new owners and one more thing to learn for people who already had a full day job.
So I placed the method inside the structure Secil already used. It inherited what was there: a Product Manager driving it, known collaborators around it and a clear handover to the next step. What it lacked was a way of thinking, and for that I went back to design thinking, which I had used in earlier product roles.
“Technology is the answer, but what was the question?”
To make that question concrete, I used IDEO's three lenses. Each became a question every discovery had to keep in view, with the first one always leading.
-
In an industrial company, the people who live a problem are rarely the ones who request a solution. A shift supervisor, a maintenance technician, a safety officer and a board member can describe the same issue in four different ways. This lens kept every discovery anchored in their reality: what they do, what gets in their way and what they have already tried to work around it. Every voice counts, from the plant floor to the board. If nobody who lives the problem would feel the difference, the problem isn't ready to move forward.
-
A real pain is not always a problem worth investing in. This lens connected what teams heard to what Secil was already committed to: safety, sustainability and lower CO₂ emissions, energy efficiency, better use of data and balanced growth. Every Discovery Plan asked which company or product goal the work would serve. That kept discoveries from becoming interesting research with no owner, and gave the findings a clear place in the conversations that came next.
-
Secil adopts digital products rather than developing them, so feasibility is less about writing code and more about fit. Will it work in a quarry with no signal, on a plant floor with gloves on, alongside the systems already in place? Will the teams have the time and skills to use it? Discovery didn't answer this in full, since that comes later with IT and procurement. But it brought the constraints to light early, so no team fell in love with an answer that could never survive real operating conditions.
Three lenses are easy to agree with in a meeting and easy to forget on a busy Tuesday. The real design work was turning them into something product groups could actually do. That meant a few deliberate trade-offs. Two research methods, observation and interviews, instead of a full catalogue, because a short list gets used and a long one gets skimmed. Templates as the main channel instead of written guidelines, because people adopt what they can pick up and use: a ready template spreads faster than a document, as long as it leaves room for each case. And problem and solution kept in separate steps, so the first answer in the room never became the only one.
Design thinking starts from the same place: understand the question before anyone offers an answer. In a company that adopts technology rather than developing it, that question has to come before any demo or proposal.
Observation and interviews: two methods, used well, instead of ten used badly.
Tools alone don't change how people think, though. Product groups needed to experience the method before they were asked to use it. So training followed the same logic: no separate course, but the monthly learning session that my fellow Group Product Managers, the Scrum Masters and I already ran for the whole Digital Tribe. In 2 hours, 25 people went through the three moves behind the model: explore, synthesise and frame. Every exercise came from Secil's reality, like a team stuck at a quarry with no signal to send its reports.
One session, 25 people, and a method explained through situations everyone in the room recognised.
The last choice was about reach. I could support a handful of teams myself, or work alongside the people who guide everyone else. I chose the second. My fellow Group Product Managers and their Product Managers took the model into their own product groups, and we kept a constant exchange while discoveries ran. Their questions shaped the model.
MODEL
FOUR STEPS.
NO SHORTCUTS
TO THE ANSWER.
I split problem discovery into four steps, each with a set duration and a clear output, so every Digital Product Group knew where it stood and reached the next step with evidence, not opinions.
Each step came as a Miro template that explained itself: what it's for, how to use it, what to do and what to avoid.
01. PLANNINGAGREE ON THE QUESTION BEFORE THE FIRST INTERVIEW.
At this stage nobody talks to users yet. The team sits down for one afternoon and agrees on what it wants to learn, why it matters now and what it already takes for granted. Skip this, and a team goes into the field hoping to confirm what it already thinks.
DISCOVERY PLAN:
The who, what, when, why and how
A single canvas that gives everyone the same picture of the discovery. It asks for the expected outcome (decisions, artefacts), how the exploration came about and what work already supports it, and which company or product goals it serves. It lists the 3 to 5 key questions nobody has answered yet, the approach, how many people to talk to and from which angles (processes, people, products, technology), the regions involved and a macro timeline. It opens with one warning: investigate, don't validate. Investigating means digging into a problem. Validating means trying to prove that an answer you already have is right.
CSD MATRIX:
Certainties, suppositions and doubts
Everything the team knows, or thinks it knows, goes on the wall in three columns. Certainties need proof. Suppositions are what people believe but can't show, including topics where opinions differ. Doubts are the questions the discovery has to answer. The certainties column is where the work happens: teams were pushed to challenge what they saw as absolute truths and to name their own biases. The matrix stays open for the whole discovery, so suppositions move as evidence comes in.
A Product Owner's deep knowledge of the business was their strength and also their biggest bias. This is where the team separated what it knew from what it only believed.
02. PREPARATION & ON GOINGGO TO THE FIELD READY TO BE SURPRISED.
INVITATION:
Short, clear and honest
A ready-made message explaining why we wanted to talk, what we expected from the participant and how long it would take. A good conversation starts before the meeting does.
Preparation and fieldwork ran as one movement, the same way the Miro board grouped them: about a week to get ready, then 3 to 6 weeks of conversations. The goal was easy to say and hard to do. Let people tell their own story, and resist the urge to steer it towards the answer the team already had in mind.
DISCUSSION GUIDE:
A script with room to move
The guide arrived almost written. It opened with a ready introduction: who we are, which part of the business we're digitalising, that there are no right or wrong answers, that everything stays anonymous and that any question can be skipped. A short warm-up about the person's role and life outside work came next. The core questions asked about specific, recent moments ("tell us about the last time…") and asked people to name the five key moments in their process. It closed with a quick round of sentences to complete, like "With the digitalisation of my unit, I hope I can…" or "The most frustrating part of my day is…", and an invitation to help test ideas later. Teams could follow it in any order, skip questions or add new ones, and always tested it in a first conversation.
INTERVIEW NOTES:
What people say, do, think and feel
One record per conversation, with the participant's role, date, place and interviewer. Notes captured the exact words people used, what they did, what they seemed to think and how they felt, because what people say and what they actually do often hide the most useful insights.
DEBRIEF:
Ten minutes that save the interview
Right after each session, the pair sat down and answered the same questions: what stood out, what surprised us, what matters to this person, which needs are still unmet, and which question we should have asked but didn't.
Every guide carried the same rules: interview in pairs or record, ask why even when you think you know, never say "normally" and ask about a specific moment instead, avoid yes-or-no questions, never suggest an answer, and don't be afraid of silence. As the playbook put it, every interview makes people a little nervous, whether it's the first or the hundredth.
03. FINDINGSFROM WHAT WE HEARD TO WHAT IT MEANS.
Two to four weeks to make sense of everything. Interviews produce far more material than anyone can use, and it's easy to drown in it. So the analysis stayed tied to the questions set at the start, following one rule from the playbook: don't ask the data a question you have no use for. Nothing was thrown away, though. The material stayed ready to be revisited later, with a new question in mind.
SYNTHESIZE & ORGANIZE:
Seven ways to sort what we heard
Every learning went into one of seven categories. Contradictions: gaps between what people say and what they do, or between one participant and another. Patterns: behaviours seen again and again. Challenges: obstacles people face, or avoid, when trying to get a task done. Validations and invalidations: initial suppositions confirmed or refuted by what people said. Hypotheses: assumptions worth testing next. Insights: new understanding of people's needs, habits and preferences. The categories were fixed, so six different teams could compare what they found.
Findings closed the loop with Planning. Validations and invalidations went back to the CSD Matrix, where suppositions either became certainties or were crossed out.
5TH TOUCHPOINTS:
The whole service on one map
Most discoveries looked at internal users rather than customers, so I turned a service blueprint towards Secil's own people, mapping their actions and feelings in five layers. An overview of each phase, with its description, metrics and time. The frontstage: who acts, what job they're trying to get done, their actions, tools and feelings. The backstage: the actions and processes that support them out of sight. The pains: problems, obstacles and risks. And the opportunities, built from a simple formula: what I observed, plus what I know, equals an opportunity.
The hardest template to get started. Many of Secil's real processes weren't linear, so we changed the approach: five key moments first, then each use case in depth.
DESIGN THINKING, WITH
BOOTS ON
THE GROUND.
OUTCOME | KEY NUMBERS
FEWER GUESSES. BETTER QUESTIONS.
Designing the model and supporting the teams who used it, from mid-2024 to 2026.
9
digital product groups with one shared way to run discovery, from Digital Cement to Digital People
6+
25+
people across the Digital Transformation team trained in the model
strategic discoveries, across 4 business units and corporate areas
3
fellow Group Product Managers who took the model into their own groups
The model also travelled upwards. In July 2024, Semapa, which owned Secil at the time, asked to see how we ran discovery so it could set up something similar. Marco Morais and I presented the process and its templates to its innovation team.
OUTCOME | WHAT I LEARNEDWHAT HELPING AN INDUSTRIAL COMPANY TRANSFORM TAUGHT ME, AND HOW I WORK DIFFERENTLY BECAUSE OF IT.
01.
RECRUIT AMBASSADORS, THEN STAY WITH THEM.
The model only became Secil's when my fellow Group Product Managers started explaining it in their own words, to their own teams. That part worked. What I didn't plan was what came after the training: follow-up depended on whoever came to me with questions. Today I choose who will carry a way of working before I finish it, and plan the weeks after a launch with the same care as the launch itself.
02.
A METHOD HAS SEASONS. KNOW WHEN TO PAUSE.
2024 was a year of exploration: product groups gained momentum and discoveries ran across the business. 2025 closed Secil's strategic cycle, and the focus moved to delivering what those discoveries had found. The model's evolution stepped back on purpose, including the solution discovery stage I had planned next. Knowing when to pause is a design decision too, if you know what it takes to restart.
03.
I DESIGNED THE MEMORY AND NEVER BUILT IT.
The research bucket was in the model from day one. Nobody ever set it up, me included. Every discovery's learnings stayed on its own Miro board, so each new discovery team started almost from zero. The piece meant to make the model stronger over time was the one I left on paper. Today I decide where learnings will live, and who looks after them, before the very first interview, not after the last.
OUTCOME | WHERE IT STANDS"WHY?"
IS STILL THE FIRST
WORD IN THE ROOM.
The model is still how a new strategic discovery starts at Secil. Most product groups are now delivering what their discoveries found.
In late 2025, Secil was acquired by the Spanish group Molins, and the integration is now redefining governance and ways of working.
None of it happened alone. Thank you to:
My fellow Group Product Managers and Scrum Masters, who took the model into their groups and made it their own.
Every Product Owner and product group who trusted a new way of asking before deciding.
#KEEP PUSHING
A fourth product, Reframe, a deck for adults, was ready to go into production when I decided to close.
