Raffle AI · Focused product case study
Making Product Commitments Dependable
Replacing reactive weekly priorities with a shared roadmap and clearer delivery conventions
I replaced week-to-week product prioritisation with a shared roadmap and clearer delivery conventions. The team completed 4 of 14 projects in their promised quarter in Q3 2025 and 9 of 10 in Q2 2026, with non-linear progress between them.
I owned prioritisation, planning, sequencing, and release decisions. The CEO agreed the quarterly commitments, engineering delivered the work, and the CTO retained formal resource authority.
Context and responsibility
Raffle AI is a small B2B AI SaaS company where product work has to connect customer needs, commercial priorities, platform development, and a limited technical team.
Before my formal Product Manager ownership, weekly priorities changed reactively, Sales and the technical team had limited coordination, and there was no dependable shared roadmap. The problem was not simply a missing planning document. Different groups lacked a common view of what the company intended to build, why it mattered, and when it could realistically ship.
My responsibility was to establish product direction and make delivery expectations clearer. I owned roadmap priorities, scope, sequencing, and release approval. I agreed quarterly commitments with the CEO, worked with the CTO on resource needs, and planned the work with engineering through Linear.
Problem and evidence
The starting system optimised for immediate response. Week-to-week requests could become priorities before the team had compared their value, dependencies, or delivery cost. That made it difficult for engineering to work toward longer goals and difficult for Sales and customer-facing colleagues to speak confidently about upcoming capabilities.
The evidence was operational rather than a single research study: changing weekly priorities, limited coordination between commercial and technical colleagues, and the absence of a shared roadmap that stakeholders could rely on.
I also needed to preserve an important constraint. A small SaaS company cannot eliminate reactive work. Customer issues and material commercial needs still require attention. The operating model therefore had to distinguish necessary interruptions from work that could be assessed, prioritised, and sequenced instead of entering delivery automatically.
Options and decision
| Option | What it optimised for | Decision |
|---|---|---|
| Keep planning close to the week | Maximum responsiveness to the latest request | Rejected. It left priorities vulnerable to whatever arrived last and gave the team no dependable longer horizon. |
| Treat the roadmap as fixed | Predictability on paper | Rejected. It would ignore new evidence, customer needs, and the realities of a small company. |
| A shared but revisable product systemChosen | A credible shared commitment with an explicit route for change | Quarterly projects, one shared roadmap, clearer Linear conventions, more realistic commitments, and an assessed route for reactive work. |
That system had five parts:
- A longer planning horizon. Quarterly projects made company priorities explicit beyond the current week.
- One shared roadmap. Commercial, customer-facing, leadership, and technical colleagues could refer to the same direction rather than relying on separate assumptions.
- Clearer Linear conventions. Product intent, scope, sequencing, and delivery work were connected in the system the technical team used.
- More realistic commitments. I adjusted scope and planned volume over time, trading speculative roadmap breadth for commitments the team had a stronger chance of meeting.
- A route for necessary reactive work. New requests could still enter, but they had to be assessed against the committed work rather than displacing it by default.
Trade-offs
The central trade-off was volume versus reliability. A roadmap with more projects can communicate ambition, but it creates false confidence when the team cannot complete them in the promised period. Narrower commitments force harder prioritisation and leave some desirable work outside the quarter.
A shared roadmap also creates expectations. It has to remain clear enough for Sales and customers to understand while still being honest about uncertainty and open to stronger evidence. The aim was not to make change impossible; it was to make change an explicit product decision.
Execution
I introduced the roadmap, established and adjusted Linear working conventions, and connected quarterly company commitments to sequenced delivery work. I brought inputs from Sales, customer success, customers, engineering, data colleagues, and leadership into the prioritisation process, compared them against value, constraints, dependencies, and available capacity, then made the product scope and sequencing decisions.
I tracked whether each project completed in the quarter it was promised in, and used that result to set the next quarter’s commitments.
Engineering remained responsible for implementation. The CTO retained authority over resources, while I surfaced resource needs and owned the product decisions within that constraint.
Result and limits
Projects delivered in their promised quarter: 4 of 14 in Q3 2025, 4 of 6 in Q4 2025, 5 of 8 in Q1 2026, and 9 of 10 in Q2 2026.
Late projects shipped in the following quarter. No project was removed from the denominator.
The full sequence was:
| Promised quarter | Delivered in that quarter | Other outcomes |
|---|---|---|
| Q3 2025 | 4 of 14 | 7 late; 3 cancelled |
| Q4 2025 | 4 of 6 | 2 late |
| Q1 2026 | 5 of 8 | 3 late |
| Q2 2026 | 9 of 10 | 1 late |
“Delivered” means completed within the quarter promised. Late projects shipped in the following quarter. No project was removed from the denominator, and the three Q3 cancellations remain counted. The path was not linear: performance improved in Q4, slipped in Q1, then reached 9 of 10 in Q2.
The system also gave Sales clearer visibility into planned capabilities, helped technical colleagues feel heard, and let customers understand and shape upcoming work through customer-success conversations. Those are qualitative reports, not measured satisfaction outcomes.
I designed and led the product operating approach — owning prioritisation and planning, and making commitments more realistic over time. The CEO agreed the commitments and engineering delivered the projects, so the counts reflect team delivery, not the effect of any one person or practice.
Learning
The useful unit of roadmap quality is not how much work fits on it. It is whether the roadmap creates a credible shared commitment while leaving a deliberate way to respond when better evidence appears.
The non-linear quarterly history matters. Operating systems improve through repeated calibration: comparing promises with delivery, reducing speculative volume, clarifying scope, and carrying those lessons into the next planning cycle. Showing only the first and last quarters would make the result easier to market, but less useful as evidence of how the change actually happened.
Evidence note
This case study uses verified interview evidence covering product authority, the reactive starting state, the roadmap and Linear changes, the quarterly delivery counts, metric definition, and contribution boundaries. It contains no internal roadmap, ticket, customer identity, or commercial detail. The chart is a recreated representation of the verified counts.
Related work
Read Owning Product at Raffle AI for the company context and my wider Product Manager scope, or Scaling a Partner Channel for a focused example of turning commercial needs into reusable product infrastructure.