Is Your Product Fit for Launch?

Questions from the Product Fitness Framework that every product organization should consider to set themselves up for success

As a Product Strategy Portfolio Lead at Cognizant Softvision, I recently had a conversation with a CIO to discuss a product they were bringing to market. The discussion centered around two related questions: “How sure could they be that their product would be successful?” and “Should they move forward with launching it to the public?”

Let me be clear: there is no surefire way to know with 100% certainty that you will be successful when you launch a product. However, there are a number of things to consider that will increase your chances of success.

When bringing a new product to market, organizations should ensure they have what’s known as a product-market fit. As Marc Andreessen (of Mosaic and Netscape fame, among others) puts it: 

“Product/market fit means being in a good market with a product that can satisfy that market.”

At Cognizant Softvision, we have taken the concept of product-market fit and expanded it just a little to guide all new products we work with our clients on. We call this the Product Fitness Framework.

Within the Product Fitness Framework, we have a number of core aspects with which to judge the fitness of a product. These form a hierarchy as you continue to define and ultimately develop your product, starting with a foundation based on your target customer and working through to execution and validation.

Image: The Product Fitness Framework

Within each bucket, we have a series of questions that should always be asked as the product evolves from hypothesis to execution and getting ready for launch. This gives us the opportunity to check ourselves as we progress, and asking prevents us from getting too far ahead in the process without ensuring we’ve covered all the requisite needs for a product to be best-positioned for a successful launch. You can use this to guide your entire process from inception to launch, as something to augment your process, or even as an audit to assess what you’ve done to date and if you need to consider anything else before moving forward. 

Target Customer

Is the product created with a target customer (or customers) in mind?

This is critical. A product without a specific target user in mind is forgetting its purpose. If you have answered “no” here, do not continue with the product until this is clarified.

Is there a clear persona (or personas) used to guide product design and definition?

The next level up from identifying a target customer is to make sure we know who we are designing for. The existence of this documentation itself is helpful. This is about the quantity—have you considered every persona, or just a single primary one?

How in-depth is each persona?

This covers how much detail is known about each persona. Sometimes personas exist but give some basic information, while others have done a great job of understanding the motivations of certain people, or how they like to consume certain content or interact with various tools.

Customer Needs

Has a journey map for the target customer been created?

The journey map is important to understand our customers’ needs and the context of our engagement with them. Without one, we have a problem or a solution existing in a vacuum without recognizing how it all plays together.

Have clearly identified gaps or needs been documented based on that journey?

It’s one thing to have the journey, but has the problem as it relates to the journey been defined? Consider the accuracy and level of assumptions being made here. Are the problems obvious and clearly articulated, based on observational or other collected information? Or is it just a hunch based on best guesses?

Are there clear business KPIs to measure success of hypotheses?

What does addressing these customer needs aim to change for the business? We need something to track to ensure we’re being successful. Do the KPIs make sense as it relates to the problem? How in-depth are they? For example, if a business wants to achieve a certain conversion rate, but you’re viewing success of the product based solely on traffic or downloads, there’s a bit of a disconnect.

Value Proposition

Have you done a competitive audit?

What else is in this space to address the needs? What are your competitors doing? You need to know this to ensure you approach solutions with this in mind, knowing what industry benchmarks or expectations from customers have been set. Consider the Kano model to know what the basic expectations are compared to the real delighters.

Have you identified your unique selling proposition compared to your competitors as it relates to this product?

If you build it, will they come? There needs to be a clear and obvious reason for someone to use this, and the cost-of-entry (or switching) needs to be considered as well. Why would someone switch from your competitor to this? Why would a non-user become a user? Why would a current customer use this? Many products get created without a clear USP, often based on hunches or just because there’s room in the budget to do it and someone wants to. 

Do you have a plan to market the product?

