The Context
Spiko is a regulated financial institution based in Paris and London, building the infrastructure that lets businesses and individuals put their cash to work.
As of writing (August 2026), our product team has fewer than ten engineers. Each is an A+ full-stack generalist, able to work across the entire stack with a solid understanding of all of Spiko. So far, this team has delivered an exceptional outcome: more than $300M of cash held on the platform for every single engineer.
But we felt we needed to change the way we operated, for two main reasons:
- AI has already drastically changed the product delivery lifecycle, and the pace of that change will only increase.
- Spiko is scaling very fast. We’re growing 20% every month, which means more footprint, more features, more users, more markets, more financial products, more distribution channels.
We decided to rebuild how our product org works. In this blog post series, we will share how this transformation unfolds. In this first post, we want to share the first big change: our engineers now own product decisions.
Why We Think the PM and Software Engineer Roles Are Converging
Taking a step back, we wanted our new org to reflect a few strong convictions.
The first is obvious: pure implementation work is soon going to be a commodity because of AI, while product judgement and technical architecture will matter more and more.
The second conviction is that there is no faster way to solve a problem than by giving a single team member end-to-end ownership of it. This means reducing coordination work as much as possible and giving team members very strong ownership over their area of work.
The third conviction is that product judgement and technical judgement can both be owned by exceptional engineers. At the end of the day, it comes down to the same thing: understanding deeply the user’s problem and the real cost of every possible solution.
If you believe in these three convictions, then the conventional Product/Engineering setup stops making sense. That old setup was: hire roughly one PM for every five engineers, have them identify the biggest problem in their area as well as the best solution to that problem, and then let engineers implement it. The new setup is: product and software engineering are merged in a single role owning the feature end-to-end.
We call that role the Product Engineer.
What a Product Engineer Owns
At Spiko, the product feature delivery lifecycle has six steps:
- Scoping. Problem understanding, user research, compliance discussion, risk identification.
- Solution design. We consider every hard trade-off and all the edge cases.
- Tech studyboard. This is our internal name for the written architecture and domain-modelling decisions.
- Implementation. The actual pull requests on the codebase.
- QA and product review. Testing the feature before release.
- Release and success analysis. Ship it, then check that customers actually use it.
All six steps are now owned by the Product Engineer. This means that we now expect engineers to run user interviews, give design feedback, weigh a compliance constraint against a UX one, and make sure that their features are used.
That has to show up in how we hire and review. We now assess product skills during our hiring process, and product thinking is part of how we evaluate engineers’ performance. Reporting lines stay within engineering, though: an engineer’s lead is always a more senior engineer.
The Business Scopes This Sits On
There’s an obvious tension between hiring full-stack generalists and building deep ownership of a single vertical. Two years ago our stack was small enough that every engineer could genuinely hold all of it in their head. That stopped being true some time ago. We’ve decided to keep the generalist mindset but add owners: everyone can still contribute everywhere, but every part of the stack will have someone accountable for it.
This is probably the least original part of our setup: we’re now organising our stack into scopes, each full-stack, each owned by at least one senior or staff product engineer who acts as its main architect and the default reviewer of every PR inside it. As of today, we have eight scopes:
| Scope | What it covers |
|---|---|
| Fund operations | Order execution, net asset value of the funds, new products |
| Payments | Deposits and withdrawals across banking and stablecoin rails |
| Distributors | The embedded and API experience for partners |
| Compliance | Onboarding, KYC, AML scoring, screening |
| Accounting | Statements, tax, third-party integrations with TMS and accounting tools |
| Growth & support | Landing page, customer care, CRM integration |
| Blockchain | Networks, wallets, self-custody, DeFi integrations |
| Platform & reliability | Infra, eventing, CI, observability, auth |
Junior product engineers belong to several scopes rather than owning one. We expect them to contribute more and more to a few given scopes as they grow into our org, so they can become scope owners when they reach senior level.
What’s Next
Two months in, we strongly believe this is the right framework. We have already shipped major features this way, including the €500K instant withdrawal facility and our stablecoin rails.
There is still a lot to do: train the product muscle of our engineers, clarify the role of the scope owner versus the business owner, and more.
But there’s one big question the team keeps coming back to: what happens to the PM role in this new world? Do we actually need PMs at all? Short answer: yes, but fewer of them. More on that in our next post!