Invested

A very common question asked by entrepreneurs we meet with is: "When am I ready to start pitching my first customers, the so-called 'early adopters'?" Even though this is a well-covered topic, there are still many misconceptions about the process, and even the definition of an early adopter, particularly in FinTech.

In this post, I'll discuss how to know when your product is far enough along for you to start a sales and marketing push to your first customers, some of the significant issues involved in that process, and how this applies specifically to technology for Financial Services.

The Definition of Early Adopter

Let's start by defining the term:

Early adopter: An early user of your product who uses it because they see a meaningful benefit to using it, in its current form, despite the fact that it may: 1) be incomplete, 2) have significantly less functionality than the incumbents, and/or 3) require a learning curve. In other words, the perceived benefits of using your new product must outweigh the risk of adoption for this particular user.

But I often hear misconceptions about the definition from entrepreneurs with yet-to-launch products, so here's what an early adopter is not:

  1. An early adopter is not a magical user that just uses new technology for the sake of using new technology. They may frequently try new technologies, they may even pay to try these technologies, but they will not continue to use new technologies if they don't quickly see benefits from doing so.

  2. An early adopter is not using your product in spite of its bugs. Bugs in your core functionality are unacceptable after your testing phase (though bugs in non-core features are acceptable in this phase if you need to prioritize development resources towards cleaning up your core functionality).

  3. An early adopter may use your product in spite of a somewhat new and confusing UI (user interface), but (and this is very important) they will not use it if the features that are key to your value proposition or differentiation are obfuscated by the confusing UI.

  4. An early adopter is not a beta tester. Some or all of your beta testers will likely become your early adopters, but beta testing and early adoption are distinctly different phases of your product lifecycle, and this distinction comes from the role that is explicitly communicated to these users. A beta test should consist of a select group of users who know they are expected to provide extensive feedback on the feature set, UI, UX (user experience), and bugs. They typically do not pay for your product at this stage, and likely receive compensation in the form of a future discount once you start charging. Early adopters, on the other hand, are simply your first real customers.

The bottom line is this: you won't even get traction with early adopters until you have a product with a clear value prop that satisfies these requirements.

Don't Jump the Gun

Entrepreneurs are often a bit too eager to get the early adopters on board before their product is ready, and this leads to a number of issues. The first issue is frustration, due to slow adoption and the negative psychological affects of your potential customers just not seeming to "get it". The second issue is wasted time, typically spent in premature sales meetings. And the final issue is wasted financial resources, as you inefficiently direct the activities of your team to sales and marketing instead of first building the right product.

There's also a risk with engaging early adopters too early. Early adopters are quick to try new products, but like in most human interactions, first impressions are very important, and you only get one shot to make them. You don't want to turn an influential group of product evangelists into an influential group of product naysayers. And this risk is directly proportional to the size of your market. If you have millions of potential users, having some early adopters see an unfinished product won't hurt you much, but in the enterprise technology market, particularly in niche product categories that are often the focus of FinTech startups, you can't afford too many bad impressions.

Knowing When Your Product is Ready: A Simple Test

So how do you know when your product is ready for a strong push to early adopters? This is more of an art than a science, but I propose asking yourself this question as a simple test:

Can a user perform a meaningful task with my product, in a meaningfully differentiated manner, without significant frustration or confusion?

In order for a task to be "meaningful", it must be important enough to the user's workflow that they would be willing to try a new product in the first place. This is somewhat subjective, but if you know your target customers well, and you have talked to them about their pain points in their current processes, you should already know the answer. You should also regularly engage with a select group of potential customers throughout the product design process to ensure you're continuing to design features that meet their real needs.

In order for the process to be "meaningfully differentiated", it must perform the task in a manner that "wows" the user relative to their current process. Is it significantly faster, easier, or cheaper? Does it produce superior insights or analysis or reduce their risk?

Finally, in order for the process to not cause frustration or confusion, it needs to be simple and easy to understand. As a general guideline, ensure there are no superfluous steps in the process or text in the UI that can confuse the new user. And certainly make sure it is bug free, at least in the core features.

