Lessons learned from my failed startup after 2 years, 300 users and 0 revenue
sergioschuler.com
sergioschuler.com
Two elaborations:
1) General advice to non-technical founders, not specific to this post: If sales is one of your primary skill sets, and you cannot sell one developer on working for you, you may want to have a brief heart-to-heart with yourself on whether you are sufficiently skilled at selling to build a company which will live or die based on your sales ability.
2) His advice about starting with 1 anchor client for a SaaS, expanding to 10 via expenditure of shoe leather, and then starting to worry about scalable approaches to customer acquisition is very, very good. (I don't know if I definitely would endorse the "An Indian company expressed desire to buy something from me other than the thing I was building, so I should have built that instead." That would turn on a lot of things, including how serious that company was about actually buying the thing. There is a world of difference between "I would buy a Widget from you" and "I commit to accepting delivery of a Widget from you, where a Widget broadly does X, my timeframe is Y, and your payment will be $Z." I'd be looking for a letter of intent or a check as a filter for seriousness following that Skype call before making a bet-the-business decision on it, personally, but I obviously don't know the specifics of what was said.)
1) I am not a developer, but I believe having an idea -> finding a developer is the wrong flow. It should be like this: 1. Have the idea. 2. Get customers who give you real money to build this idea. 3. Get a developer by telling "I already have paying customers".
2) Absolutely agree. When I say "I should build that", in fact what I wanted to say was something like "I should have looked for more X prospects that would pay for what they wanted, get their money and then build that".
Does anybody have examples of successful startups that proceeded in the way Sergio describes and became successful -- starting out with a business person/team, selling the goods first, then manage to find developer(s) to build it? (It's not rhetorical, I'd love to hear such examples -- the usual stories seem to be revolving around a gang of programmers, or at least a programmer co-founder.)
Actually, I disagree. Even if you're not a developer, you should still strive to learn enough development such that you can push out the first version of the product yourself, even if it's imperfect. Doing so will have several advantages:
1. It will make it easier to find a developer (they will respect you a lot more)
2. It will make it easier to get customers
3. It will make you appreciate the technical aspects of the business
Number 1 is the most important. The reason non-technical people have difficulty convincing developers to work on their ideas is that developers tend to look down upon non-technical people, especially "sales types." In addition, most developers have a thousand ideas of their own - you need to give them a reason to work on your idea instead. And that's a lot easier to do if you already have a version 1.0 out there that you have developed and have customers paying for it.
BUT I do believe it is easier if you do know how to code.
I disagree. Not wanting to code is not the same as not knowing anything about the product, or wanting to. There's so much more that goes into a successful product or company than time spent coding (marketing, design, testing, sales, industry/market immersion, etc.). As a developer and co-founder, ideally I want complimentary skill sets. Being able to write code may be an overlapping skill, but it's not required.
It is like saying a given business which sells through the phone is about phones. Phones are just a way of doing it.
Instead of just selling horses, you can make a startup that makes it easier for for people who want to ride horses but can't to ride them. You could have a stable with restaurant to let people watch others ride them, etc. Simply because you don't know about horses is not the problem, because the problem is finding ways to bring people to horses based on the public's opinion of horses. Your horses don't need to be looked after by the world's most knowlegable horse lover, just someone who sort of knows horses and is willing to learn will hopefully keep your horses in good enough condition until you can hire more horse caretakers.
This analogy works very well for tech startups too. You don't necessarily have to know how to make the website, it can be enough to know how to create something around the website (physical deliveries, or whatever) and just get some bare-bones barely functional web presence that you improve when you get traction and funding.
As a developer what I'd be looking for before coming onboard is a) a clear idea of what is being built b) that there is the money in place to pay me.
The thing is, there's a lot more that goes into a viable product than just the core features.
This! I agree wholeheartedly, a useful tool/hack must travel a long road before it can become a product. Even if it's essentially solving the same problem.
Yes, yes, YES! I'm doing this now, and just figuring out the "business" side of the product code is so much more work than the core idea (which is simple to code).
And getting the actual sales/marketing/accounting/admin/etc stuff is going to be 10x worse, I am sure.
Though in practice I've experienced too many cases where I couldn't imagine non-technical founders I've worked with learning enough, and fast enough, to launch a v1 on their own. It's possible, but between OP's suggested flow vs. yours, I'll side w/the OP's. As a developer and co-founder, I'd much rather a non-technical founder concentrate on finding paying customers (or other cash flow), marketing, becoming immersed in the target market, etc. than learning how to code.
To supplement, the article's Where it went wrong and Where it went REALLY wrong sections cite non-technical reasons for failure. So while you raise great points, it's not clear that the OP's situation would have been better if he had learned to code first.
Even if you are Jack of all trades, you won't have the time to execute all the tasks well on your own. If the developer looks down on you because you don't know how to code, then that is not your ideal candidate or your business or talent is not convincing enough.
It is true having technical skills can make it easier to hire developers, get customers (only one way to make this easier), and appreciate the technical side.
If a 'developer looks down on you' why does this not make them an 'ideal candidate'?
And what is the value of an ideal candidate? Is finding one even possible? Isn't 'the ideal' hard to reach in anything? My ideal life is to make millions while making the word a better place, have a six pack, lots of interesting friends, write rap, write a novel, have an uberman sleep cycle and not go crazy, and have many beautiful and intelligent woman.
Isn't 'ideal' more of a standard then an actual possibility? If so, isn't not the end of the world if this developer is not ideal? Don't you only need a talented developer who will do the work that is asked of him?
And what is 'business or talent ' not 'convincing enough' for? (hiring the developer, creating a business etc..)
It'd be great to fully understand your point of view.
I've had some really good bosses who couldn't code, though there is certainly a skill in winning over devs when you're not a programmer yourself.
There are advantages to being a non-technical founder, if you're able to bring the right techies on board.
To evaluate more ideas and to be familiar with respective areas took me another year easily (without deep knowledge in the area, how can you beat your competitors?).
So how can you guys roll out a product in 3 months? How can you quickly pivot?
Tooling. To elaborate, if you're hand writing code to call an API, then you're doing to much. This is a 15 minute task at most, and that includes production level validation, security, etc. on both the client and server.
Also, basic code quality checks should be running non-stop in a separate terminal and automated tests should also be running. Plus the core automated tests should themselves be automated.
Developing an API is again a 15 minute task.
To be totally clear, proper tooling will take you from prototype to (early) production. Obviously, tooling does not write your application for you, but standing up a basic app where you can use the UI and move data to/from the backend needs to happen with a minimum of effort. Once the core design/structure is done, you can spend your time on value add activities such as UI customization, custom business logic, and so on.
Its come to a point that hiring development staff for web based applications isn't that expensive if you focus on hiring people that aren't in North America and don't need to use the whiz bang language or framework (I would put even Ruby on Rails and Django in this) but instead use PHP.
What I do think is important for non-technical founders is to have an understanding of what software development actually involves, so that they can judge and critique the work. It's worth knowing why a company might quote you, $10K for some work versus another $50K. Is one company using PHP or ASP.NET? Does one company's quote include all tasks such as requirement's gathering, mock-ups, development and production deployment. Where does system testing and end user testing fit into all of it? What's the hosting costs after the fact. Are they using Rackspace, AWS or their own provider and charging $300 a month for it.
I think a smart person can take a good 30-50 hours and read up on all this and get a good grounding as there is no lack of materials to get this knowledge from. I don't need to know the intricate details of how to build a car to appreciate the manufacturing process for a car. We all know there are many makes and models of cars but the design and manufacturing, distribution and sales of cars follow similar patterns (not taking into account the new entrants such as Tesla).
As an added check, a non-technical founder should find a trusted technical person that can help guide the development of the product even if the technical person themselves won't build it.
I think doing this would go a long way to get something built and off the ground. It's easy for a lot of us who have grown up with technology and understand computers, the internet, programming languages, algorithms, software development etc. but for the non-technical person who grew up as a user of the tech not but not a tinkerer its hard to catch up and go beyond and build a product (even an MVP).
However, most important should be the second claim since learning to code will help you build a crude MVP, allowing you to reach customers and validate your idea. In this sense, enraged_camel and OP are both correct because they both point back to the same concept of reaching customers.
IMHO though, it comes down to what value a company is providing. If it is a tech start-up where the software product is the main value-add, then a core competency must include programming. If it is a real estate start-up with a website, then learning to code can probably be pushed off in favor of customer development. So in the OP's case, the question would be, are we in business to build a SaaS tool to help teams or are we satisfied helping team management improve in any way possible?
The point of the article, what caused my last failure, what almost everyone that bootstraps a business, and most of the ones that received investiment will tell you is that this phrase is wrong. At least in the context of growing companies (not mature companies in mature markets), if you separate the two concepts, you are dead.
And that means your sales force should never do just straight sales, and you must hire accordingly.
The worst part, I knew (at least in theory) it from the beginning. Not talking to customers is very attractive to developers. But don't mind, it didn't hurt much.
But I think "selling" the product to a developer is a difficult sell: harder than selling a product which exists and solves a pain point to a company who has money and is looking to solve their pain point.
If "selling" means getting the developer to work for no cash (only e.g. equity). A good developer has a job, and has lots of job offers, all offering them real money now. I'm not sure it'd be possible to persuade most of them to work for no cash.
As far as offering equity to a developer, this may be as weak a move as building a product before proper validation, since it essentially means bringing on an investor before proving that there's something worth investing in.
If anything convincing a developer to take your money (assuming you have any) to write code should be orders of magnitude easier than convincing a client to give you money for something that doesn't yet exist.
If that were true then an inventor could have asked a great sales person to sell an engineer on the idea, and build it.
In fact, this isn't true at all, and most innovative ideas are forced to be built by the same person in whose head they are, precisely because it is not true that "great sales people can sell anything to anyone", and some of the best ideas can't be sold, but must be built instead.
>Selling people mediocre products they don't need and probably can't afford, that is actually difficult.
This is exactly why developers (at least this one) have a pending distaste for business people. This should never, ever, be done. The difficulty of selling 'mediocre products' that are not in 'need' and to people who cannot 'afford' is awful and disgusting. It implies tricking the buyer for your own gain.
If you have a mediocre product do not misrepresent when you sell it. If you are trying to fck people out of their money, fck you.
The difficult case is what if you invest your livelihood in a product that turns out to be shitty. You are left with either tricking people in to buying it or facing the alternative -- debt, foreclosure etc.. This could include putting a family (wife or husband or partner and children out on the street). This sucks for all involved. Customers wish you had a good product, you wish you did too.
This decision comes down to responsibility. You built that product. You were in charge or you bought in to the company. Take the loss, be honest about the product (note sales is still involved just not sales that misrepresents).
To be clear, sales is great. If sales is the method of opening people's mind enough to see what you genuinely believe are the best parts of your product. If its to lie and convince them to lie and buy a product that is 'medicore' and they cannot 'afford' (implicitly that this purchase will hurt them in other ways) then fck sales. This 'lying sales' is what the statement indicated and what I, and I think other developers, do not like.
"Would you work for me for a billion dollars a year and six months holiday?" Lots of people are going to say yes.
But are they the people you want? Do you have those sorts of resources to throw around? What about other perks of working with you to fill in the intermediate space?
Extreme example, granted. But the point is that there are things you can't solve, at least not in an immediately relevant sense, just by throwing money at them. Getting a developer's probably relatively easy. Getting one you'd want; at a price you can afford... knowing next to nothing about the technical area of the business yourself?
That may still be easier than selling something that doesn't exist, but it's not clear that it's orders of magnitude easier.
They might think they are good at sales, but if that was really the case then getting enough money to hire someone to build your prototype is not that hard. Freelancers are everywhere, you can judge them by their portfolio, and getting someone to build you a greenfield project at market rates is not really difficult.
I don't think sales skills are completely fungible across domains. A great business seller may not actually be a great motivational/aspirational seller, and vice versa. So it's wrong, IMHO, to assume that just because you may be incapable of convincing a developer to join you, you will also be incapable of convincing a customer to buy your product.
That said, I'm facing somewhat the same issue myself - so they way I'm solving it is by (a) rolling up my sleeves and trying to build a bare-bones MVP/mockups using relatively accessible tech like Bootstrap, HTML, JS etc. (b) overcompensating for my tech shortfall by giving 2x of what I can in areas like marketing, customer interviews, alpha partnerships, fundraising etc., and (c) using (precious) capital to outsource the first version of my app instead of waiting for tech co-founders.
As I see it, it's Carpe Diem. There's no way I can earn serious developer cred in weeks or even months, so I might as well look for alternative approaches instead of moping around, wishing I'd followed the software developer road 15 years ago instead of the MBA one :)
My experience across a fifteen year business confirms this. Year one I had to sell. As an engineer I was a horrible sales guy. A couple of my dealers took me under their wing and over approximately a year a made notable changes.
Years later, as we grew, I had to hire sales people. That's when I learned the lesson. If someone is good about selling product A it doesn't necessarily mean they can sell product B. I hired around a dozen sales people over the years. Most were collosal failures. Some of the most memorable ones came with huge contact lists and years of selling other products in the industry. Based on the advise of other entrepreneurs I ended-up hiring someone with little sales experience and training them over a year. She was my best sales person, by far.
[Side note: there are such things as general "salesmanship" skills, like being personable, charismatic, good at articulating value propositions, good at finding ways to get in front of people, and so forth. But these things need not be conflated with capital-S Sales.]
Some of the really established guys --20+ year career in the industry-- can come with this "I can walk on water" attitude as they drive their leased Jaguar into their parking slot. Then they cave when they realize this is a new market segment and a new product segment in the industry. They are used to people coming to them to buy the old stuff. Now they actually have to work, learn the new product, learn the new lingo and also identify customers who might be receptive to the message.
Then you have the guy who worked for a rather large company and is used to the fish jumping into the boat. No fishing rod or fish finder required. You don't even have to know how to bait a hook. These guys, amazingly enough, actually think they are selling. When faced with a situation where the phone only rings if they make it ring they don't do very well.
There's the guy who faked it in a good market, got lucky and built a reputation on circumstance rather than skill. When things change (i.e., the economy tanks) the reality of their capabilities comes to the surface.
Then there's the inability to adjust to a change of audience. You don't sell to an engineer the same way you might sell to a manager or the president of a company.
One of the most frustrating things for me has always been the sales person who attempts to take credit for a sale that came in because I spent tens of thousands of dollars in marketing. They think you are stupid. Or at least they act that way. Some of the most memorable moments in my experience have been after major trade-shows. Imagine having a sales person come to you like he just climbed Everest to close a sale after you just spent over $100K to exhibit at a trade-show for a week. You look further and you see the sale was due to a years-long relationship with the customer as well as a meeting at the trade-show where the sales guy didn't even interface with the customer. What did happen is that he got and printed the purchase order because he was in charge with monitoring sales@company.com. In retrospect it is really funny and it also reveals interesting character flaws.
And, of course, there's the mercenary sales person who will hand out discounts like they are candy in order to book sales and look like a genius to anyone except for the person who actually looks at the numbers.
There's more, of course,
The advantage of the motivated newbie is that they can learn the product, the market and the approach. It takes six months to a year of real work to get someone up to speed, but it can really pay off. Most business owners I reached out for advice would roll their eyes when I asked for the secret to hiring good sales people. Everyone had horror stories galore.
One of the toughest skills to learn for in-person sales is to know when to close your mouth and let the process happen. When I started my business I would talk and talk and talk. I probably lost more sales to that than any other blunder. A year later, I'd show up to a call, "read" the room, meet some of the people I didn't know, setup the demo and mostly let the customers sell themselves on the product. Selling by saying less, not more, is a skill that takes time to develop. Most really good sales people are very relaxed and confident during a sales call.
One of my friends put it like this: It's like the hotel business. You can print beautiful brochures; exquisitely redecorate the rooms; have amazing food and all manner of services. You can't force people to take a vacation.
I did this through an ad in Craigs List. I effectively asked for people comfortable with technology, able to learn quickly and with great people skills that could be applied in the context of sales presentations in a trade show environment. I did get quite a variation of responses. I selected a small group I thought would do well.
Lean Startup, great book, decent ideas, not the religion that it's become. I'm sick of hearing, hey do this the lean way and it'll "significantly improve" how well you do, after all it's the blueprint for success. Personally, I don't buy into that. Here's my view of success in reality: do whatever works (that's legal & up to your moral standards), be opportunistic and get lucky (yes, hard work and measuring metrics alone don't do crap).
MVP and idea validation are great concepts & helpful common language. In hindsight all "successful" startups seem to have a "pattern", but in all seriousness, there isn't a friggin algorithm for success in startups, otherwise algorithms would've replaced entrepreneurs a long time ago. (Although selling success patterns & software based on such to wantreprenuers is a great idea)
I'm sorry the Sergio's experience happened. It's easy force cause and effect onto a narrative. It very well could have been that the developer Sregio met was at a point in his life where he really just wanted to build something great and did end up building the awesomest thing. Instead of trying to dissect the reasons his startup failed, had luck been a little more favorable, we might be trying to analyze how it became a huge success.
Bottom line, my heartfelt congratulations to Sergio on being successful at stepping up, despite the risks and having a crack at it. If you had never stepped up and we all gave in to our negative biases and overanalyzed the crap out of everything before we started we'd still be polishing stone wheels.
I know how shitty it feels. But remember, hindsight is 20-20 and cause and effect should really be cause+luck and effect. Hope you're a better entrepreneur and will be back in the game soon.
Heard this story so many times. Amazing how many people join a startup and don't want to do the actual work. Remember that scene in The Social Network where Mark Zuckerberg calls his outsource team about progress on that latest feature? No? Me either.
I've been apart of a lot of startups and this is far and away the best advice. It was a common theme with two startups I worked for during the boom years. One CEO's hubris was stunning. 10 million privately funded and he blew most of it on season tickets and suits at stadiums to "entertain" big prospects (nevermind we didn't have any "big" prospects at the time!), remodeled the office to the tune of a few hundred thousand dollars, it goes on, but you get the idea.
When you're in a startup, it really is about getting your product shipped, and making sure that's where the focus is.
Great writeup and glad you saw the errors of your ways. Lots of people never gain the wisdom you have until after two or three failed attempts.
One of the startups was a telecom company, the other an educational software company.
The telecom company was the one that burned through all the millions. They had an exclusive contract with one of the regional bells and were trying to make high speed internet accessible to the masses. They were banking on fiber instead of the existing DSL which ran over copper. Essentially using T1 fiber to give high speeds at the cost of copper DSL.
They thought they had a home run with a growing base of clients, and were trying to get acquired more than build the next Frontier Telecommunications.
They had a crazy story, maybe sometime I'll let the details go. That was a crazy time for sure.
FFS don't do this. There are far too many startups beached on the shores of "well, this one SRS BZNS client wanted us to change what we were doing so we did. Where'd all the rest of our clients go?"
I'm not saying "don't pivot", but "just making what they wanted" (where N(they) = 1) turns you into a poorly-paid contract developer who's also paying to host the result, not an entrepreneur.
It can be hard to get that one or two clients who can fund the company, but it is a viable strategy as long as you have the right mindset. We, Datalanche, had this opportunity but unfortunately (like most deals) it didn't work out. Had we successfully made the deal, it would have been a multi-million dollar contract which would have easily funded the entire company and the flagship product and we wouldn't have given away any control.
The problem today is (out of the perspective of a developer): To many companies rely on just "hire any (cheap) developer" to ramp up the product. I see it all the time: Quality is not asked for, many companies (specially in the web business) just want the cheapest developers. They search for a student (at best), because he is cheap and will just make a small time estimation and an even smaller fixed price offer for the project. The student will happily work overtime that is not covered by the initial estimation.
Than the companies go mad, when either the programmer is running away or the whole project runs into a blind alley (or both at the same time), because the "totally expensive" programmer had not enough experience e.g. with database development and the database structure just lets you shiver. Then the shouting and anger is big: "Damn programmers -- all are liars and lazy!"
What went wrong, stated Uncle Bob correctly in his Blog: http://blog.8thlight.com/uncle-bob/2013/11/19/HoardsOfNovice...
But the "cheap, cheap!" culture seams to be unstoppable. If you tell people in advance about "quality" and "professionalism", they don't listen or just laugh at you. It seams, all the people just have to find out the hard way -- but I guess, even than most of them will not learn at all.
(This is hypothetical, but not so much: I understand a bit of tech and even so I don't have so much clue on how to judge a developer besides what he shows me he had done).
That's a problem intrinsic with software: What you "see" is not what you get. You see a perfect polished UI, but you get a sack of bugs! So this criterion is not usable at all. The intrinsic values of a program are not visible to non-developers at all. Even software-companies have a hard time, deciding which criterion to choose as a base for decisions.
I think, when you look at cars or houses, people are more likely to ask a professional to decide about the condition of the car or house. Also everybody that loves his car (and life) will bring his car to some person that has read some books about motors and does repair the brakes "half-prize" in his back-yard. But in software practice, you just want to see some polished front lids of cars and decide that the brake repairs will be fine.
At least seems more respectful of people's time than 'try it free' just for them to have to click through and find out what it's about.
I'm left wondering, though, what you actually did over the two years? You imply that you were working on it full time. Two years full time is a lot of time. You can do pretty much anything in that time (including, as others have mentioned, learn to code).
> idiot plans, budget forecasts, BUSINESS CARDS, fancy website [and writing articles]
I find it hard to believe you can work on those things for two years, day in and day out.
So, yeah, a looooot of the time was put into building the product, refining it, getting bugs out of the way, testing it again, finding the same bugs...
Then there was marketing. Finding more clients, because we believed finding more people meant someone would buy the product.
PS: I was not completely full time, the developer was. In those 2 years, I have been freelancing (one needs to eat).
PS: This includes Marketing, Managers as well as the Business peanut gallery.
The Beatles had Brian Epstein for example (aka The Fifth Beatle)
And they're better.
Don't compare the two. The Beatles have ushered in new song writing, band lineup, tone setup and lyrical prowess. Incomparable. Do you even use your ears, or are you just regurgitating?
A lot of non-tech co-founders exist and they succeed, so certainly not absurd.
But please, keep thanking the complacent comments that do nothing to better your case.
Somebody has to find customers, make sure there is a way to accept their money, ...
Sellers as the peanut gallery, should be kept in check.
>> ""An Indian company expressed desire to buy something from me other than the thing I was building, so I should have built that instead.""
I may be the minority but I agree with him but on one condition. If this Indian company wanted to pay a small monthly subscription fee for your product I would never have agreed developing "their" ideas. I would have taken their feedback and put in the big pile with all the other feedback I gathered up. But I would have pitched this Indian company a different story, I would have pitched them a professional services contract instead of a product. I did something similar in the past and it worked out very well because in a business money is king. With no money you can't do the things you need to do, like attend conferences to sell your idea, buying adwords, hiring solid developers, paying yourself a salary so you can devote your time to the idea.
In my case the customer was willing to pay ~$10k a month to get what he wanted. We built it for him while building our own product. Once we got big enough and could sustain ourselves without our original customer, I gave the customer away. The developer who maintained the project was interest in taking on the project himself. We came up with a 6 month transition plan, including lots of product/project management help, office space, etc. It was a win/win situation at the end.
Doing this is not for everyone though. There are many days I cursed this customers for taking up the majority of our resources. We had to be very good at differentiating between their requirements and the markets requirements. We weren't perfect at it but it worked out in the end.
Seriously, if somebody could cull 2 or 3 of these a day and deliver in a weekly or monthly format? It'd be worth a subscription.
Thanks for the article!
One failure story per week should be sufficient to be constantly aware of typical problems.
I know startups that charged down the other path, being hyper responsive to their big customers, and they suffered for it because their biggest customer steered the product vision straight to crazy town. Such startups essentially become the contract development shop of a few big customers, living and dying by the whims of those big customers. Yes, you can pay the bills, but you're essentially working full-time for a few customers rather than building your own enterprise.
Also due to what I perceived as a thousand separator, not a decimal mark, I initially read the price as nineteen thousand and nine hundred dollars!
Basically being afraid to ask for the value it was really worth.
I think there was a comma/period swap, but if I'm reading correctly it looked like the product was positioned at $30 / mo?
Assuming that's correct - it's really not a meaningful amount to any company that has enough employees and management to actually be a user of the product.
I think a $30 / mo with a free 30 day trial period (once product launches and they can actually try it ;) ) that requires a credit card for the trail could have worked.
Would still need a product to actually try, but that's not much different than saying get a free trial and just taking in email addresses.
If anyone remembers the Minimalytics / Small HQ folks - I thought they did a good job with their signups. The only thing for me was I disappointed by how minimal their product was in beta. It was so basic I didn't have any use for it, and running our own startup, didn't have time to wait. We ended up building it internally.
I probably would have converted to a paying user if it was more developed at beta. Not their fault though, they did a good job I thought(if you're reading Small HQ).
If you accept his argument as true, that he should switch and follow the tide, then you might as well start looking for freelancer developer job.
< J/K> Awesome quote:
> The result of this was that in the end we had to hire a full-time (and paid) developer. So we had zero revenue, 4 co-founders and a paid employee (which was effectively the only one doing real work).
I laughed really hard reading this line. My girlfriend came from next room to make sure I was okay!!! That's awesome, like 4 guys watching a movie, say the 'Social Network', and deciding to do a startup!!! </ J/K>
Jokes apart, I think the author has got it all wrong. There are ten million reasons why a small startup failed. Most of the time is hard to tell exactly why.
But seriously, only people who have proved time and again their ability to deliver a product to the market and are famous for turning ideas into money, are able to struck deals before having a product. And we probably all know them (Jobs, Musk, etc). For the rest of us that's not how things work, I'm sorry to say that he is still getting it all wrong.
In the real world, you can't sell something that doesn't exist, these things happen only on Wall Street.
This advice always seemed like a stretch to me. Does anybody pay for a product that's not ready yet?
Isn't kick starter build around that concept? If people think something is looking good and might help them considerably they might be open to pay for developmental costs.
This stuff does seem like bullshit when you're working on it, but it's unfortunately crucial these days. It takes so long to build up the brand and visibility that I don't believe you have the option to just do it once you've got the product right. Unless you've got the investment, firepower or notoriety to get chins wagging then you've got a long road ahead of you. Good SEO actually sounds like one of the things you got right to me. But maybe you spent too long on it
What I want to say is that SEO is important, but not more important than finding the pain and the product.
As a developer and solo founder, I just can not finish a serious project in one year. For example, it took me two years to get version 1 of torapp guilloche designer (www.torapp.info). We did not get consistent/significant customers and need a new product to survive.
To evaluate more ideas and to be familiar with respective areas took me another year easily (without deep knowledge in the area, how can you beat your competitors?).
So how can you guys roll out a product in 3 months? How can you quickly pivot? (pick up ideas and evaluate them quickly)
A vector editor is very complex compared to the typical CRUD-based with a little business logic that lots of SaaS products are in the end.
Isn't the market for that sort of thing getting crowded by now ?
[ETA: which is sad, because I want to read it!]
Is that really possible? Making someone pay for a product that doesn't yet exist? How can you do that?
I think there are some mis-perceptions about the idea. Here is how I how found the concept useful, in my company.
Startups who focus on revenue rather than growth can use this technique as a success metric (duh). Rather than using active users, etc., as proxy metrics for success, this method is a very direct one to measure how marketable your idea is. Get one success banked, then you can start to optimize -- pretty neat!
However, it's also incredibly difficult to do. So the second purpose becomes this: a proxy to evaluate the importance (in your customers' eyes) of the problem you solve. If you're solving a problem that everyone in the banking industry desperately needs solved, they will be more willing to try something that isn't feature-complete (or in existence).
So while few people will actually buy your product before it exists, using that as the goal can help you in your business development. You can figure out the problem's importance (and, believe me, it's better to solve a hair on fire problem than to solve a minor inconvenience). You can get feedback from people who are actually willing to pay -- this signals they are probably your customer! (So it helps you prioritize feedback, and sort people you talk to into actual / window-shopper type customers).
What the gurus don't tell you is this is very difficult to actually accomplish, at first. But after several iterations, you can get valuable feedback from people who are closer to having skin in the game.
And, of course, there is the chance that someone will have such a big problem that they want to pay you to solve it right now. If you can find that big fish, and their problem is similar enough (or uses core technology sufficiently similar to your "productized" version), then you can partially pay to make the product. (This comes with the caveats about how you don't want to be a slave to a single customer, etc. But we're having luck developing our core technology in the process for the big customer, and will re-use it for our product.)
If I had to give founders one piece of advice it would be, "Just Ask"... Ask for the sale, ask what youll get in exchange for equity, ask, ask, ask...
Even if the goal/role is to be the non tech founder, it's important to learn the basis of html, CSS and Javascript. It will give you another perspective when you think about how to implement an idea.
We brought on a third (largely my doing), as more of the operations / finance side. Didn't set roles, and my biggest gaff of all was to not make him vest.
After a year, the third founder turned into a maniacal control freak and almost sank us. Finally departed, but took his equity with him.
My biggest lesson so far is be very careful who you partner with and ALWAYS vest. Or another way to put it, you don't need to worry about the good times, it's the bad times you need to consider and pre-negotiating the divorce is critical.
As always, I am always keen to connect with bright people and good ideas.
It takes balls to do that shrinking ego experience in public.
I'm sure something good will come out of it.
Question: what are you going to do with the product now?