How to F.A.I.L. better in product by Marc Abraham "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 16 November 2023 False #mtpcon, Product Failure, Product Management, Mind the Product Mind the Product Ltd 910 Product Management 3.64
· 4 minute read

How to F.A.I.L. better in product by Marc Abraham

In his keynote at #mtpcon London 2023, Marc Abraham, Product Director at financial services business Backbase, shows us how to learn from our product mistakes and offers a framework for failing better. Watch the video in full, or read on for highlights from his talk.

Key takeaways:

  • Product managers need to be cognisant of the risks inherent in their product
  • Start worrying about failure when you stop learning through your product or you don’t learn anything worth acting on
  • Use the FAIL framework to make sure your product doesn’t fail in vain

Marc starts by running through some high-profile product failures (Pono, Juicera and Quibi for example).

He says that each product failure brings you one step closer to success – it’s the concept of failing forward or failing fast – and we should be embarrassed by the first version of our product.

There’s a tug of war between product managers who want to fail fast and the rest of the organisation, who don’t want this because they’re under commercial pressure to succeed, so there’s a tension between wanting to fail fast and only having limited room to do so.

Marc then offers some practical tools and techniques to make sure your product doesn’t fail in vain.

Types of product failure

There are two types of product failure. The first is instant, like Quibi or Juicera. The second is delayed. The product has a good run at success, but will eventually fail – Marc cites Clubhouse and Buzzfeed here. The robustness of your product and its value proposition is key here.

Marc believes we should start worrying about failure when we stop learning through our product or we don’t learn anything worth acting on. Product managers need to be able to call time on a product or feature at the right time.  To do this product managers need to be cognisant of the following risks inherent in their product:

  • Problem risk
  • Solution risk
  • Execution risk
  • Timing risk

Each and all can cause a product to fail. For example, Juicera had no problem to solve so it was an instant failure. Zune – Microsoft’s answer to the Apple iPod  – suffered from execution risk because the product team involved didn’t have the necessary design, user interface  and app support to execute the product idea, says Marc.

Product managers need to be always aware of these risks and constantly assess them.

They need to develop some confidence about the likelihood of these risks arising and the impact they might have. By doing this a product manager can quickly establish whether they’re looking at a quick win or a big bet, Marc says.

This confidence comes from data – data about the problem to be solved, the customer, the solution and data inputs for decision making.

The FAIL framework

Marc then shares the FAIL framework which can help us to make sure our products don’t fail in vain. It has four components: Feature, Assumption, Impact and Learning. He illustrates the framework with a real-life example of a product he worked on some years ago, Settled Plus. Settled was a London-based property start-up, whose mission was to make the buying and selling of property as simple as possible.

The problem for Settled was that many homebuying transactions fall through. They assumed that the reason for this was that people find out about issues with the property a long time after their initial offer has been accepted. They assumed that if they could bring this information further forward in the process then the chance of completion would increase. The desired impact was an increase in completions. There were some successful customer trials but Settled Plus was quickly a failure. Lawyers and surveyors weren’t ready to change their ways of working and Settled’s founder wasn’t ready to go “all in” on prepackaged homes.

Failure wasn’t in vain, says Marc. They obtained valuable learnings and made critical product decisions as a result.

Framework components

Marc then runs through the framework components with plenty of detail and examples to help you apply the framework.

Feature – this means really understanding the problem you’re trying to solve. The easiest and most effective way of communicating this is through Jobs To Be Done, says Marc, where you focus on the outcome for the user.

Assumptions – there are four types of assumptions, assumptions about the problem, the user, the solution, and all the things that could go wrong.

Impact – what does success look like? A great way to capture what success looks like is through a hypothesis statement, says Marc. This statement needs to be highly measurable and it will give you the signals to look out for.

Learning – there are three simple questions that help us to capture and act on our learnings:

  • What happened?
  • What did we learn?
  • What do we decide?

“Our products won’t fail in vain if we’re clear on the why when we look at our learnings,” says Marc.

Want to turn the learning from this talk into action?

Our exciting #mtpcon London 2023 Keynote Kit brings you all of the insights from our London keynote talks plus additional helpful discussion points and thought starters so you can easily translate the insights into actions – perfect for making effective improvements to your role, team, and product. Plus, get an email notification when each talk is published! Sign up now.

