Hacker News new | comments | ask | show | jobs | submit login

I agree with this except switch the order. First, start selling. Then start building.

It is so easy to waste so much time building something nobody wants, and you won't know until it's too late if you try to sell it afterward.

Selling first will inform your decisions on what to build.




Can I ask an honest question respectfully? I don’t have a company or a startup. But I’ve always wanted to start one. So I’m always curious when I see a response like yours.

How do you sell first? There isn’t a product to show. How do you find Customers? Is it the philosophy that the customer doesn’t know better and you have to tell them what they need, all the while understanding what your capabilities are. Like undersell and overdeliver? I’m genuinely curious how you go about selling first.


I'm creating an open source todo list + calendar webapp (https://getartemis.app, source at https://github.com/satvikpendem/artemis) made by just me, and I can tell you how I approached the problem.

The video you see on the front page does not exist in code, it is simply a prototype designed with Figma (https://figma.com) and animated with Principle (https://principleformac.com). I created the landing page and video, added a Mailchimp form, and I posted on Twitter, Reddit, and here on Hacker News, the communities in which it made sense. For me, it's a productivity / task management tool, so I would post on reddit.com/r/getdisciplined or reddit.com/r/productivity.

It's all about creating a minimum viable product, as you might well be aware, but what you may not know is that an MVP need not have code. Indeed, it could be a video as I did, and I think for software, a video works best as people can actually see what it looks and feels like, without you necessarily creating the product architecture (full frontend and backend plus devops etc). Now I have over 150 subscribers in only a month due to rapid creation of this type of MVP, and based on this feedback, I changed my designs, and only now I am beginning to really create the heart of the product.

Using non-code MVPs is the best way in my opinion to sell quickly before building.


Really good advice about non-code MVP. It reminded me of this seminal post: https://blog.bufferapp.com/idea-to-paying-customers-in-7-wee.... The heart of the idea is that an MVP isn't really a Product; it's something to validate against.

How specificlaly did you go about promoting your landing page? Just 'hey check this out posts', or did you focus on comments/answers to questions? And how much time do you have invested in this so far?

If you get some free time, you might want to also post this on indiehackers.com. Could help a lot of people out there.


I'm a somewhat frequent contributor on IndieHackers actually. To promote the page, I basically posted it everywhere I could (without getting banned) and started asking my friends to critique the site. When applicable, I would also answer questions on fora as I am now. In terms of time, I'm not really sure, it's an on and off commitment as I also have a job.

Anything other questions or anything you're working on as well?


I'd like to know more about the "not getting banned" part. Reddit communities are notorious for not wanting to be sold to. what's your approach? how do you articulate the post? maybe you could share a link to an actual post as an example?

thanks for the insight!


Many subreddits have rules on when you can do self promotion, such as a separate thread or a specific day for posting. That's when I do it. [See this post for example](https://old.reddit.com/r/getdisciplined/comments/a3oz48/meth...). As well, you can see in that post that I don't directly promote my app but instead I ask questions regarding the process by which people schedule their day.

Provide value without expecting value in return. If you look on [/r/entrepreneur](www.reddit.com/r/entrepreneur), you can see some posts where people use their blog posts as a reddit post, which provides value for those who don't read their specific blog. Then, you can link back to your own blog at the end of the post. In doing so, you provide value before you promote yourself, and so any products or services you then promote will be associated with quality to your readerbase.


Thanks for posting this. I am at a very similar place with startups where I am attempting to stop just paying lip service to lean startup ideas. I'm going to look into the tools you mentioned.

BTW, the last startup I worked at we were building a really cool "timeline" interface using react. I see you are using Vue but we still might have some interesting discussions. I found some really fun/difficult product and technical problems with developing that type of interface.


I joined a startup a few years ago and I did see this in action. The founder was such a believer in his vision he would go to whatever door he managed to get through and was selling them his mock-ups. He is not technical but he has go a good eye to UI and also had great idea. When I joined him (I'm technical with no eye to UI and not very good at human relations) he already had customers aligned (no product yet) and also won 4 desks in local incubator (big brand's incubator...) I found this astonishing and to date I am under impression trying to learn from him where I lack.


I've worked at a couple startups where we would speak MVP with our lips but our actions did not follow our words. None of them were ultimately successful.


It only works for some kind of products and some kind of buyers, obviously. You can't sell someone a can of tomatoes based on a demo.

But, if the value you can provide is immediately obvious to the customer, rather than an incremental improvement on their existing situation, then you can get them to express interest before you have a finished product to provide them with.


exactly. most products don't exist in a vacuum.

"sell first" works if you have such a unique solution/value such that for the customer it's a "either this demo or nothing" situation. that's exceedingly rare.

most of the time there's a healthy large existing set of solutions serving the same market so it's difficult to justify using something new.

even if you have some unique selling points they may not be strong enough or they may be canceled out by the lack of other features and maturity of your new product vs existing established ones.

for example let's say your product is a customer support software. how do you "sell first" when there are so many mature existing companies solving the same problem?

how long will it take you to reach the same capabilities, support, security, reliability of existing solutions?

are your differentiating points really strong enough that someone's going to say "screw Zendesk I'm going to try this random new one-man product because they have this feature X"?


You pretend to have a product, and try to sell it -- market it, advertise, etc. If you get people trying to buy it / use it, you know you're going in the right direction.

So yes, basically you bullshit everyone with some mockups and a pretty website, to determine if anyone would even be interested in the thing you want to build.


Selling isn't just the monetary transaction. It's research, outreach, CRM, pipeline, working on the descriptions, marketing text, blog posts.

All of these things can be done while making the product and will inform the production process.

But.. I need to take my own advice. Too easy to retreat to building. Or passively reading and thinking that is market research.

That's my safety zone, hidden away from scrutiny and judgement.


You may be able to make a sale and then build it and still keep the sale, but if you think that this is too risky with respect to reputation or having a customer depend on what you’re selling be ready, it’s still worth going through the sales cycle until you’ve found something you can sell.

It won’t magically get easy to sell the product when it’s ready, so it’s possible eliminate bad ideas which are hard for you to sell early, even if you let the sale fall through towards the end.


Once you find a real pain points, people will beg you to buy/use your product, even if all you have is a crappy version rushed out.

To be clear, some startups require to have a super polished version to be successful. But even then, there's often a way to have customers pilot an early version or cheaply test the market.


> "Is it the philosophy that the customer doesn’t know better and you have to tell them what they need"

Yes and no. One of the only people to have ever done that successfully that I know of was Steve Jobs, and that's what made him a one-of-a-kind genius billionaire. Believing you can do the same will cause your wheels to spin endlessly without going anywhere. It's pure hubris.

On the flip side, it certainly can help to have some insight, intuition, or flash of inspiration for a product or service. When you have the idea, then you have a hypothesis. Don't treat a hypothesis like a fact! This is where people make the biggest mistake.

Your goal is then to find evidence related to the idea. The evidence will tell you whether the hypothesis has potential or whether it's completely bogus.

Two big places you can find evidence: competitors and customers.

If there are already competitors in your field, that's a big piece of evidence that your idea has merit. If there are no competitors, that doesn't necessarily mean that you don't have a chance, but definitely take it as a sign that there's probably a good reason there's nobody else doing it.

If you can find customers, it's nearly proof that you're onto something. Just be cautious because sometimes people will say they like your idea and genuinely believe to themselves that they would pay for it but then actually not in reality.

> "How do you sell first?"

The biggest way that I know of is basically just communicating with people. Find a way to get someone on the phone or get them to open your email or even see them in person, and then pitch your idea to them.

If you're selling a service then it isn't too difficult because you can just verbalize the service and gauge their response. When they like your idea it will be very obvious because they will get excited. If they're not excited then you're talking to the wrong market or your idea/hypothesis needs to be reworked.

If you're selling a product it's essentially the same, but you may need some simple mockups/pictures just to help communicate the idea. You really do not need a full fledged working product or even an "MVP" for this.

The concept of an "MVP" is a huge source of confusion because it assumes you know what "minimally viable" even means. How can you build an MVP when you have no idea what to consider "minimally viable?" The MV part of MVP completely depends on your customer. No customer, no MVP. (This may not quite apply if you're building something specifically to fulfill a need that you have.)

Hope this helps!

By the way, please take this with a grain of salt. This is my personal experience from a couple of failed startups and zero successful startups. I'm clearly not an expert.


Go to a store nearby.

Buy something.

Put it on Ebay.

Sell it.

Tinker with the product description and price and measure results.

Rinse and repeat.

You will learn more than many wanna bes.


The advice makes sense, but isnt it a bit of chicken-and-egg? How do you sell something you haven't built? (or is it really .. build a little, or enough to illustrate; then 'sell' to validate and seek market fit; and then finally truly build?)


It's essentially the build a little/sell/build a lot cycle you mentioned, but you want to minimize the first step as much as possible. As tech folks, it's easy for us to overestimate the importance of technology to our end customers. They're not buying code, they're buying a solution that will make their life easier/better.

"Sales" is a long term process, but the first meeting usually starts with understanding the customer's problem. If you build something before that (and demo it at the beginning of the meeting), you can bias the process with your assumptions. Instead, if you try to get inside the mind of your customer, you can get closer to the correct solution.

For a lot of those first sales meetings, you don't necessarily need technology to demo. Instead of showing/telling your customer, you're starting by listening. Then, you can build a small demo of something interesting before the next meeting (often, this is more to keep the conversation going and explore new ideas than to immediately solve the customer's entire problem).

I agree with the other comments mentioning an initial (days/weeks long) MVP build cycle. However, over the past few years, I've found it helpful to adopt this mindset: "my idea for the best possible product is at least slightly wrong, and the more code I write the harder it is to fix". There's a psychological concept of functional fixedness, where you view an object only as its traditional use. I think a similar concept exists in technology. Particularly as a founders-only company, the technology you build has some inertia, and impacts your mental models of the problem you are trying to solve. The more code you write, the higher the "cost" of changing (both in your mental models, and the technology itself).

All this really means is you're right about the build a little/sell/build more cycle - but what you build is less important than what the customer says. The first build is often just a means to start an interesting conversation about the customer's true problem, and you might need less technology for that than you initially assume.


MVP or fake page with credit card info or email information that says you're sold out.

If you can convert random users to paying customers then you're on to something. Otherwise your project is most likely going to flounder. Some people may think it's dishonest but without verifying you're going to spend weeks to months working on something that will never be used.


That might work for physical product, but when you claim your software download is sold out, people tend to give you funny looks.

You can definitely put up a product page where users can enter an email address and start building up a mailing list, but obviously mailing list recipients are not guaranteed to pay you money.


The purpose is to get some kind of signal that you're on the right track. Many times I've seen would be founders just go off of a hunch without a buy in from any possible users of any degree. Even their voluntary email sign up is far more of a sign than what the founders know users want.


Or, even better, build a minimal MVP (1-2 weeks dev time) and use this to attract attention and get feedback.


Not every product can get to MVP in two weeks. If you were building a new kind of airplane, it better take more than two weeks. Our software is quite complex and there isn't going to be an MVP in two weeks, lol!

I do think that building a UI prototype that you can click through is a good first step for complex software.


Absolutely, good point.


Ok, but such quick MVP should have some secret sauce - ideally introduce a complexity with a special dependency, otherwise nothing stops a potential lead to take the idea and implement it with someone else.


In the brief period I was running my own company (with a friend, not solo) the product we sold was largely unbuilt, or were selling features we hadn't yet built.

We were the 'technical creatives' and with an idea and a cost, and went out to find people who we could sell it to to enable us to build it and make it better for all the users. As our product was video crossover - this was a little easier as people are used to paying for a video before you've made it, but video was actually a very small part of what we were offering - and sometimes not at all.

But selling things that have been bukt yet shouldn't be impossible, or even hard - as long as you can show a track record of delivery.


for me, at least, it feels like "selling first" means getting product feedback first.

so, setup a landing page with a "send us our email so we can tell you when our tool is read!" form and see if it attracts people.


Depends the kind of product you are building but you don't necessary even need market validation, you only need it if your product is exotic enough that there's nothing close to it.


realistically this only works for unique products there are so many alternatives for EVERYTHING that most people will just move on to something that is ready today instead.


I hate this advice so much. I've been burned as a developer so many times by people selling products that don't exist and then expecting the dev team to just make them happen by some arbitrary deadline. It's a garbage experience for pretty much everyone.

But I'm not going to argue against it right now. It's too deeply ingrained as startup wisdom to fight it. So instead, I'll offer this compromise: if you're going to sell first and build later, at least build some basic things up front that you are guaranteed to need and that most startups don't build until long after they should.

1. You already know what your programming language strengths and weaknesses are. You can make decisions for your first product iteration already. Are you going to start with a web app? You probably already know what language you want to use. Choose your frameworks, and choose frameworks that address the OWASP top 10 at least. If you are storing data, you have a responsibility--even as a sole founder--to take security seriously. You can think about that and make decisions while you are selling, so do it. You can also make a decision to not store data or store as little as possible and choose frameworks and plugins that help you do that.

2. Along the same lines, if software is involved you have to have a way to deploy it. Set up your DevOps pipeline. If you listened to the first point, you've got somewhere to start. Take your app framework and your plugins and set up a pipeline for deploying/rolling back/backing up/restoring the very basic "hello world" version of the app + plugins. Use a service if you aren't already into DevOps personally--most of these things have a free tier. If you are looking for a native app of some kind, navigate the platform's app store at least once so you know what you're in for. Or if it's cross-platform how you will get the latest version to your users. None of these decisions matter right now in terms of what decisions you make, just that you do make them and learn how to use things.

If you are going to commit to selling first and then building, you are already shortchanging the amount of time you have to deliver after the product is sold. If you haven't made any of these decisions, the time between when you make your first sale and when you deliver it is going to be absolute shit. Give yourself the ability to use that time 100% focused on building the product confidently because you already know how you're going to build it and how you're going to deliver it.


I'm a professional software engineer too and know what you mean. It sounds like you're thinking like an engineer. That's great for building things, not selling them.

You can have the best infrastructure, best pipelines, devops, security, frameworks, styleguides, libraries, etc. etc. Sadly none of that means you're building something anybody wants.

You can spend years building something undoubtedly technically amazing. Yet if you didn't make sure there was a market first you face the very real prospect that people will go "That's nice, why do I care?"

Your advice is great for a personal project that you don't intend to directly make money with. Still would be excellent on a resumé however.


I agree with you. Thinking about setting up a DevOps pipeline before you have anything to send through it (and even before knowing if you'll ever have anything to send through it) has a name in lean management: it's called waste™️. There's so many other things to do instead that could bring immediate value


> You already know what your programming language strengths and weaknesses are. You can make decisions for your first product iteration already. Are you going to start with a web app? You probably already know what language you want to use.

I think if you are thinking about programming language strength and weaknesses when building a product you need to rethink your approach.

Building a great product has very little to do with technology choice, especially at the beginning. Building a great product is about solving a real pain for your target customer and solving it in a novel and delightful way.


I totally agree.

I've found Steve Blanks book "The Startup Owner's Manual: The Step-by-Step Guide for Building a Great Company" very insightful.


This is completely rational and works well for some people, but speaking from experience, there is another side to this coin.

If you are the sort of person who enjoys the making side of things, and aren't naturally gifted at selling, this can be a trap. I've seen so many solo founders try to validate a product by selling before building, only to get talked into different features and use cases until they're stuck building some bloated mess of a service. Not super enjoyable.

That said, if selling is your strong suit and you have the discipline to sell a product idea without deviating from your product idea to chase sales, then selling as a validation tool is fantastic.


If you can't sell - should you really attempt to be a solo founder? If you aren't strong enough to 'own the feature-set' and work with potential clients now, will you be the right person to run the company later?

This is a provocation/question - not a statement of fact btw!


Selling/customer development is a skill you can learn—and absolutely must learn if you want to hack it as a single founder. The real trap is staying in your comfort zone.


Definetly not something you have to learn. If you build something customers really want then the product will probably sell itself, and no selling or marketing will be needed.


Real life disagrees with you.

Not saying that this never happens, but it is extremely rare and closer to gambling than to running a company.


Single founder here. I think this doesn't work in B2B or may be I am talking to the wrong people, most of the potential customers I've spoken to want to see something - so the first question they ask is what have you built. This is in financial industry, building fraud product and like I said I may not know the right people to talk to. I think having domain contacts in B2B works great, specifically if you have somewhat tried to solve the problem before. I think PG writes this in one of the essays.


It can work in B2B, but maybe harder in finance as you say.


I disagree, you should know enough about what field in your in so that you have some credibility.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: