Defining Product/Market Fit: Finding & Validating Market Problems for the AppExchange


This post is the first in a series on Product Management for the AppExchange and will highlight techniques to find, and more importantly validate, market problems that might be deserving of a solution for the AppExchange.

Just like a traditional SaaS startup, the most successful applications on the AppExchange are those that have found the strongest Product/Market Fit. This factor is so important, in fact, that an entire body of work discusses why it’s mission critical for a fledgling SaaS business. Nidhi Shah does a fantastic job laying out why in her post on Product/Market Fit: The Definitive Path To Startup Success. However, Product/Market Fit can only be evaluated once a product is built and shipped. As a Product Manager, what exactly do I decide to build?

Product Managers have 4 main tasks:

  1. Find and Validate a Market Problem
  2. Build a Solution to that Problem
  3. Take that Solution to Market
  4. Measure Success at Solving the Problem

So you see, Product/Market Fit is only measurable once you’ve committed resources to building and taking a solution to market. Therefore #1 is the most critical piece of this puzzle. Making a pivot once the solution has been built is far more costly than changing your problem focus.

Types of Applications on the AppExchange

On Salesforce.com’s AppExchange marketplace, there are two main flavors of applications that businesses choose to create. The first, referred to as OEM, is a fully custom application built on Force.com. It may have the same look and feel as standard Salesforce but provides completely custom functionality. This type of application stands on its own and is not installed into an existing Salesforce subscriber organization as an enhancement package.

The second type, referred to as ISVForce, are packages that get installed into an existing customer org and supplant standard Salesforce functionality. It is very common for this type of application to act as an extension to an existing SaaS product. For example: let’s say you have a cloud-based learning management system (LMS) and you want to give sales representatives a way to see relevant learning content on an Opportunity. You would build an ISVForce-type application that connects the subscriber’s instance of the LMS and their instance of Salesforce, enriching Salesforce with LMS data and content.

Love the Problem

Think of your app as if it were its own startup, and apply startup principles to this potential business segment/line/product. You absolutely MUST find the problem that someone: a) needs, b) hasn’t already solved adequately, and c) is willing to pay for. The process is simple (although it’s hard to do well or repetitively well).

Find the Problem

This task is fundamentally the hardest part of product management but there are likely options waiting for you that you haven’t realized. For OEM apps, this is a somewhat harder task as there are inherently more possibilities with a full custom experience. For ISVForce use cases, you probably have already done some of this work for your core SaaS product. Take Heed Intrepid Product Manager: ISVForce applications should get the same level of problem validation rigor that the core product receives. The user persona on force.com is rarely the same as the original product concept personas and it’s common to see potential successes fail due to a miss on market fit specifics related to Salesforce use cases.

Find a Domain

  • Maybe you know the domain already, maybe you’re in that domain; great, you have a head start.
  • Find where people in that domain spend their time.
  • Start conversations and listen for their problems
  • Look In Areas You Have Expertise

Look for Things YOU Need

  • Ask yourself if your needs are unusual. If they are, then it’s likely someone else has this need as well but no one has solved for the problem yet.
  • The best startup ideas occur to people who are living in the future and other people eventually catch up. That’s where the fire is. Build things that people haven’t solved for yet.
  • “Live in the future, then build what’s missing.” (Paul Graham, 2012)

Look for Things Other People Need:

  • What problems are tedious, annoying, unsexy?

Go Deep!

  • The best startup ideas are those that solve a problem that the targeted user cannot live without. Focus narrowly so that you can go deep on the problem. It’s depth that makes the product essential to the success of the user — and that might be your most important takeaway.

If you make your users more successful with your product than before they had it, you will always win.

Validate the Problem

As previously stated, changing direction PRIOR to solution build is always the cheapest option. How do we know the problem is worthy of a solution? How do we know that someone needs this product URGENTLY? Just because you built it, doesn’t mean anyone actually WANTS it!

Ask as many people as you can get to talk to you.

  • Ask your sales teams
  • Ask your product people
  • Ask your executives
  • Conduct focus group interviews
  • Conduct existing customer interviews (we’ll talk about this topic in a future blog post)
  • Find domain experts and interview them.

Create a functional prototype and try to sell it

  • Take the learnings from your interviews and problem ideation and create some vaporware
  • See if your ideas resonate with the people you interviewed & Iterate!

Summary

As you can see, finding and validating the problem is the first step in understanding what solution will make your potential users most successful. In future posts we’ll explore aspects of creating and building a solution for the AppExchange and strategies to take that solution to market.

At CodeScience, we apply lean startup principles to Salesforce.com products. Contact us for assistance in bringing your product to the AppExchange.


Originally published at www.codescience.com.