How to Find a Niche and Validate Early Stage Pricing

Editor’s Note:
Over the past few months, I’ve asked creators about their success with a few key areas of early-stage tech entrepreneurship. That includes, building a minimum viable product, market validation and conversion rate optimization.

But for many of you, the biggest hurdle to overcome precedes validating your MVP or optimizing your conversion rate.

That hurdle is: Finding a niche.

In this article, Alex Moskovski — a maker and monetizer of software — will tackle that very problem and give us the rundown on finding the right niche, validating your MVP and getting your early-stage pricing right with a dynamic testing model.

Side note: Enjoying the articles so far? Tell me what you’re struggling with in your own projects via email or Twitter.

---

I recently wrote an article about my little SaaS experiment in the Russian market that brought me a steady $1,000 in monthly revenue, Menumake.

That article went viral. Many people asked a lot of questions about the details of the building process and what they needed to do to replicate that success.

Here’s a detailed follow-up on the most interesting and complicated parts, plus some tricks on how to find a niche and validate early stage pricing.

Table of contents:

1. find your niche with 3 simple tactics
2. bootstrapping a lean MVP
3. ship quickly with this tech stack
4. nail early stage pricing with 2 simple tactics

Three Simple Tactics To Find a Niche

How do you find your next idea and validate demand?

After all, you don’t want to waste time building an MVP that nobody wants.

The first and the most obvious way is to have some stats that identify a pain point.

Tactic 1: Data that leads to a pain point

In the SaaS example from my first article, I used Google Analytics data on keywords people used to find my other startup, Postio.

I built Postio to make it easier for people to find and publish content to their social accounts and groups. As a part of its marketing strategy, I bought and published a dozen articles on various subjects targeted at the web services audience to get some extra traffic.

All of a sudden, Postio started to get a large amount of traffic from Google and Yandex (a Russian search engine) with keywords that have nothing to do with Postio itself.

The keyword data looked like this:

Clearly, people were having real issues with this menu thing.

I had two options:

1. build it in the existing project
2. start a spin-off

I chose the latter, because it would be easier to implement SEO strategy and branding later on.

Also, the concept of menu generation is entirely different than the concept of post publishing, which Postio had been built on.

Back to discovering ideas.

Tactic 2: Paving

You can follow the method below, even if you don’t have any existing projects or stats.

I call it paving.

All you have to do is to go to any niche forum and start analyzing what people are doing there and which problems they’re trying to solve using the community.

For example, since we’re on SitePoint now, let’s consider their sister site, Flippa.

Most webmaster forums follow a common trend: they all have a marketplace section.

This method of buying and selling online is highly inconvenient and risky.

This path was just asking to be paved. And Flippa has done it, elegantly and efficiently, by creating a spin-off centered around making website and domain transactions seamless.

I also observed this trend in the Russian market, and I’m sure people from other local markets can tell the same story.

Just go to niche communities, listen to people, and every time you see an issue, ask yourself: How can I optimize it using the technology I wield?

It’s incredibly valuable to encourage this attitude as a mental process. I know it’s hard to do, because, since school, we’ve been taught to solve problems, not to find them.

You aren’t always going to be given problems to solve. Reverse engineering the process is a valuable skill to have in the workplace and in your personal projects.

Tactic 3: My niche-specific insight tool

Okay, the third method. It’s quite chaotic, but I often use it to reignite my brain and to set it to the right mood. I wrote a simple script that generates a table of entities and corresponding verbs to facilitate discovering new connections.

Here’s an example:

Remember, you need to fine-tune this script to match the niche you’re trying to get insights into. And it doesn’t need to be verbs and entities; you can try anything. The point is to get as many relevant intersections as you can.

Here’s the code I used for the example:

<?
$entities = array('image', 'photo', 'text', 'source', 'site', 'traffic', 'money', 'book', 'e-book', 'file', 'smartphone', 'camera', 'notebook', 'cities', 'distances', 'cars', 'mobile', 'book', 'sex', 'love', 'classifieds', 'ads', 'alcohol', 'travel');
$verbs = array('sell', 'buy', 'rent', 'exchange', 'free', 'give', 'book', 'clean', 'find', 'classify', 'compare');

echo '<table style="width: 100%">';

foreach ($entities as $entity)
{
    echo '<tr>';
    foreach ($verbs as $verb)
        echo "<td style='font-size: 14px; padding: 5px; text-align: center'>$verb $entity</td>";
    echo '</tr>';
}

echo '</table>';
?>

There are plenty more tricks for finding a good idea, but let’s not become laser-focused on them now, as we need to move to the next step of bootstrapping a startup.

Building a Lean MVP and Validating It

When I was building the MVP for Menumake, I tried to get rid of everything that could be added later on.

Here’s the menu creation interface of the MVP as compared to the one that Menumake has now, for one:

Most of the time, people that ask me what they should put in an MVP tend to overestimate the importance of some features.

Consider pruning the following:

• Authentication. Do your users really need to have an individual identity to solve their problem?
• Dedicated support interface. Having just an email somewhere in the footer may suffice in the earlier stages.
• Payment gateway. You can collect payments manually. Stripe can wait.
• Sophisticated design. This can be done later, after the validation. To start with, Bootstrap will do this job just fine.
• Robust infrastructure. Now, this can be tricky. I’m not saying you should write unreadable code, but maybe scalability issues can be addressed later. Sure, if you can assemble a scalable infrastructure fast, there’s no point using a shady stack. The rest of us shouldn’t spend much time obsessing over pleasurable issues of exponential growth at this point.

