I get a lot of emails like this:

Hi! I built an app. Can you take a look at it, give me your feedback, and then help get the word out to your readers?

No. I wish I could, but no.

But this happens so often that I wanna write a blog post explaining the position I’m in.

I only have so many hours in the day. I’m usually booked 3-4 weeks in advance. I set strict work/life balance guardrails on my time, so any work I add to my calendar either has to displace paid client work, or free community work like scripts & blog posts & videos, or my personal life. I just can’t displace any of that for free private work.

I do absolutely consult for software vendors. I used to work for Quest Software, and I’ve consulted for Amazon, Google, and a lot of third party software vendors. It’s real work that requires real effort on my part, and I need to get paid for that.

Having said that, I still wanna help you for free, so I’ve put together this blog post with my favorite advice for software makers. There’s a lot of hard-learned lessons in here, and I hope you can just read ’em and avoid some of the most common pitfalls that folks run into.

First, read The Mom Test.

The book The Mom Test by Rob Fitzpatrick teaches you what questions to ask about your app idea, and who to ask. It sounds simple, but it’s not. Instead of approaching people with your solution, what you wanna do is ask them about the problem that your app solves. You also absolutely do not want to give them answers, nor do you want to lead them, nor argue with them. You want to ask questions that prompt them to tell you what they do, without skewing their answers.

For example, let’s say you’re building a SQL Server monitoring tool. Instead of mentioning anything about a monitoring tool, the first questions you might ask:

• “When was the last time you thought your SQL Server was having a performance problem?”
• “What steps did you take to investigate it?”
• “How long did that take?”
• “Did it get you across the finish line?”
• “Are you satisfied with that? Are your users and manager satisfied with that?”

This helps you understand your real competition. Your toughest competition is complacency. Your target audience are already used to solving the problem, so any new solution is going to require them to research the options, evaluate them, implement one of the solutions, learn to use it, and to remember to use the new way when the problem strikes. Those are huge, huge barriers to adoption.

If they’re satisfied with their current solutions, stop. Give up. Look for another problem to solve. (I know you’re not convinced yet, so keep reading to see the rest of the hurdles you’re going to need to jump.) It’s not that you can’t build something better – it’s that your marketing costs will be unbelievably high. If your target market is already happy with what they have, they’re not going to switch to your product without yours being spectacularly better, cheaper, and simpler.

But if they’re DISsatisfied, congratulations! You’ve found a potential market! Keep going and ask the next question.

Next, ask where they’d look for alternatives.

In our monitoring system example, you’d ask, “It sounds like your manager is dissatisfied with the high costs of your SQL Server performance problems, so…”

• “Have you looked for alternatives?”
• “Where did you look?”
• “What alternatives did you find?”
• “What stopped you from switching to one of them?”

These questions help you understand what your target customers are looking for, the marketing routes you’ll need to take to get your product out there, and the common objections as to why your potential customers aren’t using your competitors.

In our performance monitoring example, let’s say our target user says they Googled for stuff. After you’re done asking them questions, you want to thank them, then go off and repeat the same steps they did. For example, say they Googled – then you should fire up a fresh VM from a cloud provider, not signed in with your accounts, so it doesn’t skew your results, not using any ad blockers, and do the same kinds of searches they did, so you can see what you’re up against:

Look at the first page of results, above the fold. This is your second layer of competition (after complacency), and it includes the AI summary at the top, and the sponsored results. These are all things your users are going to consider.

Make a spreadsheet of the various options, with the competitors going down the left side and the competitive attributes across the top. The competitive attributes aren’t the things you’re proud of: they’re the things your target user said they were dissatisfied with. For example, if the target user said they were having problems with the monitoring tool being too slow, too expensive, and not compatible with Mac desktops, those are the things you’d put across the top, and gauge each of your competitors to see whether they would solve your target user’s problems.

Sometimes you’re going to find that the competition actually already solves the target user’s problems.

Because sometimes, the target users are lying to you.

They’re telling you that they looked for alternatives, but they didn’t. They’ll tell you they tried the alternatives, but they didn’t. They’ll tell you the alternatives had a specific problem, but it was years ago, and the alternatives have long since solved that problem. Your target users just haven’t found out because – again, complacency.

I know, because I see it all the time with my own clients. (That includes you, dear reader.) Folks gripe about a problem – monitoring, source control, database management tooling, you name it – but when I ask the shallowest questions about what work they’ve done to replace those options, the answers become vague and evasive – because the problem isn’t bad enough that it bubbles up to the top of their task list.

The Lean Startup explains who to ask.

In a perfect world, you’d ask perfect strangers, but getting contact info for perfect strangers is pretty hard.

The book The Lean Startup covers how to do it, and I’m gonna try to summarize it as best I can. Build a short 1-page landing page describing the pain you think your target market is facing, and say that you’re working on a new way to solve it. People can put in their email address to get notified when the beta version is available.

Then, buy Google, Facebook, and Instagram ads for the kinds of keywords you think your target market will be searching for. Say you’re building a SQL Server monitoring tool – you don’t actually have to buy keyword ads for that, because that’s expensive. Instead, you can buy keyword ads for related topics with less competition, or have Facebook build you a target audience for the kinds of people who visit a particular web site.

You can – and should – do this even before you’ve got a product built. (That’s why it’s called “lean” – you don’t have to spend much.) This way, as contact emails come in, you can use the questions you built from The Mom Test to talk to them about their pain, and where they’ve been looking for relief. This helps you validate your product idea long before you invest in it.

