The Mission: Turn Five Products Into a Real Product Organization

In January 2026, I joined Roamtech as Head of Product, reporting to the CTO. Roamtech is a Kenyan fintech and telecom company running five live products across three very different domains — and when I arrived, there was no structured product function behind any of them.

No PRDs. No consistent tooling. Ad-hoc delivery. No planning cadence. Teams distributed across Kenya, Dubai, the UK, and Serbia, each working off whatever process had accreted over the years.

The mandate was simple to describe and hard to execute: build a modern product organization from scratch, without stopping the trains that are already running.

Roamtech

The Challenge: Five Products, Three Domains, Zero Product Function

Roamtech’s portfolio spans three very distinct areas of the African digital economy:

Payments

  • PayKit — payment infrastructure and SDK
  • Senti — consumer payments

International Money Transfer

  • TumaTuma — remittance corridor (MVP: B2C UK-to-Kenya via open banking)
  • Afrisend — cross-border money movement

Communications

  • Emalify — messaging APIs platform, with WhatsApp Business API integration as the flagship initiative

Five products. Three domains. Four countries of engineering and product staff. And no shared definition of what “done” meant, how work got prioritized, or how decisions got made across teams.

What I Built: The Operating Model

The first job was to give the product org a shared spine — a way of working that every team, regardless of domain, could plug into.

  • Empowered-team operating model — established a working model grounded in SVPG principles, making clear where product, engineering, and design own decisions versus where they escalate.
  • Tooling migration: JIRA → Linear — moved the entire product org off JIRA and onto Linear, with structured workspaces, issue hierarchies, and labels per team.
  • Workspace audits — ran reviews across all five teams to establish minimum standards for board hygiene: no orphaned issues, no stale in-progress work, everything traceable to a PRD.
  • “No PRD, No Luck” — introduced a hard rule: no PRD, no engineering resources. This ended the pattern of half-specified work landing in sprints and blowing up mid-delivery.
  • Weekly product update cadence — built a company-wide rhythm for product visibility, so leadership and non-product teams could always see what each of the five teams was working on and why.
  • Product wiki in Notion — created an operating documentation hub: principles, templates, how we plan, how we ship, how we make decisions.

What I Built: Planning & Delivery

With the operating model in place, the next step was to prove it worked by driving a real planning cycle through it.

  • Q2 2026 planning cycle — led stakeholder intake, PRD reviews, and grooming sessions across all five teams. First time the company ran a synchronized planning cycle across the full product portfolio.
  • TumaTuma MVP kickoff — scoped and launched the UK-to-Kenya remittance MVP, built on open banking rails, as the first new product effort under the new operating model.
  • WhatsApp Business API for Emalify — got the integration approved and moving through delivery, unblocking a key initiative that had been stalled.
  • PayKit architectural rewrite — identified and flagged a core PayKit module as a candidate for rewrite, and built the case for prioritizing it in the roadmap.

What I Built: People

An operating model is only as good as the people running it day-to-day, so a large share of the work has been investing in the team.

  • Onboarded new Product Owners — brought new POs up to speed on the operating model, their domains, and their teams.
  • Team transitions — managed handovers where existing POs shifted between products, keeping delivery stable through the changes.
  • Hiring — ran active processes for a Senior Product Owner and a Senior UI/UX Designer, from sourcing through interview loop design.
  • Sales onboarding to Linear — brought the Sales team into Linear with structured training, so customer requests and feedback could flow into the same system the product teams work from.

Key Themes: What This Role Is Really About

Zero-to-one product org building. The products already existed. The product function did not. Most of the work is organizational design, not feature design — deciding how a product org operates when there wasn’t one before.

Operating across three very different domains simultaneously. Payments, remittance, and communications each have their own regulatory, technical, and go-to-market shapes. The operating model has to be opinionated enough to be useful and flexible enough to not flatten those differences.

Remote leadership across four countries. Kenya, Dubai, UK, Serbia. Async by default, with deliberate synchronous moments. Tooling (Linear, Notion, weekly updates) is the scaffolding that makes this work.

Modern product practices meeting an org that ran on ad-hoc delivery. The goal isn’t to impose process for its own sake — it’s to replace tribal knowledge and heroics with patterns the team can rely on, so good outcomes stop depending on which individuals happen to be in the room.

Why This Role Matters to Me

Most product leadership jobs ask you to optimize an existing system. This one asks you to build the system itself — while five products and their teams are mid-flight. It’s the combination of zero-to-one organizational work, cross-domain product complexity, and genuinely international, remote leadership that makes Roamtech the most ambitious product role I’ve taken on.

The work is ongoing. The operating model is live, Q2 is in delivery, and the next chapter is about proving that empowered teams can ship better outcomes than ad-hoc delivery ever did.