In 1993, Apple launched the Newton MessagePad, a personal digital assistant (PDA) that could “send a page (as in pagers) and faxes, and soon electronic mail” according to its release ad. Among the several unique features shipped at the time, the most important requirement during product development was “that it had to fit in John Sculley’s (Apple’s CEO at the time) pocket,” as Wire describes.
In 2014, Amazon shook the marketplace when it announced the release of its Amazon Fire Phone. It was an average device in processing terms with an underperforming Android based OS, but the secret weapon that would disrupt the market was dynamic perspective: five frontal cameras and native 3D graphics which gave the impression of depth to the screen.
What both products have in common is that they were born as vanity projects from some CEO’s creative mind and, consequently, resulted in abhorrent market failures. The Newton line cost Apple over a billion dollars, and it allegedly paid back only a fourth in return. Fire Phone sold under 35k units a full year after release, and was discontinued soon after.
Product failures are abundant in recent history, and usually happen when a product has commercial feasibility risks. As a product manager, there’s a good chance that you will face these failures at some point during your career. To help you be prepared for these, this article covers the basics of commercial feasibility, why product failures are so common, and how you can avoid or deal with issues when they arise.
There are different ways something can fail. It can break and not perform to its original intent, it can harm people or society, or it can fail to be released on time.
However, when it comes to commercial feasibility the failure relates to the product not making enough money.
Feasibility risks are mainly divided into the technical and commercial dimensions. Marty Cagan’s famous Four Risks article, serves as a framework:
If delivery and usability risks are technical in essence, desirability and business viability cater specifically to the commercial dimension of product management. Will people buy it? If they buy it, are we able to make money from it?
While most companies focus on the technical feasibility, it’s usually the commercial feasibility that brings products down. Both the Newton PDA and Fire Phone failed at reading the marketplace, mistakenly assuming that the CEOs involvement guaranteed that the business risks were taken care of. Afterall, who would think that the man behind Amazon or Apple could read the market they helped to build poorly?
Human beings crave predictability, and that influences every aspect of our lives, including how people do business. Product management revolves around de-risking decisions and providing predictability on variables that are essentially impossible to control.
For every unsuccessful product launch, there’s another hit to counter balance it. No one believed the Kindle would work, and the first iPhone was a “double-or-nothing” approach to the failed PDA line. So what leads to product failures?
Launching something brand new isn’t a guaranteed success or failure. You should ask yourself if people in the market have an unresolved demand, instead of whether someone has done it before.
Apple’s Newton PDA targeted the “mobility” issue too soon. After the iPod showed how good it was to listen to music anywhere from a tiny device, and after the mass adoption of cellphones, people started wondering what it would be like to send emails from those tiny devices.
People tend to say that the iPhone created a market demand for itself, but that’s not true. Apple was very successful at reading the suppressed value demand the market had during iPhone development, and it could only do so thanks to the lessons from Newton’s failure.
It’s hard to find an all-you-can-eat buffet with great food across the board. Companies that try to do too much usually fail at one thing sooner or later.
Fire Phone was a Jeff Bezzos ego trip in an attempt to snatch a piece of the mobile device market for himself. Contrary to Apple trailblazing too soon with Newton, the market had plenty of good smartphone offers at the time the Fire Phone started development. Bezzos had rewritten the book on selling, logistics, and ecommerce, and that made him think that he could disrupt any market.
He couldn’t. Amazon’s lack of familiarity with the mobile industry, added to the poor synergy between Amazon’s existing value streams and the Fire Phone, made its launch a self-fulfilling failure prophecy.
In any product development, you reach a point where you find yourself navigating blindly. You can mitigate a lot of risk, but you still need to trust your gut.
In both the Newton and the Fire Phone scenarios, too much gut-feeling from top executives resulted in failures. At the time of release, both Apple and Amazon were heavy hitters. Because both companies had been right in the past, executives assumed that the same success would carry over into the future. However, this wasn’t the case.
Never assume that your users will like anything you give them just because it comes from you. You still need to make sure that you build things people actually want and need.
HIPO is an acronym that stands for the high paid person’s opinion. The problem is the connecting thread between the three issues above. Whoever sits in the highest role thinks they tend to know the most (otherwise they wouldn’t have gotten there in the first place).
This might not be the CEO. It could also be a director, VP, or even you as the PM. Good, effective, and efficient product management requires decentralization, sharing risk with subject matter specialists, and stakeholders directly operating in the frontline.
Let’s face it: no product manager could convince Bezzos or Sculley that their bets were off. Commercial feasibility can become useless if you’re struggling against too strong of opposition. Despite that, there are some attitudes you can take that counterpoint this imbalance:
Product discovery is equal parts commercial and technical investigation. Top executives usually have domain of the latter, leaving the more hard-core technical assessments to specialists. By creating channels for different perspectives to be empowered, you open up opportunities for the technical hurdles to mitigate over-reliance on executive bias.
Engineers might spot technical constraints that eat-up profit margins, Designers can point out product-breaking flaws that hamper usability. Regulation can shut down a project even before it starts. This collective intelligence helps balance the weight of individual opinions, regardless of their position in the hierarchy.
Keep meticulous records of user research, market analysis, and technology viability. More importantly, document every decision taken against evidence or proof. When challenging HIPPOs, data only speaks louder than opinions if there’s accountability to it.
Everybody has a boss, and even the most hawkish of the HIPPOs has to pay tribute to someone or some governing body above. Having failures traced back directly to your name doesn’t look good in a resume, and most people back down from poor commercial decisions if they’re left without a scapegoat. Top executives aren’t always to blame, though, and tend to be correct more times than they get it wrong.
The same overreliance on anecdotal evidence, gut feeling, or straight up ignorance that some HIPPOs display can be found at the operational level as well. Unprepared product managers, unqualified technical specialists or green teams can also lead to poor commercial feasibility assessment.
Rather than betting the farm on massive launches, slice initiatives into smaller, testable chunks. The Fire Phone could have started as a modified Kindle — an established Amazon product — to test how enthusiastically users would react to dynamic perspectives. Before the iPhone, Apple released the now forgotten iPod touch to test how users would react to all touch-screen devices.
When building incrementally, you essentially derisk commercial feasibility by reducing the amount of resources you spend on delivering the product to market. The organization can validate assumptions early, adjust course based on real feedback, minimize sunk cost, and build stakeholder confidence gradually.
Sometimes, you’ll have to proceed with questionable initiatives. In these cases, establish clear metrics and exit criteria beforehand. Define what success looks like and, more importantly, what failure means. This gives you objective grounds to pull the plug before investments spiral out of control.
For example:
Both Newton and the Fire Phone were pulled from the marketplace to avoid even bigger losses.
Rather than fixating on specific features or technologies, center discussions around desired outcomes. Instead of “we need 3D cameras,” or “fitting in Sculley’s pocket,” frame it as “differentiating our device in the market” in case of the Fire Phone or “making communication more accessible” for the Newton.
This shift from output to outcome mindset forces teams to confront the core question: what problem are we really solving? By zeroing in on a specific technical implementation, both companies missed opportunities to innovate in areas where they held natural advantages. The 3D interface became a solution in search of a problem, rather than a response to genuine user needs.
Commercial feasibility is a cornerstone for sustainable product development, yet it’s often overshadowed by technical obsession or executive ego. The failures of Newton and Fire Phone serve as reminders that even tech giants can stumble when they prioritize features over value, gut feelings over discovery, hierarchy over data.
Democratize discovery across teams, document decisions for accountability, build incrementally, establish safety nets, but perhaps most importantly, shift focus from outputs to outcomes. Ask not what features you can build, but what problems you’re truly solving for users.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A product teardown is a systematic dissection of a product to analyze its features, design decisions, user experience, and overall strategy.
AI-generated personas not only save time but also provide a more accurate, scalable, and dynamic representation of your users.
A product sense interview measures a candidate’s ability to understand users deeply, frame problems clearly, and generate creative solutions.
A competency matrix is a structured framework organizations use to evaluate, align, and map skills across different roles.
Learn more →
