Don’t try to solve a problem that doesn’t exist

Lots of products never find their market, and inevitably disappear. Products fail for many different reasons, but often they fail because they try to solve a problem that no one has.

To avoid this frequent issue and to thus increase your chances of building a successful product, we recommend a healthy dose of self-doubt. The original spark of creativity that has, over time, fermented into a mental image of a fully fledged digital product is probably based on some assumptions and hypotheses - and it’s time to challenge them.

Before getting started in earnest, let’s think about the best practices for introducing a new digital product to market. Many newer companies are using an approach that is based on bringing a Minimum Viable Product (or MVP) to market as quickly as possible. This has several benefits, namely being able to test if your product is really a solution to your users’ problems without having to invest the resources and time required to build a fully featured, complex product.

In this approach, the MVP is usually marketed and delivered to early adopters only, as these users are the most likely to adopt your product. Also, this group of users should be cheaper and easier to acquire using your chosen marketing channels (more on this later). They’re also the first users you’ll be going after when your product launches, so it makes sense to start with them. Once you’ve validated your initial hypotheses and assumptions with these users (or maybe abandoned your product altogether!) you can expand and market your product to a larger audience - your “early majority”, as expressed in Moore’s diagram, below.

Facebook is famous for having applied this approach. By first launching their service at Harvard, and then spreading to other universities, the Facebook team found users who were keen on trying new technologies as well as a population of highly networked, social individuals - a perfect testing ground for the first version of Facebook’s product. After testing the service and their underlying assumptions, they slowly expanded their user base to other market segments. This is called a “Think big. Start small.” approach. It’s quite different to the “Get Big Fast” attitude of the startup boom in the 2000s, during which some infamous companies spent millions developing a product without ever doubting their would-be genius ideas.

Now, back to your hypotheses at the heart of your product’s conception. Make a list of all the hypotheses you’d like to test that pertain to the early adopters you hope to deliver your product to first: what problems are your early adopters having? How is your product a solution to those problems?

Next, you need to crash test your hypotheses as quickly and cheaply as possible before going and meeting your future users. You can start by reading up on the market and the users you plan on building your MVP for, as well as contacting industry experts and fellow PMs from other companies. Combine this information and try answering the following: What similar products are they using? What existing products scratch a similar itch to yours? Are your early adopters using it? Why? Use these answers to refine or change the hypotheses you’d like to test.

It’s now time to go and meet your future early adopters. This isn’t always easy, as you might run into problems with every part of your organisation: the sales team who do not want to jeopardise their client relationships, the comms team who don’t want to risk a PR controversy as well as investors and developers who want to jump headlong into building a product as fast as possible. But it’s your job as a Product Manager to bypass all these conflicting objectives and to empower product decisions with information that you can gather by chatting with other humans, out in the real world!

The approaches described in the following paragraphs will enable you to begin filling out your Lean Canvas with information about your users (problems, customer segment, unique value proposition). In turn, this part of the canvas will enable you to drive product decisions with a user-centric approach, ensuring you’ll always stay as close as possible to your users, their problems and their needs.

Meet and understand your early adopters

Identify your panel using personas

In order to test these assumptions, you need to create a panel of early adopters. These users will help you answer key questions, iterate on your product and better understand your larger user base. If your product’s vision and promise resonates strongly with them, they may even become your first real users and your product’s first ambassadors.

Before going out and trying to meet your future early adopters, we recommend taking the time to create a persona of this (for now) imaginary group of people. The kind of information that should compose your product varies a lot depending on what you’re trying to build. For example, a B2B product’s early adopter persona might be focused around a highly specific skill-set or professional background, whereas a product with a broader audience will define their users using socio-economic indicators (age, income, education, digital literacy…). Always keep this persona in mind when making product design decisions, and make sure you continue updating your personas as you learn more about your users.

Recruiting a panel of early adopters

