I’ve built (and shipped!) various projects over the years. These have ranged from online courses to SaaS apps and podcasts. Some of these projects have failed. Others did OK. And With Jack—the business I’m building now—made money before it even launched.

The failed projects taught me a lot. Each mistake I made culminated in a successful launch for the project that’s mattered most—With Jack. (Well, successful by my standards given I had no money for marketing.)

But let’s not get into With Jack just yet. First I want to explore why it’s important to talk about your ideas before you write a line of code.

The Project Where I Kept My Cards Close To My Chest

One of the first projects I wanted to monetise was Lodger, a SaaS app for landlords. It was a simple tool for landlords to manage tenants and payments. Lodger is one of my many ideas that flopped.

Reasons Lodger Failed

It’s easy to see why Lodger failed. There’s nothing I did right at any step in this project.

  • I targeted an audience I had no interest in
  • I didn’t do customer development or research what features users would want
  • I spent 9 months building a fully functioning SaaS app I hadn’t validated
  • I had no existing audience to market to

I built something I thought landlords would value, instead of researching what they actually need.

Not having an audience to market to was also an issue, but that’s secondary to not recruiting feedback prior to and during the development stage. After all, it doesn’t matter how big your audience is—if what you’re building only solves an imaginary problem, nobody’s going to give you money for it.

Since then I’ve taken online courses, listened to podcasts and read blog posts on the subject of product creation. They’ve all taught me the same thing. To have any chance at building a successful business, you must uncover a pain or desire a group of people have and work with them to develop a solution to it.

That’s the opposite of what I did with Lodger. I had an idea, locked myself away in my office and built it.

This wasn’t a quick mistake I got out of the way after a few evenings and weekends spent coding. This was the project that taught me how to code, so it wasn’t built overnight. 9 months of learning Ruby and a lot of hours on Stack Overflow. Women grow human beings in that time!

With Lodger being my first app I wanted it to be perfect. As I was progressing with learning Ruby, I’d go back and refactor my early code. A completely pointless act given I had 0 users. Hey, at least I felt like I was being productive.

Not only did I invest a lot of time building it, I wanted it to look slicker than the competition. This was going to be the edge against my competitors (or so I thought), many of which were desktop apps with clip-art inspired icons. So, I hired a designer and Lodger looked great.

I received compliments like this:

And this:

On the surface these compliments felt like validation and made me feel good, but there was a big problem. These words weren’t coming from the people who would pay for the app. There were no glowing testimonials from landlords who’d finally found the solution to their burning problem, because Lodger wasn’t solving a burning problem.

Speaking to my target market and validating there was a need for Lodger—instead of diving into Sublime Text and Photoshop—would have saved me 9 months of work. (Another lesson I’d learn is that landlords don’t care if software looks nice or has squeaky clean code.)

What design can’t do is solve a fundamental problem in your business model — Reid Hoffman

Where I failed was by not talking to landlords and uncovering a pressing pain they all had. I didn’t design a solution they’d pay for. I just built something I thought they would like, which is stupid because I’m not a landlord.

This all sounds obvious, but I’m not alone in doing this. A lot of people take this approach when building stuff.

“I have an idea. It’s going to be brilliant and will make money. Instead of validating there’s any need for it, I’ll dive into my code editor and start building it.” Does this thought process sound familiar?

In a monetory sense Lodger was a failure. My SaaS app generated £0 in revenue and I’d spent thousands of pounds in design fees. The only purpose it served was a lesson in how not to build a business (and also how to code).

Learning From Past Mistakes

Now onto the story of With Jack…

This looks very different to my experience building Lodger. I intentionally did things differently.

With Jack is the first project I’ve made money from prior to launching. It’s the first project I’ve embraced imperfections with and built in a public way, with the input of my customers. Maybe that’s why it made money prior to launch.

I started small. I tested the water by signing up as an affiliate for an insurance broker. Whilst I couldn’t build my own tech and customer journey, it meant I could launch something quickly and gauge interest. That interest was 55 sign-ups, £14,000 Gross Premium Written and positive feedback towards the brand.

That was my first step in validating With Jack.

The next step was to get authorised and partner with an insurer so I could build my own tech (insurance is a regulated industry). Whilst going through that process, I put up a landing page with a few paragraphs about my vision for With Jack. I followed this with a call to action to be notified of launch.

120+ people signed up. It was a small list, but they were engaged. I shared what I was building with this list, sourced feedback from them and invited them to beta test. Several of these beta testers became my first customers.

This process of sourcing feedback before writing code is still at the core of With Jack, 1.5 years later.

Unlike the SaaS app, With Jack is growing every month. It’s consistently made money from day one. Out of all of the ideas I’ve executed on, this is the one that functions like a business.

Don't Make The Same Mistake I Did

Maybe I’ve skirted around why I’m writing about this, but I wanted to open by sharing my different experiences of building Lodger and With Jack.

The point of this post is to prevent people from making the same mistake I did. Coming up with an idea, convinced it’ll work without validating it, then spending months building out a complete vision.

More often than not, the idea doesn’t take off. It’s a lot of work and disappointment that could have been avoided had there been some initial validation.

I’ve seen a lot of people skip idea validation. Recent experiences of seeing this happen have been the catalyst for this blog post.

Last month I gave my talk—Idea to Execution and Beyond—at Frontend NE in Newcastle. Afterwards somebody approached me with a question. Our conversation went like this:

Guy: “How much would insurance for my startup cost?”

Me: “It depends. What does your startup do?”

Guy: “I can’t tell you. We haven’t launched yet and we don’t want anybody stealing our idea”.

I had just given a talk about the importance of idea validation. He said he’d enjoyed most of my talk, but disagreed with that part. That’s OK, I don’t expect everyone to agree with me. Yet I couldn’t help but feel he’s shooting himself in the foot before he’s even started. And I told him that.

