‍Mubashar Iqbal, also known as “Mubs,” has been writing software since he was 8 years old. He’s a prolific maker who’s built over 80 side projects. In 2016, he was Product Hunt’s Maker of the Year. He was runner-up in 2015 and 2017 too. Currently, he’s working on Pod Hunt, a way to find the best new podcasts daily, in addition to a full-time role. Decades of launching experience has taught him how to turn ideas into solutions, build those solutions in days not months, and get projects in front of real customers. 

Too many founders get stuck in a cycle of continuously adding features without every launching. This not only drains the founder of resources, it robs customers of ever deriving value from the product. From experience, Mubs knows there’s a better way to build things.

In this interview, we explore how to break that cycle, why getting things out in a week is ideal, avoiding major sunk costs, and what kind of feedback you shouldn’t skip.
‍

Stuart Balcombe: I struggle to come up with a ton of ideas, but you seem to have no problem with that. Where do yours come from? 
‍

Mubashar Iqbal: For me, ideas come one of two ways. One is sometimes I just build other people's ideas. People come to me and say, “Hey, I need some software or a website that solves this problem.” 

And although it seems like I sit in front of a computer 24 hours a day, seven days a week, I do other things as well: I like to watch sports and movies. So while I'm out in the world, I see things that are a pain, and that’s a second way I find my ideas. 

Pod Hunt is a little bit different. It’s an idea that's been around for a couple of years, even though I didn't build it until July. The idea came around because Product Hunt used to have other categories on its site. You used to be able to submit books, video games, and podcasts as well. It’s been a couple of years now, but Product Hunt decided to shut down all those other categories and focus on the actual software side of things. 

I'm a big fan of podcasts and I always wished that category still existed on Product Hunt so we can find new episodes. And it wasn't just me saying that. People I'm friends with online were saying the same thing, but I never felt like it was the right time to build Pod Hunt because of where the industry was, where the software was, and where I was.

...while I’m out in the world, I see things that are a pain, and that’s the second way I find my ideas. 

In July, I was talking to some friends again, and it just felt like it was the right time. So I hopped in and started working on it again. 

You're an engineer by trade, you have some design chops, and you can make pretty much anything you want. So how do you evaluate risk and opportunity costs when you start working on a new project? 

That's changed over the years. Right now, I'm more concerned about time because that's the thing I have more than anything else. What I mean is, I don't have to pay for my time. If I was building something that needed lots of money to host and serve and hire people...I don't have any of that. But time is mine and I can spend it.

One of the reasons I held off building Pod Hunt was I felt like the time investment of building and launching it would be too high. You have to go and curate the content, manage the community, and all those things would take way more time than actually building the software and the site itself. 

Right now I’m more concerned about time because that’s the thing I have more than anything else.

You have to look at the ROI, not just in terms of cash, not just in terms of can I get people to pay for the product, but how long is it going to take to build? How long is it going to take to manage? How long is going to take to get to the point where it can give me what I'm looking for?  Do I have the time to do that? Do I have all the skills I need to accomplish that?

But also, you shouldn't be very happy with what your MVP looks like when you launch it. As Reid Hoffman said, “if you're not embarrassed by the first version of your product, you’ve launched too late.”

...it obviously doesn’t function entirely the way I want it to. But it’s something I can share. 

Often I have ideas at 9 o'clock one night, and I build something I can share with people by the next morning. Now, it obviously doesn't look great, and it obviously doesn't function entirely the way I want it to. But it's something that I can share. To me, that has always been the important thing. 

You can try to tell people what you want to build, and they can try and tell you what they want built. But it's really hard for them to give you accurate feedback until you can put something in their hands and say, “Look, this is what I'm thinking. This is how it works.” 

I see a lot of people building an “MVP,” but it takes them three months. And what they've actually done is build a crappy first product. Whereas when you think about MVPs, you just gave the example of having an idea at 9pm and shipping something the next morning. 

This has been said by many people much smarter than me, but the idea of the MVP is not that you do anything poorly, it’s that you do a lot less. It’s minimum viable, minimum loveable, or whatever you want to call it. But it has to do one thing really well, because that’s the thing that's supposed to hook in users, make them come back, and wait for other features. 

...the idea of the MVP is not that you do anything poorly, it’s that you do a lot less. 

I try and focus on the core of the thing I want to build. And then I ship that. I mean, I've shipped stuff in the past where you can't change your password or update your profile once you’ve signed up. You just get through what you need to get through for users to be able to use the core feature of the application. And that core feature should do the thing users will come back for every day, every week, or every month. You should do that really well.  

But then don't worry about all the other stuff. They just signed up five minutes ago, why should they need to change their password? Build that a week later. Think about what is really important for what you want to build, and make sure that’s what you focus on. Because that's what you want feedback on. 

