Why Cadana Rebuilt Their Product Three Times Before Finding Product-Market Fit
The hardest decision in startups isn’t whether to pivot—it’s knowing when. Pivot too early and you abandon something that might have worked. Persist too long and you waste resources on something that never will. Albert Owusu-Asare, CEO and Co-Founder of Cadana, faced this decision three times. In a recent episode of Category Visionaries, Albert shared the framework that helped him navigate three complete product rebuilds before finding product-market fit. This isn’t theory—it’s a replicable decision framework built from years of expensive mistakes.
The First Kill Signal: When Customers Don’t Exist at Scale
Cadana’s first product focused on helping African software companies distribute their products globally. The vision made sense, the market opportunity seemed massive, and the team executed well. But after a year of effort, they hit an unmistakable signal.
“We spent about a year trying to sell that product, and we just couldn’t find enough people who wanted to buy it,” Albert explains. This wasn’t a sales execution problem or a marketing failure. The fundamental issue was market maturity. “The market just wasn’t mature enough for it to be a venture scale business in that category.”
Here’s the framework that emerged from this failure: market maturity beats product excellence. You can build a perfect product for customers who don’t exist yet, or who exist in numbers too small to support venture-scale growth. The kill signal isn’t that zero customers want the product—it’s that you can’t find enough customers to hit venture milestones within a reasonable timeframe.
Albert’s specific criteria: after a year of active selling to a clearly defined ICP, if you can’t find enough customers to create momentum, the problem isn’t your pitch—it’s market timing. This is different from having ten customers who love the product but slow expansion. This is struggling to find even early adopters at scale.
The decision framework: If the market doesn’t have enough companies with the problem right now, and market maturity will take years to develop, kill the product regardless of how much you’ve invested in building it.
The Second Kill Signal: When the Problem Exists But Doesn’t Hurt Enough
After killing product one, Cadana pivoted into payments infrastructure. They built technology to improve payment acceptance rates. The product worked. Customers acknowledged the problem existed. But again, nobody would switch.
“We went into the payments infrastructure space because we realized that, okay, a lot of people have problems accepting payments. If we can help them accept more payments, then we solve the problem,” Albert says. The logic seemed sound until they tested it in market. “People weren’t actually losing that much money from payments not being accepted. So it wasn’t actually a big enough pain point for them to want to switch.”
This failure taught Albert a more nuanced framework: problem existence isn’t the same as problem intensity. Many B2B founders make this mistake—they validate that a problem exists without validating that the problem hurts enough to justify the cost, risk, and friction of switching solutions.
The specific test Albert developed: Can customers quantify how much money, time, or opportunity they’re losing to this problem? If customers can’t put a dollar figure on the pain, or if that dollar figure is smaller than your price point plus switching costs, you’re solving a nice-to-have.
The decision framework: If customers acknowledge the problem but can’t articulate significant financial impact, or if the pain isn’t acute enough to drive switching behavior, you’re building a vitamin, not a painkiller. Kill it and find a problem with measurable, expensive consequences.
The Discovery Signal: When Customers Volunteer the Expensive Problem
After two failures, Albert changed his approach to customer discovery. Instead of pitching solutions and gauging interest, he started with open-ended questions about where businesses were actually losing money.
“We started speaking to a lot more people and realized that actually the biggest problem that people had was not even accepting the payment. The biggest problem people had was everything that happens after you accept the payment,” Albert reveals. “That’s where businesses were actually losing the most money, and that’s where they actually needed the most help.”
This discovery came from asking better questions. Not “Would you use a tool that does X?” but “Where are you losing the most money in your payment operations?” The difference is subtle but critical. The first question validates your hypothesis. The second question discovers their reality.
The pattern that emerged: when customers volunteer a problem without prompting, describe it in financial terms, and immediately want to know if you can solve it, you’ve found something worth building. When Albert mentioned he could help with post-payment operations, customers didn’t need convincing—they needed implementation timelines.
The decision framework: Build when customers describe a problem in concrete financial terms before you mention your solution. The expensive problems reveal themselves when you stop pitching and start listening.
The Build Signal: Progressive Validation Through Each Iteration
What’s remarkable about Cadana’s journey isn’t just that Albert pivoted three times—it’s that each iteration got closer to the real problem. The first version validated that African businesses needed better infrastructure. The second validated that they’d pay for financial tools. The third found the specific financial problem worth solving.
“We basically built the entire product again, version three, to focus on that operations piece,” Albert explains. This third build wasn’t a shot in the dark—it was informed by two years of expensive education about what customers actually needed.
The learning compounded. Version one taught them about market maturity. Version two taught them about pain intensity. Version three combined those lessons into a product that addressed a mature market need with intense, quantifiable pain.
The decision framework: Each pivot should incorporate lessons from previous failures. If you’re not getting progressively closer to product-market fit with each iteration, you’re guessing, not learning.
The Validation Signal: When Growth Becomes Organic
The proof that Cadana finally found product-market fit came not from hitting arbitrary metrics but from how customers responded. “We currently work with over 400 businesses across 26 African countries,” Albert shares. This growth didn’t require aggressive sales tactics or heavy marketing spend—it came from solving a problem customers were desperately seeking solutions for.
After years of pushing products uphill, Cadana suddenly had customers pulling them forward. The platform now processes over $400 million in transaction volume annually. The difference between this and the previous iterations wasn’t execution quality—it was problem selection.
The decision framework: You’ve found product-market fit when sales cycles shorten, customer acquisition becomes easier, and growth starts feeling like surfing instead of swimming. If you’re still pushing hard after 12-18 months, you probably haven’t found it yet.
The Meta-Framework: Time-Boxing Validation
The underlying principle across all three of Cadana’s rebuilds was time-boxing. Albert didn’t persist indefinitely with any single approach. He gave each version roughly a year to show clear signs of traction, then made hard decisions based on evidence.
“It’s taken us quite a long time to get to the point where we’re at today,” Albert acknowledges. But that time wasn’t wasted—it was invested in learning what actually mattered to customers. Each failure made the next iteration smarter.
For founders facing their own pivot decisions, Albert’s framework offers a replicable approach: give yourself a clear timeline, define specific validation criteria, and commit to honest evaluation when the deadline hits. Persistence matters, but persistence without evidence is just expensive stubbornness.
The question isn’t whether to pivot—it’s whether you’re learning fast enough to make each pivot count.