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.
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.
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.
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.
Anything other questions or anything you're working on as well?
thanks for the insight!
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.
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.
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.
"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"?
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.
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.
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.
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.
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.
Put it on Ebay.
Tinker with the product description and price and measure results.
Rinse and repeat.
You will learn more than many wanna bes.
"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.
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.
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.
I do think that building a UI prototype that you can click through is a good first step for complex software.
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.
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.
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.
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 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've found Steve Blanks book "The Startup Owner's Manual: The Step-by-Step Guide for Building a Great Company" very insightful.
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.
This is a provocation/question - not a statement of fact btw!
Not saying that this never happens, but it is extremely rare and closer to gambling than to running a company.