Comments 0

Join the community

Sign up for free to share your thoughts

About the author

In his keynote at #mtpcon London 2023, Marc Abraham, Product Director at financial services business Backbase, shows us how to learn from our product mistakes and offers a framework for failing better. Watch the video in full, or read on for highlights from his talk.

Key takeaways:

  • Product managers need to be cognisant of the risks inherent in their product
  • Start worrying about failure when you stop learning through your product or you don’t learn anything worth acting on
  • Use the FAIL framework to make sure your product doesn't fail in vain
Marc starts by running through some high-profile product failures (Pono, Juicera and Quibi for example). He says that each product failure brings you one step closer to success - it’s the concept of failing forward or failing fast - and we should be embarrassed by the first version of our product. There’s a tug of war between product managers who want to fail fast and the rest of the organisation, who don’t want this because they’re under commercial pressure to succeed, so there's a tension between wanting to fail fast and only having limited room to do so. Marc then offers some practical tools and techniques to make sure your product doesn't fail in vain.

Types of product failure

There are two types of product failure. The first is instant, like Quibi or Juicera. The second is delayed. The product has a good run at success, but will eventually fail - Marc cites Clubhouse and Buzzfeed here. The robustness of your product and its value proposition is key here. Marc believes we should start worrying about failure when we stop learning through our product or we don’t learn anything worth acting on. Product managers need to be able to call time on a product or feature at the right time.  To do this product managers need to be cognisant of the following risks inherent in their product:
  • Problem risk
  • Solution risk
  • Execution risk
  • Timing risk
Each and all can cause a product to fail. For example, Juicera had no problem to solve so it was an instant failure. Zune - Microsoft’s answer to the Apple iPod  - suffered from execution risk because the product team involved didn’t have the necessary design, user interface  and app support to execute the product idea, says Marc. Product managers need to be always aware of these risks and constantly assess them. They need to develop some confidence about the likelihood of these risks arising and the impact they might have. By doing this a product manager can quickly establish whether they’re looking at a quick win or a big bet, Marc says. This confidence comes from data - data about the problem to be solved, the customer, the solution and data inputs for decision making.

The FAIL framework

Marc then shares the FAIL framework which can help us to make sure our products don’t fail in vain. It has four components: Feature, Assumption, Impact and Learning. He illustrates the framework with a real-life example of a product he worked on some years ago, Settled Plus. Settled was a London-based property start-up, whose mission was to make the buying and selling of property as simple as possible. The problem for Settled was that many homebuying transactions fall through. They assumed that the reason for this was that people find out about issues with the property a long time after their initial offer has been accepted. They assumed that if they could bring this information further forward in the process then the chance of completion would increase. The desired impact was an increase in completions. There were some successful customer trials but Settled Plus was quickly a failure. Lawyers and surveyors weren’t ready to change their ways of working and Settled’s founder wasn’t ready to go “all in” on prepackaged homes. Failure wasn’t in vain, says Marc. They obtained valuable learnings and made critical product decisions as a result.

Framework components

Marc then runs through the framework components with plenty of detail and examples to help you apply the framework. Feature - this means really understanding the problem you’re trying to solve. The easiest and most effective way of communicating this is through Jobs To Be Done, says Marc, where you focus on the outcome for the user. Assumptions - there are four types of assumptions, assumptions about the problem, the user, the solution, and all the things that could go wrong. Impact - what does success look like? A great way to capture what success looks like is through a hypothesis statement, says Marc. This statement needs to be highly measurable and it will give you the signals to look out for. Learning - there are three simple questions that help us to capture and act on our learnings:
  • What happened?
  • What did we learn?
  • What do we decide?
“Our products won’t fail in vain if we’re clear on the why when we look at our learnings,” says Marc.

Want to turn the learning from this talk into action?

Our exciting #mtpcon London 2023 Keynote Kit brings you all of the insights from our London keynote talks plus additional helpful discussion points and thought starters so you can easily translate the insights into actions – perfect for making effective improvements to your role, team, and product. Plus, get an email notification when each talk is published! Sign up now.