#118 - MyOneApp and the Edsel Problem

Ford’s most famous failure and what it tells us about managerialism, tech ambition, and Safaricom’s FinTech 2.0 moment

Illustration by Mary Mogoi

Hi all - This is the 118th edition of Frontier Fintech. A big thanks to my regular readers and subscribers. To those who are yet to subscribe, hit the subscribe button below and share with your colleagues and friends.

---

Introduction

On April 2nd 2025, Safaricom unveiled MyOneApp at its annual Decode engineering summit; a unified platform merging the M-Pesa app and the MySafaricom app into a single interface, complete with 80 mini-apps, an AI-powered receipt scanner, and the explicit ambition to become Kenya’s answer to WeChat. Peter Ndegwa, Safaricom’s CEO, called it the consumer face of FinTech 2.0. Within days of launch, Safaricom’s own communications acknowledged that “most of the financial mini-apps services are not working.” Users reported frozen transfers, invisible balances, and a SIM dependency that locked out the diaspora customers M-Pesa had spent years courting.

I was a victim of this debacle. All of a sudden, I found myself as a squatter on my own phone asking to be let back into my compound. I have an M-Pesa line and a separate line for my data and calls. Also, as someone who works from home, I’m always on WiFi and barely ever on network data. To access M-Pesa, I had to switch on network data, make my M-Pesa line my primary line and jump through a few other hoops before I could make a simple payment. What’s worse is that my saved payments had disappeared in this upgrade. The entire experience to me was baffling. For sure, half a year ago, Safaricom seemed to have sunsetted the old “MySafaricomApp” and slowly integrated its features into the M-Pesa app. With a single swipe, I could toggle between M-Pesa’s features and traditional functionality such as buying airtime. To me then, the entire idea of a new unified platform was confusing because from a user perspective, the entire thing was already unified.

Having said that, the logic behind the unification was a deeper infrastructural one. Safaricom was upgrading the underlying M-Pesa system with upgraded transactional capabilities and features including AI-driven personalisation and mini-app features. It was part of the big-move towards Fintech 2.0 and the broader idea of Safaricom being a technology company. I’m happy to report that I’m no longer a squatter on my own phone. Safaricom has since fixed all the access issues. I’d never write an entire article about my inability to log into my M-Pesa. The broader issue is one of Safaricom’s stated ambitions of being a tech company and what this bungled upgrade says about where Safaricom is in that journey.

To understand how this happens; how a company with over 35 million active users, 800 internal developers, and years of preparation ships a broken product to a press audience and calls it a super app, it is worth spending a moment in postwar America. We’ll compare the MyOneApp launch with a story about a failed product launch from Ford Motor Company in the late 50s. We’ll then discuss what it takes to be a tech company before honestly evaluating Safaricom and M-Pesa’s trajectory. There are a lot of vital lessons about managerialism, focus and the role of innovation in an ever changing world.

Ford and the Edsel Disaster

By the early 1950s, the United States was in the middle of one of the most sustained economic expansions in its history. Returning veterans were buying homes in new suburbs, filling them with appliances, and replacing cars with a regularity that would have seemed extravagant to their parents’ generation. Between 1945 and 1955, American car sales nearly tripled. Detroit had become, in the words of one contemporary observer, the city that built the country.

At the centre of this world was a particular theory of how corporations should be run. Alfred Sloan had built it at General Motors across the 1920s and 1930s; a system of divisional management, financial discipline, and hierarchical coordination that was so successful it became the template for the modern large corporation. Under Sloan’s framework, GM had structured its brands as a ladder: Chevrolet at the entry level, then Pontiac, Oldsmobile, and Buick, with Cadillac at the top. The idea was simple and elegant. As Americans grew richer, they moved up. Each brand existed to catch them at the next rung. Ford, watching GM accumulate market share, concluded it had a ladder problem. It had an entry-level brand and a luxury brand. It had nothing in between substantial enough to hold the aspirational middle. The solution, ratified by Ford’s planning committee in 1955, was a new car; internally named the E-Car, for Experimental, that would slot between Ford and Lincoln and capture the buyers GM’s Oldsmobile and Buick were harvesting. The project was assigned its own division, its own leadership, its own dealer network. On paper it was a complete strategic response to a real competitive problem.

Image Source: Road and Track

What followed was one of the most elaborate product development processes in American industrial history. Ford commissioned Columbia University’s Bureau of Applied Social Research to conduct motivational studies. These weren’t structured as surveys asking what people wanted in a car. Rather, they were deeper investigations into what car ownership meant psychologically, what aspirations different models activated, what kind of person each brand suggested its driver to be. They engaged the poet Marianne Moore to propose names; she submitted suggestions including “Utopian Turtletop,” “Mongoose Civique,” and “Andante con Moto.” A shortlist of several thousand names was eventually narrowed to four serious candidates. The research was, by the standards of the era, exceptionally thorough. The pre-launch advertising campaign that followed was equally ambitious; months of teaser advertisements that refused to show the car, building anticipation toward what Ford internally called E-Day: September 4th, 1957.

