I turn fragmented, support-heavy processes into self-service experiences that large customers can trust.
Eight years in product. Enterprise B2B data products, supplier networks, bulk data and APIs. Working remotely with international teams from Poland.
Discovery is a series of bets about customers. I name the bet, pick the cheapest method that can prove it wrong, and write down what would change my mind. Then I combine methods, because each one hides something the others show.
At the sales and support organisation, every customer interaction was logged by hand in an internal tool, and nobody knew how long one entry took. I linked one week of session recordings to database logs and got a measured time per entry. An opinion became a business case.
Everyone quoted that 52% of bulk edits changed a company's identifiers and its contact person at the same time. I checked what was behind it. Most of it came from a tags column that is nearly always filled. The real overlap was 45 percentage points lower.
One discovery, on a new standalone product for suppliers, ended with "not worth building". Another, on moving an internal contact log into a shared customer record, ended with "not yet", because it depended on a separate project that had to come first. Both spared the team from building on weak ground.
Behavioral data shows where the problem is. Conversation explains why. I use both.
Whatever I build or investigate has to connect to an impact: a north star metric, or the main business KPI the team exists to move. An impact map walks down from that goal. It names the people who can move it, the behaviour that has to change, what we could build to change it, and the experiments that test the idea first. The technique comes from Gojko Adzic.
Read it from the top. Each level answers one question, and everything underneath has to explain how it helps the level above.
A business metric taken from the strategy or the team's goals. Everything below has to explain how it helps this number.
The people whose behaviour moves the impact. There can be several, and it matters which. Look beyond the obvious power user.
Something people do differently, which creates value. Write it as a behaviour and never as a feature.
Solutions that could drive the change. Being on the map promises nothing.
Tests of the riskiest assumption behind a bet, run before committing to build it.
The impact depends on who you are trying to move. The whole customer base behaves differently from one segment, and a change that helps one group can leave another untouched. So I say which actor I mean: all customers or a segment, large or small customers, customers in one country, customers on one subscription, or customers affected by a regulation. In my upload work there were two actors: the programme managers who run supply-chain sustainability actions, and the procurement managers who analyse the ratings of their suppliers.
It also helps to look at the neighbouring groups that customers move between, such as free, trial and paying users. They show where the next gain could be.
A lag indicator is a definitive result of the past. It is the true measure of impact, and it moves slowly because many initiatives add up in it. A lead indicator is an assumed predictor of future success. It moves earlier, so a team can steer by it. In my scope the lead indicator was the size of the supplier network. More suppliers on the platform means more buyers' invitations that can lead to paid subscriptions. The lag result is ARR, which I did not own and which my work points to.
Each step is an assumption that the next one follows. The lag result is where the assumption gets checked.
Hover over or tap a card to see why it matters.
Before anyone proposes a solution, I want both named.
If the team can simply ship it, it is probably a feature. An outcome is only reached when customers behave differently.
Every output is a bet, so each one needs a test that could prove it wrong.
And which lag result will tell me later whether I was right?
If it fits nowhere, it is a new bet, or the map is missing an actor.
Under every branch of the map, the loop between problem and solution runs, the research map helps pick the experiment, and the evidence ladder weighs what comes back.
It is rarely obvious which space a team is working in. The problem space asks whether something is worth solving. The solution space asks what is worth building. I move between them in a loop, and what a release teaches us often sends me back to talk to customers.
Select a step to see how I work there, with examples from my work.
Problem space · Is this worth solving?
A customer said that mapping suppliers from their ERP, the system where a company keeps its supplier data, "needs to be simple and effective". That line anchored the upload redesign.
Problem space · Is this worth solving?
Market benchmarks, export and dashboard limits and external data cost shaped the decision to raise the network size cap by about 65%.
Problem space · Is this worth solving?
For the eight upload reports, the files that tell a customer which rows of an upload worked and why others failed, every use case ran from requirements to user stories, design and acceptance criteria. This is the hand-off into building.
Solution space · What is worth building?
Staged rollouts: internal testing, a small customer beta, then wider waves.
Solution space · What is worth building?
Before launch I defined the tracking for search and add, the way a customer finds a company and adds it as a supplier, so the ranking of suggested matches can be tuned with real choices.
Solution space · What is worth building?
The quoted 52% overlap between identifier and contact changes turned out to be 45 percentage points lower. The team still chose a combined flow, so I designed the safeguards, then sent the learning back to the next question.
Research methods differ on two questions: do you learn what people say or what they do, and do you need the why or the how many. This map follows Christian Rohrer's framework from Nielsen Norman Group. Pick a method to see what it is, when to use it, and where I used it at EcoVadis. Where I have not used one yet, the page says so.
What customers and colleagues tell me does not all weigh the same. I judge it with two questions. How close was I to the source, from anecdotal to first hand? And what did the person put on the line, from lip service to serious commitment? I aim to decide on the top right. Everything else tells me where to look next.
Theory shows the general idea. My practice shows where it appeared in my work. Hover over or tap a note for context.
Decide on this
You saw it yourself, and people acted on it: they used a prototype, paid, or changed their behaviour. This is the strongest evidence.
Real, but second-hand
Rules and big market moves force action. They tell you that you must act, and very little about what customers want.
Cheap to say
You heard it directly, but saying it costs nothing: requests, praise and opinions. Use it to point a direction, then test it.
Investigate before you act
Hearsay and unchecked numbers. A reason to look closer, never a reason to decide.
Decide on this
Real, but second-hand
Cheap to say
Investigate before you act
In the old platform's data, edits to unidentified suppliers, which are uploaded companies that could not be matched to an existing organization, almost never led to a match. I had to design a way for customers to add identifiers, such as a registration number, themselves and have the system try the match again, and to decide whether those fixes and regular edits belong in the same file.
Everyone quoted that 52% of edits changed a company's identifiers and its contact person at the same time. A reason to look, not a reason to decide.
I checked tens of thousands of old edit rows. Most of the 52% came from a tags column, where customers add their own labels, that is nearly always filled. The real overlap was 45 percentage points lower.
Clearer outcome reports, a simpler explanation and common practice in enterprise import tools.
Prototype reviews gave a simpler edit flow and a mandatory company name, so a blank cell cannot erase data.
After an internal demo the team went combined. I accepted it and designed the safeguards: a failed match changes nothing, identified companies are protected, and customers are told when a company ID changes.
State the recommendation with the evidence, make the disagreement visible, then commit fully once the group decides.
ESMA, the EU securities regulator, required that a supplier is notified before a buyer sees its risk profile, which EcoVadis calculates from industry and country. In the upload, a customer who adds suppliers without a contact email address now has to acknowledge that. The regulation set the requirement, and the design made it understandable.
The card lists a customer's past uploads and their reports. Customer interviews on a prototype checked whether the card was understandable and whether customers would use it. I trusted what they did with the prototype more than what they said about it.
I studied real uploads from the old platform to see what data customers actually enter. That shaped the new process and which data to enrich.
EcoVadis, sustainability ratings platform
Performa IT, Brazil and Poland
Startup Development House, Poland
Crusar Logistics, Poland
felipe.rebello@gmail.com