11:FS FoundrySole product lead on a banking-as-a-service platform when its anchor client stepped back during COVID, and the pivot that followed

1. The Context

11:FS is a fintech consultancy. Over time, the team recognised that a significant portion of the work they delivered for clients was structurally similar: onboarding, identity assurance, KYC, accounts, lending, credit decisioning, all wired to different underlying providers but following common patterns. Rather than wait to be disintermediated, they decided to build the configurable platform they kept rebuilding from scratch, and expand from being a consultancy into a product business. That platform was Foundry.

They started with a partner: DNB Bank, Norway’s largest financial services group. The intent was to build out a new system for DNB but with the longer-term goal of turning it into a banking-as-a-service platform. In practice, the initial build ended up quite specific to DNB’s requirements.

I joined in early 2020 as a Product Lead, owning the customer and onboarding domains and supporting the other product managers on the team. The subject matter was technically deep: identity verification workflows, regulatory compliance pipelines, and credit decisioning logic, all of which required close collaboration with engineering and a genuine understanding of how the systems worked underneath.

2. The Problem

When COVID hit in March 2020, DNB retained their investment in the company but decided not to go live with the platform. There was too much uncertainty in the world to launch a new banking product. That left the team in a difficult position: a system built too closely around a single client who was not going to use it, at least not yet.

Over the following months, COVID and the commercial pressure it created led to redundancies across the product team. I remained as the sole Product Manager on Foundry.

The commercial challenge was a chicken-and-egg problem. Banks have long procurement cycles and would not trust a platform that had no other customers. But the platform had no customers because it had been built for one bank that had stepped back. Selling to other banks was not a realistic near-term path.

At the same time, the roadmap that had guided development was now pointing at a destination the team could not reach. Most roadmaps assume a known direction. You prioritise features against a strategy, sequence work, and ship. When the strategy itself is uncertain, that model breaks. You cannot tell a team “we are building X” when X depends on a commercial outcome that has not happened yet.

3. The Decision-Tree Roadmap

I needed to give the team a way to work with purpose when the destination was uncertain. The approach I took was to map out the decision space rather than pick a single path and pretend it was certain.

Instead of a linear roadmap, I built a decision-tree roadmap. It captured the key commercial scenarios we might face and traced each one forward to its development implications. If DNB resumed, the priorities looked one way. If a new client signed in a different market, they looked another way. If neither happened in a given timeframe, there was a third path focused on capabilities that kept options open regardless.

Each branch was grounded in real commercial conversations that were happening at the time. The roadmap made the dependencies explicit: this work matters if this deal closes; this work matters regardless; this work only matters if we pivot to multi-tenant.

Internally, this was the working document. The team could see why their current sprint mattered under multiple scenarios, not just one. That removed the paralysis that comes from not knowing which future you are building for.

Externally, I maintained a separate linear version for stakeholders who needed a simpler story. It showed the most likely path and the next quarter’s priorities without exposing the full branching logic. Both versions were true; they served different audiences.

Product thinking: A roadmap that assumes certainty in an uncertain environment is not a plan. It is a guess with formatting. The decision-tree approach made the uncertainty visible and workable instead of hiding it behind a confident-looking timeline.

4. The Pivot

The decision-tree roadmap had already mapped the multi-tenant scenario as one of the branches. When that scenario played out, the groundwork was already laid.

The pivot was to target non-banks: fintechs, embedded finance providers, and companies that wanted to offer financial products without becoming banks themselves. These organisations had shorter procurement cycles, lower trust barriers, and an immediate need for the kind of configurable infrastructure Foundry could provide. It was the way to break the chicken-and-egg problem: build a customer base outside banking, then use that traction to re-enter conversations with banks from a stronger position.

I shaped the product roadmap for this transition, repositioning Foundry as a “Financial Services OS.” This meant rethinking how the product was packaged, how tenants were isolated, and how new clients could onboard without bespoke delivery for each one. The platform needed to go from something built around one bank’s requirements to something configurable enough to serve organisations the original design had never anticipated.

The pivot produced concrete outputs: a developer portal that gave prospective clients self-service access to the platform’s capabilities, and pre-configured product templates (branded as 11:Money) that let non-bank prospects launch financial products faster.

5. What It Required

The work was holding direction for a team when the commercial ground was shifting underneath them.

It required staying calm when there was genuine reason not to be. It required giving the team honest context about the uncertainty without letting that uncertainty become paralysing. And it required building planning tools that treated uncertainty as a structural input rather than something to be papered over.

In the months before the team contracted, I mentored the other product managers, supporting their growth into independently owned product workstreams.

The hardest part of product leadership is making progress legible to a team when the options themselves have not settled yet.