I build the way a company learns from its customers and turns that into revenue.
What I am usually brought in to do
I am brought in when a company knows it has to become product-led and does not yet have the people, the process or the evidence to do it. That has meant hiring and developing researchers and designers, giving product teams a way to decide, and building the shared infrastructure that lets many teams move as one.
It also means tying that work to a number. Discovery, design quality and OKRs connected to revenue, so a research function argues from measured outcomes rather than from principle.
The hiring bar is whether someone raises the people around them
A small research and design function cannot serve a company of thousands by taking requests. It becomes a queue, the queue becomes a bottleneck, and the teams route around the bottleneck by guessing. So craft is the entry ticket, and the hiring question is whether a person raises the capability of everyone around them.
At FTI Group I built that function from the first hire to eleven people in two years: product researchers, product designers, and later the design system team. I hired for people who could teach the rest of the company how to work with customers. The function was small against an organization of more than 11,000 employees, and teaching was the only arithmetic that worked. Several people from those teams now lead themselves.
Three things make that bar enforceable:
- Role clarity before headcount. Every role has a written scope and an accountability before anyone is hired into it, and the product trio model makes it explicit who owns value, usability and feasibility risk in a team. Ambiguity about who decides is the most expensive thing in a product organization, and the cheapest to fix.
- A competency model before the first requisition. Hiring at speed across two disciplines is where a bar quietly becomes whoever the last interviewer liked. The model says what each level is expected to do, what separates one level from the next, and which of those are craft and which are the ability to raise others. The same definition then decides an offer, a promotion and a development conversation.
- A work sample close to the real job. Scored against the model, with the teaching question in front of more than one interviewer, so an offer becomes a decision the group can defend, and stops being a preference somebody held.
At Conrad Electronic the same approach goes into infrastructure instead of headcount. A standing participant panel turns a study from a six-week recruitment problem into a two-day one, which changes what a team is willing to ask. Capability that sits in the way work happens is capability that keeps paying.
How I run a design org
What makes a standard hold is not that I set it. It is a small number of rhythms that run whether or not I am in the room, and these five have gone into every function I have built.
Weekly team sync. One hour, the whole function. What shipped, what is blocked, what each person needs from the others. It is the only meeting where the function sees itself as a team and not as individuals embedded in other people’s teams, which is the standing risk of the embedded model.
Critique, on a stated standard. Work in progress, reviewed against the problem it is solving and the evidence behind it. The standard is written down, which is what lets a junior designer challenge a senior one and what keeps critique from becoming taste. Engineers and product managers are welcome in it; that is usually where the platform-level inconsistencies get caught.
A monthly research digest. What we learned, who it is for, and what changed because of it. It goes to the whole product organization and to the executives who fund it. A function that only reports activity gets measured on activity, and the digest is the habit that keeps the conversation on decisions.
Capacity follows the question. I do not staff a designer per product team and call it coverage. Roughly: the teams run their own discovery on their own surfaces, supported by the panel, the repository and the training; the function spends its own depth on the questions that cross teams, where nobody owns the answer and everybody is affected. That is where the compounding work lives, and it is invisible if capacity is parcelled out by org chart.
A ladder that does not require management. A senior researcher or designer has to be able to grow while staying in the craft, which means a written path with the same pay bands as the management track. Where that ladder is missing, the best practitioners leave for a title somewhere else, and the function loses exactly the people who set the standard.
At scale, discovery has to be a habit the teams own
Continuous discovery, in Teresa Torres’ sense, means the people building the product talk to the people using it every week, and the decisions follow from that contact. It is a habit, and habits need infrastructure.
Research operations first. Recruitment pipeline, consent and data handling under GDPR, tooling, and a searchable repository, built before the specialist hires. Studies run on infrastructure compound; studies run without it cost the same every time and are unfindable six months later. What one team learns has to be reachable by a team that never met them, or every study is a presentation that happens once.
Jobs to be done interviewing as the default method. It produces statements about the progress a customer is trying to make, and those survive contact with a planning meeting. A satisfaction score does not survive the first hard question about what to build.
Voice of Customer as a company capability. A program with an owner, a synthesis step and a decision forum. The dashboard version gets read for two quarters and then cut. I have run this including the licensing side, with Qualtrics, Medallia and Microsoft VoC, and the tooling is the smaller half of the problem. The harder half is answering who represents the customer when the signal contradicts the plan.
An operating model that connects it to delivery. OKRs, defined roles, and a shared shape for how work moves from question to shipped change. Discovery that never reaches delivery is research theater.
An evidence standard with a number at the end of it. Research opens the question and an experiment closes it. At Conrad nine of the ten shipped initiatives carry an A/B test result, which is why the function can argue for its own budget in the same units the business uses. A function that cannot say what its work was worth is asking to be trusted, and it will be trusted right up until the first difficult quarter.
Where this approach works, and where it does not
This works in a product-led transformation: a company that has decided to change how it builds, has executive sponsorship for that decision, and needs the research function, the design system and the operating model to exist for the first time.
The context where this works best:
- E-commerce and marketplaces, consumer and B2B, where traffic is high enough that evidence is abundant and decisions are measured in days.
- Product and technology organizations of roughly 50 to 500 people: large enough that coordination is the real problem, small enough that one function can still change how the whole company decides.
- A mandate with a line to the executive table. Building a research function is an organizational change. A function with no line to the board gets overruled by the next deadline. At FTI I reported to the Chief Growth Officer and at Smart InsurTech the sponsor was an executive board member, and in both cases that is the reason the work was possible.
It does not work where a design team is wanted to produce screens on request, or where the artifacts of being product-led are wanted while the same people keep deciding the same way.
On AI, specifically what I actually do with it
I use Claude Code connected to Figma for design system governance: checking component usage against the system, finding drift between what is designed and what is built, and generating the parts of documentation that are tedious enough that they otherwise go stale. It is pointed at the maintenance burden, which is where design system hours actually go.
I also designed and built an AI-assisted discovery planning tool end to end, which is the clearest evidence I can offer that this is hands-on.
What I do not claim: that AI replaces research or design judgment. It compresses the overhead around both, and the overhead is where most of the week goes.