Giving Your Idea a Real Shot (Pt II)
Why Your Idea Isn’t a Product and How to Change That
Part I of “Giving Your Idea a Real Shot” provided actions and perspectives that when adopted can drastically improve your chances of turning your idea into a product or business others want. From realizing that your ideas are if not wrong at least incomplete, to making more efficient iteration cycles, we then talked about the need to understand users. And we left off at the next action item: customer interviews. These interviews are some of the most useful tools to convert the idea in your head into a solution in the real world. They come in four types and you do them in order:
- Problem interviews
- Solution interviews
- Qualitative Validation
- Quantitative Validation
The objective of the first two is simple: to learn.
During the problem interviews, you are looking to learn about the problems faced by those people you are servicing. This is a little counterintuitive because how could you know who you are serving if you don’t know the problem you’re solving? In practice, it works out because you often start with that idea of yours in mind. Let’s use our experience with mediaBrew as an example.
We were originally building a news aggregator. But we abandoned that idea and we were left without knowing what to do. We knew we wanted to help people find signal in the sea of noise that is online content. We also gravitated towards journalists because we were tired of the left-vs-right circus that’s news media in the U.S. these days. So, we scheduled conversations with journalists and asked them to describe their workdays, what they did, what they struggled with, what tools they used currently.
While talking to journalists we ended up talking to friend who hosts a podcast. Serendipity, I know. At one point she said “I just want to combine all of my tabs and files into one master file.” We thought that was interesting and in all subsequent interviews we asked about that problem: How often did people face it? How painful was it? How did it compare to other problems they faced? Eureka! We found many people who faced and hated that problem! We made some assumptions. Mainly, there was plenty of them, they were bothered enough by it to pay for a solution, and they were connected enough to create a market we could serve. We did some online research and concluded that the problem looked promising enough to go after it (meaning, it could potentially serve enough people to make a profitable business out of it).
So we spent four months developing our MVP for them to try… No. Of course not (see our previous blog post if it isn’t obvious why that’s not a good idea). We didn’t build anything but instead worked on finding the elusive product-market fit. That is, the right product, for the right audience. Just because you identified a problem doesn’t mean that you can develop a solution, or that even if a solution was viable, that people would really want it (enough to pay for it, enough to adapt to a new workflow, enough to tell their friends about it). To accomplish that we used what at this point might become your best friend: mockups.
A mockup is some representation of what your solution looks like, and what it does. It must meet the following criteria:
- Be easy to create — usually a day or two
- Be specific enough that prospective users get a clear idea of how it looks like and what it does
In a lot of cases, as it was in ours, it’s a drawing, or more specifically, a series of images that show how the solution (product) would look and function… We made them using Paint, and it looked something like this:
We had identified a problem from our interviews (i.e. synthesizing content from multiple sources is slow and tedious), and we designed our version of a solution to it. Our mockups contained those features we thought would solve the problem we had identified.
With a mockup in hand, you moved on to solution interviews.
In our case, we created a presentation that flowed like the use of our website would flow. We pretended to click on a button in the image and the next slide would be the window that opened when “clicking” on that button.
We found people who we thought faced that problem and we held those interviews. Again, future posts will cover more details on exactly how to hold those interviews, but briefly, the main objectives of the solution interview are to:
- Identify the market
- Identify your early adopters
- Determine the minimum set of product features to include
- Determine if the pricing model works
Your focus during those interviews should be to learn, not guide or persuade. You’re not convincing someone that your product is great and can solve their problem(s). Instead, you ask open-ended questions with genuine curiosity. That means avoiding:
- Do you think this feature is a good idea?
- Would you use this product?
- Which features did you like the most and why?
- Which ones could the product do without and why?
- What is this missing for it to be of value to you?
We talked to just about everyone: marketing specialists, PR firms, bloggers, content creators, graduate and undergraduate students, academic researchers, podcast hosts, journalists, lawyers. On and on the list went. And what did we find? Most of them did not have that problem or it wasn’t as painful to them to pay any money for a solution. But, we did find interest. In particular from three groups: academic researchers, students, content writers. Those are two, maybe three markets. The challenge then is finding which one of those markets looks most promising. Because yes you might be able to capture all three eventually, but at the beginning, you want to focus on a niche market and nail it, make them become superfans of your work. For that to happen you need to tailor to them and understand their problems like no one else does. More on that soon.
By having those conversations you inform your product development. Be careful not to just add or remove whatever features users point out, though. It’s your job to translate what they say into the version of your solution that actually works for them. If a prospective user says “I didn’t like that button” you should not take that as “get rid of it”. It could be that it is positioned in an unexpected location, or the color is different from what they are used to seeing for similar buttons (think what would happen if the Maximize button on a computer window screen was red and the “Close” button was green). So listen attentively, be curious and let the interviewee talk. On and on. Ask “why”. Then you’ll understand what’s behind their message.
The ultimate goals are to know how much each interviewee struggles with the problem you’re solving, what they liked and didn’t like about your intended solution (and why!), some intuition of whether they would likely use that solution (which involves changing how they do things now) and lastly, if they would pay for it and how much.
Side Note: Moving Beyond Interviews
Another way of testing whether you have a problem people care about enough, and a solution worth building, is to build a site that asks users to go through the process of signing up.
You build the skeleton, just enough of a website to show what your product would do, and add the steps for them to sign up for it. You find where your audience hangs out (virtually or physically) and display your site there. Then you measure the number of people that visit the site and that actually sign up.
This will prove or disprove a couple of things: you know who your audience is and how to reach them, and there is real interest in your product, or not. This is a low-effort and relatively inexpensive approach to determine if you’re getting enough interest. If so, then it makes sense to start thinking about actually spending the time and resources to build it. Otherwise, you need to change something(s) — from design to audience to problem statement, it could be anything, which is why even here it’s a good idea to hold interviews so you can ask “what” and “why”.
Once you’re confident about (a) the problem, (b) your early adopters’ demographics and psycho-frame, (c) the solution minimum features, (d) pricing, and (d) that you can scale it into a business, then and only then you move onto validating qualitatively and verifying quantitatively. That’s a whole other topic, but just know that it has to do with metrics you can see or estimate, like the percentage of early adopters who understand your product and sign up for it, or the percentage of users who pass the Sean Ellis Test.
All this, however, the problem and product interviews, mockups, and verification are meant to be quick ways of testing your ideas. Remember that the name of the game is short testing cycles, where you go from hypothesis to results with as little time and resources spent as possible. Also remember that for this process to actually help you, the information you gain needs to be of value. So you must be methodical in how you gain knowledge, otherwise, you may have the shortest test cycles in the world, but if they are going in the wrong direction you will never get to your destination.
When gaining and interpreting information you’re fighting powerful forces. One is your own bias, the other is that of your prospects. You shouldn’t build what you want because you are not your customers. But you also shouldn’t build what they say they want, because people don’t know what they want.
The best way to stay true to the mission of solving an actual problem for your customers is to fall in love with the problem itself. The opposite, and what you shouldn’t do, is to fall in love with your solution. Throw that ego out the window. Otherwise, you are too easily persuaded by someone saying “This is awesome!” when they’re just being polite. Conversely, if you hold your solution too close to your heart it’s equally easy to be discouraged when one pessimistic uncle says “This will never work! Happy birthday by the way”. Easier said than done, but the best way to deal with the noise and extract true signal from the information you gain is to be a little obsessed about the problem, not the solution, so that the rest (the long nights, long months, and high levels of uncertainty) becomes easy.
And that, Falling in Love with the Problem, will be the topic of our next and last part in this series of “Giving Your Idea a Real Shot”. Stay tuned and stay learners!
To go from your idea to the right idea, you want to iterate quickly and in the right direction. The best way to do that is by putting your idea in front of your prospective customers/users and measuring their reactions.
One approach is to do interviews, first to identify the problem, second to test your solution to find one that your target audience loves, third and fourth to validate quantitatively and qualitatively. Another approach is a little less interviews-based and consists of displaying your solution capabilities and asking people to sign up for some future access, like a waitlist. The intent is the same: to test whether people like your intended solution. If and when you gain enough positive signals, then it might be time to finally build a simple version of your solution.
As you navigate that process of coming up with ideas and designs, testing with users, going back to the drawing board, testing again, so on and so forth, it’s easy to be taken in the wrong direction by following incorrect information. As an example, it’s easy to seek or prefer information that confirms your biases, but that maybe doesn’t really reflect reality. One way to avoid that is to fall in love not with your solution, but with the problem you’re trying to solve. But more on this to come.
Coming up next on this Series:
- Fall in Love with the Problem
- Practical Guide to Conducting Customer Interviews
- Investors are People Too