Ernest Breech, Ford’s chairman, presided over the meeting at which the final name was chosen. He looked at the shortlist and dismissed it. The car would be called Edsel, after Henry Ford’s only son, who had died in 1943, over the explicit objections of the Ford family, who had asked that the name not be used on a product. The research, the poet, the thousand-name shortlist: none of it mattered in that room. The decision had already been made.

Image Source: Studebaker Museum

E-Day arrived to enormous public attention. The actual car arrived with oil leaks, doors that would not close, push-button transmissions mounted in the steering column hub that jammed or failed, and, most visibly, a vertical grille that critics compared to a toilet seat and a man sucking a lemon simultaneously. The quality failures were structural: Edsels were being assembled on the same production lines as Fords and Mercurys, with line workers switching between models and no one specifically accountable for Edsel build standards. Within the first year, sales came in at less than a third of projections. Ford killed the brand in November 1959, twenty-six months after launch. Total losses run at approximately $350 million.

John Brooks, who told the Edsel story in Business Adventures with access to the executives involved, made some observations that stayed with me. The research had not driven the decisions. The name had been chosen in spite of it. The pre-launch hype had committed the organisation to a date the product was not ready to meet. The divisional structure had ensured that the people whose careers depended on the car had no incentive to escalate concerns that already existed internally, and concerns did exist. Quality problems on the assembly line were known before E-Day. The market shift toward compact cars was visible in the data. The 1957 recession, which crushed mid-priced car demand precisely as the Edsel launched, was not unpredictable. None of it penetrated the decision-making process in time to change anything. The organisational commitment to stick to E-day and the inability to share negative but correct information within the org created what Munger would call a Lolapalooza effect. A compounding negative spiral that led to the Edsel disaster.

At the core of it, this is what managerialism looks like in its operational form. It is not a story of incompetence. The people who built the Edsel were experienced, serious professionals working inside one of the most sophisticated industrial organisations in the world. The failure was structural: an incentive system that rewarded launch over product quality, an information architecture that filtered bad news before it reached the executives who could act on it, a research process that generated enormous volumes of consumer insight that was then set aside when a chairman decided he preferred a different answer, and a commitment device; the E-Day campaign, that made course correction organisationally impossible once doubts had crystallised. In effect, managers were individually making the right call if the objective function was surviving within the org. The aggregation of these mis-aligned incentives led to a disaster. The Sloan system, which had been so effective at scaling and managing a known business, had produced an organisation incapable of the honest self-examination that a genuinely new product required.

Ford recovered. The Mustang arrived five years later and became one of the most successful product launches in automotive history, driven by a small team, operating with unusual autonomy, anchored in a specific and observed customer insight rather than a strategic planning committee’s theory of market segmentation. The contrast is instructive.

That is the pattern worth holding as we look at what Safaricom built, and how it chose to launch it.

Safaricom’s Edsel Moment

The rationale for upgrading the M-Pesa system makes sense although the Mini-App structure is debatable. Mobile Money as we wrote a few weeks ago is close to 20 years old. It’s no longer a new and exciting thing. In business terms, it’s well past its mid-life. From a tech perspective, the next wave of MoMo has to run on modern architecture and not the Mobiquity’s of a decade ago. Safaricom therefore had a really strong reason to upgrade the infrastructure. The super-app story to me is debatable as I’ve written before that there’s little in the way of a business case for a super-app in Africa. The conditions simply don’t exist. The mini-app story then is simply a vendor driven decision that is cascaded down into organisational KPIs. It’s Conway’s law in reverse where tech capabilities drive commercial and organisational design.

Safaricom Decode Summit - Image Source

Nonetheless, the need for new infrastructure, the need for mini-apps and the apparent need to consolidate Safaricom and M-Pesa functionality drove the need for MyOneApp. It was unveiled at Decode 4.0, built on cloud-native infrastructure rated at 6,000 transactions per second and hosting more than 80 third-party services. The internal rationale, as an engineer close to the project described it, was straightforward: maintaining two separate codebases, two security protocols, and two user journeys had become operationally unsustainable. The framing offered publicly was considerably grander. Peter Ndegwa positioned MyOneApp as the consumer face of FinTech 2.0, Safaricom’s operating system for Kenyan digital life, its answer to WeChat, its declaration that a telco had become a technology company.

