Story of F-104 or Some Short Notes On The Challenges of Solution Crafting*
Like most of people (I am aware that I am exaggerating the numbers), I prefer to have a Youtube video (or a podcast) playing in background while resting or sleeping; using it as a “white noise”, a way to stop continuous thinking on user problems within my products’ domains — let’s name it “product person’s dilemma”.
A few weeks ago, that Youtube experience was about a legendary fighter aircraft, F-104, and while listening it I suddenly realised that it is a perfect example for some of the challenges of solution crafting that we encounter daily in product management.
The story begins with the Cold War era, Korea Conflict. During that period, American pilots were using F-86s against Soviet MIG-15s and reported that they couldn’t gain air superiority. So, people from Lockheed Martin visited air bases in November 1951 and met with several pilots, asking the basic instinctual question: “What do you need?”. Nearly all pilots reported a request for a fighter aircraft with high speed and ability to reach the high altitude, as these seemed to be the missing parts in the aerial warfare against Soviet aircrafts.
And based on those feedback, F-104 Starfighter was born.
And then comes the Vietnam War, during which it was realised that although F-104 met every criteria that American pilots requested, it lacked the essential manoeuvrability which is crucial for close-range dogfights (aerial battles between fighter aircrafts conducted at close range). So suddenly, people had a product that was purely developed based on its users’ requests but didn’t successfully handling its users’ needs — as a result, F-104 aircrafts were withdrawn from Vietnam.
Users are product people’s greatest allies when it comes to problem identification. They use our products every day and encounter challenges and friction points that we didn’t foresee. Their first-hand experiences, pain points, needs and desires form the foundations of product development (it is essential to recognise that these aren’t the sole basis). Through surveys, interviews, observational studies and feedback loops, we can discover a wealth of insights that shed light on the domain of user problems.
But as we move deeper into the user research process, an intriguing paradox emerges. While users excel at articulating their problems, the situation becomes more complicated when it comes to envisioning solutions as users often shape their solution definitions based on their prior experiences with existing products, unintentionally limiting themselves. This isn’t a flaw on their part but rather an evidence to the complex nature of solution creation.
One of the dominant biases in product management is the tendency to develop features or solutions solely based on immediate user requests without considering the broader strategic vision. This bias can stem from the desire to please users quickly, receive positive feedback or address visible pain points promptly. While user satisfaction is paramount, a myopic focus on immediate requests may hinder long-term product success — as it can be seen in the story of F-104, at least at the beginning (high speed and altitude aircraft vs air superiority aircraft). It is crucial for us to interpret user feedback through the lens of product strategy and feasibility.
A similar pattern can also be observed in the communication with our stakeholders in the organisations that we work. While they play a crucial role in aligning the product with business goals, it is essential to decipher their requests without moving to the execution phase and distill them into underlying problems.
And I know this is the time I must mention the famous statement attributed to Henry Ford: “If I had asked people what they wanted, they would have said faster horses”. May be we can make it more up-to-date, something like “If I had asked people what they wanted, they would have said more taxis” by Uber’s Travis Kalanick :)
The F-104 saga doesn’t culminate in defeat (not all the stories have a unhappy ending); rather, it pivots towards adaptation. Recognising that the aircraft’s core competencies aligned more with interception (defensive role against attacking enemy aircrafts) than dogfights, it found success in a different role and successfully performed interception flights against Soviet bomber aircrafts.
This mirrors the typical product development journey of a product person. Understanding the distinction between problem definition and solution crafting is vital for us. It places us in a unique position to bridge the gap, translating customer insights into actionable and innovative solutions.
The story of F-104 also shows that pivoting is not a sign of failure but a strategic response to changing circumstances for a product person. It is about recognising when the current course is not producing the desired outcomes and having the courage to move in a new direction. Through adaptation and strategic pivoting, we can turn challenges into new opportunities.
Product people may hesitate to pivot for a variety of reasons, with a common fear rooted in the significant investment already made in the current product direction. The fear of disappointing existing users who have already provided positive feedback, combined with the reluctance to face potential resistance from stakeholders, adds another layer of complexity. The uncertainty surrounding the unknown outcomes of a pivot, along with concerns about cultural dynamics within the organisation, can contribute to the overall reluctance. Additionally, the pressure to meet tight timelines and hard deadlines usually amplifies the challenges product people face when considering a strategic pivot. Addressing these fears requires a balance between effective communication, data-informed decision-making and promoting a culture that embraces adaptability and continuous learning.
And, as a final note, it is crucial to acknowledge that not every pivot ends as a success (not all the stories have a happy ending). While we love to share and celebrate achievements like Burbn’s transformation into Instagram, a fascinating journey from a location-based social networking app to a global phenomenon, or Glitch’s evolution into Slack, worldwide accepted leader in team collaboration, there are also narratives of less favorable outcomes. Consider, for instance, Path’s effort to shift from a social networking application to a messaging platform, which faced challenges and did not achieve the expected success. Or, Jawbone’s attempt for a transition from a wearable fitness tracker company to a health and wellness platform, which encountered several difficulties and eventually led to the company’s closure. These examples underline the complexities and uncertainties that come with strategic pivots in the dynamic landscape of technology and business. As mentioned before; approaches like staying user-centric, embracing a learning mindset, executing data-informed decision making, iterating strategically, maintaining transparency with stakeholders, having collaboration across the organisation, experimenting continuously can be used to minimise those risks.
* I must confess that I drew a significant amount of inspiration from “Dr. Strangelove or How I Learned to Stop Worrying and Love the Bomb” for the title of this post :)
