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.)
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.
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".
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.
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.)
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.
PS: This includes Marketing, Managers as well as the Business peanut gallery.
Sellers as the peanut gallery, should be kept in check.
A lot of non-tech co-founders exist and they succeed, so certainly not absurd.
The Beatles had Brian Epstein for example (aka The Fifth Beatle)
Somebody has to find customers, make sure there is a way to accept their money, ...
[ETA: which is sad, because I want to read it!]
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.
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.
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.
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).
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 ?
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.)
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.
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.
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!
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.
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.
Question: what are you going to do with the product now?
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.
>> ""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.
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.
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.
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...
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.