At that point, you’ll understand the pain, market, and your solution.

You’ll understand more about the pain you’re trying to solve, how your target users are relieving that pain today, and how your proposed pain relief will need to look in order to get any market traction. Ideally, you do these questions first, before you build something, so that you save valuable time. I’m not saying you’ll save time by not building altogether – I’m saying you’ll build something that solves the real pain users are facing, not the pain you think they have, and not the pain your competition thinks the users have.

Ideally, you build something that solves it in a clear simple way.

Non-ideally, you’re reading this after you’ve already built something – but at least now you understand how you need to modify your app, pricing, and marketing material in order to be the #1 competitor in your target market.

Next, build your minimum marketing materials.

At minimum, you need a single web page (which can be the readme.md in your app’s Github repo, if you’re open source) that explains:

• The pain the user is facing
• A clear, 30-60 second video demoing your solution relieving that pain (can also be an animated gif)
• A 2-3 paragraph explanation of how your solution relieves that pain
• Pricing (or if it’s open source, the license)
• A download link, plus a link to minimum requirements and installation instructions, with a video showing the fastest, simplest installation method
• A few 1-5 minute videos showing common use cases, and 2-3 paragraph text explanations with screenshots of those use cases, covering folks who wanna read or folks who wanna watch/listen
• A link for where to get support or file issues
• A signup form to join your email list for announcements

You want the reader to go from top to bottom to get their objections out of the way, in order, so that they’re gradually more and more sold on your product. Think back to the target users that you interviewed, what they were searching for, and why they didn’t choose one of the existing alternatives. Your page needs to make it clear that your solution doesn’t have those problems that prevented ’em from using one of the alternatives.

I’m going to use Erik Darling’s SQL Server Performance Monitor page as an example:

That one first line addresses his target market’s most common concern: performance monitoring tools are expensive.

Then, go back to the target users that you interviewed and tell them, “Hey, while I was doing research, I stumbled across this page. Can you take a look at it?” Have them go through the page, and just listen to their reactions. Ideally, when you’re just getting started, you don’t want your name on the page: you just want their raw reactions as to whether or not they’re interested. If they jump up and point at the screen, saying they gotta have this thing, then you’ve done a good job.

Then the real work starts.

I know, I can hear you from here, yelling, “OMG, Brent, I thought the rest of this was work!” Nah, that’s just table stakes.

Remember back when our target users said they looked for alternatives, and where they looked? You need your solution to show up there. Some of those locations are going to be genuinely hard, like getting on to the first page of Google search results. You may have to resort to expensive ads on Google, Facebook, Instagram, etc, and those also really need expensive consultants to get the job done correctly.

You probably wanna start with the cheapest, least-popular places where your target users looked. For example, maybe they looked in Reddit or a particular forum. You wanna be active there, showing people how to solve their pain points with your solution, without being spammy.

You can’t just announce the product once and expect the users to come rolling in, either. You have to keep talking about the pain, your relief, and how it works. Again, I’m going to use Erik as an example. If you go to his blog or his YouTube channel, odds are that at least one post in the last week or two is about his free Performance Monitor. He has to keep demonstrating it in different ways, showing its value, showing how easy it is, because people never hear you the first time.

That work never ends. Ever.

I announced sp_Blitz, my free SQL Server health check stored procedure, way back in 2011, and I still have to blog about it and the rest of the First Responder Kit stored procedures all the time. New users keep coming into our community, experiencing the same database pains, and I have to keep showing them how to get relief. All this, even though my solution is free!

I can’t do all this for everybody.

I truly wish I could. I get so many emails from people with really cool ideas. Heck, the thing that motivated me to write this post was that I got an email from somebody who’d built an open source tool on Github that sounded like something I’d personally love to use – but the Github readme included a 2-page wall of text about the product, no screenshots, no license, no list of versions or platforms supported, etc. I felt like I was part of the target user market – but I would have to do so much work on my own part to even figure out if the thing could work for me, and … I just don’t have time for that.

In the age of AI, where anybody can haphazardly describe something and a robotic assistant will slap something together that looks vaguely professional, building an app is the easy part. It’s too hard for consumers to sift through the noise to find the good stuff.

However, we’re also in the golden age of open source, where it’s never been easier to manage a public open source project. We now have all kinds of AI tools to help us vet code contributions from strangers, quickly with low effort.

So if you’re thinking about building something to relieve a pain you’re experiencing, and you don’t wanna do everything described in this article, I’d highly encourage you to look at the open source tools you already use on a day-to-day basis. Could those tools be modified to more helpfully address the pain point you’re experiencing? Are the project maintainers open to code contributions from you that aim to relieve that pain? Consider starting there instead of building an all-new tool. You’ll get the satisfaction of helping people get their pains relieved – without the pain that comes with trying to get a new product adopted by the market.

I know, it’s sexier to be the person who runs/owns The Product™, and it’s tempting to think you could be the next SaaS gazillionaire from your Incredible Idea™, but the reality is a lot harder than that, and it’s a grind. It’s absolutely doable, and you CAN do it – but it’s unrealistic to expect other people to do that grind for you.

The least I can do is give you a roadmap for that grind. If you do that grind, and you build the minimum page described above, THEN email me a link to it! That way, I can take 5 minutes to read through it, scan a couple of the videos, and give you my feedback for free. Good luck, happy grinding, and I’m excited to see what you build!