99% of the time you’ll get it wrong...and that’s fine because the whole point is to get feedback 

If you get that bit right, you have something people sign up for and use. Or if you've got it wrong, that's also absolutely fine because the whole point of the MVP is to get it into people’s hands and get feedback as to what's wrong with it. 99% of the time you'll get it wrong the first time. And that's fine because the whole point is to get feedback so you can change your path and figure out, “what is the thing users actually want?”

Two interesting things you mentioned there. One is value. When someone gets into the product, how quickly can they understand how the product makes their life better or adds value for them? 

And the other thing is, the purpose of the MVP is to complete the loop. To go all the way from, “I think this is going to work” to showing it to someone and finding out if it's actually valuable. So I'm curious, with each new thing you ship, what does the feedback cycle look like?

It depends on the application. If it's more of a enterprise-y thing, your feedback loops are different than if it's a direct to consumer kind of thing, like Pod Hunt. 

With Pod Hunt, I had a core set of people who were asking me about it for a long time prior to me building and launching it. I started with them. A week after I started working on Pod Hunt, I did a private launch. I shared it with five or six people I knew wanted the application. They knew what Pod Hunt is because they told me they wanted it. Beyond that, I didn't tell them too much. I wanted them to have the same experience that anybody would walking through it.

I talked with three or four people and they told me what was easy, what was obvious, what was hard...

That was the first feedback loop. It was an “okay, here’s the URL, tell me what you think” kind of thing. And then I had conversations with them asking, “What was it like? What was it like to submit your first episode?”  to understand pain points. I talked with three or four people, and they told me what was easy, what was obvious, what was hard, and what was kind of unclear. And I went through and I tweaked. 

As I got closer to the soft launch, I started a mailing list. I think I had 100 people on it. It was basically the same thing, but a wider scale.

The main reason I do these two steps is, with the core people I know I'm going to value their feedback highly because of who they are and what their history is. When you go wider, you have to adjust your expectations around the feedback you get. You don't know everybody in that list, you don't know what their background is, or what their expertise is. Although I still value and analyze their feedback, I'm not going to jump on the thing they tell me needs to be fixed.

Be careful about whose opinion and feedback you take action on. 

That’s where it gets a little tricky for new indie hackers and makers. Just because somebody tells you something isn't clear and obvious...well, it may not be. But it may be fine for 99% of people out there. So be careful about whose opinion and feedback you take action on. If you don't know who they are, you might want to wait and gather more signals from other people, to see if everybody else is having the same issues.

A lot of times, people skip that first step of talking to five, six core people. They get 100 signups and say to all those signups “okay, it’s live, I need feedback.” But when they get feedback, they get signals from everywhere—signals that are not necessarily aligned. The first step of getting feedback from that core group is highly, highly necessarily. 

I mean, if you’ve got an enterprise product, yeah, it's good to get feedback from everybody in the industry. But at the end of that, you want feedback from the people who are going to use your product—going to pay for your product. If you know who that is, and you're 99% sure a person will sign up and pay you for your product, then you're going to value their feedback higher. 

Other people may be experts in user interfaces or other fields, and that means you don't ignore their feedback, but you have to try and figure out what angle are they are putting feedback in. 

Aesthetics don’t always signal whether what you’re building is helpful or not. 

Because although it might be nice to fix the UI, if the customer is saying “I understand it and I know how to use it,” then it's less important to focus on. I've known plenty of websites that are really ugly, but do really well out there. So aesthetics don’t always signal whether what you're building is helpful or not.

There’s definitely a difference between being aesthetically pleasing and providing a lot of utility. 

Yeah. 

You're getting a product in people's hands really quickly, and then you're getting feedback from people who are actually using the thing. How much feedback do you get pre-launching an MVP and how much do you get post launch? 

People fall in two camps. 

One camp is you shouldn't write anything until you've got feedback from people who have told you exactly what they want. I don't typically fall in that camp, because I'm solving problems I have myself. Based on my experiences, I know what I want the solution to be. I don't need to interview 20 people to know what the pain is.

So I don't worry too much about gathering feedback pre-MVP because I'm just not investing a lot of time. I’m investing a lot of energy, but I’m not investing a lot of time or spending a lot of money. I'm not hiring people. For me, being able to launch something in a week and get feedback on it is much better than talking to 20 people and then building something for three months. 

If you find problems early, they’re much easier to fix. 

If you find problems early, they're much easier to fix. If you know you're on the wrong path and fix that in a week, you're going to get somewhere much faster than if you talked to 20 people for three months. Then you're already so far down the road that the angle you're off is much worse. And to get back to where you need to go is going to take you much longer. 

