How I operate
Product management is mostly judgment under uncertainty, made visible to other people. Here are six things I actually work by — each one has proof on this site already, not just a claim here.
Ship the argument, not the deck
A memo says I understand the problem. A working demo, a real cost table, a stack I'd defend out loud — that's what actually shows how I think. Asked to demonstrate product thinking, my instinct is to build the thing, not describe it.
→ this whole site is the answerMake the tradeoff visible, not just the decision
Every real call has a reason it could go the other way. I write that down on purpose — not to hedge, but so the decision can be argued with and reversed cleanly if the facts change.
→ the stack review states what would flip each callName the missing piece, not just react to what's given
Handed a stack, a plan, or a brief, I look for what's quietly assumed rather than only grading what's already there. The gap is usually more important than the parts someone remembered to mention.
→ flagging AI orchestration and UI/UX design, unpromptedTalk numbers fluently, not directionally
"Make it cheaper" isn't a plan. Cost per token, per call, per feature, priced against real published rates — that's a plan, and it's the only version a finance conversation can actually use.
→ the cost estimator runs real pricing, not vibesFind the real leverage, not the obvious lever
"Be better than the competitor" isn't a strategy. Naming the specific weakness — credit opacity, a hard complexity ceiling — and building the one feature that targets it directly, is.
→ the Lovable leverage points, each aimed at one named weaknessDefault to building, not asking
Given an open question, I'd rather go find a defensible answer and bring back something concrete than hand back a list of things I'd need from someone else first.
→ this page exists because that's the defaultWhat I'd actually do in the first few weeks at IONOS
Sit with Customer Care before writing a roadmap line. The real sameness-and-trust problems show up in support tickets first, not in a brainstorm — I'd rather start from what's already going wrong for a real customer.
Get the token-economics math into a shared model, in writing, in week one. Nobody should be pricing a plan tier by intuition when the product's core cost driver is this measurable — the table on this site is the shape of it.
Pick one number to instrument before touching the roadmap. Probably publish rate or edit-to-publish ratio — so "working" has a figure attached to it from day one, not just a feeling by week eight.
Name the AI-orchestration owner explicitly — even if that's me, for now. The piece most likely to end up silently unowned is the piece the entire product depends on. I'd rather say that plainly than assume someone has it.
Why a build, not just an application
Anyone can say they'd be effective. I'd rather leave something you can click through, argue with, and check my math on — a research brief, a stack I'd defend, a tool that prices its own claims. If any of it is wrong, I'd genuinely like to know where — that's the same standard I'd hold the product to.