When you join a company as its first PM and the founders have been making every product call for years, your first job is not to add structure. Your first job is to not break what is already working.
Most first-PM hires get the order wrong. They arrive with a playbook from a previous role at a 50-person product org and start importing Jira workflows, OKR cadences, sprint rituals, PRD templates. Three months in, the velocity has halved, the founders are doing PM work around the new PM, and nobody is sure what the new structure was supposed to solve.
I joined Kkiapay in 2024 as its first Product Manager. SaaS payments aggregator, four UEMOA countries, 50 million+ transactions a month, founder-led product. I left two years later. The product function is now a team of three PMs running the structure we built together. This article is what we built, what we deliberately did not build, and what I learned about being the first PM at a company that did not need one to work, but needed one to scale.
The state I inherited
Kkiapay had been growing for several years on a model I now think is underrated: founder-led product with high customer empathy. The founders came from operator and merchant backgrounds. They knew the rails. They knew the pain points. They had personal relationships with the biggest merchants. The roadmap was whatever the next call with the next merchant produced, filtered through a small group of senior engineers who knew the system deeply.
It worked. It also had three problems that were visible from week one.
- Discovery was not absent, it was sporadic. Some weeks the founders did five merchant calls. Other weeks they did zero. Whichever week the next sprint planning fell on determined the priorities.
- Delivery was fast but illegible. The team shipped daily. Nobody outside the engineering room could tell what was about to ship in two weeks, which made the CODIR unable to plan quarterly.
- Country priorities silently competed. Four countries, four different sets of operator partnerships, four different regulatory contexts. Each country lead was advocating for their roadmap to a CODIR that had no shared model of how to arbitrate.
None of these were emergencies. All of them were already producing low-grade waste that would compound as the team grew from five engineers per country toward fifteen.
The principle I imposed on myself before adding anything
I wrote this on a sticky note in week two and looked at it before every change I introduced:
Add structure where the absence is currently costing us. Nowhere else.
The temptation as a first PM is to import the playbook you used at a 50-PM company. The playbook assumes problems that small product orgs do not have, and creates the friction that those problems were the price of. The right question is the inverse: what is the smallest structure that solves the actual problem we have, without creating the problems we do not have yet?
The four structures that survived eighteen months of trying to delete them are the four below.
Structure 1. Voice of Merchant, 90 minutes a week
I did not formalise discovery. I made it weekly.
Every Tuesday at 10am, 90 minutes. Three to five merchant conversations from the prior week, transcribed or summarised by me, shared with the engineering leads, the country leads, and the customer success team. No backlog grooming. No Jira tickets opened in the meeting. Just shared narrative: what are merchants saying this week, what changed since last week, what surprised us.
The mechanism was deliberately lightweight. The output was a Notion page per week, three to four paragraphs, with one section labelled “decisions we should consider this quarter.” The decisions section was the only part the CODIR cared about. The rest was context the team needed.
Two compounding effects, both visible by month four. The engineering team started referencing “the Voice of Merchant from last week” in design reviews, without me being in the room. The country leads started reading each other’s sections and noticing that what their merchants wanted was often already being solved in another country. The shared narrative replaced what would otherwise have been my job as a translator.
Structure 2. A two-week delivery cadence, not a sprint
The founders had been shipping daily. I did not try to fix that. Daily shipping at 50 million transactions a month is not a problem. It is a feature that took years to earn.
What I added was a two-week checkpoint. Every other Thursday, a 45-minute meeting with eng leads and country leads. Three questions, in order:
- What shipped this cycle that matters?
- What did not ship that we expected to, and why?
- What are we shipping in the next cycle that the CODIR should know about?
No sprint planning. No retrospectives unless something broke. No Jira boards. The output was a single email to the CODIR with the three answers, written by me on Thursday afternoon, read on Friday morning.
The point was visibility, not control. The CODIR needed to be able to plan a quarter. The team needed to keep their daily shipping cadence. The two-week checkpoint was the smallest interface between those two needs.
Structure 3. A CODIR roadmap that arbitrates, not aggregates
This was the hardest structure to introduce because it required the country leads to accept that not all of their priorities would survive the quarter.
The old roadmap had been an aggregation: each country lead listed their top five priorities, the CODIR approved most of them, the team shipped the intersection. The result was a roadmap that was long, contradictory, and impossible to deliver on, which produced the worst possible outcome where everyone felt unheard despite having had their items listed.
The new format had four parts, in this order:
- One shared global goal for the quarter. One metric, one number, one definition of success that all four countries committed to moving together.
- One country-specific priority per country. Not five. One. The country lead chose which of their five mattered most, knowing the other four would not get shipped this quarter.
- One explicit non-goal per country. The thing we are NOT doing in this country this quarter, written down, read aloud at the CODIR, signed off. This was the most uncomfortable part of the meeting and the one that earned the format its credibility.
- Two infrastructure investments shared across countries. The platform-level work that makes the next quarter possible.
The forcing function was the “one country-specific priority, one explicit non-goal” format. The country leads pushed back hard the first quarter. By the third quarter, they were arriving with their non-goals already chosen, because the exercise had taught them which priorities were vanity and which were real.
The trade-off becomes acceptable when the system makes the constraint explicit. We can not do X this quarter because we chose Y for the shared goal. That sentence is the entire art of a CODIR-level roadmap.
Structure 4. The Merchant Sync that replaced ten Slack threads
The hardest part of running product at a payments aggregator is not building the right thing. It is keeping engineering, sales, and customer success aligned on which merchant pain is worth moving on this week.
Pre-PM, this coordination happened in roughly fourteen overlapping Slack threads, plus side conversations, plus the founders privately deciding and announcing. The waste was not the decision-making, which was usually correct. The waste was that nobody had a shared map of why decisions were being made.
I replaced the threads with a 30-minute weekly Merchant Sync. Five people: eng lead, sales lead, customer success lead, country lead from the most affected country that week, and me. Each person brought one blocker they had heard from a merchant that week. Five blockers, six minutes each, ranked at the end of the meeting.
The ranking went to the engineering lead, who decided what to do with it tactically. Some weeks the top blocker became the next sprint priority. Other weeks it informed the messaging for the sales team. Either way, the five people who needed to know what was happening at the merchant level all heard the same things, at the same time, in the same order. That was the entire output.
The AI builder reality, in parallel
The job description for a senior PM in 2025 changed in a way most org charts have not caught up with. Through the two years at Kkiapay, I shipped six AI products in production as the builder, not just the PM:
- Mimics, an AI workflow for video creators
- Justixia, an AI legal assistant for OHADA jurisdictions
- PM Agent, a RAG-based product coaching system
- Enutri, a childhood-nutrition app for francophone West African families
- EqualHome, a couples app for domestic labor balance
- Zinvest, an investment access platform
None of these were side hustles, in the sense that they did not compete with the day job for cognitive priority. They informed it. The thing I learned by writing the code for six products is that the discovery-to-decision loop, when the PM can prototype directly, compresses by roughly ten times. A merchant says something on Tuesday, I prototype a possible response by Tuesday evening, the engineering team sees a working artifact on Wednesday, the design choice is made on Thursday instead of three weeks later.
At Kkiapay specifically, this changed how I worked with engineering. Instead of writing a PRD describing a feature, I would write a Claude-Code-built prototype showing the feature roughly working, hand it to the engineering lead as a conversation starter, and let them decide what to keep, what to rewrite, and what to drop. The PRD compressed from a six-page document to a thirty-line note attached to a working prototype. The conversation started in a much better place.
The PM who cannot code in 2026 is increasingly handicapped, not because writing code is the job, but because writing prototypes is the new shape of the spec.
What I learned about being the first PM
Three lessons, in roughly decreasing order of how often I would tell them to another first PM hire.
1. The first PM is a structure subtractor, not adder. The default mental model is wrong. Your first job is to find the friction that already exists in the founder-led model and reduce it. The structure you introduce should be the smallest possible thing that solves an actual problem the team is feeling. Anything more is overhead the team will resent and route around.
2. Multi-country roadmaps are arbitration frameworks, not feature lists. If your roadmap aggregates country priorities, you have built a wishlist that no one can deliver. If your roadmap arbitrates them with one shared goal, one country-specific priority, and one explicit non-goal per country, you have built a tool that lets the CODIR plan a quarter. The difference is the entire reason a multi-country product org has a PM at the top of it.
3. The PM who ships AI prototypes compresses the discovery-to-decision loop by a factor of ten. This is the change in the role I find most under-discussed. Six products in 2025, all coded directly, all informing how I ran product at the day job. The PM and the builder are not two career tracks anymore. They are the same person doing the same job, with the same constraints, at different scales.
Closing
I left Kkiapay this year to focus on building and advising. The product function is now a team of three PMs running the structures I described above. The Voice of Merchant happens without me. The CODIR roadmap is being arbitrated by someone else, with the same format. The Merchant Sync is on its second iteration, with a sixth participant added because customer success doubled.
The product is what survives the person. Two years in, the Kkiapay product function survives. That is the test.