PRODUCT DEVELOPMENT · DIAGNOSIS
Physical product development — and a wider look at everything connected to it.
20+ years of hands-on product development — hypercars to heat pumps. I deliver what I am hired for. Along the way, I usually also notice something nobody put in writing: a design flaw, a broken process, a supplier not living up to their word, a gap on the team. The original work stays the priority, unless the company agrees the other one matters more.
02 / HOW I WORK
Engineering is the way in.
Diagnosis is the actual job.
I get hired for something concrete — a component, a certification, a piece of a product. Once I am inside a company, a pattern repeats: I notice what people either tell me directly or reveal without meaning to, and it is rarely the thing on the brief. What usually gets me there is lateral thinking: pulling a working solution from a completely different field and adapting it to the problem actually in front of me. Some real examples, kept general on purpose:
-
KOENIGSEGG
Hired for: Homologation support and general engineering.
Found instead: The engineer tasked with a new cockpit instrument left the company, weeks before it was due at the Geneva Motor Show. Designed and built it from scratch instead — not just compatible with the old third-party part, but reinterpreted to match where the company wanted to go: real custom components in what customers see and touch first.
-
BOSCH THERMOTECHNOLOGY
Hired for: Concept development on a new heat pump, working closely with colleagues and suppliers.
Found instead: Engineers had no easy way to find or apply the standards they were supposed to be working to. Built simple internal tools linking people to the right documents and shared drives, and made them aware of why those standards — and things like proper geometric tolerancing — actually mattered.
-
SPYKER
Hired for: Development engineering and homologation support — CAD and engineering tasks.
Found instead: The colleague assigned to a remote/key fob housing was given other priorities before he could finish it. Took it over alongside my other tasks — the proposed material killed the radio signal, so tested alternatives until landing on one that worked for both performance and manufacturing tolerances.
-
SPYKER, ROAD-LEGAL CONVERSION
Hired for: Converting a static Geneva show car into a road-legal, UK-homologated vehicle for an investor.
Found instead: Redesigning the rear structure surfaced a supplier substitution — an easier-to-form material, prone to fatigue, quietly swapped in for the one specified. Caught it because the achieved bend radius was not physically possible with the correct material. Managed and largely designed the whole conversion with a small team: new drivetrain, rear frame, crash structure, and a right-hand-drive rebuild — about as close to building a car as this work gets.
-
KOENIGSEGG, LATER
Hired for: Engineering support on a low-volume vehicle programme.
Found instead: Through homologation feedback, engineers already knew the regulations existed — but the approach was still reactive: see what is wrong this time, then fix it. Worked alongside the homologation manager to shift that to proactive: check the requirements first, so the design is compliant from the start. Getting the vehicles through was a shared effort with him and the technical director.
-
A RECURRING ONE
Hired for: Engineering execution on a development programme.
Found instead: Management and the team were not aligned on which stage of development they were actually in, or who needed to be involved and when. Often ended up as the bridge between management, engineering, testing, software and mechatronics, and design — translating what each side needed the others to know.
I do my best work early — before structure exists, when a technical or design problem is still ambiguous, and when I have direct access to whoever can act on what I find. That combination is where I thrive. Once a problem turns commercial, operational, or gets buried behind approval layers I cannot reach, it is not where I add the most value.
03 / WHAT I BRING
The toolset behind the diagnosis.
"Product development" often means software today. Mine is mechanical and structural — physical products are where I have spent 20 years, and it shows in how I read a problem.
Cross-team & cross-company diagnosis
Finding where communication actually breaks down — between departments, with suppliers, with management — and fixing the gap, not just the symptom.
Development-stage & stakeholder mapping
Physical product development moves through distinct stages, each with different requirements and different people who need to be in the room. I read that quickly, and can explain it clearly to management — often the missing piece.
Leadership without waiting for the title
Repeatedly ended up leading teams and steering projects informally, because the work needed doing more than it needed a job description.
Physical product development
Concept through production, on mechanical and structural systems — from single components to full vehicle platforms.
CAD & engineering tooling
CATIA V5, SolidWorks, Siemens NX, Fusion 360 — from full sub-system assemblies to advanced surfacing on individual components, inside PDM systems like SmarTeam and TeamCenter that keep engineering data usable at scale.
Regulatory & compliance navigation
Type approval and homologation for low-volume and specialist vehicles — including the documentation itself: clean, purpose-built technical graphics that one notified body, IDIADA, called the best-looking submission they had received.
Founder's perspective
Running my own product company (LAGOM mobility) means I understand the commercial and practical constraints around the engineering, not just the engineering itself.
Also have experience as a project and product manager, but that role itself is not what I am offering here — engineering, technical leadership, and diagnosis are where I add the most value, and where I want to keep working.
04 / PROOF
Where this has played out.
I founded and led my own vehicle development venture for several years — working through concept, engineering, and the practical realities of building a company around a physical product. When a change in regulations shifted the underlying business case, I made the call to pause the project, including fundraising, rather than push forward regardless. Still mostly out of public view for now, but it says as much about how I work as anything else on this page.
05 / HOW WE COULD WORK TOGETHER
Three ways in. Same way of working.
Diagnosis
You know something is not working, but cannot quite pinpoint what. A focused look at the product, programme, or organization, fixed in scope and timeframe. You get what I see, what matters, what does not, and what I would do next.
Project-based
A defined piece of work — a product, a component, a certification, a specific problem you already know you have. I deliver against that brief, and flag clearly if I find something underneath it worth your attention.
Interim / embedded
A seat on your team for a stretch of time, when you need hands-on engineering capacity and the judgment to notice what else needs fixing along the way. Remote-first, on-site when the work actually needs it.
Paid for value, not hours
I would rather be rewarded for what the work is worth than for the hours it took — including when the right result is that nothing dramatic happens, because a costly mistake got caught early. Engagements are scoped as a fixed fee tied to that value, paid upfront, regardless of company stage — not billed by the clock, and not tied to how a business performs afterward. Fees, not equity.
When scope grows
Real problems rarely stay the size they first appeared to be — that is the nature of the work. When that happens, we stop and agree the new scope and fee together before I continue. You are never billed for growth you did not agree to, and I am never stuck delivering more than what was priced. If I notice something outside the agreed scope while still doing the original work, I make it visible — rather than quietly working it in the background.
No fixed packages, no forced framework. Tell me the shape of the problem — or just where it hurts — and we will figure out the right form of engagement together.
06 / CONTACT
Tell me what is not adding up.
The fastest way to find out if I can help is to describe the problem as you currently understand it. It is rarely the whole picture — that is fine, that is where I start.
Loading contact link…I read every message myself.