11 ms·
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
by warent 8y ago
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.
- gooftop 8y agoThe 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?)
- fernandotakai 8y agofor 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.
- realusername 8y agoDepends 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.
- borplk 8y agorealistically 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.
- dizzydes 8y agoOr, even better, build a minimal MVP (1-2 weeks dev time) and use this to attract attention and get feedback.
- mimixco 8y agoNot 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.
- dizzydes 8y agoAbsolutely, good point.
- imhoguy 8y agoOk, 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.
- got2surf 8y agoIt'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.
- drenvuk 8y agoMVP 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.
- coder543 8y agoThat 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.
- drenvuk 8y agoThe 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.
- ljf 8y agoIn 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.
- gwbas1c 8y agoI disagree, you should know enough about what field in your in so that you have some credibility.
- ChefboyOG 8y agoThis 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.
- ljf 8y agoIf 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!
- metafunctor 8y agoSelling/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.
- NightlyDev 8y agoDefinetly 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.
- williamdclt 8y agoReal life disagrees with you. Not saying that this never happens, but it is extremely rare and closer to gambling than to running a company.
- headalgorithm 8y agoI 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.
- deepGem 8y agoSingle 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.
- orasis 8y agoIt can work in B2B, but maybe harder in finance as you say.
- iscrewyou 8y agoCan 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.
- ramtatatam 8y agoI 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.
- wuliwong 8y agoI'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.
- joaomacp 8y ago> How do you sell first? In a podcast [1] a mattress company tells a story about how they got started: they just built a one-page site where you could buy a mattress, but the company didn't actually exist: after a certain point it failed and you couldn't buy it. They publicized the site and soon enough they found that someone had clicked to buy a mattress: a potential customer. So they effectively "sold" before building. Since the test was good and they found that people were willing to buy mattresses with the features they offered, they then built the company (and are now successful). [1] https://www.indiehackers.com/podcast/061-jt-marino-of-tuft-&-needle#71 https://www.indiehackers.com/podcast/061-jt-marino-of-tuft-&...
- ianamartin 8y agoI 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.
- warent 8y agoI'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.