Building the Operating System at receeve

The situation

receeve was built to modernise debt recovery for financial institutions — an industry that had barely changed in decades, with major banks and lenders still running on legacy processes and disconnected tools. The proposition was strong. The customers were serious: tier-one European financial institutions with demanding compliance, security, and delivery requirements.

From the start, the stakes were asymmetric. Winning a major financial institution means a long, careful procurement cycle and a high bar to pass. Losing one — through a failed delivery, a missed commitment, or a product that couldn’t keep pace — means more than a lost contract. In this sector, reputation is everything.

The question wasn’t whether to build a product organisation. It was what kind. Enterprise B2B fintech at scale is not the environment for startup playbooks. The teams that fall back on estimation theater, roadmap politics, and velocity metrics are the ones that eventually buckle under customer pressure.

The approach

The product and engineering organisation was built from first principles — not borrowed from a methodology intact, but designed around the specific pressures of the environment.

The core engine was a customised Shape Up system adapted for enterprise constraints. Basecamp’s Shape Up is brilliant for what it was designed for: a small, autonomous team with no external commitments. receeve operated in a different reality. Tier-one financial institutions expected roadmaps. Sales had made commitments. Compliance and integration work didn’t fit neatly into 6-week cycles.

So the system evolved to handle those realities without abandoning the discipline at the core. A thematic roadmap gave customers and stakeholders the direction they needed without false precision. A two-horizon betting table separated urgent triage from strategic selection. A dual-track system ran Shape Up cycles for product increments alongside a Kanban board for integration and service-layer work — so customer commitments could be met without disrupting the product team’s cadence.

Appetite-weeks replaced story points. Every bet was denominated in real capacity — the number of people multiplied by the working weeks in a cycle. No estimation theater. No planning poker. No velocity arguments.

Pre-agreed disruption rules set ARR-based thresholds for acceptable mid-cycle interruptions. When a disruption met the threshold, it was handled cleanly. When it didn’t, the answer was no — and the rule absorbed the conversation.

This system held through six years of continuous growth. The organisation scaled from a single hire to 38 people in Product and Engineering without losing the ability to ship on a predictable cadence.

The outcome

In six years, the system produced two cycle disruptions. That number matters more than it might appear. It means that in roughly 36 six-week cycles, the delivery cadence was broken twice. Not because the team was lucky or the customers were easy — because the system was designed to absorb pressure.

Revenue grew at 100% year-on-year in the first several years. The customer base expanded to 33 countries. Tier-one financial institutions — organisations not known for rapid procurement or generous tolerance for delivery failure — became core clients and stayed.

The operating system became the subject of the Shaping Enterprise field guide: a 35,000-word documentation of the mechanisms that made it work, written for other CPOs and product leaders facing the same pressures. Not theory. The system that ran in production.

What this illustrates

The pattern that broke product organisations at this stage and in this sector was always the same: a methodology imported from a context it wasn’t designed for, force-fitted onto enterprise realities, and held together with heroics.

The alternative is to build the operating system deliberately. To treat the way the team makes decisions, absorbs customer pressure, manages capacity, and communicates direction as a design problem — one with a right answer and wrong answers.

When the operating system is right, the team doesn’t need to be exceptional every day. They just need to follow the system. Exceptional outcomes come from good systems, not from heroics repeated indefinitely.

---

If you’re scaling a product organisation under enterprise pressure — customers with contracts, sales making commitments, boards expecting a roadmap — this is exactly the problem fractional leadership is built for. Let’s talk.