How to Deliver a World-Class Product Experience

In this first of a series of articles by our product advisory team, we explore why around 2 in 5 new products don’t meet their expectations in the first year after launch and offer practical advice on how you can systematically improve these odds and consistently launch something that your customers will love.

It all boils down to making sure your products are three things:

• Designed right
• Built right
• Launched right

Easy, right?

Depending on which study or post you read, somewhere between 40% and 95% of newly launched products fail after their first year in-market. For the product profession, these are not great stats. But why is it that so many new products fail?

As product development practitioners for the last 20 years, we’ve had our fair share of experience with the highs and lows of launching and scaling new products in both corporate and start-up settings. Over the next few months, we’ll be sharing our experiences here on why newly launched products fail, but more importantly what you can do to avoid it. Our experience, focused mainly on large organisations, fuses many of the best aspects of what are predominantly digital product management approaches (such as lean, Human Centered Design, and Agile) with products and experiences developed in the physical world.

Over the next decade, it’s our view that there will be very few products left that don’t have a digital component as either part of the overall offering or at their core. As such, it’s never been more important to adjust product management practices to account for this shift.

But firstly, do 40% of new product launches fail? Well… it depends on who you read and how you measure it. When measured against their objectives, there is a large body of research across many industries that shows that at least 40% of new product launches fail. Whilst Clayton Christenson is often quoted as saying that 80% or even up to 95% of new products fail (although he later disputed saying this), there isn’t as much evidence to support the failure rate being that high.

Why do new products fail?

But even at 40%, why do 2 out of 5 new products fail? From our experience, the short answer is that it’s typically from a lack of planning and coordination between one or more of these three key areas:

1. Designed right: Is it a product that solves an actual customer problem? Would someone pay for it? How can you be really sure of this before you start building it?
2. Built right: Can you build the thing that customers said that they wanted, in the way they want it? Can you avoid the temptation of being sidetracked down a pathway of adding new features that you (or your stakeholders) think customers might want? And most importantly, is  it really ready to go  to market?
3. Launched right: Can you launch it in the right way and get your shiny new creation in the hands of people that want to buy it, when and where they want to buy it?

With many large organisations set-up in a matrix structure where different teams have responsibilities for only one, or sometimes two, of these elements like design, product development or marketing, the coordination across all three becomes ever more critical. At risk of stating the obvious, where any of these three parts of the product development process are not in sync, the probability of a new product failing is going to be much closer to the 80% rate. You can see from figure 1 below what the likely outcome is when they are out of sync.

For start-ups and scale-ups, this issue of coordination across teams is typically less problematic. However, for large organisations, managing the organisational matrix to ensure that all three areas work harmoniously, especially when they’re siloed, is where the really successful product teams make their mark. However, it shouldn’t just be up to the heroic efforts of a product team to make this work. Your chances of success can be significantly improved when organisational systems are put in place that give your product team and company a repeatable model that brings all of these elements together.  

When done right, it will create a new organisational muscle that can be flexed again and again to maximise the chances of successful product delivery.

So let’s have a look at these in a bit more detail.

Designed right

“Make sure you are building the right it before you build it right.” - Alberto Savoia, Innovation at Google

One of the most common and costly mistakes in business and entrepreneurship is creating a solution before taking the time to identify and understand the real customer problem that it solves for. At the start of every new venture, we are assuming that there is a large enough group of people, whom we can find, that share a common problem, that we can solve in a way that is valuable to them. For many companies, there won’t be a shortage of ideas, but winnowing these down to a smaller number that can then be validated is one of the key skills needed for any effective product team. For larger organisations, these ideas should be aligned to the company strategy and within the guardrails of the product teams’ remit.

Assuming there is alignment to the company strategy (a big assumption that we’ll write more on later), at the centre of effectively scoping a new product are the processes of lean, human-centered design and customer validation. For now, we’ll just summarise these as the process of interacting with potential customers to prove or disprove the assumptions made about the problems they need solved.

However, the critical step of customer validation is often either skipped or structured in a way that positively reinforces the product or management team’s hypothesis. The real role of customer validation is to validate and explore customer needs, while proving that there is a solution to address them.

For most companies, but particularly those that offer physical products , one of the best methods that can be used to cost effectively validate products in this phase is pretotyping. This is where a cheap, often simulated version of a product is put in front of customers to gather real data on interest, desirability and purchase intent. We’ll dive into this much more deeply in later posts.

When this stage is done properly, it helps mitigate three of the biggest failures of product development.

These include:

• Inadequate customer research: Insufficient research to  prove whether there is a problem to be solved and if  there’s a solution to solve it.  
• Lack of adequate customer benefit identified: Whilst there might be a validated problem, is the solution to that problem sufficient for them to act, at a price point that they’re willing to pay for? And, how can you prove that you’ll be able to get this product in front of customers in a way that they’re likely to buy it?
• No clear differentiation: Does what you’re proposing to do, do it better or more cheaply than something that already exists?

When a product isn’t designed right, significant resources can be expended on building ‘the wrong it’ as Albert Savoia, formerly of Google, is often quoted as saying. Building and then launching the ‘wrong it’ will almost always end in tears for a company where a new, fully functioning product makes it to market, is launched well, but falls flat as it didn’t get to the heart of solving a real customer problem.

Built right

“Ideas are cheap, execution is everything.” - Chris Sacca, Investor in Twitter and Uber

Another reason that new products fail is that they aren't built in a way that actually solves the customer problem. This can occur for a number of reasons, but it usually boils down to one or more of the following:

Feature bloat

For those who follow the learnings of the Lean Start-up, feature bloat is the antithesis of getting a successful new product to market. However, it is still a common occurrence, more typically in larger organisations that are trying to add new product lines on top of their core offerings. Two of the main reasons why feature bloat occurs are:

1. Product design by committees: Big organisations often have a wide range of big opinions and ‘enterprise requirements’ that are tacked onto every new product. For a product manager in this environment, effectively running this gauntlet requires a great deal of skill. Not only do they need the right data to support what’s really needed for the build, but they also need the interpersonal relationships and EQ to manage the wide range of opinions in the room. Organisational culture and team empowerment play a big role here and for some organisations, this will be more challenging to navigate than others.
2. The product team is not constrained effectively: Product teams with ample budgets can sometimes rely on their instincts as opposed to what the validated customer data is telling them about first product iterations. Don’t get me wrong, intuition is important, but it should be used to guide and interpret information - not act as the only source of direction for a development.
   

When I think of feature bloat, I’m often reminded of a legendary Swedish story about a warship called the Vasa. The Vasa was built in the 17th century under the orders of King Gustavus Adolphus and was richly decorated as a symbol of the king's ambitions for Sweden (and perhaps himself). It was to be the pride of the Swedish navy and was heavily laden with bronze cannons to make it one of the most highly armoured warships of its time. However, on her maiden voyage, when she had sailed just over a kilometer, a slight wind change caused her to become unstable due to too much weight high above the water (partly from the cannons on the upper-deck) and not enough ballast lower down. Unable to right herself after the wind change, moments later she sank, just off the coast of Stockholm.  

Feature bloat is just like the Vasa. If you overspec your new creation without proper validation prior to build, it’s likely to cost too much and sink quickly in the market.

Launched too early

When we set out to build a new product, plans are made on what it is we’ll build, how long it will take and how much it will cost. However, for most product developments, there are so many unknowns as you set out on this journey, yet an ‘immovable’ date for launch is often set. This can be for a variety of reasons, such as aligning to a major event in the corporate or national calendar, like holidays. When this happens, it can create the wrong behaviours for a product team in getting to market, forcing compromises to be made on quality to meet the date. Windows Vista and Apple Maps are two examples often cited of this occurrence. On many occasions, the early launch will be rationalised as “this is our MVP”, when in fact, it’s just a partly built set of functional components that don’t deliver a really useful or desirable experience. You can see from the diagram in figure 2 what this might look like.

This idea of an MVP in a corporate setting is often more myth than fact. If a large company is taking something to market with it’s well respected brand featuring prominently, what it launches is almost always more than an MVP. Validating a product in-market where an expensive build precedes it is rarely a recipe for success. This validation can and should be done far more cheaply via pretotyping during the design phase to maximise the chances of the ‘right it’ being built.

‍Launched too late

What do product managers and Goldilocks have in common? Well, the flip side of launching a product too early is launching it too late, missing the Goldilocks window of getting it ‘just right’. This often happens when a product team spends too much time in the development phase, building out the fully featured product set to the extent where it is either bloated (see feature bloat), trying to service the needs of too many potential users at the outset, or it just takes too long to get to market and the opportunity has either passed, or been filled by an alternative.

We’ll write more in later posts about how to deal with these challenges.  ‍

Does agile delivery solve the ‘built right’ dilemma?

When implemented properly, agile is a fantastic methodology to build products the right way. However, for large organisations, agile delivery often goes off the rails in two places:

