I talked with Ronan Berder about process, benchmarking, and what product engineering looks like when your "users" are Fortune 500 brands shipping to tens of millions of people on day one.
Ronan founded Wiredcraft in Shanghai, grew it past 160 people, and spent years building localized consumer experiences for brands like Nike, Hilton, Burberry, and Adidas. A lot of that work was China-specific: WeChat, loyalty, e-commerce, apps that were not just a global launch with a locale switch. He was also clear that for much of that time he was not living in the IDE. He was in sales, finance, people management, and the messy work of turning C-suite intent into something a team could ship.
That background is exactly why I wanted him on the show. Product engineering is not only "write the feature." It is understanding the domain deeply enough that you can disagree with a stakeholder when the idea is going to waste money.
Strategy before tickets
Ronan's firm insisted on being a partner, not a vendor. Clients often did not show up with a clean brief. They showed up with "we are not winning in China" and needed help figuring out where to start: loyalty vs delivery, iOS vs Android, WeChat vs something else.
The early work was boring on purpose: situate the client, audit what they had done, benchmark competitors, define terms so people stopped talking past each other, then map a happy path. Only after that did they get into epics, user flows, mood boards, and delivery cycles.
I keep running into engineers who want to skip straight to building because building answers questions. Ronan's point is that skipping the strategy work answers the wrong questions faster.
Align engineers on the outcome, not the OpenAPI spec
One of my favorite threads was how hard it is to keep engineers pointed at the product goal.
Ronan's version of success was not "the API matches the spec and the tests pass." It was "we launched something secure, scalable, and useful for the end user." Getting that into every sprint took one-page briefs, internal design presentations, and hammering the North Star over and over.
He also called out something a lot of us avoid: most engineers never benchmark. They invent. Steal the boring 80% from competitors, reverse engineer what already works, and save your curiosity for the interesting problems. AI makes that kind of research cheaper. It also makes "I only convert tickets into code" a weaker career bet.
Boundaries make creativity possible
Ronan has strong opinions about design process. Design systems early. Shared process. Written SOPs when the team gets big enough that hallway coordination stops working.
His claim that stuck with me: without boundaries, you do not get creativity. You get a blank canvas and inconsistent luck. If you cannot consistently deliver good, you will not consistently deliver great.
That maps cleanly to engineering too. A process that lives only in your head is not a process. Writing it down forces the gaps into the open, creates an artifact the team can argue with, and gives you something to iterate. Delegation is a late-stage benefit. Clarity is the early one.
Expectation gaps beat "bad code" as a failure mode
When I asked about failures, I expected more "we built the wrong product." Ronan's answer was sharper for consultants and internal platform folks alike: a lot of blowups come from mismatched expectations about the relationship. Who gets to say no. Whether you are an order-taker or a partner. Whether the client wanted a roadmap they already decided, or judgment they claimed they bought.
He also named the disheartening consulting truth: you do not fully control the roadmap. Sometimes you say "this is a bad bet," lose the client, and get vindicated years later. Sometimes everyone thinks it will work and it does not. With large brands there is usually enough distribution that total flops are rare, but the boring, data-backed investment still loses fights to the cool campaign idea.
The homework
Ronan's homework is almost insultingly simple, which is why it is useful.
Whatever you are struggling with right now, write it down. Organize the thoughts. You will be surprised how helpful that is, even if you think you already understand the problem.
If you are early in your career and unsure you can stay in the top slice of pure engineering, he also floated a harder career option: take a strong technical background into sales. And if you are mid or later career, stop hoping the AI wave goes away. Get interested in design, marketing, sales, architecture, and the horizontal skills around the code.
That is the product engineer move in one sentence: keep solving puzzles, but widen the puzzle.
