Fishing for Product Validation

How to get a good idea of how good your idea is

Let’s just say you have an idea for a business or a service, or you’ve at least uttered the words “we should make an app for that,” kudos to you. It shows you’ve been paying attention to the world around you. Now let’s just say your idea is brilliant/rubbish. How do you know the difference? You do some early research. It’s actually not that hard.

One of the most important things to be aware of at this stage is that your idea is in its most rudimentary stage. Ideas, no matter how potentially mind-blowing, need to earn your resources. This means keeping the investment of time and other resources low initially and increasing allocation as the idea merits.

With that in mind, here is an easy set of guidelines for testing an idea. I’ll use an example project I’m working on for demonstration purposes. It’s a fishing app. To be clear, “fishing” as in catching aquatic animals on a line, not “phishing” as in “email can be a dangerous place.”

1. What’s the problem?

There isn’t a good resource for getting information on fishing locations on a mobile device. I can’t tell you how many times I’ve gone fishing at a local pond, without so much as a nibble to account for the $23 of tackle snagged along the bottom or in nearby trees. I think it would be great to have an app that kept me up to date on the stocking status of my favorite spots. ← that the last statement is an assumption. More on that later.

2. Who is my customer?

This is can be as simple as defining “who will be using my product?” Let’s make some assumptions. Keep it general. In the case of the Fish Stalker app, I’m starting with simple who, what, when, where, why, and how:

• (Who) like to fish
• (What) use stock reports for local fisheries
• (When) As alert worthy events happen (or as close as possible)
• (Where) anywhere? could be local information or destination related
• (Why) want to catch more fish
• (How) use a mobile phone or web apps

We could go into more exhaustive detail listing out assumptions about our user, but we’re limiting allocation, remember? We could spend more time mapping out a user persona with more fidelity on needs, goals, assumptions, and constraints. For now, this is enough to illustrate the next step.

What is the riskiest assumption from our list?

• We know there is a probably a significant market for people who like to fish, this is validated by a large presence in retail.
• We know that an increasing number of people are using smartphones to gather information about their surroundings every day.
• What I’m not sure of is this, is there is a significant correlation between the behavior of checking the fishery stocking reports and our user.

Let’s use that as a hypothesis for our research:

“I believe that people who like to fish, check fishery stocking reports when they decide where to fish”

To sum up the process to this point — I think I have an idea of what this product should be, but it would be foolhardy to be confident that the direction I’m taking is correct based on my assumptions alone. Yes, I like to fish, but does my behavior as a novice fisherman really scale to a larger audience? I truthfully don’t know. Time to test my hypothesis.

3. Seek feedback

I went to social media.

You may have noticed that I didn’t get super specific on the initial question. You also may have noticed that this wasn’t a very deep dive on the research front; only 4 respondents. But, this was enough for me to understand the need to pivot without spending more time on crafting out a survey for a larger audience. Remember, we are keeping investment light at this phase. Baby steps.

Learnings

From my initial query to social media, I was able to garner two things.

1. I was headed in the right direction…kind of. There is, in fact, interest in an app that aggregates information to help in deciding where or when to fish.
2. My initial assumption that stocking reports would be the greatest value proposition was only tangentially correct. While I did get one unprompted response validating my initial assumption, there was a lot more gravity around getting information relating to environmental conditions like weather, water clarity & volume, local insect hatch etc.

Hypothesis invalid. A product that offered reports might be of value; I was probably just putting too much weight behind stocking reports alone. Going directly to market with that as the lead value proposition, could easily result in a fumbled or failed launch.

I need to pivot. Luckily, only a little bit. I would do this by rewriting the hypothesis to match my findings and then retest. It could be accomplished by generalising the value statement like this:

“I believe that people who like to fish, want simple access to aggregated fishing related conditions, to better inform their decisions on where to fish”

I could test this new hypothesis with a rank sort order exercise and potentially validate the hypothesis while getting an idea of what matters most to the greatest number of respondents. But that’s the next step. It’s a little more involved. But I’m willing to invest in it, because of what I’ve learned in this less rigorous exercise.

Cost

30 minutes over about 24 hours.

Savings

Not completely certain of this, but avoiding the need to hire a developer to build out proof of an unproven concept is significant.

Conclusion

At this point, I know my idea is good enough to continue. Future exploration will help me determine how good. I’m willing to invest more time in user personas, Jobs To Be Done, Storyboards, as well as Objectives and Key Results (No wireframes or mocks yet.) I’ll cover all of these in later articles.

Please let me know if this article was useful with your claps, feedback, and questions below.