What’s Your Tech Stack?

I use a simple LAMP stack with Codeigniter and jQuery mixed in for all my web services. When the task is demanding, I consider Go.

That’s just about it.

I go with what I’m most comfortable with, and what allows me to ship fast.

That’s what makes the difference at the end of the day. Users can’t see your stack anyway.

Consider the web app in question: what would be the most important features we couldn’t omit?

Let’s even go a bit further and ask a bolder question: what do our prospective users expect to get from us, and why are they here?

It’s not for a signup form, support, and a neat design. Even the menu creation interface doesn’t interest them yet.

They want a menu. In their group. Right now.

This is the solution we should strive to achieve, removing any obstacles that could be in the user’s way. All we need is a simple generator and instructions on how to install a menu.

Yes, I know, I didn’t follow my own advice with Menumake’s MVP and built in some extra features like authentication and a bit of user account UI. I could afford that because this is not my first project in the niche, so I had a lot of templates and could set everything up fast.

Back to the menu generator.

Again, I hadn’t used anything fancy, just good old ImageMagick with simple math sorcery.

After building the whole menu image, it was cut into pieces, and offered for download with brief instructions on how to put it in the group.

This simple process brought me around $50, validating the idea.

Let me stress something one more time: I never considered myself a professional developer. I’m lousy when it comes to sophisticated stuff like modern approaches in software engineering. So I have to cut corners. If you are comfortable with building scalable infrastructure from the day one, you have an edge on the people like me.

Just don’t obsess over it at this point. Most of the time it has nothing to do with getting your baby startup off the ground.

Pricing Your MVP

Pricing is hard.

What’s worse, there isn’t much space for guesstimating here, since even the smallest mistake can easily cost you money in the long run. We need to stop thinking of pricing as an art form, but rather adapt a more data-driven approach.

Usually, I resolve this issue in two steps: estimating and fine-tuning.

Step 1: Estimating

First, we need to look around and try to get an idea of the average price in the niche.

If your SaaS is in a well-established market, you can use catalogs like Capterra or GetApp to get an idea on the distribution of prices.

You can collect raw data from the competitors yourself, but I suggest outsourcing it to someone. After all, that’s not the most exciting thing to do.

After collecting the data, I visualize it on a chart.

Most of the time, it’s a bell-shaped curve.

If it’s not, or there’s more than one bell (like on the screenshot below), chances are you’ve taken your data from several niches instead of one, and you need to eliminate the sources that don’t belong to your segment of the market.

All we need from our chart are two prices, the one at the beginning of the bell and the one at its end.

These are the minimum and maximum price points.

Usually, there’s no point going beyond this scope, but each case is different, and there are a lot of variables that you need to take into account when deciding whether to test the outlying prices or not.

Usually I postpone analyzing these prices until I have some real stats after the fine-tuning mentioned in Step 2 below.

Sometimes it’s impossible to estimate the price range because the market doesn’t exist yet. That was the case with Menumake.

So we have to find another way to figure out the maximum price users are willing to pay for our product. Again, there’s no silver bullet here, but for Menumake I estimated the maximum price by observing how much professional designers were charging for this job. (I figure they have much more modest expectations now.)

Step 2: Fine-Tuning

It’s time to fine-tune our price estimation. As much as we like to think we understand the pricing in our niche now, we don’t. The only way to actually figure out the most profitable prices is to test every single one of them.

In Menumake, I did this by assigning a random price — from the scope I’d estimated during Step 1 — to each user after the signup.

Sorry, no fancy AI algorithms this time:

Please note, I was testing two prices at the same time — for creating a menu, and for updating it.

But what if the users become aware of our unfair split-testing we perform on them?

Just tell them the truth.

Tell them that you’re trying to estimate the real value of your product.

Offer them a discount if they’re still unhappy about the price but are willing to negotiate.

Personally, I couldn’t believe how laid back my customers were about pricing. Sure, I had a couple of angry customers here and there, but there weren’t any issues that couldn’t be settled by offering a solid discount.

Make sure your testing period is long enough.

Remember, the sooner you find out the most effective price, the more you earn in the long term.

Oh, and don’t forget to re-adjust the prices for users that have been affected by an unfairly large price tag. A small discount would work.

To give you an idea of what you should have at the end of the test period, take a look at the data I collected for Menumake:

What do these stats tell us? Pretty interesting stuff:

• $1, $2, and $3 for menu creation and $0.50 for updating it are the most profitable prices.
• $1 has twice as many menu creations as $2 and three times as many as $3.
• The $1/$0.50 combination is the most profitable in terms of ARPU.
• Even though the $2 price appeared to be much less hassle for the same revenue, I decided to stick with $1. I wanted users to create as many menus as they wanted, as every menu had a little viral mechanism.

Yes, these conclusions are still imperfect, and there’s a lot of room for improvement. But at least we’re a bit closer to the reality now.

I hope both this article and my previous one have clarified some points on building a simple SaaS web app — despite there still being a lot of things I’d like to mention.