Within days, Safaricom publicly acknowledged login issues and that “most of the financial mini-apps services are not working.” Users who were logged out found themselves unable to log back in. The app required Safaricom mobile data during onboarding and blocked VPN users entirely. For many users, the app did not simply fail to open, it deleted years of saved data, including frequently used paybill numbers, till numbers, and transaction history. Users with automatic updates found the new app installed on their phones without notice, forcing a switch from the familiar M-Pesa and MySafaricom apps before they had chosen to make it. The complaints that landed hardest came from the diaspora; the segment of M-Pesa’s user base that processes the remittances that are, for many Kenyan families, a financial lifeline. My OneApp required a Safaricom SIM with active Safaricom mobile data just to complete first-time activation; someone travelling or living outside Kenya who was logged out was essentially locked out until they returned or found a workaround.

Safaricom’s position was that the SIM-based activation requirement was a fraud prevention measure, designed to verify the SIM is physically in the device and block SIM-swap attacks. Safaricom issued a public apology on April 16th, two weeks after launch. Version 5.1.5 followed shortly after, reinstating features that had been removed in earlier iterations.

What the launch sequence reveals is not a technology failure. The Fintech 2.0 backend infrastructure is genuinely impressive; a cloud-native rebuild that took years and represented a real architectural leap. The failure is organisational. Decode 4.0 was Safaricom’s E-Day: the summit had been announced, the press had been invited, the FinTech 2.0 narrative had been built into investor communications. By the time internal testing was revealing problems serious enough to break financial mini-apps and lock out diaspora users, the organisational cost of delay had already exceeded, in every internal calculation, the user cost of a broken launch. Nobody owned the question of whether the product was ready. Everyone owned the question of whether the launch was on schedule.

Whilst I haven’t had any discussions with Safaricom staff about this, I sense that it was a case of broken telephone. The entire org has likely been fed a steady diet of “We’re a Technology Company” or “The Future is Fintech 2.0”. How this has been translated into practice is that managers who support this vision get promoted and those that are not seen to be part of the new Safaricom quietly exit. The underlying result is that survival within Safaricom was about supporting Fintech 2.0. Practically, this meant ensuring that Decode 4.0 happened and that the MyOneApp was launched successfully. This is not to say that Peter Ndegwa is dictatorial. In fact, I’m pretty sure he’s the kind of leader who wants both the good and the bad news. It is simply a challenge of trying to be a tech company when the people manning the business are used to running a utility. It’s what happens when seemingly logical decisions at an individual level aggregate into horrible decisions at the organisational level. It’s managerialism taken to the extreme. For me, the MyOneApp debacle is a nothingburger from a technical perspective, they were always going to fix it. The alarm bells for me were about what this means from an organisational perspective.

It’s worth discussing what being a tech company is all about.

What is a Tech Company

Fundamentally technology companies are built around the idea of getting the best people in the room to build tech that will fundamentally and continuously solve an existing problem. It’s about the people, the focus on the tech and the continuous improvement.

Larry Page and Sergey Brin in the early years - Image Source

The talent obsession is the founding condition of technology companies, and it is inseparable from the quality of decisions they make. In Google’s early years, Larry Page personally approved every hire. He understood that the quality of the people was the product, long before any specific product existed. A-players attract A-players; B-players attract C-players; and once that second dynamic sets in, it is almost impossible to reverse without rebuilding the organisation entirely.

Google’s AdSense story shared by Gokul Rajaram in the Invest Like The Best Podcast illustrates what that talent density actually produces when it meets a managerialist impulse. Google had built a system for placing contextually relevant advertisements on third-party websites; a product that would eventually become one of the most profitable advertising engines in history. As the team prepared to launch, the operations group identified a legitimate problem: how do you prevent Google ads from appearing on pornographic websites, extremist forums, or other pages that would embarrass advertisers and damage the platform’s credibility? The answer they built was a proactive approval system. Every publisher who applied to carry Google ads would be manually reviewed before a single impression was served. The team hired staff specifically for this function. The workflows were designed, the headcount was approved, the system was operational. From a managerial perspective, it was a thorough and responsible solution, it controlled risk, it created accountability, and it gave executives something concrete to point to when advertisers asked how Google was protecting their brands.

Sergey Brin walked into the launch review and looked at what had been built. He asked one question: why are we reviewing publishers before they’ve done anything wrong? He told the team to kill the entire system. The operations staff, some of whom had been hired specifically to run the approval queue were stunned. Brin’s instinct was precise. A proactive approval gate optimised for the organisation’s comfort, not the customer’s experience. It created friction for the thousands of legitimate publishers who would wait days or weeks for clearance while their websites sat idle. It scaled badly; the manual review burden would grow with every new publisher, creating a bottleneck that would eventually throttle the product’s growth. Moreover, it solved for a risk that hadn’t yet materialised at scale, by building a permanent bureaucracy that would outlast the problem it was designed to address. Brin replaced it with a reactive model: publishers could load ads immediately, and a review was only triggered after a URL crossed 100 impressions. The system served the publisher first and managed risk through observed behaviour rather than anticipated behaviour. The team rebuilt. AdSense became the backbone of Google’s publisher ecosystem.

