Building the Product Function at Raffle AI

When Raffle changed leadership, I took on product — a role no one held — brought a deliberate planning process to a fast-moving, reactive company, and built the partner platform that a new reseller channel now runs on.

Context

Raffle AI builds AI-powered search and chat for enterprises. The team is small and deliberately so: two frontend developers, two backend developers, a data scientist, a designer, a CTO, technical support, and me.

For most of the company's life, product direction was driven by the founder — a strong operator with a sales background who carried the company through its early years largely on her own energy. That kind of founder-led momentum is what keeps early companies alive, but it creates a particular product environment: fast-moving, deeply customer-driven, and hard to scale. Priorities shifted customer by customer. The platform had accumulated technical debt, several large foundational projects had stalled, and many features were one-off solutions built for specific customers rather than for the product as a whole.

When the board made a leadership change, that gap became something I could act on.

How it started

I proposed it to the new CEO directly.

There was nobody dedicated to product, and the gap was visible. Two years inside the product had given me deep knowledge of what it did and where it was fragile. Between a design background from Politecnico di Milano, frontend development work, and growing involvement across sales and marketing, I was comfortable working directly with both engineering and the business.

He agreed. Product formally sat under the CTO, who was candid that it would be a difficult role. He was already stretched across security compliance, customer prospects, and deep technical work, and had never had the bandwidth to own product direction. He backed me fully from the start, and we've operated as genuine partners throughout.

What I introduced

First, shared visibility. I migrated the backlog from a cluttered ClickUp to Linear, cleaning and restructuring it in the process. Before anyone could align on priorities, everyone needed to see the same picture of what existed and what was in flight.

Then, a planning rhythm: quarterly alignment around a clear business goal, followed by a discovery phase, then execution with defined requirements, scope, and deadlines — reviewed by the team before work began.

Discovery became the part I invested in most. Each cycle pulls from a few real inputs: customer success feedback collected regularly and fed into the backlog, the CEO's strategic priorities, our own analysis of where the product was struggling, and a check on competitors so we weren't falling behind on table-stakes features. No single input decides direction; it comes from weighing them together.

I made POCs a standard part of scoping. Before committing the team to a major project, I'd build a working prototype to test feasibility and shape the requirements. The clearest example is the current chat refactor — moving from a system that summarized search results to a fully agentic chat with tool calling and context layers. Before writing a single requirement, I built a rough working version to pressure-test the approach, then handed it to our data scientist, who turned it into the production design document. It took a few weeks alongside other work — but the team started execution with a clear picture of what they were building and why.

I didn't tell engineering how to work. My job was to make the goals clear and the requirements solid. The rest was up to them.

This didn't mean everything slowed down. Structured work was roughly 80% of the roadmap; the remaining 20% was intentionally left flexible for fast fixes, low-hanging fruit, and the opportunistic work a startup still needs. Fixes still happened — they were just scoped, prioritized deliberately, and planned around rather than allowed to dominate.

The partner platform

The clearest example of what this process made possible is the partner platform built in Q1 2026.

Raffle had identified partners — resellers and integrators — as a significant growth channel, but there was no infrastructure to support them. I worked closely with our partnerships manager from scratch: starting with deep discovery into what they actually needed, then deliberately generalizing those needs into something scalable rather than building another one-off.

What we built was a full account-management platform for partners:

• A self-serve flow to create and configure customer accounts and run scrapes
• A plan and permissions system to assign features based on commercial agreements — fully scalable, and now used internally as well
• A widget template system so partners could set up new customers quickly and consistently
• A monitoring dashboard to track account performance and surface issues and opportunities early

The result: partner-managed accounts went from zero to more than 200, and Raffle's overall customer base grew from roughly 100 to over 300. That category of customer didn't exist before — the product couldn't support it. We'd been hand-building tailored solutions for a handful of customers; this turned that into something partners could sell and scale on their own.

I want to be straight about the headline number, though: that growth hasn't translated proportionally into revenue. The new contracts are smaller and churn has offset some of the volume, and closing that gap is work still in progress. But none of it was even possible before the platform existed.

How the team responded

I was a designer stepping into a PM role on a team that already had a designer — someone with every reason to question it. The tension was real but brief, and the team came along faster than I expected.

I didn't try to arrive as a PM. I focused on being useful and let the work earn the role. The delivery and the quality of what we shipped came from the team; my job was to make that easier.

What changed

Features started taking longer. The product got substantially better.

Before, a fix could ship in a day. A real feature that removes a core product limitation takes two to three months. That tradeoff is worth it — but only if you're honest about it. We still move fast on the things that deserve speed. What changed is that slowness became a choice, not a symptom.

The shift is visible in two numbers. Unexpected fixes dropped from roughly daily to about once a week or every other week — the remaining ones scoped and prioritized deliberately rather than fired off on request. And on-time roadmap delivery climbed every quarter as the process matured: from around 50% in my first quarter to roughly 60%, then 70%, and about 80% now. The early roadmaps were too ambitious and we missed deadlines; as the planning got more realistic, delivery improved each quarter.

The team moved from reactive to intentional, and the difference shows in what we shipped: a complete vector search refactor that cut costs and indexing time, a full widget overhaul, the partner platform behind a new customer category, and an agentic chat — currently in progress — that aims to fundamentally change what the product can do.

The revenue gap I mentioned earlier is the next problem to solve, and it's a real one. But it's a problem the company can now actually work on. Eighteen months ago the product couldn't scale at all; today it has a foundation that makes sustainable growth possible — and building that foundation, with the team, is what the last year of work was really about.