6 ms·
This is actually a very insightful question. You get them the same way you plan to get customers after you have built the product. If you do not have a way to
by takinola 6y ago
This is actually a very insightful question. You get them the same way you plan to get customers after you have built the product. If you do not have a way to get customers to test the idea, then you do not have a way to get customers after you build the product. The process of building an MVP includes the process of figuring out distribution.
That said, it depends a lot on what type of product you are building. If you are building a consumer product, then throw some money at digital ads and drive some traffic towards your idea. If people are signing up but not using it, that's feedback right there. They are intrigued enough to sign up but find it lacking in some way to stick around. Fix one thing and see if that changes anything. If it does, great. If not, fix something else. Hint on what to fix, think about user engagement in steps. Always fix the first possible step that you know is not working. When users start crossing that step then go to the next one. Repeat until IPO.
- lovedswain 6y ago> The process of building an MVP includes the process of figuring out distribution. As blindingly obvious as this is, I've never seen it put quite so concisely. Fantastic. I could've cut short so many bullshit discussions this way
- nocommandline 6y ago>> The process of building an MVP includes the process of figuring out distribution. << Maybe I'm being picky here but I disagree a little bit with this. At the start, your MVP might just have been for you i.e. to scratch an itch you have and it is only later that you think about getting other people to use/pay for it. So maybe your above statement will (should??) apply if your MVP was targeted for the public
- hnarn 6y agoIsn't an MVP, by definition, not just for you?
- nocommandline 6y agohmm, good point. I didn't look at it from that POV. When I'm trying to scratch an itch, I try to get something 'rough' and then try to add the bells and whistles later on. Mentally, I always think of that 'rough' bit as 'my own MVP' i.e. what are the minimum features I need to build for this tool to solve my problem. For example I needed a self hosted solution to convert svg images to png. I need a way to specify the image to be converted, code to convert it, and a place to store the output. My first build had a text field where I manually enter the path to the svg file I need to convert, and I hardcoded the output folder. I thought of that as my MVP. When I was sure the code was working and much later on when I had the time, I added a file picker to allow me pick the input file and another file picker for me to specify the output location.
- hnarn 6y agoThe "product" part of MVP refers to something you sell (rather, offer) in a market, and the "minimum viable" part refers to it being barebones but functional enough to be "sellable" and provide value, ie someone that isn't you is willing to go through the stated process to install and use it. So writing a tool that you use yourself without "customers" (used loosely) isn't in my mind an MVP, and neither is a product with no thought given to distribution.
- bob33212 6y agoFor anyone reading the above comment and thinking "Well maybe for your product, but my product is so great once people see it they will buy it" You are setting yourself up for a hell of a sales problem.
- jasondigitized 6y agoNever heard it put it that way either but it is so true. I am going to add key qualifier for any idea I have: “How difficult is it to talk to someone about it?”
- harrisreynolds 6y agoI really like the insight about the feedback you are getting from crickets (no feedback) and the engagement progression. Just fix the next step and start with the first step. Repeat until IPO (Ha!!) Great comment.
- dahart 6y agoVery well said. Will add that from experience, the suggestion of knocking down technical issues is so important it’s mandatory, and it does not stop once you get users, it will be required forever with a successful product. BUT! ... IMO it’s a very slow way to acquire users, and the engagement improvements are incremental at best, unless you are making sweeping changes or hit something viral (unlikely!!) or were missing something truly glaring. I did a lot of testing between adding features, addressing bug fixes, and then random attention-getting marketing like blog posts that happen to mention cats or money or other things people care more about than software. There was no comparison to the amount of attention they got, the tangential posts got many, many more people in the door than the technical posts. The steady feature improvements are what will keep people there, while fluffy emotional blog posts are what will attract a lot of window shoppers. It’s better if the blog posts are relevant to your app and feature announcements, of course, but I’m saying you can get users faster without writing software. It’s just a hard problem and a delicate balance, and don’t get stuck thinking “if I build it they will come.” Some amount of marketing is needed. And don’t get stuck writing ads or blog posts either. Some amount of attention to the software is needed. Do as much of both as you can. It’s very difficult to get users to talk, whether they like your app or not. Most of the time they don’t know enough to be able to articulate what they want or need, even though they can sense it. And the people that talk loudest aren’t often the most important to listen to, especially if they’re not paying for anything. Good Luck!
- marktangotango 6y ago> And don’t get stuck writing ads or blog posts either. I felt this one.
- ergocoder 6y ago> If you do not have a way to get customers to test the idea, then you do not have a way to get customers after you build the product. I need to hear this. Wow, really well thought out sentence. It makes so much sense.