What the story reveals is that the managerialist impulse; build a process, hire people for it, demonstrate due diligence; produced a system that made the organisation feel safe at the direct expense of the product’s ability to scale. Brin could kill it because he was in a room with people who understood, when forced to confront it directly, that the customer’s friction was the real risk. A room assembled on different principles would have defended the approval system as responsible stewardship. The room Google had built recognised it as an obstacle.

The same dynamic also played out when Google’s Ad Team had built very robust ad management systems for large advertisers. Larry Page on seeing this killed the entire product and said that the capabilities that were built for large enterprises had to be available to small companies on a self-serve basis. Interestingly, given that smaller entrepreneurs were often spending their own capital for ads, they ended up being super-users who surfaced edge cases that moved the entire product forward. Probably, these tools would never have improved as fast if this self-serve capability hadn’t been built.

What distinguishes a technology company from a company that uses technology is, ultimately, this: in a technology company, the organisation exists to serve the product, and the people are selected with that logic in mind. The engineering team sets the pace of commercial decisions. Product calls are made by people with the latitude to make them, the ownership stake to care about the outcome, and the standing to attract colleagues who raise the standard rather than dilute it. Technology, in this sense, is a culture, assembled person by person, that compounds over time into something that organisations built on different principles cannot replicate by spending more money or launching a better-named app.

This is not a Safaricom issue. We’re inundated with statements from large African companies mentioning that they want to be tech companies. Unfortunately, being a tech company is not an issue of nomenclature. It goes deeper into the DNA. The entire MyOneApp story is representative of a company that is awkwardly approaching being a tech company from a nomenclature perspective rather than from a true DNA perspective. As if you can shout it into existence.

Don’t get me wrong. Safaricom is a great company and so are many across the continent with the ambitions of being tech companies. All I’m saying is that it’s ok not to be a tech company. In fact, it’s better to acknowledge that you’re a tech-enabled company that is doing its best rather than creating dissonance internally.

The Honest Qualifier

None of this is a prediction that Safaricom will fail, in fact, it will likely continue to scale and succeed. The structural conditions that protect it are real and they are durable. Over thirty-five million active users will not evaporate because of a broken launch. M-Pesa’s agent network, built over nearly two decades, is not something a competitor assembles in a funding cycle. The Fintech 2.0 backend infrastructure is a genuine architectural leap that will compound in value over time. Also, Airtel Money, despite gaining 8.1 percentage points of mobile money market share since 2023, remains a distant second in a market Safaricom has shaped in its own image. The MyOneApp debacle will be forgotten by most users, myself included, within a quarter. Safaricom is not the Edsel.

What the launch does reveal, and what is harder to fix than a broken app, is an organisation that has not yet resolved what kind of company it wants to be. The gap between the “tech company” narrative and the organisational reality is not a communications problem. It runs deeper into how decisions get made, whose question gets treated as the primary one, and whether the people with the ability to surface a better answer have the authority and the incentive to do so. Safaricom has 800 engineers. The question is whether the organisation they work inside was assembled to let the best answer win, or to protect the schedule, the vendor relationship, and the investor narrative.

That is a harder question than any infrastructure upgrade can resolve. And it is the question that Peter Ndegwa, whatever his considerable operational abilities, has not yet answered in public in a way that is convincing. In truth, I suspect that the leadership at Safaricom genuinely care about being a tech company and driving Fintech 2.0. As an outsider, it seems to me that they need to bridge the gap between their aspirations and the current reality. It may be a harder task than they may admit in public.

There is, it should be said, an entirely respectable version of Safaricom’s future that does not require it to become a technology company in the Nubank sense. A dominant platform company, with unrivalled distribution, a modernised backend, and the discipline to focus on what it does exceptionally well, is a very good business. M-Pesa at its core; moving money reliably, instantly, and relatively cheaply for over thirty-five million Kenyans is one of the most valuable financial infrastructure assets on the continent. The honest version of FinTech 2.0 might be the story of a utility that got faster, more resilient, and more open to third-party developers. That is a worthwhile thing to build.

Image Source: Auto Evolution

Ernest Breech named the car Edsel in a boardroom, over the objections of everyone who had done the research. Ford recovered. The Mustang arrived five years later, built by a small team with unusual autonomy and a specific customer insight, and became one of the most successful product launches in automotive history. The lesson was not that Ford was incapable of building a great car. The lesson was that the organisation capable of producing the Edsel and the organisation capable of producing the Mustang were structured around entirely different questions.

Safaricom knows how to build and maintain infrastructure at scale. The MyOneApp launch revealed that it is still deciding whose question it is actually trying to answer.