Understand the workflow
Start with the operating reality, not the tool someone wants to buy.
Platform product · Internal operations · Reviewable automation
The work behind the experience should be easier to operate.
I turn messy operational work into clear, measurable systems. I map how work actually flows, find the bottlenecks, and ship practical tools people trust.
Based in Arnhem, I am open to hybrid roles in Arnhem, Amsterdam, Rotterdam and Utrecht, and to remote roles across the Netherlands. For a conversation about product, platform or operations work, connect with me on LinkedIn.
01 / THE PRACTICE
Clarity first, then act.
Before proposing a platform or workflow change, I map what people actually do: the hand-offs, exceptions, incentives and decisions that are easy to miss in a neat process diagram.
From there, I observe the real workflow, map decisions and hand-offs, instrument the bottleneck, prototype with operators and measure the result. Automation and AI can reduce repeated effort while a person remains responsible for consequential changes.
02 / TRANSFERABLE PRACTICE
Useful across the lifecycle.
Make decisions testable
Turn ambiguity into a small contract with named inputs, decision points and outcomes.
Keep risk legible
Use controls and review points that support people instead of hiding behind them.
Build enough to learn
Expose the hidden constraint early, then simplify the system around it.
03 / RANGE WITH A THROUGH-LINE
Grounded in the work, not the label.
My career has crossed customer operations, commercial leadership, regulated risk work and independent product building across countries and sectors. The common thread is practical: understand the people doing the work, make decisions and trade-offs clear, and leave behind a system that remains useful under pressure.
- Senior account management and customer success
- Underwriting and risk-aware commercial judgment
- Local-first systems building and validation practice
- Independent game production under real scope constraints
04 / SYSTEMS I CAN IMPROVE
The internal work that makes customer work possible.
Commercial & admin enablement
Clear intake, ownership and exception handling for teams moving quickly.
Trust, risk & KYC-adjacent work
Reviewable controls, proportionate friction and visible appeals.
CRM & data quality
Source contracts, healthy records and useful lifecycle signals.
Payments & exceptions
Practical queues, retries and accountable resolution paths.
Internal tooling
Small, usable products for the people carrying the operational load.
AI-assisted triage
Constrained suggestions with human review where impact or uncertainty is real.
05 / OPERATING PATTERNS
How I would make a platform change without breaking the people already doing the work.
Illustrative operating patterns: how I frame unfamiliar platform problems before proposing a solution.
01 / COMMERCIAL & ADMIN ENABLEMENT
A fast response with a reviewable record.
Operators need a visible response quickly. The consequential record still moves through confidence, schema and duplicate protection before an approved sync.
- Operations or Sales sees an immediate workspace response while the asynchronous job continues.
- Extraction may suggest structure, but confidence and schema gates decide whether the item can sync.
- Duplicate and retry protection prevents repeated consequential changes; low-confidence or invalid work enters a manual review queue where correction is first-class.
- Audit records retain the route taken; queue age, review time, exception count and rework rate remain observable.
What I would not automate: Final approval where confidence, policy, or customer impact requires accountable human judgement.
02 / GROWTH, MARKETING & CRM INFRASTRUCTURE
A clean event contract before a clever dashboard.
Attribution only becomes useful when events have an owner, a contract, a freshness expectation and an honest failure path.
- Consent-aware first-party events enter a named validation and schema contract with clear ownership.
- Identity is resolved before attribution; the event store retains freshness information for lifecycle and activation work.
- Malformed events go to quarantine rather than disappearing. Downstream destination failures use retries and backoff.
- Event freshness, schema-failure rate, match rate and sync lag show whether the pipeline is healthy.
What I would not automate: Silent merging, deletion, or enrichment of customer identity when the source record is ambiguous.
03 / TRUST, RISK & EXCEPTION HANDLING
Appropriate friction with a named way back.
The objective is not maximum friction. It is a proportionate route that protects people, explains the decision and keeps high-impact ambiguity reviewable.
- A user action first meets low-cost checks before a risk signal bundle routes the next step.
- Low-risk actions can proceed; more uncertain actions can step up, enter quarantine and human review, or receive a clear explanation and appeal route.
- High-impact or ambiguous outcomes stay reviewable. Review and appeal outcomes improve monitored rules or models rather than silently changing them.
- False-positive review rate, exception age, appeal outcome and step-up completion rate make the trade-off visible.
What I would not automate: An unexplained permanent block or a high-impact adverse decision without a named review and appeal route.
04 / ROLLOUT & CUTOVER DISCIPLINE
Prove parity before asking people to trust a change.
A rollout is part of the product. I would introduce it in small, observable steps while keeping a safe way back for the people doing the work.
- Observe the existing workflow before choosing the change; name the users, states and failure modes that must remain safe.
- Shadow measurement and operator feedback establish parity before any cutover decision.
- A small opt-in pilot expands only when it improves the named observable; otherwise roll back safely and learn.
- Keep a read-only legacy fallback until the new route has earned retirement through evidence.
What I would not automate: A broad rollout before current work, parity and operator feedback have been observed.
| Failure mode | Response |
|---|---|
| Parity drift | Stop expansion; reconcile before retrying. |
| Downstream rate limit | Use a bounded queue, backoff and a visible exception state. |
| Duplicate action | Apply an idempotency or review guard. |
| Adoption resistance | Co-design with operators and retain a safe fallback. |
| Bad data | Quarantine and correct at source; never silently discard. |
06 / EXPERIENCE
Systems are learned where work has consequences.
Different industries, same habit: understand the work as it is actually done, then improve the path without losing the people who depend on it.
Kitchen production
- Context
- High-throughput kitchen service where timing, quality and coordination had immediate consequences.
- Constraint
- Prep and busy service create pressure when small teams have limited capacity.
- Operating decision
- Remove empty movement: combine requests, prepare the return trip and help the next constraint on the way back.
- Transferable lesson
- Design internal tools for flow, so the next useful action is easy to see without repeated single-purpose journeys.
Underwriting and broker relationships
- Context
- Risk, portfolio judgement and broker relationships in a regulated commercial environment.
- Constraint
- Risk appetite, capacity, pricing and relationship trust had to move together.
- Operating decision
- Look for demand patterns, strengthen recurring working relationships and make clearer lanes for repeatable work.
- Transferable lesson
- Segment demand, make trade-offs explicit and avoid one workflow for every customer or partner.
Customer operations
- Context
- High-volume support and escalation work across customer channels.
- Constraint
- Constant context-switching creates fatigue and obscures the next useful queue.
- Operating decision
- Advocate for focus by channel and strength, then help the next queue once the primary lane is clear.
- Transferable lesson
- Role design is product design: reduce cognitive load rather than asking every person to carry every workflow at once.
Customer Success and Account Management
- Context
- Customer value, commercial ownership and executive visibility needed to stay aligned.
- Constraint
- When negotiation, customer outcomes, paperwork and reporting blur together, clients and teams repeat themselves.
- Operating decision
- Separate commercial ownership from customer-value work and retain a shared current record.
- Transferable lesson
- Clear boundaries and a genuine source of truth prevent duplicate meetings, conflicting incentives and customer confusion.
06 / INDEPENDENT SYSTEMS BUILD
Current practice, with clear decision boundaries.
01
Independent systems build
Current
Preserve the outcome. Reduce the burden.
- Context
- Independent product practice where technical, visual and production decisions meet.
- Constraint
- Unbounded presentation scope and unclear decision history make a small build difficult to test and sustain.
- Decision
- Keep deterministic source-of-truth state separate from presentation; choose a constrained 2.5D direction; define import contracts and validation gates.
- Observable practice
- Repeatable tests, visual review and boundary failures that can be inspected and corrected rather than silently absorbed.
07 / PRACTICAL AI FLUENCY
AI that suggests. People who decide.
I use AI the way I would ship internal platform features: clear briefs, constrained tools, confidence people can inspect and a named human owning consequential outcomes.
My daily setup combines cloud and local tools. I use ChatGPT Pro, Grok and Gemini in the browser; Codex with the Zed IDE on Linux; and Cursor with Grok and Claude on Linux. Each has a different role across research, structured drafting, implementation assistance, review and critique.
My five-computer lab includes an NVIDIA DGX Spark Founders Edition, multiple operating systems and virtual machines. It gives me a private place to test compatibility, recovery and multi-model workflows with synthetic or public-safe material before proposing anything inside an employer environment. Current local models include Qwen 2.5 Coder, Qwen 3, Mistral Small 3.1, Gemma and Phi-4 Mini.
The value is disciplined comparison, not a model deciding what becomes true. Tools produce options. A named person owns the decision to integrate, reject or stop.
- Start with a defined goal and constraints, then give specialist work lanes a bounded brief.
- Research, drafts and prototypes need evidence and review against the brief.
- If the result is not good enough, revise it or stop. If it meets the brief, a named person owns the decision.
- Integration stays controlled, then validation and a record establish what changed and why.
07 / HOW I WORK WHEN I DO NOT YET KNOW THE DOMAIN
A small usable system before a large claim.
Visual and technical production scope
- Situation
- A desired player feeling depended on a presentation approach that was becoming too expensive to carry.
- Constraint
- Asset, camera, performance and production scope all competed for a small team’s attention.
- Decision
- Preserve the feeling; reduce unstaffable machinery with a constrained 2.5D presentation direction.
- Small usable system
- Clear staging, reusable authored layers and a narrower production contract.
- Observable
- Whether the intended moment still reads while scope and iteration cost remain controllable.
- What I would not automate
- Aesthetic judgment about what the player must feel in the moment.
Unreliable system result
- Situation
- An impressive result is not useful if it cannot be reproduced, inspected or safely improved.
- Constraint
- Iteration creates pressure to accept outputs that look plausible but cannot be replayed.
- Decision
- Choose deterministic replay and QA gates over impressive but irreproducible output.
- Small usable system
- Bounded inputs, recorded state transitions and repeatable validation checks.
- Observable
- Whether a result can be reproduced, explained and tested after the first run.
- What I would not automate
- The decision to accept a result when the evidence is incomplete.
Asset and data boundary chaos
- Situation
- Incoming material becomes costly when formats, provenance and expected state are implicit.
- Constraint
- Boundary failures tend to surface late, where they are harder to trace and correct.
- Decision
- Specify an import or event contract, validate at the boundary and quarantine failures.
- Small usable system
- Named inputs, schema checks, receipts and a repair queue.
- Observable
- Failure rate, queue age, correction path and the source of repeated errors.
- What I would not automate
- Accepting an ambiguous asset or record into a consequential downstream state.
08 / CURRENT SYSTEMS LAB
Supporting evidence, not the headline.
I maintain a small purpose-built environment with clearly separated responsibilities for development, local compute, testing, storage and services. It is where I test boundaries, recovery paths and human-reviewed automation before describing an approach as dependable.
09 / OPERATING PRINCIPLES
Make ownership and next action clear
Name the owner, the decision and the hand-off before adding automation.
Human judgment stays present
AI can support research and review. A person still owns the accepted result.
Useful after launch beats impressive at launch
Prefer systems that teams can understand and maintain after the launch moment.
Learn in the open
Build a small proof, test the real behaviour and use evidence to decide what comes next.
10 / FIRST 90 DAYS
A practical operating start.
- 1 to 30Understand and map
Sit with teams; map customer and operator journeys; identify bottlenecks, ownership gaps and data-quality issues.
Evidence: shared workflow map, agreed problem statements and baseline observables. - 31 to 60Deliver a bounded improvement
Build one useful improvement with the people who use it, then test it in a bounded pilot.
Evidence: a faster or clearer path, operator feedback and clear exception paths. - 61 to 90Establish ownership and evidence
Turn the learning into an operating model that teams can use and a prioritised platform roadmap.
Evidence: named owner, success measure, rollout decision and an explicit not-now list.
FOR FUTURE TEAMS
Let’s make the operating system easier to trust.
I am open to conversations where product thinking, internal tools, operational workflows and risk-aware automation belong in the same conversation.