5 Product Development Lessons Learned from Failure

In product, we often hear the stories of how the successful products we know and love came to be. We read books about how the iPhone made revolutionary design decisions and listen to talks from product leaders who built high performing teams at leading organizations to learn from the best of the best. 

While these stories are inspiring and useful, we don’t hear enough about failures in product development and what can be learned from these failures. In this light, I’m going to share some reflections from my personal experience in the hopes that it will help the Product Development community at large.

Before starting Connected, I had the opportunity to consult with a company called the Merchant Customer Exchange (MCX) on a product named CurrentC. Having worked in the mobile payments space earlier in my career at IBM, I had been following MCX and their plan to build a merchant-owned payment system, so I jumped at the chance to work as a Product Manager on the CurrentC mobile application.

Announced publicly in 2012, MCX was a consortium of the largest retailers in the world including Best Buy, Target, Walmart, 7-Eleven, and other huge brands that made up for over $1 trillion (yes with a “T”) in annual sales. While mobile payments were well established in other markets (e.g. mPesa in Kenya, WeChat in China); in the US, Starbucks’ mobile gift card and loyalty program was the standalone leader. 

CurrentC’s plan was to offer customers a form of frictionless mobile payment and loyalty rewards across all major retailers. While customers got an easy way to pay, retailers benefited from lower transaction fees by avoiding traditional credit card processing fees. It seemed like CurrentC would revolutionize mobile payments. But it didn’t.

So as a Product Manager for the Mobile app, how did I get it so wrong?

Product development is hard.

In his book, The Innovator’s Solution, Clayton Christensen makes the statement, “product development is hard.” To emphasize just how difficult it can be, he goes on to break down the numbers behind how frequently products fail:

• 60% of products fail before they even reach the market
• 50% of the products that do reach the market fail to stay in business
• 75% of the money spent on product development delivers failed products

To make things more difficult, the environment is more competitive than ever with the advent of software. Marc Andreesen’s legendary article about how software is eating the world captures how software is infiltrating every aspect of our lives. 

We live in a world that is increasingly connected, with millions more people and “things” coming online every year, and the majority of citizens linked through a worldwide communications network—4.39B people were regular internet users in 2019. We are living in a world of universal computing. In this world, software-powered products are the primary driver of business growth. 

Returning to my experience with CurrentC—the product made sense for the world we were living in in 2012. It was a new way to connect our physical shopping habits to the digital world. But the reason it never grew to its potential can be attributed to missteps in the product development process. 

Being a part of this project and experiencing these common problems in software product development firsthand gave me a better understanding of why it’s so easy for organizations to fall into them if they’re not careful—and why it’s so hard to course correct once problems set into the team, organization, culture, and inevitably the product.

Problem 1: Inside-out focus

Many organizations default to an inside-out focus. Leading organizations understandably (given their success) overvalue their assets (systems, intellectual property, data, knowledge, expertise, and insights) and significantly undervalue external experiences, trends, and even secrets. This causes them to lose the perspective of their customers, technology shifts, societal trends, and competitive threats. All that to say they have a hard time maintaining an external “outside-in” perspective on their business and on the way they’re approaching product development. The major risk with this is they fail to acknowledge and manage the assumptions and hypotheses they are carrying into a New Product or Feature.

One of the most critical parts of product development is validating that your product is actually usable and desirable to the end user. Jumping into CurrentC when it was “mid flight” I quickly got caught up in the complexities of the systems and operations required to make it work. I knew what the merchants were looking for and would get out of the product, but what about the customers who had to use the payment system in stores? I naively thought Starbucks’ mobile barcode payments solution (also a merchant issued payment method with loyalty attached) was working phenomenally and had strong adoption. Why wouldn’t CurrentC be the same?

The merchants that made up MCX were collectively paying millions of dollars in credit card processing fees each year, so their main goal with CurrentC was to cut costs while delivering value back to end customers using loyalty rewards based on data analytics. However, customers don’t really care how much a merchant is paying to process their credit card payment, they just want to remove friction at the point of sale and get “something in return” for using the product/service (points and/or promotional offers).

