Idea to First Users

If you are like me, you’ve probably bought a few domain names in your day. An idea comes to your head, you think this is the thing I want to work on, you buy the domain, work on it a bit, but then never make the leap to first users. Maybe this is a sign that you weren’t that passionate about solving that particular problem. Or, perhaps you hit a wall and just didn’t know what to do next. I’ve been there. Here’s a case study for how we took Taskable from idea to first users. Hopefully, something here helps you to make the leap from concept to MVP as well.

Idea

The idea came from a problem both me and my co-founder had. Tom was working for a software agency, and I was working with multiple clients as a freelancer. We each had several Slacks, Gmails, Asanas, Jiras, Trellos. All the information we needed to get work done lived across multiple products. It killed productivity, created chaos, and generally made us feel bad about our workdays.

That was the first sign to us that it was something potentially worth pursuing. We both felt the same pain. More importantly, it was a good fit for us because it solved our problem.

Interview and Validation

With that first bit of validation, we set out to see how big of a problem for a large enough number of people. To validate, we talked to people we knew first. Friends, family, former co-workers who we thought fit our target user persona. They gave us a bunch of useful data.

We then set out to interview more users. We found a low response rate when we would post in communities and Slack groups asking for an interview or 15 minutes of someone’s time. We decided then to lead with a survey in these communities. That reduced friction enough to get some responses and a bit more useful data. Most importantly, we asked users for their email address in this survey if they were willing to follow up with us for an interview. Nearly 60% of people did. I think this was for two reasons. First, they had made a small investment already (taking the survey), so it was less of a leap to make a more significant investment. Second, the survey gave them a bit of insight into what we were working on, and it resonated with them.

We began doing interviews using the Mom Test principles. We focused on asking about problems, validating/invalidating some of our hypotheses, and also better understanding who our target audience is.

I don’t think there is a hard and fast number for how many people you should interview before deciding to build something. We talked to about 30-40 people before writing a line of code. What we were looking for was getting to the point where we are hearing the same problems described by the same type of personas/people. Once we had that, we knew we were focusing on the right headache.

Scoping the MVP

Based on the user interviews, we scoped out the truest minimum viable product we could. With the benefit of hindsight, we could have gone ever more minimum, but I digress.

We focused on just two integrations, where we thought the most number of action items come from, and the most straightforward task manager feature we could. We began work on that while continuing to talk to prospective users.

Building our waiting list

While working on the product, we also began to market the product a bit more. First, we posted our product on Betalist, generating about 100 sign-ups. Second, we used Product Hunt's upcoming/paid Ship feature, adding about 300 subscribers to date. Finally, and most importantly, we spent time in other forums again, where our target users hung out and posted useful content that got us a lot of pre-registrations.

Pre-registrations were also a good source of prospective user interviews, as well as additional validation that we were working on the right problem.

Test Release

Once we finished what we thought was the MVP, we started to invite some closer friends/users we had talked to a few times to test. We, of course, were dogfooding it ourselves. It quickly became apparent that some key features were missing based on early feedback.

We then went back to make the necessary changes and kept testing until we were satisfied that we had an MVP, and were ready to do a proper beta release.

Launch

We started inviting our pre-registration list. We found that the conversion rate on was lower than expected, so we went back to posting in communities and asking if people had the problem we were solving. If they did, then we asked them to join our beta and do a video onboard so we could show them around the product, get initial feedback, and iterate on it.

Talking directly to people in communities and forums is where our initial users came from and were way more valuable than spending time building up a launch list.

From this early launch, we gathered our first five or so active users, and have been growing from there.

Key Takeaways

To summarize, what worked best for us was:

• Talk to people about the problem, not the idea because. There might be a different or better idea to solve that problem. This HBR article is great on this subject and also read the Mom Test.
• Hang out where your prospective users hang out. Understand their headaches and get to know them
• Build relationships in these communities by helping first. If you are a good community member, and contributing to helping others out, then asking for help yourself is a whole lot more fruitful. We wrote a blog on being a good community member here.
• Do things that don't scale, to begin with - video onboard, one to one user acquisition, whatever you have to do getting people set up using your product. And ask people you do bring on for intros to other people that might have the headache)

I put together a checklist with some other resources that might help. We also have another blog that goes into more detail on our launch.