Even the ability for a user to perform a single process in this manner means you are ready to show it to early adopters (well, as long as the rest of the product isn't complete garbage). But if your product is an amalgamation of half-baked features, you're simply not ready. Keep working on it and keep asking potential users and beta testers for feedback. In the meantime, stop making sales pitches, because your product isn't ready for real usage yet, even by early adopters.

How Does This Compare to an MVP?

A commonly used term in startup-land is MVP, or Minimum Viable Product, and it is a very important concept. The MVP approach dictates that you should only build the minimum amount of functionality necessary to test the adoption of new features with real customers, and nothing more. I encourage you to read more about this if you are not already familiar with this approach, and a great resource for this is Eric Reis' The Lean Startup.

For those of you who are familiar with this term, I am simply recommending that you incorporate this simple test into your decision about when to start pushing product to potential users outside of your beta test group. There's a distinction concerning MVPs that is sometimes misunderstood by entrepreneurs: "functional" does not always equal "ready". I've seen many products that are technically functional but that don't meet the above requirements, and therefore have little to no hope of seeing enough usage by early adopters to generate any meaningful data about customer preferences. Yes, collecting data from real users is great, but rushing it doesn't actually achieve this goal.

Being Ready is Especially Important for a FinTech Startup

Second chances are rare when it comes to working with other people's money. Here are a few tips for applying these concepts specifically to the Financial Services industry:

For consumer finance products: The user experience, even at an early stage, hinges on building trust when it concerns someone's finances. If something is buggy, trust will be very hard to maintain. Therefore, it's better to release a product with fewer features done very well than a feature-rich product with bugs. Early adopters of a finance product have a much higher threshold than of other consumer-facing products.

For professional or institutional finance products:

  1. Professional users have short attention spans when it comes to changing their behaviors. You need to wow them with your key differentiators very early on. Therefore, your killer features need to be easily found and understood in your UX (user experience) design, not just in your sales and marketing materials. The non-core features can be less polished at this point. You likely won't achieve mainstream adoption until they are polished, but your early adopters are most interested in your key differentiator, so make that shine first.

  2. Professional users expect professionalism from day one, and this is particularly true in the Financial Services industry. Buggy products are unprofessional and will establish a poor reputation for your company that will be hard to shake off.

  3. Certain types of users and firms are very unlikely to be early adopters. Banks, for example, have security, compliance, and regulatory concerns. Unless your product can only be sold to these types of institutions, don't start with a focus on these users, no matter how big you think the contract might be if you could close one. You will spend many months jumping through hoops to meet their requirements, while there were probably many other groups of users that could have been more immediately valuable to you.

  4. Early professional adopters are unlikely to put mission critical processes in the hands of a new technology, particularly when run by a startup with a limited track record. You may need to get creative in how you work with a few select firms to build this track record, and these firms may need to maintain redundancy with their current systems (so don't expect to get paid much at this stage).

  5. Enterprise users often require premium levels of support. Be careful not to get too far ahead of yourself in onboarding new users whom you don't have the staff to support. It's a great problem to have when you need to hire customer support personnel because your business is growing, but you'll rapidly lose credibility if you over-promise and under-deliver on this support.

We talk to many decision makers in the industry who say they are looking for the latest technologies, but what they are often implicitly saying is that they want to be "fast followers" of the latest technologies that have been proven to work by their peers. Don't be fooled by the wolf in sheep's clothing. Ask your potential customer lots of questions about the likely roadblocks to adopting your new product before you spend much time in product demos.

But that leaves you with a chicken-and-egg dilemma: how do you get the first major customer on board if they are generally risk-adverse, even when they claim they are not?

We Started ValueStream Labs to Solve this Problem

One of the main reasons we started ValueStream Labs (VSL) is that we could see how difficult it was for FinTech startups to reach high-quality early adopters. There is a lot of noise in the startup ecosystem, and therefore it is difficult for a professional user or institution to know what new products are actually worthy of their time. By sitting at the center of the FinTech ecosystem, ValueStream helps to guide professionals to the best startups, and helps guide startups to the right early adopters for their specific product.

A core component of VSL is our Industry Advisory Network, which is an extensive community of Financial Services professionals and decision-makers who have expressed strong interest in demoing, investing in, and advising the newest FinTech products. For companies that have not yet launched their product, this creates a safe environment to receive valuable product feedback to help shape their value prop. And for companies that are ready to begin a strong sales and marketing push, this network is an eager source of early adopters.

The Next Important Questions

There are two important topics to consider next:

First, what should be your primary goal of having these early adopters using the product? Is it product validation, early revenue, to get a reference customer for marketing and sales purposes, to kick off your viral marketing efforts, or for another reason entirely?

Second, what types of potential users should you target first? I've spent the last few pages describing how to know when your product is viable to an early adopter (the Minimum Viable Product), but you must also determine what potential customers are actually viable targets based on your company's current capabilities. And most importantly, which groups are optimal to go after first: your "Minimum Viable Customers".

Like most questions in the startup world, the answers are multifaceted, and I'll cover how to think about these issues in future posts.