• The partly agile organisation: If the rest of your organisation (such as finance, legal, marketing, sales, or traditional PMO) are not ready to work using agile principles with properly empowered, cross-functional teams delivering frequent iterations, agile may not be the answer to your ‘built right’ challenge. This environment needs to be recognised for what it is at the outset, with plans developed to either have the team empowered to deliver in this way or for a more traditional, waterfall delivery method to be employed. Using “Wagile” or other delivery hybrids can work, but often don’t.
• Where digital meets physical: When your product involves physical components in the real world (not just software), it can take months and in some cases years to design, manufacture and test them properly before they’re ready for market. Committing a company to the large costs involved with this kind of process is often a big deal and you want to be certain you are manufacturing the ‘right it’ before you do (see ‘Designed right’ above). It also means that the agile cycles of frequent iterations do not always align neatly with the long lead times of the manufacturing process. In many large organisations, software and hardware teams (or the hardware manufacturing third parties) also work using different delivery methodologies. This can be managed with the right up-front planning where the ways of working and the cycles of iteration are carefully sequenced between the teams. However, where this critical early planning is left too late, the consequences are usually costly and result in late delivery… or perhaps another Vasa.  
  

Launched right

“People don’t buy what you do, they buy why you do it. “ - Simon Sinek, Author of “Start With Why” and “The Infinite Game”

So you’ve designed it right, you’ve built it right, but can you actually get in front of customers in a place where they want to buy it, with a sales and go-to-market approach that supports it? If you just start planning for this step towards the end of the build, your chances of success are pretty low. Throwing something ‘over the fence’ to the marketing team is never a good strategy and especially not late in the development cycle. In order to succeed here, it’s critical to plan and validate this step as part of your design phase. You need to be clear on the value proposition and what profitable per-unit economics look like, inclusive of the sales and marketing costs.

Launching a product right typically involves developing the:

• Right value propositions & positioning: Product teams that fall in love with features can forget value propositions and try to throw a hospital pass to the marketing team to figure this out after the product is built. The same can be said for the target market and positioning. Feature bloated ‘mass market’ products are much harder to position and sell than clear value propositions targeted at specific segments. Early design testing can and should help here.
• Right marketing approach: This needs to focus on the ‘why’ of the product and not just the ‘what’, or the list of features. If customers don’t ‘get it’ quickly, then there isn’t much chance of success. The marketing plan needs to recognise this and be realistic for the ambitions of the product you’re planning to launch. Again, testing, learning and optimising, prior to a full scale campaign, is also a key step towards success and can be done at very low cost during the design phase.
• Right channels: Launching something new doesn’t always mean it needs to be available in every channel on the first day of launch. Selecting the right launch channel/s where you can maximise early feedback on which approaches are working can be a critical stepping stone towards creating a growing category.  Again, pretotyping can help here too.
• Right incentives: Are you able to remunerate the selected channels in a way that will motivate your target market’s  attention, in a profitable way? If budgets are unlimited, it’s easy to buy your way in. However, few budgets allow that, and getting the remuneration model right takes careful planning at the early stages of design.
• Right capacity in those channels: This one is more of a trap for product teams launching new offerings via an existing (or core) channels team like in a bank, energy provider or telco. If the new product  doesn’t fit their current mould, this can be a recipe for disaster. Geoffrey Moore’s thinking in Zone to Win offers some great perspectives on what’s needed for brand new products launching through an existing or core organisation structure. We’ll elaborate on this in future posts.  
• In-market optimisation: Once a product launches, a new journey starts for a product team and there needs to be a focus on optimising the product in-market. Product success is typically measured through the financial outcomes that it delivers, and while incredibly important, these outcome metrics are not typically actionable in the early stages. Instead, product teams should look at usage or funnel metrics for insight into where optimisation effort is required.
  

The product management system

How can your organisation maximise the probability of a successful product development pipeline?

In order to consistently deliver successful products that customers love, we believe that you need a product management system that helps guide your development teams and organisation through this process.

Our system (see figure 3) brings together our experience as product builders over the last 20 years. It takes the best parts of the start-up and software worlds (using lean principles, early validation, human centred design and agile methodologies) and combines them in a way that we think is relevant for corporate Australia today. This model is ideally suited for larger companies (late stage scale-ups and beyond) that offer digital-only products or products that span both the digital and physical worlds.  

The system has three layers that typically span the organisation and are supported by the organisational culture and ways of working. The three layers are strategy and executive layer, the product development & management layer and the go-to-market layer. The strategy and executive layer creates the right guardrails and alignment needed for the rest of the system to work. The product layer is covered above, and the go-to market layer focuses on creating the alignment needed to bring a product to market.

In later posts, we’ll dive into a range of other product management topics in more detail.

If what you’ve just read resonated, or if you would like to ask us any questions, we’d love to hear from you.

If you want to discuss how IE can help your business, feel free to get in touch with us.