Nine years in product, and the operations desks before it

Clearon handles digital coupons, gift cards and payment clearing for around 6,000 stores. My team was six developers and two QA working on several legacy systems, and the backlog was driven from above.

The three initiatives took five and a half months from definition to delivery. One was campaign sendouts with the consent handling they need. Another was a prepaid gift card subscription flow with balance checks against Visma. The third was a fulfilment model for digital value objects, built for Triss lottery delivery but designed so other products could use it later. I also did early discovery on turning the main products into a SaaS offering.

There was no spare UX or developer time, so I built prototypes myself with AI instead of waiting for it. These included a dashboard package built from the backend API contract, an internal calculator for Customer Success and the funnel and consent tracking around sendouts.

Lendo is a loan broker, and I worked on business loans and insurance. The journeys are long and depend on complex integrations, so a flow that breaks is expensive.

I owned the insurance flows day to day with a product designer, and the two of us worked directly with the developers. Accident insurance was the hard one, because it competed for attention with Lendo's existing insurance in the same flow. So we tested concepts as live A/B tests instead of settling on one design up front, and were still tuning it when the team was disbanded. I did not track numbers for that period.

We also built an integration with Monto.ai. It worked, but few people used it, and it was removed. Nobody had checked whether a business owner applying for a loan could log into their own accounting software. Often they can't, because the access sits with their accounting firm. Since then, who holds the access is one of the first things I check before an integration.

I also worked on a Focus API integration and on autogiro. When most of our work became long running integrations, sprints were costing more than they gave back, so I suggested we try Kanban. The team set its own work in progress limits and kept adjusting them.

Payments came with the risk and fraud work, and I learned them on the job. During the royalgames.com years I handled the technical side and a colleague handled the commercial side with the payment providers. When she left in 2018 I took over her part too, which also let me move back to Sweden from Malta.

Someone new became operations manager, but a lot of the work stayed with me, since little of what I knew about the platform had ever been written down. By the end the business was the two of us, with support outsourced and a single developer.

king.com handled tens of thousands of microtransactions a day and royalgames.com thousands. Each site had its own payment platform, with the same providers integrated into both. The US and Germany were the largest markets, and the available methods and providers differed by market. The providers included PayPal, Klarna, Paysafecard, Neteller and Payvision, each with its own fees, refunds and chargebacks.

My fraud title had ended years earlier, but I kept the fraud and risk work because dropping it would have cost more.

I joined King in 2008 and spent my first years on the payment support, risk and fraud desks, including a period leading a small second line team. By 2015 I owned product and operations for royalgames.com. I had worked with the platform since 2008 and knew it as well as anyone.

The 2015 accounts, from the year I took over, show around 12 million euro in revenue, down from close to 16 million, and the decline was expected to continue as players moved to mobile. I was the only product person, working with three developers and later two. There was no budget for a turnaround, so my job was to decide what was still worth the effort.

The fraud signals existed but nobody could look at them together, and there was no capacity to build anything into the admin system. I designed a QlikView investigation solution and specified its search logic. A QlikView specialist implemented it, since I had no build access. It cut player-account fraud by an estimated 40% and freed around 50 support hours a month, at roughly a tenth of the projected cost of building it properly. There's a longer write-up.

I made two smaller changes in the same years. First line support decided case by case what needed fraud review, so I mapped the logic into a branching flow, drew it in Word and shared it as a clickable PDF. It cost nothing and cut processing time, errors and incorrect escalations by an estimated 45%. Approved withdrawals also still took three repeated actions after the checks, so I moved them to a batch list. At 300 to 500 withdrawals a day that removed roughly 600 to 1,000 clicks, and the final payment control stayed as it was.