Recruiting a panel can seem daunting at first. We recommend starting simply, by recruiting people you know who fit the profile of the persona you created. By asking them to introduce you to friends and colleagues, you should already be able to form a group of potential early adopters.

If this isn’t sufficient, try to meet your ideal users where they congregate, both online (social media, specialized forums, etc.) and in the real world (at events, meetups, seminars…). A last resort - which is very effective, but also quite costly - is contracting a specialized agency to build a panel for you. This is especially useful for very niche products, but expect to pay handsomely.

Once you’ve built a panel you’re happy with, you need to start thinking about how you’re going to interview them. We highly recommend doing this yourself, as, in our experience, Product Managers who roll up their sleeves and do this themselves usually get a lot more insight and value out of the process. This goes for both conducting the interviews and analyzing the data.

Their problems, your solutions

Interviews and observations

Before you get started, always remember that you started this whole process to learn from your users. This is not the time to pitch your future product!

We recommend starting with some one-on-one interviews (face-to-face is always preferable if possible). If you’re new to this, don’t hesitate to base your interview script off some great examples that exist, like Ash Maurya’s example in Running Lean. The objective here is to confront your view of the problem with your interviewee’s view. Go through all the problems you have identified by talking them through one by one. Really try to get to the bottom of each issue by understanding where the problem comes from, how it affects them, and what they are currently using or doing to get around the issue at hand. Don’t just go by what they’re telling you, but ask for examples, stories and real evidence that this problem exists in their lives. If your interviewee tells you they are experiencing a real issue, but are currently not doing anything about it, they may be lying to you, consciously or unconsciously, or maybe the problem you’ve identified really isn’t that big of a deal to them.

In general, you can be relatively certain that you’re onto something if a significant amount of interviewees (around 10-20) report they’re having the same problem. It’s an even better sign if many of them are actively looking for a solution, have built one themselves, or are using an existing product (it’s even more encouraging if they’re paying for the product they use).

Brainstorm solutions

Once you’re sure you’re addressing a problem that is really worth solving, you need to begin thinking of some solutions! As you may have noticed during your interviews, many people are very good at describing their problems quite precisely - but very few are good at thinking up solutions to their issues.

We’re big fans of Design Thinking as a framework to help you turn a list of observed problems into potential solutions. Here are the main steps and tenets:

Work with a multidisciplinary team, composed of technologists, designers, business experts… They will all play an important role and contribute an interesting perspective.

Start with a divergence phase: use all the material you’ve accumulated up till now, including your interview verbatims and such, to find a list of varied possible solutions - don’t be afraid of coming up with some crazy, far-fetched ideas.

Bring the team together and identify some of the best ideas during a convergence phase. You can judge ideas on their technical feasibility, coherence with your existing product lines and brand, monetization possibilities, existing competition, uniqueness, and patentability…

Build Prototypes

When prototyping, anything goes. You’re looking for a fast, simple and cheap way (this means with as little code as possible) to express your ideas. From videos to roughly sketched interfaces, to simple mockups and prototypes (built with tools like Sketch, Powerpoint, Balsamiq…), use the tools that you have at your disposal to build something you can put in the hands of your panel. Again, we recommend you try to do this amongst yourselves in order to be able to iterate quickly and cheaply without the intervention of a design studio or other outside help.

Test your ideas

Now that you have a prototype of your solution, it’s time to call back your panelists and organize testing sessions with them. The objective here is to understand if your proposed solutions match with the problems your panelists are experiencing. Have them look at or use your prototype. Ask them what they like and dislike, what seems essential, or useless, or missing in the prototype you’ve created. If you’re getting a lot of positive responses, it’s a good idea to make sure your panelists aren’t biased and overly-friendly. Ask them if they’d like to sign up to your mailing list to hear about the product’s launch, or put in a pre-order, or help you spread the word about your product. This will help you understand how enthusiastic your panelists are, and, hopefully, have the added benefit of ensuring they will become your first clients when your product launches.

This article is part of a series on Product Management: Product Academy volume 1.