Validating Product Ideas Before Building Them

Hiya guys!

Patrick (patio11) here. You're getting this email because you asked to receive my occasional thoughts on writing and selling software.

[Edit: Actually, it's possible that you've never gotten an email from me. Somebody might have just given you the link to this page, which is an online archive of an email that I sent to folks who had asked for it. If you'd like to get articles like this in your inbox, totally free, about once a week or two, give me your email address.]

I'm sorry that it's been a month since my last email -- I got hit hard with a health issue. Getting substantial work done was like attempting to construct an Eiffel Tower out of wet spaghetti. I'm on the mend, and (gradually) ramping back up to usual productivity. Sorry for worrying y'all, and thanks for those who mailed with well-wishes.

One of the most common questions I get in my inbox is "I built this thing. It has no customers. How do I find customers for it?" This is a heartbreaker, because oftentimes the core problem is that the entrepreneur has succeeded in solving a problem which no one has. You can try to find customers for a solution to a problem which no one has, but it's like pushing a piece of string -- generally, it's a better use of your time to just toss it and try something with a market next time.

Thus the question: how do you de-risk production creation by verifying that there exists an audience who will pay for your solution prior to that solution existing?

My assumptions are going to be skewed in the direction of B2B SaaS products, because that's where my interests mostly lie. Your mileage may vary if your product is a tycoon game with dragons that you're going to sell on the App Store. (Send me an email when it launches -- I love dragons. There, one customer. Your second will probably be harder.)

Idea Stage: Does This Substitute For Anything?

Customers should already know they have the problem you think they have, and be attempting to solve it. If they don't know they have the problem, this suggests that you're a) going to have to engage in a very ambitious marketing campaign to suggest to them that a portion of the life they are living is, in fact, wrong or, more likely, b) you're delusional.

Many things which purport to make particular business processes easier are not in fact solving a problem, because the existing process is Good Enough. If you can't find any book written about it, any competing software, any much-maligned downloadable Excel spreadsheets... consider that it might not be an important enough problem.

The ideal product for a bootstrapped company solves a problem which is well-understood but poorly solved. There are probably many competing ways to solve the problem, some involving employee time and paper, some involving spreadsheets, and some involving one of several competing software solutions, none of which have dominant market share. This much activity suggests that people are genuinely having this problem, but there isn't a total stranglehold on the market by a company which you'd have to fight for mindshare.

You'd be almost crazy to bootstrap a company with Quicken or Excel in your sights... but making a more limited invoicing SaaS product, on the other hand, is a lot more viable. There are dozens of companies which have done it and at least ten have multi-year viability, so that suggests that if you have any path to getting to your minimum required number of customers, your product will probably work.

My favorite symptom of an unmet need for software is any Excel spreadsheet which is ever updated by one employee, sent to a second employee, updated, and then sent back. Every time that happens a SaaS angel gets its wings.

Customer Interview Stage: Is This Problem Top Of Mind?

Businesspeople generally have room in their head for three things: problem #1, problem #2, and Boring Stuff I Don't Have Time To Deal With Right Now. Don't build until you find people for whom this problem is, at least, problem #2. There are plenty of big hair-on-fire problems which can be addressed in the same amount of time as the not-such-a-problem problem you might think you could address as a first shot.

Note that, crucially, what to some people is a detail is to other people a life-or-death problem for their business. Ideally, you'll understand how the market/niches cleave prior to building your solution, because this will inform both the design of your product and the marketing for it.

How do you figure out what people in your industry think of your problem? Just ask them. Seriously, whining about how much work sucks is a well-established pastime enjoyed by all occupations, social classes, nationalities, etc etc. People will be happy to talk to you, often just given the opportunity of a sympathetic ear.

Three years ago, I had had the idea for Appointment Reminder, and wanted to discover whether businesses had a large enough no-show problem to justify paying $30 a month for it. I don't have great access to non-technical small business owners, so I just decided to pretend I was an extrovert for a day, and interview people door to door in Chicago.

Here was my pitch, which I made to every massage therapist and hair salon owner I could find just doing a breadth-first search down Michigan Avenue:

Hiya, do you take walk-ins? Are you the owner? Great, can I book the thirty minute option for name a service? Great, actually, I've got a request. More than the name a service, I am really interested in the business of name industry here and want to talk to you about it a bit. I'm happy to pay for your time. Does that work for you?

I lost my notebook where I kept the interview results (d'oh), but my recollection was that only one person out of a dozen plus actually took my money for this. Most were happy to talk, since unscheduled time for them in the early afternoon had a predicted value of zero anyhow. (n.b. That was, in itself, a useful lesson.)

Here's what I asked, for de-risking Appointment Reminder:

How many appointments do you have in a typical day?
So that is about X a month, right?
What is the ratio between booked appointments and walk-ins?
What do you do to book an appointment? Can you walk me through that? How do you get the appointment? What do you record it in? Does anything happen between you recording it and the appointment happening?
Do people not come to appointments ever?
About how often does that happen?
How does this make you feel?
Have you ever tried doing anything about the no-shows before?
How did that work out for you?

At this point, I did a quick demo of the two-page version of Appointment Reminder. It just basically demonstrated to people that I could automatically call their customers in advance of the appointment and leave a message. (This wasn't actually possible at the time, but hearing the message on their own cellphone was sufficient demonstration for everyone.)

That doesn't exist yet. Would you use it on your computer if it did exist?
[If no] Why not?
[If yes] I think it's going to cost $30 per month. Can I get your email address to tell you about it when it launches?

A variation on this last question, by Jason Cohen, which I rather like: "I think it's going to cost $30 per month. Will you write me a check for the first month right now to reserve your place? I won't cash it until we deliver." That keeps people honest about whether they actually need the thing versus just not wanting to crush your hopes and dreams.

Was this a total win for me? Actually, nope, it mislead me in one important way. I latched onto the idea "My core customer for this is someone with a walk-in services business, like a massage therapist" early in the cycle for Appointment Reminder, and then only interviewing massage therapists and salon owners gave me a availability-bias on who would actually use it. (Ten of the last ten people who said "Yes" ran massage therapy practices, imagine that! And ten out of ten were women! And ten out of ten used no scheduling software. Wow, that's three things I didn't know about my customers. <-- All three of these things are substantially wrong.)

But it was a darn sight better than firing totally blind. At the time I did this customer discovery, I had probably 20 hours invested in Appointment Reminder. If it had landed like a lead balloon, I could have either tried to find other customers or just given up and moved to a more promising idea.

What If I Don't Have Any Ideas?

Occasionally folks tell me that they want to run a SaaS business but have no idea for anything they could possibly build to solve a problem.

Sometimes this is expressed as "... that hasn't been done before." If that is you, don't worry, almost all successful businesses in history have been Done Before. Competition generally doesn't kill software companies, primarily because we're at the point on the technological adoption curve where most customers are moving from Non-Consumption to The Suckiest Thing That Barely Works. You can be that suckiest thing! Or rather, as of day 1, you'll be the suckiest thing, which is nonetheless transformative for your earliest customers that have the most pain associated with the problem. Over time you'll improve both your product and your understanding of their pain, allowing you to create value for customers with less urgent needs and improve the amount of value created all along the spectrum.

But let's say you've got nothing.

Alright, suggestion #1: try working in industry for a few years. I occasionally get college sophomores asking what problems Name an Industry has, and while I could make some guesses, no amount of my guessing would come close to working in that industry for a year or three. So do that. This will also let you developed a more nuanced mental model of the mind of potential decisionmakers at your target customers, which is invaluable when you're attempting to sell them on your solution.

I built back-office systems for Japanese universities for three years. First takeaway: don't build stuff for them, because it is overwhelmingly sold by boots-on-the-ground sales forces racking up expensive bills taking the relevant decisionmakers out drinking. But if you were to build stuff for them, you'd quickly learn that they treat student administration as a cost-center which they want to do for the absolute cheapest amount possible, but that everything on the critical path to undergraduate admissions has both high-perceived-urgency and high-value associated with it. (Unsurprisingly, since they make money when undergraduates accept offers of admission and their institutional prestige is affected in an outsized manner by who gets in and what percentage of those who get in say "Yes." This is called the "yield rate", and to my understanding both Japanese and American universities pay bespoke consultancies eyepopping amounts of money to manage it.)

Failing that: talk to people in the target industry. As a technologist, it's likely that you have incredibly deep expertise on a number of topics of potential interest to your target industry. For example, you probably know quite a bit about how one would go up setting a website and getting it in front of potential customers. Even if you have no desire to actually do that for them, teaching a class on it for Insert Industry Here will get you a bunch of people who'd be thrilled to chat with you about what their day to day lives are like.

Another option for talking to people is interviews. If you're smart enough to set up a blog about a given industry and write three posts, you're smart enough to interview people. Just say that you were impressed with their business and wanted to interview them for Name Of Your Publication. Some folks won't say yes to this, but many will. (Free publicity plus the psychological kick of being seen as the expert? Yes please.) Do the interview, but after you've done it, you're no longer strangers. Feel free to ask them about what really exercises them about their business.

Failing that: read about the industry. (You'll note that I put this after participation and talking to people, because I think software folks share with me a disposition that privileges reading thousands of pages of books versus taking the terrifying step of talking to someone you don't know, and that is a critical skill you will have to learn for business so might as well get used to it.)

Almost every industry has trade publications ("rags"), blogs by practitioners, and a small cottage industry of how-to books available on your local Amazon.

If, for example, you were very interested in QSRs (fast food restaurants, but you'd learn they often call themselves QSRs within 15 minutes of research on it), you could find a book on QSR management or franchising, read it, and figure out where likely pain points would be.

Having never worked in one, but being well-read, I'm going to guess that hiring is one major pain point, since they tend to have some of the highest employee turnover rates of any industry. Let's roll with that.

Finding people who have managed a QSR is fairly easy: LinkedIn obviously exists, but just walking into one and asking for the manager is even easier. Ask for a business card and permission to chat for 15 minutes, because you're considering going into the industry. (You can mention that you don't have anything to sell, if that makes you feel better. People in business are probably less allergic to being sold to than you are to selling, but hey, whatever gets you to actually do this.) Thank them for their time and leave. You could probably line up 3~5 interviews in an afternoon of scouting.

At the interview, just ask in general terms about their employees, hiring practices, etc. Ask where the money is being spent today. You don't have to ask for any trade secrets, just simple questions like whether they pay for placement of job ads anywhere, how often they do hiring/interviews, what tools they use to support hiring, what the consequence of a mistake in hiring is, yadda yadda.

When you're reviewing your notes, try to see if you can match up known pain points to things which you could reasonably solve with software.

Write Text Before You Write Code

Do you want to earn a living as a programmer? Great. Google is hiring. Do you want to run a software business? Assume that you're going to either get really good at writing or become the employer of someone who is, because writing is about as good as software code for capturing an ephemeral idea in a reproducible artifact, but vastly easier to iterate on.

Before you write a single line of code, start verifying that you can connect to the target audience and their understanding of the problem. If you can't write Why Hiring For QSRs Is Broken then you have absolutely no business trying to solve that problem. So write it.

It will take you a few hours of honest-to-God work and require a bit of tedium like setting up a blog, which are both penny-ante for running a business and thereby help to separate idle daydreaming from serious desire to work on a problem for a few years.

Even if you're the only person who ever sees that piece, you're net ahead on writing it, because the discipline of writing it will clarify your understanding of the problem. That said, writing is a much more effective way to build a platform than not writing, and a platform is a really useful thing to have when doing sales/marketing. (See generally my podcast episode with Nathan Barry.)

By the way: I'd encourage you to collect email addresses, from your very first article. Even if you only get a few dozen of them, that puts you in a much, much better position than having no list when looking for people to do customer development on or getting ready for launch. And actually send them stuff -- even if it is just emailed copies of blog posts you do on the problem domain followed by a launch announcement.

Successful SaaS Starts As More Service Than Software

It often takes weeks or months of work to get software from a blank Git repository to the point where it independently creates enough value to charge for. (Obviously, in many problem domains it can take substantially longer.)

You can get better results faster at lower cost by not rushing straight to a 100% software solution, but instead implementing a service model with a bit of software embedded in it. For example, rather than saying "I'll build a SaaS with 3 payment plans which will manage your QSR's hiring process", try selling "I'll handle hiring for your QSR. You don't care about this, but I'll have a basic CRUD app to track applicants which I'll bolt additional features to as needed."

Why start there?

Services are easier to sell than products -- substantially every business pays for them, where many don't buy SaaS all that frequently
Clients are largely looking to buy outcomes rather than to buy products
You can course-correct on services sales and delivery faster than you can on SaaS, since all you have to do is change your mind rather than going through the whole software lifecycle
The bit of software which you make to support your service offering doesn't have to be ready for prime time for a few weeks/months, so you can afford to skimp on design/UX/scaling/etc in favor of a laser focus on writing code which delivers disproportionate business value

As you get more understanding of the problem domain (and more customers), you can change the ratio of how much software versus how much service you are selling.

Rob Walling has been doing very interesting things with this model recently with Drip, an email marketing app. The first alpha version delivered to a single ~~victim~~ intrepid early adopter was probably not the most featureful email marketing software ever, but it came with an open line to Rob, who is one of the smartest email marketers active in software.

Rob and his team have brought on new customers one at a time for the last couple of months, rather than throwing open the floodgates. This let them punt on architecture, scaling, and complex features for the moment, and ensure that they've got a good understanding on where their customers are, what their challenges are in email marketing, and the like. Many of the challenges aren't really software problems -- it isn't "What button do I push to get this result?" or "Can we A/B test delivery times for these emails?", it is "What should I be emailing people? When? How do I write that?" Being one of the early adopters means that, rather than figuring that sort of stuff out for yourself, you have "Ask Rob" available as an option.

Learning what issues people are having lets Rob target his sales/marketing efforts appropriately, build resources to support customer success (FAQs, onboarding experiences, and the like), and alter the product roadmap where appropriate. This means that rather than spending six months of building a product which might have been unusable for target customers, he's guaranteed to have dozens of existence proofs of companies successfully using it on launch day, because it was basically built exactly with their needs in mind. Then he can start selling that product to similar companies at scale.

This also gets Rob and company a bit of a leeway with regards to dealing with technical problems. Email marketing is an infrastructure product. Infrastructure is no less vulnerable to failure than any other software is, but when it fails it tends to fail... spectacularly. (I'm unaware of Drip having had any problems ever, but I run an infrastructure product, and I have shed literal tears over bugs in it more times than everything else in business combined.) Since software tends to fail more early on, restricting the fallout to a small number of hand-picked people who have lots of reasons to like you (viz, you're giving them lots of consulting at below-market rates) gives you the opportunity to burn-in without burning bridges.

My understanding is that after Drip launches (any day now, I think), Rob and company will continue to have a concierge level of the service available, for people who'd prefer to just have somebody "do email for us" rather than operate the tool themselves. They'll get to have their cake and eat it, too: easily affordable entry points which scale to the moon leavened with higher LTV accounts which can leverage the human-in-the-loop factor.

That's a very, very powerful combination. (It's the topic of a podcast I recently recorded with Erica Douglas. Sadly the editing isn't done yet -- maybe for next time.)

Speaking of not burning bridges

So about a thousand of you are probably wondering "Hey what happened to that A/B testing thing Patrick was doing? I kind of liked those emails, why didn't I get any in the last month?" Answer: I'm still planning on releasing a course on A/B testing and conversion optimization for software companies. (If you'd like to hear a lot more about that, see here.) Unfortunately, my Gantt chart looks like Gaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaantt at the moment due to a few weeks of unanticipated illness. I'm finally easing myself back in the saddle, and those of you who are on the A/B testing list should start getting emails again next week.

Until next time.

Regards,

Patrick McKenzie