I was so focused on looking inward to the needs of MCX that I ended up not sufficiently working through some critical hypotheses and assumptions around customer’s usage of credit card, debit card, and cash. I significantly underestimated the switching costs for consumers and the resistance we would face from Financial Institutions and Credit Card Companies. You could say that customers didn’t want to pay with their phones, but Apple Pay and Google Pay have since become great examples of this form of payment being something customers desire. Apple in particular embraced the customer behavior of using a credit card, used its competitive advantage in proprietary hardware integration, and used its market dominant position to get Financial Institutions and Card Issuers to play by their rules, making onboarding incredibly easy for its users. As a comparison point for CurrentC, users had to essentially create a new bank account to store cash to use digitally in the CurrentC wallet app. 

Had I done proper validation upfront—actually going beyond talking to MCX and speaking with potential app users—I could have found ways to make the experience more desirable and usable across the board.

Problem 2: Projects instead of products

It may seem like an obvious statement that product development should be about the product as a whole and not focused on individual projects, but it’s quite easy to fall into a delivery mindset of producing outputs instead of delivering outcomes. Many organizations see outputs and outcomes as interchangeable, but outputs are essentially checked-off tasks. They are not the same as something that has product impact and achieves the outcome that you are looking to provide with a product. 

With CurrentC, the work was broken up into multiple projects. As an example, the point of sale team went away and developed a set of robust features based on the complex sets of merchants’ business operations and my app team made beautiful features for end users. Unfortunately, when these two groups of features were brought together they didn’t complement each other or make for a delightful user experience. Tradeoffs and tough decisions were pushed late into product development, some of which were too costly to change. 

Since there were different projects going on at one time with a multitude of stakeholders representing the Merchants and MCX, it was difficult to maintain a holistic view of the entire product and experience. If we had originally approached the development with a product-first approach, we could have avoided knowledge silos and handoffs that created problems and hurt the overall outcome. Furthermore, within projects, the disciplines of product strategy, engineering, and design were at times isolated which  inhibits a cohesive product experience. 

Over the course of product development, the technology, people, and competition can all change. But what needs to stay the same is a unified vision for the product. As the size and complexity of a product grows, more work streams emerge, hopefully with each workstream having two tracks: discovery and delivery. It is critical that learnings in each stream are shared across teams in order to gain the necessary confidence to focus on the act of delivering. 

Since the multiple parts of CurrentC were produced incrementally and independently, we ended up focusing on outputs rather than outcomes. Ideally, if we had looked at the overall outcome of how the app would affect business while delighting users (e.g. how to onboard new customers more seamlessly), we could have worked towards a real, measurable business benefit ensuring that all steps of development were aimed at the same goal.

Problem 3: Falling back on ”silver bullet” tools and discipline purity

In product development, when things start to get messy and confusing, it’s common for teams to default back to the mindset of “if we just follow a proven process, everything will sort itself out.” Different disciplines can stubbornly become protective of their own gold-standard approach, not allowing for collaboration with peers from other discipline areas.

From my experience, this never works out. There is no “silver bullet” tool or process that lets you easily achieve product success. Saying “this isn’t best practice for X” doesn’t help in fixing a problem at hand. When difficulties arise, it is at that time, more than ever, to look outside of your own experiences and practices to learn about the ideal solution for the product you are building and the team you are doing it with.

When the cracks in the foundation of CurrentC were starting to show, instead of pivoting, we dug in our heels, kept on practicing Extreme Programming, and spun up new tools. We did more usability testing and built a more reliable and robust mobile application, but these initiatives didn’t ultimately solve the larger product issue of “do customers want it?” and “will this be usable for real customers and cashiers at the point of sale?” Better user research and testing could help in these areas, but again in isolation, more research and testing are not silver bullets. 

We were taking an agile approach to software engineering and instead of stepping back and assessing if a change in Product Development process could help, we kept moving forward because agile was seen as the best of the best in terms of development approaches.

Problem 4: Balancing execution and innovation