If a tree falls in the forest but there’s no marketing plan, did it really happen? Without a plan for this product’s launch to attract its users, how will it be effective? Consider how the marketing team is involved. Are campaigns focused on just awareness, or are there other benefits or RTBs (reasons to believe) put out there as well? 

Roadmap (Feature Set)

Does a product roadmap with identifiable epics or features guide continuous discovery efforts?

The entire product team needs to know what they’re aiming towards. It gives the team guidance on where to focus their efforts to design and define the product through continuous discovery. Are we looking at major epics or themes, or are we able to get down to specific features? How far out are we looking? How much backlog is there for the product team to focus on ahead of the delivery team?

Is there a clearly defined MVP with at least high-level user stories mapped out?

When we’re thinking about MVP, we need to be very focused on what we have to deliver. We may not have every user story written when the MVP is first defined, but we should have a very good idea of what’s covered in it. The MVP is often running on limited time, where we need to know when to expect to get something in market, so being able to see what will be delivered, and letting the team determine how and, more importantly, when, is critical.

Is there a clear prioritization of customer needs or business value guiding MVP definition and/or the roadmap?

We need to know how features are being prioritized for inclusion in the product, as this can give a good idea on how well this will hit those desirable and viable aspects for the users and business, respectively. There are many ways to focus on prioritizing, but the best are going to let the needs of the customer dictate this. Basing priority solely on business needs without weighing customer needs or value will reduce the confidence in the fitness of the product.

Execution

How is the product performing?

When you build a product, it needs to not only work, but it must work well. A poor-performing product will deter customers pretty quickly. Load times? Uptime? Error rate? Consider all these and more when determining how it performs vs. the customer expectation.

How well-executed is the UX of the product, in-line with best or cutting-edge practices?

The one most people are going to ask about—is the design good? Frankly, how does this stack up with an expected experience for this kind of product? How does it compare to industry benchmarks or competitors? What’s the latest and greatest in design, and does this match or exceed it? Consider Kano here as well when looking at those benchmarks. Customers will call you out for a mediocre or dated experience pretty quickly.

How well-written is the product’s code?

There’s ways to solve problems, and there’s ways to just keep them at bay. There may be a better way to write something than a thousand nested If, Then statements. How rigorous is your code review? How up-to-date with best practices are your developers? The best products need to be written by the best people using the smartest approaches.

Validation

Based on user journey improvements, did the team validate hypotheses on business KPI improvements (product success metrics)?

Once you have a good idea where you’re going out of the Define or Ideate stages (based on Design Thinking methodology), you should confirm you’re headed in the right direction. How was the concept received? What feedback was documented and needs to be (or was) addressed?

Has any form of user testing been utilized prior to development?

If we haven’t tested anything with potential or current users before getting it out to the market, how do we have any idea that our ideas are right? There are many ways to do this, so teams need to consider the kind of feedback they can take in and what they can do to address it.

Has there or will there be a form of beta testing with target end users that quantitatively and qualitatively validate new features and customer journey improvements?

Once something is built, before a complete launch, it’s best practice to get it out to a smaller group to ensure everything is running smoothly and see how users are using things. This will typically be an even larger group than what’s done for usability or other testing, so it’s likely to get additional feedback or a chance to see how users are doing things en masse.

Is there a plan in place to receive continuous feedback post-launch?

Once launched, what systems and processes are in place to receive and address feedback? Is someone monitoring specific channels? How connected are other areas of the business (customer service? employee feedback?) to report on issues or ideas? The more all-encompassing the plan, the better. If, for example, the business has a customer support line but there is no clear action plan for when they receive feedback on the product, that should be a red flag that needs to be addressed.

In my aforementioned conversation with this CIO, we went through these questions together, and it gave each of us a good deal of confidence in their new product as we discussed what work they had already done to get to where they were.

It must be reiterated that there is no surefire way to know with 100% certainty that you will be successful when you launch a product. Using the Product Fitness Framework, however, helps to ensure we’re well-positioned to succeed.

 

Background Image