There is a debate running through product management circles right now. One camp says build to learn: get out of the building, talk to users, validate your assumptions before you write production code. The other camp says build to earn: ship something, generate revenue, let the market teach you.
Let Me Tell You What This Debate Sounds Like From Here
I was in a product review once where someone quoted Marty Cagan's advice about running weekly customer interviews before committing engineering resources to any new feature. Good advice. Sound principle. The same week, the CBN issued a revised circular on IMTO operations. My team spent three of the next five working days not talking to customers but instead reading regulatory documents, consulting our legal team, and determining which parts of our product roadmap were now undeliverable.[1]
That is not an edge case. That is the environment. And it is not a reason to abandon structured product thinking. It is a reason to adapt it β seriously, not superficially.
The "Build to Learn vs Build to Earn" framing originates with the Silicon Valley Product Group, popularised by Cagan (2018) as the distinction between product discovery, the work you do to decide what to build, and product delivery, the work you do to actually build and ship it.[2] Teresa Torres (2021) sharpened the concept further, arguing that discovery should not be a one-off sprint but a continuous habit, with product teams talking to actual users at least weekly to keep decisions grounded in real behaviour rather than assumptions.[3] Both of these contributions are genuinely useful. The problem is not the framework. The problem is when we import it without asking what the operating assumptions underneath it actually are.
The framework was not built for a market where a regulator can rewrite your product's legal architecture between your Monday planning meeting and your Friday sprint review.
Vasco Duarte (2025) argues, correctly in my view, that even within Western product practice, Cagan's model treats discovery and delivery as separable phases when they are in fact deeply entangled.[4] A finding from delivery constantly reshapes what you discover. A strategic constraint from compliance constantly reshapes what you can even attempt to build. That entanglement is already present in mature markets. In the African fintech context, it is more intense by an order of magnitude.
The Four Walls Closing In on the African Fintech PM
Before we can talk about discovery or delivery, we have to be honest about the specific constraints shaping every product decision in this context. I identify four of them, and all four interact.
1. Your runway is not a hypothesis; it is a countdown
African startup funding dropped to $2.21 billion across 488 deals in 2024, down from $2.86 billion the previous year.[5] Equity-specific fintech funding collapsed 64% to $221 million in the first half of 2024 alone.[6] Investors who were backing "growth at all costs" models in 2021 are now explicitly requiring revenue-driven businesses with solid unit economics before they write a cheque.[7]
What this means, practically, is that a fintech startup on a 14-month runway that runs a three-month, open-ended discovery sprint before building anything has consumed more than 20% of its survival window without generating a single transaction. That is not prudent product management. That is existential risk mismanagement. The teams that survived the 2023β2024 funding winter in Nigeria were not the ones that discovered the most. They were the ones who found revenue fastest while also discovering, not in sequence.
2. The CBN does not send calendar invites before it changes your product
Between January 2024 and March 2026, the CBN issued revised IMTO guidelines, new PTSA circulars, updated AML/CFT frameworks, revised foreign exchange market guidelines, and a mandatory automated transaction monitoring directive that required all fintechs to submit an implementation roadmap within 90 days of the circular.[8,9,10] In practical terms, a Nigerian fintech PM managed at minimum four major regulatory re-architectures in that window, each of which had the potential to invalidate product assumptions baked into prior discovery work.
The 2025 CBN Fintech Industry Report confirmed what every operator in this space already knew viscerally: 87.5% of Nigerian fintech companies say compliance costs limit their ability to innovate, and 62.5% report that regulatory timelines directly affect how quickly they can launch new products.[11] More starkly, over a third of operators reported product rollouts taking more than a year due to duplicative reporting requirements and unclear regulatory guidelines.[12]
88%of Nigerian fintechs say compliance costs limit innovation (CBN, 2025)
62.5%say regulatory timelines slow new product launches (CBN, 2025)
>β report product rollouts exceeding one year due to regulatory friction
500 million Africans still lack legal identity documentation (AfriCatalyst, 2025)
No discovery framework built for Silicon Valley budgets time for the "compliance pivot": that Friday afternoon when a new circular arrives and your entire Q3 roadmap suddenly needs legal review before anyone touches a line of code again.
3. Half your users have never been inside the funnel
Standard product discovery methods (user interviews, usability tests, app-based analytics, NPS surveys) all assume the same thing: that you have users you can talk to, who are already inside your product. But nearly 500 million Africans still lack legal identity documentation, which means they sit completely outside the onboarding flows that every fintech product assumes as its entry point.[13]
Think about what that means for a PM trying to validate a payment product. The users who most need the product are the ones who cannot clear your KYC flow because their NIN is still pending at NIMC, or their BVN was registered with a phone number they no longer have, or they simply do not have a formal address to submit. You will not find these users in your product analytics. You will not recruit them through your app's interview scheduling tool. Your discovery methods, as typically described, structurally exclude the population your financial inclusion mandate is supposed to serve.
KYC complexity deepens this. Each African market follows its own identity requirements, licensing rules, and AML procedures.[14] A product decision validated with urban Lagos users, who generally have BVN and NIN, will not transfer automatically to the trader in Onitsha or Kano market who manages a β¦2 million daily turnover through a mix of cash, POS, and bank transfers but cannot pass tier-2 KYC.
4. Your users' financial lives run on systems your product did not build
The majority of economic activity in Nigeria still happens in the informal sector. Trust, credit, and accountability in that sector flow through rotating savings groups (ajo and esusu), market associations, community lending arrangements, and human networks that predate every fintech app by decades.[15] If you are building a financial product for that population and your discovery work consists entirely of structured interviews and digital prototype tests, you are studying the people without studying the systems they actually use. You will produce insights that are technically accurate and operationally useless.
What "MVP" Actually Costs When the CBN Is Your Co-Founder
Eric Ries (2011) defined the minimum viable product as the version of a new product that allows a team to collect the maximum amount of validated learning with the least amount of effort.[16] That is a clean definition. It assumes that "minimum" is a technical and scope decision. In Nigeria, "minimum" is also a compliance decision, and the compliance floor is not low.
A fintech startup cannot ship a consumer-facing payments product in Nigeria without functional AML controls, tiered KYC, sanctions screening, and BVN or NIN verification infrastructure. The CBN has already demonstrated it will suspend the onboarding operations of firms with lax KYC systems.[17] So when someone tells you to "build something scrappy, test it with users, and iterate," they are not wrong in principle. They are wrong about the cost baseline. Your "scrappy" product still needs a compliance layer that a San Francisco startup would not build until Series A.
The core tension
The standard MVP logic assumes you can ship something incomplete and learn from it. A Nigerian fintech MVP that skips AML or KYC controls does not produce learning β it produces a CBN enforcement action. The "minimum" in your minimum viable product has a regulatory floor that most frameworks never account for.
The corollary is equally important: teams that over-rotate into pure discovery, conducting waves of user research without building revenue infrastructure, hit two walls simultaneously. The first is runway depletion. The second is insight obsolescence β the regulatory environment may have shifted by the time the team converts insights into features. I have watched startups in Nigeria run excellent discovery programmes, produce rich, well-documented user insights, and then find that by the time those insights could be acted on, the compliance requirements for the relevant product feature had changed enough to require a full re-evaluation. Learning without earning, under these conditions, is not just commercially dangerous. It can be temporally futile.
The False Binary, and Two Ways Nigerian PMs Fall for It
The discovery-versus-delivery framing is pedagogically useful and operationally misleading in equal measure. Duarte (2025) argues that Cagan's product operating model incorrectly treats strategy, discovery, and delivery as separable dimensions, whereas they are continuously entangled in practice.[4] The insight lands harder in our context, because the entanglement is tighter and the cost of separating them is higher.
Nigerian PMs tend to fall into one of two failure modes, both disguised versions of the false binary.
The first is perpetual discovery syndrome. The team runs beautiful research. They conduct community interviews, map user journeys, and produce insight decks with real quotes from real market women in Balogun. And then those insights sit in Notion while the team navigates a compliance backlog, handles an investor update, manages an engineer who just left, and generally fails to convert any of that learning into shippable product before the next regulatory cycle resets the context. This is not a research problem. It is a structural one: discovery and delivery were treated as sequential rather than parallel.
The second is a pure delivery trap. The team ships constantly, driven by a roadmap inherited from investor pressure or a founder's intuition. Features go live. Transaction volumes grow. But nobody is building the feedback infrastructure to detect whether the product actually fits the user's real financial context, or whether it is succeeding despite its UX friction rather than because of it. Kippa, the Nigerian bookkeeping and payments startup that raised $11.6 million before shutting down, demonstrated both failure modes in sequence. It found initial traction, then faced monetisation challenges with small merchants and intensifying competitive pressure it could not outrun.[18] The monetisation failure points to an underappreciated willingness to pay in the informal SME segment. The competitive failure points to a delivery speed that could not outpace that of well-capitalised rivals. Neither pure discovery nor pure delivery would have saved it.
A Context-Intelligent Discovery Framework for the African PM
What I am proposing here is not a rejection of discovery. It is a reintegration of discovery into the actual operating conditions of African fintech. I call it Regulated-Context Discovery (RCD). It has five components, and all five run in parallel, not in sequence.
The Five Components of Regulated-Context Discovery (RCD)
Compliance-First Hypothesis Scoping. Before any customer discovery activity, map the current regulatory perimeter. Which product hypotheses are testable within your existing licence? Which require pre-approval from CBN, NFIU, or NDPC? Prioritise hypotheses that sit within the perimeter. Do not run a discovery sprint that produces a feature idea you cannot legally build without a licence category you do not hold. The discovery work and the compliance boundary must be drawn together, not independently.
Analogue Immersion Before Digital Research. For any user segment operating primarily in the informal economy, do field immersion in the analogue financial systems your product intends to replace or augment. Study how ajo and esusu groups manage accountability and float. Observe how a POS agent in a market reconciles at the end of a trading day. Understand the trust mechanics of community lending. These systems encode user behaviour that no app-based usability test will surface, and they represent the financial logic your product must interface with, not override.
Compliance-Embedded Prototyping. Build your prototypes with the mandatory compliance elements from day one. KYC tiers, BVN or NIN integration, USSD fallback paths, and AML prompts are not post-discovery additions. They are part of the testable product surface. A prototype that omits the compliance layer generates user insights that do not transfer to the production environment, because the compliance elements change the experience materially.
Revenue-Signal Discovery. Given compressed runways and investor pressure on unit economics, every discovery activity must produce a revenue signal alongside a behavioural insight. Run pricing experiments, not just usability tests. Test willingness to pay for specific features before building them. Ask not only "does this solve a real problem" but also "will this user pay the price that our model requires to break even."
Regulatory Watch as a Product Input. Assign one person on the team, in smaller teams, this is the PM, to actively monitor CBN circulars, NFIU advisories, SEC guidance, and NDPC directives on a weekly basis. Treat new regulatory issuances as discovery inputs that revise your product backlog. A circular that changes KYC requirements is not just a compliance task for your legal team. It is new information about the feasibility constraint on every feature currently in development.
What the PM at Each Stage Needs to Do Differently
Pre-launch
Do not run a discovery sprint that produces outputs you cannot act on within your current compliance perimeter. Map the regulatory boundary first. Ask your legal team which features require which licence categories. Then scope your discovery to the hypotheses that sit within that boundary, because validating a product direction that your current licence forbids is not discovery. It is noise.
Go to the market. Not the metaphorical market, the actual market. Balogun, Onitsha, Wuse 2, Computer Village. Observe how your target users currently manage the financial problem you intend to solve. Run pricing experiments with rough concepts, not polished prototypes. And include the KYC flow in every prototype you test, because the KYC friction is a first-class part of your user experience, not a post-launch afterthought.
Early growth
Your delivery infrastructure is now your discovery instrument. Transaction patterns, agent feedback, and churn behaviour carry more signal than periodic interview campaigns at this stage. The question is whether you have built the capacity to read those signals. Run the Regulatory Watch component actively, because a new circular that changes your product's compliance requirements in months 8 or 12 is not a surprise β it is a feature of this environment.
Critically: commission willingness-to-pay experiments on your highest-cost features before building the next version. The 2024 funding environment has made it clear that investor patience for features without revenue signal is very limited.[7]
At scale (Series A and beyond)
You can now afford more structured discovery investment, and you should build it. But ensure your research function recruits from the full user population β not primarily from the urban, formally employed early adopters your product already serves. The next 20 million users will not look like your first 500,000. Cross-border expansion adds another layer of complexity: the CBN's 2025 Fintech Report identifies fragmented digital identity systems, high API costs, non-portable credit data, and fragile USSD infrastructure as structural barriers across African markets.[12]
The Tension the Global Debate Has Not Resolved
There is a gap in the global product literature that becomes visible the moment you read it from a desk in Abuja rather than San Francisco. Torres (2021) defines discovery primarily as an epistemic activity, connecting product decisions to genuine customer insight, generating the right product rather than a merely functional one.[3] Cagan (2018, 2024) incorporates viability risk, which he defines as the question of whether the business can actually deliver and sustain the product.[2] But viability risk in Cagan's model is primarily a business model question. It assumes a regulatory environment that, even if challenging, does not rewrite the product's legal architecture on a quarterly basis.
For the Nigerian PM, viability risk and compliance risk are often the same variable. A feature that solves a real user problem but was built into a product whose licence category was revised mid-sprint is not viable regardless of its user value. The discovery work and the compliance architecture must be built together, because the compliance environment is part of what you are discovering β it is not a fixed wall you are working inside. It is a moving one.
Nigeria's real-time payment infrastructure processed nearly 11 billion transactions in 2024. Behind that scale sits a hard reality: 50% of fintech operators describe the regulatory environment as enabling, while the other 50% describe it as a brake on innovation.[11] The same system, experienced differently depending entirely on whether your product is compliant, capitalised, and correctly licensed.
African fintech revenues are projected to reach $47 billion by 2028, roughly five times their 2023 level of $10 billion.[22] The PMs who capture the most meaningful portion of that growth will not be the ones who discovered the most, or the ones who shipped the fastest. They will be the ones who built organisations capable of doing both at the same time β under regulatory conditions that change faster than any quarterly planning cycle, and for users whose financial lives are more complex and more resilient than any research deck will fully capture.
Build to learn and build to earn are not opponent positions for the African PM. They are co-dependent activities that must run in parallel, filtered at every point by the current compliance boundary, and grounded in the analogue financial systems that your users already trust. The framework exists. The context demands that we use it honestly.
References
Central Bank of Nigeria. (2024, January 31). Revised guidelines of international money transfer services in Nigeria. CBN. cbn.gov.ng
Cagan, M. (2018). Inspired: How to create tech products customers love (2nd ed.). Wiley.
Torres, T. (2021). Continuous discovery habits. Product Talk LLC. ISBN 978-1736633304.
Duarte, V. (2025). Entangled dimensions: Why product strategy, discovery and delivery can't be separated. Substack. https://vascoduarte.substack.com/p/entangled-dimensions-why-product
Tech In Africa. (2025, February 18). African tech startups in 2024: Mergers, expansions, and funding challenges. techinafrica.com
Tech In Africa. (2025, June 30). Early-stage fintech funding trends in Africa. techinafrica.com
Tech In Africa. (2025, December 26). Nigeria & Kenya lead as Africa's Big 4 dominate 2025 funding. Tech In Africa. https://www.techinafrica.com/nigeria-kenya-lead-africa-big-4-dominate-2025-funding/
The Condia. (2026, March 15). Nigerian fintechs get 18β24 months to automate anti-money laundering checks. The Condia. https://thecondia.com/cbn-automated-aml-standards-fintech-banks-nigeria/
Mondaq / Udo Udoma & Belo-Osagie. (2025, March 17). An overview of Nigeria's regulatory landscape for fintech in 2024 and outlook for 2025. Mondaq. https://www.mondaq.com/nigeria/fin-tech/1598186
Mondaq / Udo Udoma & Belo-Osagie. (2025, April 8). An overview of the regulatory changes in the Nigerian banking & finance sector in 2024 and outlook for 2025. Mondaq. https://www.mondaq.com/nigeria/fund-finance/1608274
Finance in Africa. (2026, February 17). Nigeria's fintech regime split between speed and stability. financeinafrica.com
Central Bank of Nigeria. (2026, February 2). Shaping the future of fintech in Nigeria: Innovation, inclusion and integrity (CBN Policy Insight Series 2025). CBN. https://www.cbn.gov.ng/Out/2026/CCD/CBN_FINTECH_REPORT_.pdf
AfriCatalyst. (2025, June 4). Why financial inclusion still matters to Africa. africatalyst.com
Digipay Guru. (2025, November 24). Financial inclusion in Africa: Challenges, solutions and growth. digipay.guru
Techpoint Africa. (2026, March 19). POS agents made cash accessible. Now it's time to rethink them. techpoint.africa
Ries, E. (2011). The lean startup. Crown Business.
Global Legal Insights / SimmonsCooper. (2025). Fintech laws and regulations 2025 β Nigeria. globallegalinsights.com
WeeTracker. (2025, September 24). The 10 highest-funded African startups that failed. WeeTracker. https://weetracker.com/2025/09/24/highest-funded-african-startups-failed/
Rest of World. (2024, March 12). Moniepoint leads Nigerian fintech along with Chinese-backed OPay. restofworld.org
Moniepoint. (2025). The Moniepoint 2025 informal economy report. moniepoint.com
Fintech News Africa. (2025, March 13). Nigeria's fintech sector surges 70% despite challenges. fintechnews.africa