A big thing people get stuck on is that idea of sunk costs. At what point do you quit?  Where’s the line where you say, “okay, we tried this thing and it's no longer worth the cost?” 

I think it's always better to ship something than not to ship anything. If you can ship it in a short amount of time, that's even better. 

People say “I'm going to build this MVP”, then they talk to a bunch of people, build a thing, and never launch it. They say,  “Well, I need to add one other feature. I talked to somebody and they said, ‘you need to do this one other thing.’” People get stuck in that cycle.  

At the end of the day, if we don’t ship anything, then it’s never going to provide any value whatsoever. 

My solution is always ship off and ship early. That way, you don't get stuck having a long roadmap of things you want to do without actually shipping stuff. At the end of the day, if we don't ship anything, then it's never going to provide any value whatsoever. 

In terms of when you kill it...if I built something in a week and I ship and people are like, “well, it's cool, but I'm not going to use it.” I've only spent a week on it. It's not a big deal. But if you’ve been working for three months, six months, a year...you’ve spent so much time on it that you're really afraid to launch it.

For me, shipping early solves two issues. One is I can launch fast and get lots of feedback. Also, I'm not really attached to that particular approach to solving the problem. So if I need to pivot and do something else, it's still young and fresh. It’s easier to kill things then, than when they're old and mature.

I've had this conversation with people still on the build phase, and they see shipping as the goal. Whereas shipping is actually a means to an end: learning. You ship to get feedback to learn what to do next.

You have to think about you want to accomplish and then what’s the shortest way to accomplish that. 

If your goal is to get paying customers, that's awesome. You should think about what's the shortest way I can get people to give me a credit card. If it’s I just want to launch something so I can get more followers on Twitter, that’s fine too. 99% of people don't build something, launch it, and that's the thing that they work on for the next 20 years. 

The idea of trying to launch something and get it right the first time is the exception, not the rule. 

It’s like, “Well, I tried this thing. It didn't work. I'm going to try something else.” The idea of trying to launch something and get it right the first time is the exception, not the rule.

Nobody is an overnight success. Not even athletes and movie stars. You see them at the top of their game now, but there's a ton of work you didn't see, and people sort of gloss over that. 

Over the last two or three years, the maker movement has really taken off. At what point does a product go from fun project to viable thing that adds value?

I think it all goes back to why you're doing the thing. 

A lot of what I build is on nights, weekends, and evenings. I have a full time job. I'm quite happy doing my full time job. So I'm not I'm not worried about building stuff I have to charge users for immediately, scaling up to $20,000 MMR, and quitting my job so I can finally be happy. I'm quite happy right now. 

It’s fine to make stuff for the sake of it. 

So, it depends on where you are. You also have to be honest with people when you launch. Often when I launch stuff, I tell people I spent ten hours working on it. It's not something a VC-funded team has been working on for 10 months. When people understand it's something that was only built in 10 hours, their expectations change a little bit. 

Be clear with people. Just say, “look, this is something I used to hone my craft.” As long as you're open and honest with that side of things, it's fine to make stuff for the sake of it.

Certainly the maker movement has a lot of people doing things they would not have done otherwise, which is awesome. What would be the one piece of advice you would give to somebody who's getting started, or who has tried and failed to get something started?

Start small. A lot of times you’re working on your own. You have to be realistic about what you can accomplish in the time you have. 

Don’t think you’re going to launch the next Facebook working nights and weekends.

Most people aren’t working on their ideas full time. They're doing it nights and weekends because they're at school or they're working a job. Don’t think you’re going to launch the next Facebook working nights and weekends. 

And the other thing is, don't go chasing the hot market. Do the things that interest you. If you have a pain of your own, solve that first. That will give you the ability to build and launch something. 

Like with anything, the first time you do it, it's hard. It's hard to ride a bike for the first time. You try to get on and stay balanced. But after a while, it's second nature. You just hop on and you ride. 

It’s the same with launching and building. The first time you do it, you’re afraid of feedback. You're worried about what people will think. But the second, third, or fourth time you launch you’re like, “Well, I don't really care what people think. I built this thing.” You want to get good quality feedback from customers, and you want them to be able to use the product. But you build a thick skin pretty fast.

Launching isn’t the end. Launching is how you get feedback.

I mean, look, it doesn't matter what you build. Somebody, somewhere is not going to like it. Dropbox launched on Hacker News and people hated on it. It doesn't matter what you build, somebody is going to say, “oh, I could have built this in three hours.” But they were the ones who sat on their hands and didn't do anything. 

Launching isn’t the end. Launching is how you get feedback, and it’s just the start of the next loop in the next cycle. So don't worry about launching. Launching happens every day, every week, every month. So just take that first step, build something small, launch it, and then keep on it. 

This interview has been edited and condensed for clarity. 

‍