If I hear one more person say “sell before you build” I'm going to puke
indiehackers.com
indiehackers.com
Just go to potential customers and tell them "hey, in [a few months/years], I'm going to launch a thing that can do this and that for you. Would you like one at prelaunch price?"
If customers don't like your initial pitch and don't buy, why would you give up? Iterate on what you're selling. You don't need to build to iterate.
Then you can build something people want.
I like to phrase that as "as a software consultant, I'm in the business of not writing code. The first rule of this business is to never write code until somebody definitely wants to use it".
Of course, if you're building it just for fun, iterate on the code all yu want before you sell it.
"Hi customer, after months of meetings and calls and briefings and checklists and ... here is my final 76 page presentation about an ideal not buildable extremely expensive software that if finished will look like Homer's car"
Never had experiences different from the above, be it from big or small players.
There are consultancies in the CYOA business, and consultancies (or, usually, single consultants) in the delivery business. Both have high customer demand, for different reasons. Admittedly, the first kind usually make a lot more money, but I live nicely.
The thing you are describing sounds like the first phase of a project where you are gathering the requirements, in a one-to-one business relationship with a single customer. "Sell before you build" as far as I understand is usually used in a one-to-many scenario, where you start selling (or better, marketing) a product before building it.
And it's very rare that I'm engaged to write a complete system, because I'm quite expensive.
However, from the way I approached the answer you can easily tell I'm a software person and not an MBA/salesman by birth.
Usually I work with startup CTOs (which I was myself until half a year ago) to solve very complex business or technology problems or support the design and development of a complex project. For example, you might engage me to perform design reviews with your team, or to dive into the code of a system written in a language nobody in the company knows and add a complex feature that sends ripples across the codebase, or to design a critical system and then write the most complex module myself and stay involved enough in the development of the rest that I can ensure what the team delivers is what the organization actually needs. I really am a consultant, just a software consultant, not a "management consultant", like McKinsey or Deloitte.
"Sell before you build" means before you waste resources building something, have expectant customers waiting for them to exist, with money already committed to buying it once it exists. There are many ways to structure this commercially. Of course you should sell one-to-many, not just one-to-one.
Many times the first thing I tell a potential customer on a sales call is "wait, you want to build this before you have paying customers? Why take all this risk? Go out and sell it (or market it, if it's a B2C product) and then build it without the product-market-fit risk!" I then go into the many strategies that exist for selling things before they are built, as they apply to their specific industry and business. This can save my customers millions of dollars or years of their lives if they're at the first stages of a startup. This kind of thing is a major reason I can charge consulting rates and not freelancing rates, and is essential business advice that every serious entrepreneur either learned the easy way or the hard way.
I guess it is just a matter of terms, I would have never called what you just described as a "software consultancy" since you mentioned building, developing, code reviewing and such terms a lot of times.
By talking to you I understand that the meaning I give to the word "consultancy" is not as universal as I have thought. For me consultants never dive into anything "practical", they limit themselves to aspects of the software that stay all around the actual development.
From my point of view you I would call you an experienced freelance developer, or a development agency (congrats on growing BTW, going from 0 to 1 employee is a big step). Mind that developing is not simply coding, so IMHO you are still a developer even if you "stay involved enough in the development of the rest that I can ensure what the team delivers is what the organization actually needs".
You happen to advice your customers about stuff not strictly related to the actual development process, and that would be a consultancy, but it doesn't sound from all your comments that this is your main focus so from my strictly personal point of view I wouldn't call you a consultant.
Developer: code, output, stuff that works and implements some business logic.
Consultant: advices, indications, expectations... and then it is up to someone else to make it work. (and they don't care if ever, how, when, why, who)
Anyway don't take it personally, and by the way I didn't mean to be disrespectful towards you. Maybe my first comment was a little harsh, so I'm sorry if you felt it as an attack on your person or your professionalism :D
I'm an uncommon type of consultant, but definitely not a development agency or software freelancer. I help my clients build things, but I don't usually build things for my clients, as that would be too expensive for them.
This is just selling an idea, not a product. You can sell anything this way, just promise something and trick them into buying, it doesn't mean that you can actually deliver on that promise.
> Then you can build something people want The problem is that you don't know what people want. People don't know what they want. It's hard to know how to solve a problem or if a product will work unless you try it, there are so many unforeseen issues that can arise once the product is"done".
> doesn't mean that you can actually deliver on that promise
It's very rare that the big risk in a problem is technical feasibility. And you should definitely be, or partner with, someone who can tell the difference between a spec that can be built to a spec that has real technical risk, and only sell things that you can deliver.
> The problem is that you don't know what people want. People don't know what they want
Indeed, and the only real way to tell is to build it. But you can de-risk by selling a few first and then building, instead of just investing years of your life completely blindly. And there's no reason not to. It's very rare that a product idea can be sold once it's built but not before, and there are other, less risky, products you could build instead of that one.
- Putting up a landing page with an email collection form at the bottom without a strong value-add for the potential user
- General idea of MVPs (not saying MVPs don't work, I'm saying the way we're told MVPs have to be bereft of features and polish is bullshit), though this has mostly been replaced with Minimal Loveable Product.
- The idea that you have to be first/second to an idea to make money from it (I was 200th to my idea, it's profitable)
- The idea that you have to quit your job and "hustle hard" to make a product others will want (I did it in 2 hour chunks before work)
Unless your startup received massive media exposure, nobody will part their money for a product which does not yet exist... You need exposure to massive numbers of people to get any measurable success... And without the right personal connections, it costs a prohibitive amount of money to get that kind of exposure. If you're a developer, it would be cheaper for you to build the thing and then try to grow linearly over the years than to pay the cash up front to achieve that kind of reach... What if your product doesn't measure up to expectations? This is a real risk if you got your customers through advertising (selling a dream) instead of winning them over slowly through a superior offering. The problem with selling a dream is that it's essentially impossible to make reality match the idealised image which you projected into the customer's mind... Even in the cases where it does seem to work out and customers make repeat purchases, the product may just be a superficial representation of what the customer actually needed and it could take them a few years to figure out that the product was itself just an extension of the dream, a shell of a solution... There are better alternatives out there.
The first step is to know yourself. Which style are you? Which style you want to be?
If you are on the consulting end, talk to people, understand the problem, build a solution, and iterate on it. This is how software has been preached to be built for decades. Waterfall/agile/whatnot are all the same, assuming idea come from somewhere and keep iterating your solution.
If you are on the crafting end, you have an ideology to preach. Akin to art in any form, you are both the source of idea and executor. You broadcast your ideology and look for followers. Rich Hickey of clojure, Mike Bostock of D3.js and Bret Victor are on this camp in my opinion.
Note that you can hop between crafting and consulting/iterating. But iterating is like newton method, no amount of iterating will get you to answer if the initial guess is too off. So one has to have strong conviction to craft an initial solution with good enough quality before launching into iteration cycles. I've seen many "metric-minded" product people obsessed about iteration without having any conviction on what to build. Without the initial conviction, no amount of iteration can give you clojure, d3.js and co.
I would do that if I already trust the organization, which implies it has already launched useful products in the past. For an unknown startup, the idea would have to be truly Earth-shaking for me to sign up.
In most cases, I'll just wait until I hear that the app is out, and then try it and consider purchasing.
To me, "sell before you build" is a no-go for upstarts with zero audience, whereas "market before you build", or maybe "market as you are building", creates the awareness you'll need to warm people up when you are ready to sell.
It could be a bit dangerous to rely only on those when building your startup, but having a good combination of these early adopters and pre-sale conversations with late adopters is super important.
Zero audience is not a problem btw since a) there’re are usually relevant communities, b) there’s trivially automating cold outreach that is a single best way to test your PMF hypothesis.
Edit: typos
In this case, I think there's a strong argument to be made that while yes, there are people who will be willing to buy into an unknown startup's unreleased product, by and large, those people are fools (in the sense of "a fool and his money are soon parted", at the very least). There's certainly a segment of our population (which is, completely unsurprisingly and reasonably, overrepresented on HN) that's very excited about startup culture, and wants to believe that any given startup is going to Change The World™...but far, far too many of them fall into one of three categories:
1) Come up with a "new" way of moving money around so that rich people get richer (eg, the entire cryptocurrency space)
2) Make something that looks just flashy enough for them to get bought out by a bigger company
3) Fail outright
It is a question of versioning and packaging. Basically, v0 of a product is for testing the initial hypotheses that people are interested in buying at all. And it also serves as a tool for finding the initial "fans" that are excited by your product vision and will help you flesh out the product.
"Sell before you build" is just way to communicate this.
btw: The post is very short. Here it is:
> This is such bad advice. It assumes that everyone will nail their product on the first go. Almost no-one does.
> If I went to customers and pitched Songbox to them with what was the initial version of it I had in my head - I would have gotten nothing. And if I'd given up on it at THAT point then I would have missed out on (a couple years later) having a business that's well into X thousand MRR and even more importantly, working with some amazing people and having truly exciting and unique experiences.
> There is no doubt that "sell before you build" will work for some people; but everything and anything will work for SOME people.
> For the general populace of makers it is crushingly bad advice.
They might be fans of you vision, of your marketing or whatever else but that can be as bad as it can be good when your product finally lands.
Generally, a lot of indie hacker types of entrepreneurs just like building cool things!
A bit more proactive on the communicative and sales side is not a bad thing, but I believe it's best to play to your individual strengths.
Let me tell you that it's also hard to find skilled ppl in the context you wish to exploit.
Let me tell you I saw many clowns telling they are good with computing...
But unaware what a heap memory. Says a lot. :)