“How do you know this idea is worth your time and money if you aren’t speaking to people and validating it?”

“How do you know you’re building something people want if you aren’t talking to potential customers?”

Those were a couple of the questions I asked him. I wish somebody had asked me this when I was building Lodger. I wouldn’t have had an answer, which would hopefully have served as a wake-up call.

Not long after my conversation at Frontend NE, I watched a friend of mine start a business. She’s following my doomed footsteps with Lodger. She’s avoided doing any customer development and is building her app in secrecy, but she has printed business cards and t-shirts with her business logo on them.

I love how excited she is about this, but it’s quite simple—before you invest resources into building something you must validate there’s a need for it. Otherwise you’ll potentially waste time and money only to realise that nobody wants it.

I’ve been there. I’ve done that. It sucks.

Why It's Important To Talk About Your Ideas

Despite idea validation being an important step of building something, a lot of us skip it. Here’s why you shouldn’t:

  • It helps you avoid spending time and money building pixel perfect products. You don’t want to wait until launch to discover nobody wants what you’ve built (I should know. I did this)
  • Whether it’s from pre-orders or beta testers, you can generate revenue earlier. If people aren’t prepared to give you money then you’ll know the idea doesn’t have legs and you should pivot
  • You’ll build a product people want, instead of building what you think people want
  • Our ideas usually aren’t as good as we think they are. It’s better to get real feedback from people who aren’t emotionally invested in it

Building stuff is hard. Be it a side project or business, burying your head in code and emerging months down the line with a finished product is taking an expensive stab in the dark. You’re making the process harder for yourself.

The top reason that startups fail is that there’s no market need. I’m guessing a lot of those failures—Lodger included—could have been dodged if we talked about our ideas earlier. The odds of success could have been improved if we were speaking with potential customers, validating there’s a market need and generating revenue.

Okay, I’ve oversimplified the reason startups fail. But talking to people about what you’re building is a great place to start!

Why Don't People Talk About Their Ideas?

I’m sure everyone has different reasons for not sharing their ideas. The guy that spoke to me at Frontend NE was worried people would steal his. My friend with her new business is excited to get stuck in.

When it came to building Lodger, I had three reasons for diving into the build instead of talking about it.

  1. I was convinced my idea was good
  2. I was embarrassed by the thought of sharing a product that was less than perfect
  3. I didn’t have any connections in the buy-to-let scene. Rounding up a herd of landlords for customer development seemed intimidating

I’m a big fan of Reid Hoffman’s podcast, Masters of Scale. One of the recent episodes saw Reid Hoffman interview Payal Kadakia about her startup, Classtivity. Classtivity didn’t have a successful launch and would later pivot to ClassPass.

I’ll paste part of the transcript below, but you should really download and listen to all of the episodes.

Hoffman: Frequent listeners of this show may recall my theory that you never want to release a fully realized vision in the software world — because it’s most likely flawed. In fact, if you’re not embarrassed by your first release, you’ve released it too late. Many successful entrepreneurs have discovered this counterintuitive theory the hard way. They perfect their product, as Payal did, and then on launch day, well…I’ll let her tell the rest.

Kadakia: And so, June of 2012, we launched Classtivity, finally open to the public. We had thousands of classes listed, a beautiful design. And I would say we did about ten reservations a month. It was terrible.

I can relate to Kadakia with my SaaS experience. We both focused on honing a beautiful design. We both launched with a feature-rich product. We both failed.

Later in the podcast, Kadakia talks about the pivot to ClassPass.

Kadakia: We were sitting behind the screen here, right? For a year-and-a-half, we were building API integrations. We were building scrapers to get the schedule data. We weren’t talking to our partners or our customers. And that was also something that we started doing.

Hoffman: Payal started interviewing fitness studio owners. She asked one after the next, how do you get people to sign up for a class? And immediately she spotted a pattern of responses.

Classtivity pivoted to ClassPass when they finally got away from their screens and started speaking to customers. ClassPass was last valued at $400 million.

But what if somebody steals your idea? This is the fear the guy I spoke to at Frontend NE has.

Don’t let fear of idea theft stop you from speaking to potential customers. My logic is that people can steal your idea post-launch. You may as well start talking about it now. You’ll get a head start, build a product people actually want and start to acquire customers.

In Closing

I did a lot of things right when building With Jack. It wasn’t the perfect formula, but it was better than my attempt at building Lodger.

I started small. I made a bit of money by testing the water as an affiliate. I spoke to my target audience. I built an email list and involved them in the build process. I launched with manual processes. The business has been growing every month, unlike Lodger that was dead in the water.

All idea validation should involve speaking to potential customers, but here are some other avenues to test if your idea has legs.

Publish a blog post

A great example of validating an idea with a blog post is Ghost, the blogging platform. John wrote about his concept for Ghost in 2012. It generated enough of a response to justify exploring a prototype.

Monitor interest with a tweet

Today I saw my friend, Ben, publish a Twitter poll. He was using the answers to “validate a tiny idea for a tiny app”.

Design a landing page

Landing pages are typically what spring to mind when talking about idea validation. I used this method to build a small email list and get beta testers, several of whom became my first customers.

Build a micro version of your idea

Pieter wrote about surpassing $50K a month in revenue, but Nomad list originally began as a spreadsheet. It was a tiny version of what’s become the biggest crowdsourced database of cities in the world.

Please don’t waste resources building something before validating it. I don’t care how good you think your idea is or how afraid you are that someone will steal it. You need to confirm it’s something people want. How you validate it is up to you. Don’t wait until your product is perfect. Involve your audience as early as possible. Never assume you have a million-pound idea.