Organizations constantly face the challenge of how to balance continuously looking to the future for new trends, ideas, and technologies with executing on the committed outcomes and deliverables that time and money have been invested in. This is especially true when there is a larger focus on outputs over outcomes—as I previously discussed. 

In New Product Development, upfront, foundational discovery work should always be completed before delivery starts. At Connected, we believe discovery efforts should be allocated between the risk areas of desirability, feasibility, viability and usability depending on the product concept. Once product-market fit is discovered, delivery starts and it’s critical to continue discovery activities alongside the product delivery. Truly innovative products are not born out of one-off ideas that are handed off to a development team to deliver—it’s continuous discovery and research into the latest trends, desires, and technologies helps ensure that development is on track or needs to adjust to new learnings. Furthermore, one (or more) people who truly embody the product are needed to keep the product on course throughout the product’s lifecycle.

CurrentC started out as an innovative idea—a way to enhance the in-store shopping experience through digital with seamless payments and loyalty that would also save merchants significant dollars in credit card processing fees. When it was conceived, the US retailers and issuers had not chosen to adopt contactless EMV (or even “Chip-and-PIN”) payment cards and the dominant smartphone platforms did not support NFC, these were key constraints when CurrentC was conceived in the early 2010s. Once the idea was set, we got so focused on getting the app up and running that we lost track of our North Star and got entangled in delivery without sufficient discovery. The result? A product that was late to market and didn’t sufficiently address the needs of users or protect against the competitive threats of the Smartphone platform powerhouses.

While we focussed on execution, we went too long without real customer feedback to fuel innovation. To say the least, the tech blogs were anything but kind to a product that ended up launching its public Beta after Apple Pay had started its roll out in the United States.

Problem 5: Fear of failing and obsession with “sure bets”

Experimentation is critical to great product development. However, teams can shy away from proper experimentation when they fear the possibility of failing or when they think up a good idea (a.k.a. a “sure bet”) and decide no further exploration is necessary. After all wasn’t that Steve Jobs’ MO 😉 ?

To quote product development coach, David Hussman, “the difference between learning and failure is how much money you spend to do it.” 

The team around CurrentC fell into the “sure bet” trap. The idea was novel and made business sense—the merchants loved the prospect of reducing fees and people are so attached to their phones that surely they would love a way to pay with an app. Let’s remember, Starbucks had proven barcode-bard payments and loyalty working in North America. Once it was decided that this was the direction for the product, insufficient exploration into other innovative solutions was done. What alternative solutions were there? How would we entrench against the dominant Smartphone Platforms who were later known to be working on Mobile Payments? To compound this problem, not only were other avenues not explored, but the idea for CurrentC wasn’t rigorously validated against different risk areas. 

To help ensure the success of a product, it’s my belief that risks should be tackled up front before development begins and then continuously re-evaluated throughout the entire process to ensure that the idea is still viable—because trends, technology, and people can change overnight. The four risks that should be validated against are:

1. desirability – will someone actually want to buy it/use it?
2. usability – can the user actually use it? or is the barrier of entry too high?
3. feasibility – can we actually build it, or is this just a pipedream?
4. business viability – does this actually work for our business model?

So many of the problems that we came across in the development of CurrentC could have been avoided had more rigorous risk validation been completed before we began full on delivery. We would have found that customers didn’t actually desire to use the app unless they saw sufficient value in return and the friction of onboarding and at point of sale was low.

Putting lessons into action

Having the amazing opportunity to work on CurrentC and then eventually seeing its ultimate sunset has taught me so many valuable lessons about product development. This is just part of one story, I’ve witnessed these common mistakes in other organizations before and since. I have been able to work with companies with highly successful products who have managed to do the exact opposite of the mistakes I made with CurrentC. 

These “what not to dos” shape how we approach product development at Connected. By applying a Product Thinking lens to our work, Connected’s Design Researchers and Product Strategists help clients avoid an inside-out focus by doing diligent user research throughout engagements. We make sure to maintain a product-centric mindset, run discovery and delivery concurrently, and iterate, iterate, then iterate again. 

To Christensen’s point, product development is hard, but knowing the common problems that teams face helps with a successful navigation from concept to release and beyond.