Do not be seduced by the technology!
I killed one of my startups this way. I've seen many many die this way.
It can hurt your pride as a passionate technologist to choose non-cool but mature and easy-to-hire-for tools. But it's those tools that are the most economical.
Remember, your customers care 0% about the backend technologies you're using as long as they are getting the value you promised them.
"Be regular and orderly in your life, so that you may be violent and original in your work." Gustave Flaubert
You're running a business, not a technological showcase for other engineers (who are not even your customers!).
Remember that the most economical tool for the job is often not the coolest or trendiest - but is some old boring workhorse that other engineers will scoff at.
Build your business for your customers, not for your technological pride or to demonstrate your technical prowess to friends.
Don't get me wrong though! There's certainly a time and a place to play with all the coolest and trendiest stuff, but if you're optimizing for growing a business, that is the time for choosing low-risk, simple, mature tools.
During this same period, I launched 2 SaaS products on boring PHP 7 and Python for the backend and HTML, jQuery/intercooler.js for the front-end. Both profitable and growing.
I think sometimes devs don't realize the hardest parts of starting and growing a business have nothing to do with code or the tech stack you choose. Marketing, getting and retaining customers and everything else in between is way harder than writing code.
I use Scala because Google App Engine didn't support PHP for example. It's an Android app, so I use Kotlin for that.
I personally do not want to spend time re-writing my app every 6 months before it is even launched. I would much rather spend the time acquiring customers. I tend to choose a stack at least to start that I know I won't need to re-write in 6 months. Unless of course it needs to be re-written/refactored to accommodate all those customers knocking at my door ;)
That generally means I stay away from the front-end flavor of the week when starting a new app. Don't get me wrong, I myself have used Angular and Vue for a couple of projects but not in the beginning and not for the core product. I don't like the instability and constant changes of a lot of the newer frameworks.
It's usually best to focus on propping up your differentiation and competitive advantages, going stock with everything else. If you rely on standard components for things that aren't your special sauce, then you get to ride market forces of commoditization which will drive the cost of those standard components towards zero.
Can you build your own backend database in Haskell instead of using Cassandra or PostgreSQL? Yeah, that would probably be really cool and do well on these boards. Then look back at how many hours you spent getting that to just understand simple SQL, and how many customer-facing features that could've been. Is it cooler to build that database than to set up an email auto-mailer? Yes! Special functional algorithms that operate on B-trees are far more exciting than simple state machines that send emails. But the latter is what the customer cares about, so therefore that's what you care about.
One interesting exception to using cutting-edge stuff may be making it easier to hire cutting-edge people.
It doesn't matter how smart you are. The opinion of the market is the only one that matters, and it expresses it in the form of repeat sales.
I want to emphasize this, and expand on it: Your cool tech startup is not about the tech.
You exist to solve a problem.
Sure, you might use your Cool Tech(TM) to solve the problem. But the salient point is that the problem gets solved. Your customers don't give a rats ass if you solve it with automatic hyperparameter selection for LSTMs, or if you solve it with an Excel macro. They just want. Their problem. Solved.
Outside of that...it's all about the business. That's why so many successful businesses are built with Ruby and not "benchmark winner of the week" because Ruby tends to deliver on almost all of the business cases around solving problems and growth.
If you're a larger business and planning to deploy at scale to an existing customer base, the business problems tend to change more towards performance and Right Tool for the Job.
There are still much faster options out there but it's nowhere near the beast that it used to be.
I just get tired of hearing the "but Ruby is slow" drum beats when it's so consistently successful. Scaling web servers is easy. Scaling the database is hard.
It being successful doesn't excuse its slowness, in my opinion. There are lots of bad products out there that are successful by many metrics. Speed is an important part of making something good, and RoR added significant hurdles to making very fast sites. There are other stacks that don't have that issue that are also successful, but have other downsides.
Anyway, not worth rehashing these old arguments, I just wanted to know if it had improved. Sounds like it has.
All mature technology will come with a known set of tools and processes to tackle almost any problem very quickly, as long as you're familiar enough with the stack.
One thing that's especially productive about it that helped to grow the 3rd party ecosystem is that the options you have for dependency injection in Ruby due to monkey patching give you an experience much closer to Aspect Oriented Programming.
It also makes it easier when you need to add functionality somewhere high up the inheritance chain without having to rebuild the entire chain around your new object base, or fork the library, use your fork as the dependency and make the change directly.
In the world of object oriented web development, Ruby was close to a miracle in time-reduction in WORKING with an ecosystem.
In some cases it is about the tech.
Instead the suggestion should be to apply the concepts of a minimum viable product relevant to your business problem.
Unless you are building tools, products, or services for other engineers.
> Build your business for your customers, not for your technological pride or to demonstrate your technical prowess to friends.
I'm going to assume that if someone is going into business for themselves then they are planning on having customers. There are ways to show off that don't put your mortgage and credit rating on the line.
> Remember, your customers care 0% about the backend technologies you're using as long as they are getting the value you promised them.
I'm going to assume, this too, is obvious. What I mean is that anyone who has written a fair amount of software has probably already realized this.
What is it that makes people think programmers are a bunch of navel-gazing narcissists that take great pleasure in impressing other programmers? We do, but we're also rather intelligent people.
I say: be seduced by technology. Programming is beautiful. Hard problems are a joy to solve and bring great value to the world. Do what pleases you. Life is short.
The specific business advice I have is: learn to be a leader. Take responsibility for outcomes, give ownership to your team, and learn to guide people. If your business grows and takes off you might find you won't have much time to program everything and will have to act more like a guiding hand and lead your team in the mission and trust them to take you all there.
My other advice is: avoid intuition and gut-instincts. Use data: analyze commit history, watch your issue manager, track performance indicators just as much as sales and marketing. A business is always shifting and changing. Rely on data to help you identify trends and make effective decisions. A gut decision should be a last resort.
It's far easier to fall into a hole of technical debt this way. The extra costs incurred could be too much for your venture to bear. Among all risks new ventures take, this is probably has one of the least cost:benefit ratios.
marketing encompasses the 4 P's: product, price, promotion and place. product is literally the finding of the fit between your offering and the market's needs. price is the portion of the value you deliver to the customer that you capture. promotion is finding and providing potential customers with info about why your product is the shizzle. place is how you deliver the product to your customer (e.g., physical store, direct sales, saas, app store, etc.).
build things that support your marketing activities, rather than building tech that you hope you can market.
I strongly believe that startups very rarely fail because they have chosen to build on a particular immature technology. Some fail or stall because they cannot bring themselves to stop redesigning and rebuilding on the next new technology or design philosophy every couple of months.
But these are completely different issues (related by psychology for sure but not by necessity)
My opinion is you should choose what you find coolest and most exciting now and then stick with it!
Of course the technology you choose should have some traction but don't choose technologies of the past! Whatever you choose will be the past soon enough and that is when you must find the strength to stick with it and get on with creating value for users.
It requires lots of energy to see these projects through, and it's hard to emit that energy on something that you don't enjoy doing. If using a less common technology is going to get you working on the problem enough to start getting some velocity, that may well be a worthwhile tradeoff (as long as it's not too out there).
The other thing to consider is that while a basic library supplied by a young language may suit your needs when you're starting out, larger ecosystems are likely to have more advanced libraries that have better performance characteristics, support more obscure use cases, etc., which will only become more valuable as one grows.
The downside is it could backfire on who you're able to hire. It could just lure people who will either want to migrate to the next new-and-shiny or just leave quickly.
In my company, we hire middle of the pack programmers for a bargain and use commonly known tech stacks.
The customers will not know the difference.
Having done some recruiting at a startup last year, even getting the top 50% to reply to an email is a tough proposition. The problem really stems from brand awareness. No one has heard of your startup, so in a sea of "help wanted" postings on Angelist, Stack Overflow or Craigslist or cold emails, it's extremely easy to be ignored.
Using novel technology and getting the word out (as Twitter and Jet.com did), can at least get technical awareness within a motivated subset of engineers who are interested in said new stuff -- and of all skill levels.
That said, Peter Norvig made a pretty good refutation of your core point. Say your initial site was successfully launched by average engineers. If you're not always trying to hire better than the average employee at your company, your team just gets worse over time.
 - https://research.googleblog.com/2006/03/hiring-lake-wobegon-...
 -- btw, using the new-shiny stuff is not all-or-none. You can still use tried and true tech along the way.
I just don't think research done from the perspective of the biggest tech company in the world has any relevance on 99.9% of small tech startups.
Your main focus should always be to ship good user tested product, and I agree you don't have to be the best programmer to build something that users want and like.
I'd like to add: if you find the time, try to have a side-project on your own time where you apply all these cool new things you were looking to apply in your company. This will help you keep your sanity and it will let you experiment with that technology so that you can make a better informed decision on wether to implement it in your company or not.
Yeah you can make a good business. Yeah you can make a living. But you're probably not going to make a unicorn.
Most entrepreneurs are happy building a good product that helps their customers while making a good living at it.
I mean, that will probably allow you to ship a bare bones MVP pretty quickly, but making improvements to said MVP in a timely manner may be a different story.
Case in point: I used to work for a company that developed a product that was made in RoR and was probably actually pretty nice looking at one point. Unfortunately customers had ideas for what sort of improvements should be made to the MVP, and very few suggestions were turned down. So, after some time, the codebase grew pretty hellish, and it became harder to release substantial improvements in a reasonably timely manner. If I remember correctly shortly before I left they decided to replace it with something built from scratch using a leaner Ruby framework called Sinatra.
For that reason I'll typically write projects in Node or Golang, but typically Node. They're flexible, they're not a framework, they're not opinionated, but at the same time they both still have robust package ecosystems so I don't have to reinvent the wheel.
And actually, by all means use new technology if you can honestly tell yourself and your customers that it allows you to ship faster. Just remember, you writing code faster != you being able to ship faster. You'll probably have to bring on additional employees, so your choice of tech has to factor in how quickly you can hire and train someone to use your tech stack as well as how well they can reasonably perform with it. That being said, developers who like using your uncommon technology or tech stack are typically going to be a little more enthusiastic, just don't go too far.
This is the problem, not Rails. I've been using Rails for years since 2009 without any problems. I've also used PHP, Java, and Node. These projects have survived 5+ years not because of any language or framework but by treating code as a craft.
But lastly, if you pick the right technology, you might naturally get access to a pool of very high quality developers, the type who are already interested in that very technology.
I don't get the point of hiring "Java people" and whatnot, anyway. Polyglots are the way to go.
The thing that made Paul Graham a thing was his use of Lisp to edge out his competitors at the time. The fact that Viaweb was later rewritten in [whatever it was rewritten in] is irrelevant. That's my final point.
Technology is actually an advantage. I would look at it this way, if you used N tech, and it actually results in a faster, better app, meaning happier users and therefore more business.
TLDR; use technology that gives you an advantage.
Big if there...
E.g. if you make a website, it should be a unique and engaging website. But you can make a unique and engaging website with Java. Even though it's old tech, your users will not know or care.
When I read this, a voice in my head yelled PHP.
The myth that they tell themselves is that $REVOLUTIONARY_FEATURE_Y will greatly improve their productivity, but the fact of the matter is usually that no matter how revolutionary the features, it's hard to overcome the benefits that come from an active ecosystem of well-tested and widely used libraries. Even if productivity is improved 20x by the revolutionary feature, a library that has 10 man-years of effort in it will take you 6 months to implement. Rinse and repeat.
This is not to mention the availability of online references and established conventions/best practices, the impact of hitting esoteric errors, and so on.
A good example of this is probably reddit. Originally written in Lisp, they eventually gave up and compromised down to Python due to improved tooling and library availability. 
It's just really hard to beat the reliability, community, ecosystem, and features that are table stakes when using a competent web framework.
When you're poking at a new market, you really don't have time to give a shit about writing CSRF middleware. That's one less customer interview or feature request to grow your business. I'm sure you can do it, and no one's doubting your capability to do so. But these are just things that are tricky to implement and takes everyone time and effort to do so correctly.
And secondly, some of the features you list the frameworks as having are questionable at best. Rails has built-in user accounts, permissions and admin interface? Since when? And action cable is a great example of everything that's wrong with Rails - kludge together a frankenstein solution to tick a feature box. I do not know a single production user.
I think you confused the two messages of "don't build your own web framework" (I heartily agree) with your assertion that a startup in 2017 would be somehow remiss to not be using frameworks developed in the time of Windows XP, with which I do not agree.
For me the current "Rails in 2006" framework is elixir/phoenix, and for the slightly less adventurous, something in nodejs - maybe meteor or plain express. Of course Rails still works, and is not an absolutely horrible choice, but it's for last decade's web, and has profound disadvantages compared to today's technology.
However, for new business owners who don't care so much about getting an A+ for technical excellence, I would still stand by this advice. The benefits of technology maturity and ecosystem are extremely compelling.
Today, for someone who just wants to let their users log in with Facebook, Elixir has far fewer user-friendly resources and will require more technical expertise to produce the same result. How many StackOverflow questions address common woes in these popular frameworks as opposed to the up-and-comers? How easy is it to hire someone to build + maintain? What about for hiring on the cheap? What existing libraries and integrations exist?
Of course, these things get better for new technologies over time. Until then, I can't tell people to use them if it incurs a disproportionate cost to achieve the same return.
Lastly, that "it's old" is not a compelling reason to me to recommend something else. GNU/Linux was created in the 90s, and it's still everywhere and growing. There's a job for an operating system to do, and GNU/Linux solves it well enough for the amount of effort required to use it. I believe the same to be true for Django or Rails in building a fast business prototype for most enterprise or consumer use cases. I think measures of suitability for the task are more relevant than age.
For the use case you're describing, I agree completely with your comments. Perhaps a useful razor is - if you can't state specifically why you can't use rails (and don't say "it doesn't scale"!) - then use rails. I concede that 90% of the time, this is probably the case.
And yes, harping on about its age was silly of me. Age does not inherently mean anything. I'd use postgres (1984!) over mongodb anyday. And erlang is older than ruby. Right tool for the job is far more important, thanks for pulling me up on that.
All that said - I still think that categorically stating "use boring technology" or "just use rails" for absolutely any new project is harmful. New technologies are not always just about the new shiny, they can provide capabilities and functionality simply unachievable with the old. Look at what you can do with concurrency with phoenix. Look at what you can do with react native. Roundly writing off the whole idea of using this new tech as "magpie development" is just lazy.
The whole point of ActionCable was that it is being used by Basecamp: https://medium.com/@dhh/rails-5-action-cable-demo-8bba4ccfc5...
And it's particularly irrelevant if the front-end or back-end is weighted more heavily than the other in terms of product value, when you might hire distinct rather than "full stack" devs someday.
1. Your devs can always go to where the work is - if you divide FE/BE and suddenly you have a feature that needs a lot of BE dev, you can move people from the now-mostly idle FE team rather than try to hire them
2. You can share business logic between FE/BE for client-side functionality. I've seen a surprising amount of bugs that boiled down to "oh we updated code on the back end but forgot it surfaced somewhere in FE code as well and didn't update there"
Of course, YMMV and this probably highly depends on your project, architecture, quality sensitivity, etc etc. But to say sharing FE/BE languages has "no real upside" is a bit... optimistic IMO.
In practice, Point 1 isn't too realistic though:
Front-end and back-end almost always use different build/debugging tooling, different unit/integration testing frameworks, and even different paradigms. Unless your developers are good at constantly switching modes, it's hard.
"no real upside" is wrong, as you point out, but I would stand by "no guaranteed upside" :-)
But some top tips stand out for me over time:
* Talking to people, networking > Not talking to people
* Bug free > Elegant code
* UX > UI
* Simple products that do one thing well > Complex products
* Understanding entire market > understanding some people
* Building brand > Making quick money (for the long run)
* Sleep, exercise & healthy food > late night coding
* Solving your problem first > Solving the worlds problems
* Adaptability, pivoting > Ego
* Knowledge of where the money is > No knowledge of it
* Overestimating cost/expenses > Underestimating it
* Patience > No Patience
* No procrastination > Procrastination
* Reading books > Not reading books
Especially at the beginning, you read here how often big clients can put you under at the beginning because you're not ready to deal with them.
After four years in which I frequently worked in a 6h/1h work/sleep rhythm for weeks at a time, I just left town and decided to never again have any customer that I couldn't fire and forget about on the spot if I wanted.
Big clients and projects were, at least for me, a complete nightmare. Worst were the lawsuits which, even when we ultimately won, would basically ruin whole years at a time.
Now I'm working for a few thousand customers at maybe $50/year average. When some technology or idea seems interesting, I'll spend 48h straight trying to get it working. When the weather starts to get warm, I'll spend the day in the sun with a bottle of white wine and no appointments until November.
A few big jobs > many small jobs
Low-paying jobs will consume more time than you expect. Be careful when quoting these. Always charge more than you think you need to cover your time.
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
> Simple products that do one thing well > Complex products
It has been my experience that business people constantly make this mistake. They feel a product has to satisfy all needs. The engineers I have met have consistently argued to remove features that are expensive to develop and add little value.
Both of those are anecdotes. Your milage may vary.
* Doing something you're interested in > all the self-help and motivational quotes in the world
* Doing something potentially meaningful and failing > doing something you don't care about and muddling through
Listen to people, figure out what 90% is bullshit or irrelevant and what 10% is interesting business opportunity.
2009 post, but still one of my favorite distillations of the issues around b2b customer types. Particular impactful if you read it when you end up going above and beyond with support, feature development, and contract negotiations with both rabbits and whales and you're running out of money.
Sorry, what did you mean by "in 21 days route"? Also, do you have any MOOC on doing business to recommend?
> * Sleep, exercise & healthy food > late night coding
Looks like it's against other points. I have a full-time job and I'd like to create a brand, too. Thus. I have to do late night coding.
Sounds like someone doesn't have kids.
Mostly tongue in cheek, but also slightly serious. There are plenty of life circumstances that preclude all those things.
Do you work more than 40hrs a week? Why? Sounds like you're creating someone else's brand if so.
If it is, it means you're probably working too much for someone else!
This isn't exactly olympian conditioning, but I do notice a benefit and the time investment is low.
I think late-night coding is a near-constant because of our brains automatically optimize us onto what pg describes as "the Maker's Schedule". Context switching is anathema to effective coding, so people automatically go to the time when they'll be least-interrupted, which is when the rest of the world is asleep.
Any chance you could expand a bit on this one?
But trying to solve the world's problems vs. trying to solve your own is another matter. You probably better understand your own problems.
If the problem affects the whole world, including yourself, then it falls in the left bucket.
In my case that means knowing the major datapoints about competitors in my space (public vs private companies, who's making/losing money, appannie stats), knowing everything available about cost of user acquisition, and looking at psych studies on user motivations.
These are things I would have benefited from knowing on day 0 but instead only learned after building a prototype that I had to scrap.
If your business is enterprise focused rather than consumer focused, understanding one or two customers is probably good enough for a start.
This is true for many things. I'm the best developer as long as I don't compare myself to a better developer.
Some of the craziest and successful startup ideas come from people who don't understand the industry at all and if they had they probably would have never tried to do what they did.
You can't understand your customers if you don't understand their industry. Picking customers is like investing: if you pick a bunch of customers that are not going to win their industry, you won't thrive either.
Business, like developing software, is a strict discipline, and there is a vast amount of knowledge that only comes from experience.
I found myself trying to do everything, until a friend taught me a clever trick:
1) Write down all of the tasks you have to do on a daily, weekly and monthly basis.
2) Write a short paragraph for each task's job description.
3) Write a job application from yourself for each of the jobs.
4) Contemplate why on earth you would ever hire _you_ for the job!
My advice is to work out exactly what tasks there are in running your business that you are not an expert at, such as accounting, sales and marketing, copy writing, etc. and hire people to do those parts for you. You'll see a return in no time... unless you don't... in which case your business model would never work.
On GoodReads: http://www.goodreads.com/book/show/81948.The_E_Myth_Revisite...
On Amazon: https://www.amazon.com/gp/product/0887307280
Thanks for the links, I may actually get around to reading this one soon.
Scream it in a loud voice, IF YOU BUILD IT, THEY WILL NOT COME!
You are going to have to build it, find them, plead with them, fight their refusals and shove it down their throat.
There are many unknown "unicorns" that currently exist as code. The code is done, there's just no users, because the world doesn't even know it's a thing and those that do know have not being convinced that it's needed.
My opinion, my advice. Forget the code, find the customers/market first.
A software developer with complete code and no customers is just a software developer.
A business person with tons of customers and no software/product is in business.
So decide if you want to be in business or to be a software developer. I suspect that most developers just dream about business as a means of escape from their day to day reality, but secretly don't even want to be in business, they love writing code more than being in business.
And I often think there are too many people going around spouting wisdom for example about how you _must_ let customers and market demand drive your product design before writing a line of code. It's actually not true. There's plenty of good businesses which are built upon a fairly deep technical idea, which must have required a lot of development work in isolation before it saw the light of day.
...but I agree it's also a trap leading the death of many unknown unicorns.
It still hasn't shipped and that was 5 years ago.
These people are usually imposters who are asking for things that are totally unrealistic or generating interest for a concept that doesn't make any sense from a technical perspective. They have an idea and assume it can be done.
It's sort of like saying "Let's build a perpetual motion machine." Everyone is really interested in it, because it's a total fantasy. If the idea is practical, it's usually not hard to find someone who will implement it.
As a technical person, you know the limits. That means that when you go out and sell people or kick up interest, it will be for something that's at least plausible.
The frank truth is that software and technical work is relatively cheap. It cannot be the basis of your business because someone can come in and clone your product after you've done the hard work of introducing an innovative product and establishing/educating the market (I know because this happened to my business).
It doesn't matter if the clone is way worse than your product, because people are only looking at the very high level. If the clone can provide the basic functionality 20% of the time as opposed to your 99% of the time, if combined with substantive marketing, that's more than enough to win. Anyone who has done any amount of product research knows that the good products are almost never the most common ones.
Your brand, reputation, and intellectual property are 100x more valuable than any software or technical feat. Consider that Google and Facebook could lock 4 engineers in a closet for a year and come out with almost any software they wanted for around $1 million.
Ask yourself why, then, they pay $1B+ for companies like Whatsapp and Instagram. It's certainly not because it's too complex to figure out photo sharing or text messaging. They want the brand and the users that come with it, and it's that simple. The one thing that is most expensive in business is user attention and loyalty.
There are many apps that dominated app stores and were probably hopeful that they would be bought by Google/Apple and achieve fame and fortune, only to find that in the next iteration of the OS, they had been "NetScaped"; their core functionality baked into the OS either as an extension of an existing app (many souped-up camera and photo effects apps) or as a new bundled app (e.g., Keep).
The most important thing for tech entrepreneurs to understand is that while the technology is important and can give an edge, it is not the main value in your business. The main value will always be the brand and the users that come with it (and, as intimated above, beware of platform vendors, because they will always have the option to divert most of your user base to a first-party clone). Technology is comparatively cheap.
Going out on a limb here, but I've been searching for a way to define this for a while, but... maybe those aren't tech companies? I'm talking about companies like Snapchat or Uber or AirBnB which, while they do exist as smarphone apps and lean heavily on the Internet, which unarguably involves a lot of technology, but they're brands, and not tech companies. Nothing wrong with that, but there are "tech" companies where the tech is the value... there are just a lot of non-tech "tech" companies, a majority of them B2C.
Companies that are doing things that humanity previously hadn't done are tech companies. Intel, as an early semiconductor company is, at least originally, a tech company. SpaceX's technology is the company. Regardless of who ends up winning, self-driving cars are going derive a lot of value from their technology in the form of patents.
In principle, the same concept applies, it's just that it's too expensive for new entrants to come in to those industries, so they mostly don't have to worry about it. It should also be noted that businesses in other industries often attempt to install similar barriers to entry for themselves; suppressing competition is a huge part of remaining the big dog.
I hate to say it, but "tech companies" are "patent companies". If you have a patent on the technology and someone decides that it's not worthwhile to try to work around it, they'll license the patent, or maybe even buy your company if your patent portfolio is strong enough. In terms of an unpatented innovation by itself or actual software, it's not worth much on its own.
1. why will those customers wait for your software?
2. what if you delay launching your software?
3. As a software dev, I've noticed that 90% of the product is built in 10% of the time. However, it's the final 10% that make/break it - how do you account for that (as you have already promised your future customers a product that you have yet to build) ?
Customers will wait for your software because their problems are not being addressed in the marketplace.
The consequences of launch delay are that you erode your credibility and allow opportunities for competitors.
You will want customers to start that will work with you closely so that as you continuously deploy your always-working solution, they see benefit with every release. The second highest compliment you can get is "Your product just gets better and better". The highest complement you can get is payment.
1) Build an MVP, and get it to beta.
2) _Then_ get customers to try it out (give them an incentive, such as giving it to them for free). This works well with individuals, or small businesses. Larger company's won't give you the time of day, and you probably want to wait until you have some sort of following before you approach them; or you'll get squashed.
3) Get feedback.
4) Repeat steps 2/3 until your out of beta.
Some primitive folks think computers are magic, but it is human sacrifice that makes their religion work at all.
Better advice is to work on them in parallel.
Everyone thinks that when they announce their product is released that they'll have hundreds of signups the minute you launch.
What really happens is no one notices or cares.
You have to put on your sales hat before you launch.
You need to get your company to 10k USD monthly product revenue within three months. If you can't, either the product, target market or team needs to be revised drastically.
It's hard advice to follow, but it will save you a lot of time because you can't wait months and years doing unessential tweaks to the product and marketing, hoping that sales miraculously grow.
It's also useful as a pricing yardstick early on. If you have very few customers, they need to be paying enough that you reach $10k almost immediately. If your product isn't worth that much, then you need to scale out. It's best to figure this out right from the start.
If it feels like you can't do $10k MRR in three months on your own, then you need to find a cofounder who can do it together with you... So it's a good way to calibrate cofounder expectations as well.
I think that for most people, if they abandon anything that's not already a huge success three months in, they'll just end up bouncing from one thing to the next and never seeing anything through. It's virtually impossible to bootstrap that quickly, and I'd be surprised if many of the big VC-backed startups we've heard of hit that either (certainly not Google or Facebook who weren't even monetizing yet at that point).
Of course there are scenarios where $10K MRR is possible quickly, but there's no way that is what most successful software businesses look like in 3 months.
It's really a way to frame the product launch by forcing you to ask hard questions about what you're doing. If you don't even see a way for the product to reach $10k/month with a short-term plan, maybe it's a side project rather than a startup? Or maybe the product niche is too vague or unprofitable, and you need to work on that first?
I'm still a crap entrepreneur, but I've become slightly better at teaming up with people who can make it happen.
If it's a side project, that's a different game. A side project doesn't need traction to be successful for its creator.
I don't know how much Atlassian made in its first three months, but they are one of the only bootstrapped tech companies to go public in the last 2 decades. It took them 15 years. While this is not necessarily the fastest path to success, I 100% believe it deserves immense respect. They're one of the biggest success stories in tech as far as I'm concerned.
(Of note, Atlassian has mainly focused on enterprise markets)
To answer your question: The day all your other investment dries up in the worst case. If you have no job or savings you can probably live 3 months on things like your credit cards and not paying the landlord - after those 3 months you better have enough income to start paying your personal debt. That is you need to send the landlord a check for at least 1.5 months rent and with a promise to pay the rest off soon. Likewise you need to be able to buy your groceries with cash and pay down the credit card dept you ran up. It should go without saying that in those 3 months your personal bills should be just enough to stay alive.
Note that the above is the worse case. If you are in month two of the above situation and realize that you won't make the $10kMMR number you should cut your losses, declare bankruptcy and find a day job.
You probably have some savings to live off of though. This means that you have some flexibility. If you are in month 2 and realize you won't make the 10kMMM you can decide if you cut your losses now or not. You have an idea of what your overhead is, who your real competition is and what your leads are (and thus likely future MMR - though don't get over optimistic), if you think things will get better continue, if not cut your losses: you can probably sell to a competitor for a small price and make everyone happy.
If you have investors who are any good at all they have considered your business plan. Sometimes they will insist on the 10kMMR or they will exit, other times they will agree to fund a plan that won't make money for months - but the plan covers that and you have enough income from the investors to live.
There are always other considerations to. 10kMMR is a good number, but you have to figure out how it applies. If your target market is snow plows you should expect your entire income to come during the 3 winter months, and 0 the rest of the year. Thus in winter your MMR needs to be at least 40kMMR, and you need a savings plan of some sort to get through summer.
Don't forget that you can sometimes moonlight. Maybe your ideal is only worth $2kMMR. If you can support this business working only 8 hours a month you keep (or find) a day job for most of your income. That extra 8 hours a month works out to $100/hour after overhead. This again changes the calculations.
You probably need to add how much you can spend on customers acquisition to your equation.
2) Banks will loan you money when you don't need it and won't loan money when you do need it. Apply for a loan or line of credit when you're flush with cash in case of a rainy day.
3) Running a business is a different skill than developing software. Be prepared to learn a lot of new skills.
4) Don't hire too quickly. Payroll + benefits can eat through profits like crazy in a software business. The counter-point is that a good salesperson will bring in far more revenue than they cost in salary and commission.
5) Know your numbers. You should have good accounting records and know from week to week if you are on track or slipping.
6) Don't hire a 'marketing' firm. They will charge 10's of thousands of dollars to ask you questions like 'What do you think we should do?' and then feed it back to you. If the product is positioned well with customers, you know more than the marketing company ever will.
7) Don't let a single customer account for more than 10% of your revenue. If that customer leaves, you'll be in a painful situation. It's difficult to do this at first but it keeps you from chasing a big fish to the detriment of the rest of your business.
8) A good reputation and word-of-mouth is better than buying the #1 spot on Adwords.
9) Figure out how to sell again and again to the same customers. A one time sale makes means a high cost of customer acquisition. Once the customer likes your company you should see what complimentary products and services you can sell too.
10) Once you've had a taste of the freedom (and stress) of working for yourself, it will be very difficult to go back to a regular job and work for anyone else.
Prototypes. Powerpoints. Smoke and mirrors. Demos.
Don't build a thing until you have a buyer. A buyer usually is equally happy buying software or watching a powerpoint and buying software that will be delivered in a few months.
Having a customer who has money waiting makes all the other things simpler. Need to rent an office? Tell them you have customers but no money at the moment. They'll figure out a way to get you into that office. Etc.etc.etc.
1) Customers don't care about the technologies you're using, the elegance of your XYZ algorithm, or the novelty of feature ABC. What they care about is solving some problem they have, making their day easier, becoming more productive, etc. When you're pitching your product, talk about how it helps the customer, not about how it's built. A great 5-minute video on this is "Understanding the Job" by Clayton Christensen: https://www.youtube.com/watch?v=f84LymEs67Y
2) Think about monetization early on. Like most engineers, I had dozens of side project and business ideas. For each idea, I had thought about the features I'd build and how I'd build them, but not the business viability: who would I sell to? What would the pricing model be? How much money would that translate to for a typical user? Would users have the work/personal budgets to pay what I wanted to charge? Was the price enough to cover marketing and user acquisition costs? I haven't read it, but have heard that a great book on this topic is Monetizing Innovation (https://www.amazon.com/dp/B01F4DYY1I). Another good book to think about business models is The Art of Profitability (https://www.amazon.com/dp/B000FA5TTM, brief notes: https://codingvc.com/the-art-of-profitability)
3) Finally, think about marketing and customer acquisition in parallel with product. After almost 5 years as a VC, I can readily confirm that most products don't sell themselves. Even the really good products need sales, marketing, etc. A great book to get started on marketing is Traction by Gabriel Weinberg (of DuckDuckGo) and Justin Mares (https://www.amazon.com/gp/aw/d/B00TY3ZOMS/)
- Shoot for between 3 and 10 clients. Any less and you'll be very stressed about losing a client. Any more and you'll be overwhelmed with juggling too many balls.
- Fire bad clients. They aren't worth the stress, frustration, and opportunity cost.
- Work on your process. Doing an hour of client works earns you one hour of revenue. Improving your agency processes can earn you a large multiple of that.
- Don't be a <insert software technology> shop. Be a solver of a specific business problem for a specific type of business. Example: "We streamline backend processes for multi-million dollar trucking companies." The most valuable contracts are for solving expensive problems.
Totally agree in principle, but I've found it's very hard to do this in practice.
Unless you have a priori knowledge of an industry, before your first consulting gig in it, it's hard to just step into a business domain and know what specific problems an industry has that can be improved with better software and which of those specific problems are generic enough to be shared by many companies in that industry – while not being served "well enough" by an existing product. And you have to figure out if it's a niche that's big enough to support a company, while balancing other desires, e.g., not spending weeks traveling around the country to sell and work with companies in this sector.
I'm not saying it can't be done. It can, obviously; there are companies doing it. But it's not easy to just go do it. From my limited exposure to consultancies taking this approach, many kind of kept their eyes open and fell sideways into it, i.e., they worked with one client in a sector and realized the client's competitors had similar problems.
This book really helped me overcome many those issues:
- Aquire Clients
- Do client work
- Manage projects
- Bill clients
- Do pricing/timeline and estimates
- Hire employees or freelancers
Within each of these high level tasks are numerous subtasks.
You do not want to re-invent how you do those things each time you need to do them. You want a tried a true process that you keep evolving and improving based on a historical success and experimentation. This will allow you to scale and handle larger and larger projects. It will also allow you to onboard new team members quickly and when they leave, the things they learned won't leave with them because you'll have documented the learnings.
This is the book that inspired this line of thinking in me.
I think he means what this person said: https://news.ycombinator.com/item?id=14147079
* Execution>Idea. Don't work on multiple projects till at least one is shipped.
* Pairing up with other like minded folks is better than going solo, but only if you can get along really well.
* The highs are higher, and the lows are lower.
* Develop good habits
* Make your first project a small one
* Failure (at least small ones) is not a problem. Failing to recover is.
* Sales and Marketing are very important. They need as much time as working on your products/ideas
* Start now, you'll never feel ready
This is the tl;dr version of a longer blog post I wrote about my personal experience http://www.dotnetsurfers.com/blog/2016/03/29/lessons-learned...
Build something, get it in front of customers as quickly as you can and get them to pay you. You'll likely need to do this multiple times to get the right product or features that people actually want and will pay money for. Skip anything nonessential at the start. Focus on the key features that customers will pay for. It will feel broken, but it's only broken if you can't get any customers. This seems like obvious advice, but you're a developer, it will be difficult for you not to aim for perfect before you ship.
Know going in that you will probably be embarrassed by your codebase, but it doesn't matter. When you find the right product formula and need to scale, you'll probably need to refactor or rewrite large parts of it anyway. Even if you build it "perfectly".
Whatever you do, don't use this time as an opportunity to learn some new language or framework. Use whatever you are most efficient with - now is not the time to be learning React/Vue/Angular or whatever else you've been wanting to get stuck into recently. If you can build it faster with mostly server-side views, then do that. Don't stress about picking a language or framework based on future problems like how you'll hire a team - worry about getting that far first. If you're a pro with PHP, use PHP - don't worry about others thinking you're less of a developer because you're not using Go or whatever the flavor of the month is.
Oh and keep it cheap and lean. Don't go building out a huge microservices infrastructure that you may never need. Build a simple monolithic app first and host it on a dirt cheap VPS. Once you get traction you can start splitting it out and worry about scaling individual services.
I've written a little more about this on Medium - https://hackernoon.com/shit-startups-do-episode-1-cbfa73f9c2...
I've managed at least one developer who was a genius at bug finding and fixing but who was completely lost when given a "green field" part of a the product to work on. I found this out when I "rewarded" him by giving him a "green field" to work on....
Your first MVP is simply a static website describing problem, solution and signup, with Google Adwords and analytics.
* Given that your target market are going to be ideally using Google to search their problem or solution, with Adwords, you can test exactly what they are actually searching for when they are looking for your product.
* Analytics will be powerful to measure the engagement of the user to your desired product. Have buttons or measure scroll for engagement. Do they read your problem and leave? Obviously not relevant. Do they continue onto your solution but leave? Wrong market-product fit. Have options on the website for easy A/B testing to figure out your demographic.
* Static website is super easy to change and make pretty as so many templates out there, and even if you don't use A/B testing tools, you note when you make changes, so you can compare sets of user analytics data.
This approach was popularised by lean startup methodologies, but what I love about it is it takes a couple of hours to setup, and an hour each week to tweak and monitor, and you'll know early on whether it's worth even developing the software from the very beginning. The saved time is worth the adwords cost (you can set a budget per day on their dashboard) and cost of static website hosting.
1. Your idea and your software will probably not be aligned to your market needs at first;
2. Go out and talk to your customers;
3. Do not just focus on code;
4. When your customer really needs something that is not in your software, do not hesitate to bill this customer for special developments: it will finance the feature for all your customers and keep your feet on the ground;
5. CIO are overstretched by sales rep, so B2B sales cycles can be really long (at least in France).
Disclaimer: CEO of a French Cybersecurity software company.
French market is known to prefer service over software and "On Premise software" over "SaaS". As a result, we switched from SaaS mode to On Premise, and we started with Penetration Testing to join the end of the month.
While my advices might not be the best, we are in our third year of business and should finally reach profitability :)
Let me elaborate on that a bit. Seeking more and more knowledge and wisdom in an effort to learn some kind of system or trodden path to success is understandable but can quickly consume all of your time & energy and likely won't provide much real value over the long term. Nothing, and I mean absolutely nothing, beats jumping in, doing stuff, being objective and introspective enough to identify what works and what doesn't, and iterating. What people are doing now will change. What people are using to do those things will change. What won't change, though, is the value of being able to take action and move through that world with confidence and resilience.
Reading, research, and listening to people is good but you should trust the laboratory of action above all else, especially over other people's opinions. Why, if you're a normal, intelligent, rational human being, would you ever put the opinion of some arbitrary person above what you can observe yourself? Because it's on the web or in a book? That's silly. Be extremely selective in who you allow to be your advisors - you wouldn't indiscriminately sleep with just anyone at the drop of a hat, would you? Don't just take advice from everyone, either.
Don't let people pigeonhole you, don't let people project their ideas onto your passion, and learn to identify where you should spend your precious time & attention - most of the time, you should spend those on action, not navel gazing and not "preparation" for action.
There are maybe a handful of books and blog posts that are really worthwhile. Once you have read those, everything else is simply other people regurgitating what they have read and is therefore not very useful. Also, on points that are very crucial, like legal and financial matters, I would hope you have an attorney and accountant to help you make those decisions - don't try to learn everything yourself and carefully establish and nurture your inner circle so that you can focus on - you guessed it - action.
Can you recommend one or two favorites?
Overall, the number one most valuable skill in my opinion, and the one that I keep coming back to over the years is critical thinking. For that, I love Understanding Arguments, the Philosopher's Toolkit & Ethics Toolkit by Baggini & Fosl, and anything "legal", which sharpens your critical thinking, like Farnsworth's Legal Analyst or even Intro to American Law on Coursera. But those three books on basic reasoning will serve you well for the rest of your life as a business and technical leader.
2) Pick an idea that you would pay to use (product champion). If you are not the target market, you need to find a product champion who will join your team prior to the MVP creation.
3) Do things that don't scale. don't future proof your MVP, just make it so you can validate that your product has a market beyond your product champion.
4) Create a website for your MVP and make sure you can run it at low/now cost for at least 6 months before you decide to abandon. Marketing is hard and product discovery might be the biggest challenge you face. As long as you have more customers every month you are doing ok.
5) Even if you give your product away for free during MVP/beta, figure out some way that customers who want to pay you can. This is very valuable for determining product fit. if nobody wants to pay, figure out what would make them decide to, and use that for determining how to pivot.
source: myself, I made/make phantomjscloud.com
. The Mom Test - good and bad questions for customer discovery
. Competing Against Luck - introduces the concept of "jobs to be done" - people are hiring your product for a specific job they need to get done
I made this mistake in 2012 thinking that my product would no longer be wanted by 2016 and so didn't invest in expanding sales. 2017 has arrived and our sales are at an all time high and I have no idea when the market will start to decline. I lost a huge amount of money getting this wrong.
In my defence eveyone else in our industry thought the same thing and made the same mistake.
Another surprising reason is the OEM manufacturer of the instrument (hitachi) basically over engineered the machines and built a tank. The machines just keep running and running.
Keep it cheap and keep it good.
1) It takes longer than you think/imagine
2) Start smaller, no smaller still
3) Self fund for as long as possible
4) Be positive, stay positive
5) Identify people you can talk to about your work
6) Be honest with yourself, hard/brutal honesty
The product is not as cool as you think.
Cash flow is king.
Interest does not mean shit, turnover is the only important indicator. The difference to gt somebody to go from excited to hand over money is day and night.
Nobody cares about how cool the code is. Nobody cares about how pretty the application is. Those are side issues, does it solve a problem that people are willing to pay to get solved. Excel solves many problems and people are already paying for it.
Your application/idea is not as unique as you think it is.
Disruption and innovation are words that have little meaning these days, most of the time one is trying to improve a process or business, that does not equate disruption/innovation only improvement. Improvement is a good thing.
There are going to be hard days, acknowledge those. Know that everyone who is trying it on their own has those days. Most people don't show them to the outside world it does not mean they don't have them.
Thus technical debt, scalability etc. simply don't matter until you iterate your way to solving a problem other people care about. That's much better than solving a problem well, a problem that not enough people have.
Ie. in short, stop engineering software and start figuring out what people actually need. Not just 'nice to have', but a real need that causes real pain. To see if enough people need what you are planning to build - you don't need to built at all, just draw it out, explain it in a doc, and go ask people. You have to really ask them and push beyond their initial "sure yeah, it'd be nice to have". Ask them how they do the task / fulfill the need now. Ask them how much that costs. How much would they pay if you built a better one, etc. Really try to get a "no i don't actually need it" instead of being content with the polite lie of people wanting the product.
The other advice that has been invaluable to me is NEVER EVER reveal your salary to recruiters. Always state what you want to be paid and go from there. When you reveal what you are earning, you are immediately weakening your negotiating position. This may seem obvious but it would surprise you how many people just go along with their very invasive questioning.
If OP is considering a move to contract software development work, your advice could be relevant to OP not offering his/her hourly contract rate to third party recruiters who ask for it, but most independent contractors have an hourly rate because they know the market for their skills.
Best advice is do it early, use your usual job sites (Monster etc.). Resources will depend on your country but the only real administrative hurdle is insurance and taxes so you will need to look up what your country's business rules are. Most people tend to set up as a small limited company or something of that nature and then get the necessary insurance and taxes once you actually land your first contract.
A developer with marketing skills can build products and achieve revenues far in excess of their skill set.
It's co-written by the DuckDuckGo founder, and as an engineer who is thoroughly tired of marketing "hackers" who justify expensive campaigns with hand-wavy nonsense, this book changed the way I view marketing in general.
How do you feel?
Definitely worth buying even for the first two chapters.
If you want a TL;DR:
I've seen what happens when you keep the product secret, trying to perfect it before you show it to the world. You'll run out of money making a pretty baby that no one wants.
* Look after yourself. The body supports the mind and vice versa. Neglecting one is neglecting both.
* Create a distraction-free environment. Co-working space, public library, converted garage/shed, quiet cafe. Only work from home if it is truly free of distractions & interruptions.
* You can't be an expert in everything. Focus on the value creating activities.
* Serve people, not problems.
* Solve problems, not people.
I wish I knew that I could start saving and investing the money I was already earning — and retire while still young. Your odds of success as an entrepreneur are basically zero. (I know some of you are going to do the startup or nights/weekends project anyway and I wish you the best of luck.)
If I knew this I could probably have shaved years off of my FI date.
You won't get anywhere solving any problem.
Find a niche for what you can offer, and only go forwards once you've saturated that niche. For example, find a specific line of business that you're passionate about and approach them. Get a name for yourself and excel.
Learn how to do sales end-to-end.
How to listen to a customer and understand their needs, how to market to those needs, how to convert those leads into contracts, how to bill those customers, how to make them feel valued and show value to them, how to upsell when the contract expires (how to get more value from them).
Learn sales. Mostly because it helps you understand the whole of a business, and will guide any prioritisation of your engineering like nothing else.
It turns out, you really don't need to build a great thing, you just need customers who pay.
When I came to the Bay Area I knew I wanted to be entrepreneur but I also knew I had a lot of gaps in my understanding. The two big ones were sales and marketing, and the other end production and release. I took positions at established companies (Intel and Sun) to learn what these functions do in "real" companies. I then joined as an early employee a start-up, and learned everything I could about funding and equity and the unique environment of small groups tackling big problems. Then did it again and got to learn about the whole acquisition process, the challenges of taking things public (or not), and learned I still had a huge gap in what MBAs called the 'business model.' I went to work at a company that had an excellent leader and business model at the time (NetApp) and started internalizing what adds value, what doesn't, and what is and what isn't a reasonable way to look at things.
If I had to do it again, I would probably have gotten an MBA while I was at Sun (my second job). While there is a lot to dislike about 'MBA culture' that would have been a faster way to accumulate an understanding of how to evaluate a business to see where it could be improved.
- Some of that quick & dirty temporary code would be used for the next 18-19 years.
- I might as well have used PHP instead of Perl. Same (bad, messy) code quality, but even faster development and much easier hiring.
- Costly hardware early on was a waste of money (we outgrew it so fast that a beefy desktop PC would have been a saner investment at that point).
- Managing people is the one thing that you can't "fix" permanently. It's always an uphill battle unless (presumably) you're naturally talented/charismatic/psychopathic.
- don't bother with marketing people, advisors, business consultants early on and don't create product dependencies (e.g. by building a specific version of your product for others). It's not worth it until your product is polished and proven.
- Don't hire people carelessly because you don't want to invest precious time. Don't hire friends/acquaintances unless you've seen them working. Firing people is one of the most difficult tasks.
- Bad things will happen. Don't spend too much time trying to prevent them, or worrying to much. Just make sure you know what your options are when you need to put out fires and manage basic info (don't go searching for your hosting provider's phone number when you need it).
4 years later, happy to report that I have a successful startup.
Disclaimer: in my experience small privately held companies do pay consistently and on time. Other kinds of customer, not so much..
> Startups don't create new technology, they create new technology-dependent business models.
I wouldn't say this is 100% true, but it is probably 95% true.
My one thing: The software business changes faster than you think, especially when you're young and your frame of reference regarding time is so short. Just when you think you're hitting your stride and the business is cruising, that is when you should be working on your next big thing. If you don't, you're going to find yourself "out of the game" pretty quickly.
If I were to do it again I would focus on the creating a solution to the smallest subset of the problem I am solving and trying to sell that. Program that one feature and do not start on the next feature until you have a paying customer for the first one.
- Be organized! Many developers have messy desks, cluttered folder structures, and no task lists. Taking time to organize and get a good practice of listing out tasks, place items in correct order, and knowing what your daily plan helps in becoming a better developer and more valuable to a business.
- Tooling! Get useful programs, apps, and utilities to get you more productive. Good spreadsheet application, useful powerpoint templates, and documentation tools are an example of items that will go a long way in business.
The most useful piece of software that is used by almost all Software Developers around the world was created using Microsoft.NET -> That piece if software is StackOverflow.com. Microsoft .NET is not a sexy and cool tech. Solving problems is hard enough. Don't make it even harder by chosing technology you hardly know.
Having a a prospect, a channel for repeat feedback on your MVP could be a good start...and mid way through your dev..start looking to convert prospects into beta and then paying customer..
Spending 6 months just to find a customer and not touching product work isnt a great idea for me...
 Market is a group of people whom you can reach and who have a problem you could probably solve.
 Product is whatever thingamajig that solves the problem market has. Probably software, but don't force it.
Take cash over equity. Drop acid or shrooms at least once. Don't get married young.
- when venting/bitching/complaining, make that clear by saying, "Hey friend, I'm just venting here. <venting> ... </vent>"
- don't run out of money
- don't take money from anyone who can't afford to lose it
- search for ways to delegate & outsource non-essential tasks, but plan on doing them yourself, as you'll find there are somethings you can't offload no matter how much you try
- try to avoid putting yourself in a situation where your business dies if any single person dies/walks/disappears
- assume anything you say to anyone was not correctly heard, and ask them to repeat it back to you
- commit to working in 100% in person, or 100% remotely
- be prepared to have to trust others, and adjust your expectations accordingly
> Willingness to pay
Most people see it "charge as much people pay"
But the real lesson here is a different one:
You create a value. The value - costs is profit. Someone along the chain makes this profit. Might be the people you work with, your boss, might be the person sitting at your client looking smart for buying in cheap or your client's boss. Someone does. People are ok to pay as much as long as it's less than the value provided (and comparable to the rest of the market - sidenote: specialization)
Someone makes the money. Stop charging in hours. Charge based on the value. (obviously it should be more than the hour costs otherwise dont take the project)
Apply Why? to everything.
- Why this tech?
- Why this market?
- Why this team?
- Why do I want this life, experience, challenge, team?
- Why do paying want this product?
- Why will I push through when everything is bleak?
Watch for vanity answers as mentioned by others.
1. The most important thing for developers to understand is the business goal of the software they are delivering.
2. The second most important thing for software developers to understand is how much they cost and their opportunity cost - especially if they are on staff.
To explain in more detail:
1. Software you develop professionally serves a business goal. Engineering decisions should be made in support of this goal - they are, themselves, not the primary motivating force. There are often cases where an engineering decision is a key part of the business offering - e.g., a specification, compliance with a protocol or a law or regulation, performance metric, systems compatibility - but this is still a business point. You are still building software for it to be sold. Part of understanding the business goal of the software is how the client (whether that is your employer or your actual client, if you are an independent developer or studio) actually makes money off of that software or how it fits into their business model. This means that, by and large, while executives are actually very sympathetic to engineering decision - you have to understand that a very large number of engineering decisions (possibly a majority?) are non-responsive to business concerns - i.e., they truly do not care if you go with react as opposed to angular for engineering reasons - but they do care if you tell them that there are more developers out there familiar with angular, they are easier to find and hire, the codebase is more actively maintained, it is less prone to failure, it is more likely to continue to be stable in five years, and it will not cost as much to re-factor the old parts of your production-software to this new platform as opposed to an old platform (NB: this example is made up. I have no idea if it is or is not true, with regard to react v angular). They don't care if one is shinier or newer - unless it has a material impact on the ability of software developers to perform and deliver, or it will have a material impact on the stability, security or performance of the underlying software.
2. Software developers are monstrously expensive. Mind-bogglingly so. And non-technical people have a very, very hard time understanding what you do all day. The many, many attempts to metricize software development - velocity, kanban boards, (god forbid) LoC measurements - are an attempt for non-technical people to try and match cost to output. Please understand that this is well meaning - they do respect what you do, they just do not fully understand it, which is why they have to build these elaborate systems to try and make sense of it. To express this another way - you cost money with every breath you draw, and you are fantastically expensive to keep around. A few months ago I was at a JS meetup here in NYC, where a CTO walked through how much work it took to install bower, grunt and babel into their production stack. He said it took 3-4 senior engineers three months of dedicated time to make this transition. I thought to myself, he must have made a great business case, the business managers must have understood this was necessary for the health of the product, his managers must defer to him without question, or the organization has very loose controls, or some combination of the foregoing, because that is somewhere on the order of 3.5 (persons) * 150 hours (productivity / month) * $125/hr (cost of a senior dev, fully loaded) * 3 months = ~$200,000 worth of work for changes to the stack that were purely internal. The math is crude and very back of the envelope - but consider the opportunity cost - that was senior dev time not being put into feature development, critical bug fixes, or performance optimization - it was purely back-end refactoring. Personally, I have no idea if this investment will turn out to have been worth it - I don't know enough about what it was like to write code in that org before and after these changes - I do know a tiny fraction of JS devs work in es6 - so I am skeptical of the utility of babel at this point, but that may be very shortsighted. What I can say with some certainty, however, having negotiated many, many millions of dollars worth of software development agreements, that this was a major operation, even for an 'internal' client. To put it another way, if you hired outside guns to do this same thing, double the cost. The whole point of this story is realize that, when this was all pitched to the management, who are decidedly not software developers, they had to put tremendous faith in their engineering team that this really large cost was worth it, when I'm sure there was a yard-long list of bugs, features and optimizations that were being de-priotized for this fix that the managers would never actually see, touch or interact with directly. When you are pitching engineering decisions to your clients, you have to make it very expressly clear why it matters for the business case - not just why it matters for the engineering case. You may be right and they may even understand and agree - but in the end, unless the engineering changes are going to have a business impact, it is not a good business decision to invest in them. Please understand - sustainability, security, performance and the happiness of the software development staff are important business considerations - so you can include them in your pitch. But if you just tell a manager that react fiber is better and the way of the future, and you must do a full-stack migration from your static HTML forms to react fiber and it will take 1000 hours of dev time, don't be surprised if you get the stinkeye. Tell them this is an investment in the sustainability of the product and it will mean it will work on more systems, more browsers, work better on mobile and make it easier to hire engineers? You may succeed in your pitch.
Communication, communication, communication. I'll say it again, communication.
When it gets time to hiring someone to take over the day to day handling of your clients support needs and/or sales inquiries. I suggest you get someone who is very knowledgable about your product and who is interested in converting every single lead into a sale.
This will mean the difference in your business making money or not.
I'm starting a venture and I have many vendors. I must have spoken to 50 potential vendors across many different markets and there are so many sales and support people who are utterly clueless about their company and product. Who go above and beyond telling a potential customer to pound sand. Sometimes I am speechless in the service that I have had with some companies.
In fact, a few times I've actually had to use the nuclear option, which btw I hate. I've had to find the CEO's email and contact them directly. This always made the difference in the connection.
When I have had to do this, it always it went from the support person detailing reasons why the business can't do "that" and that they supposedly pushed it up the chain or spoken with colleagues and it's just not possible to accept my request.
After emailing directly with the CEO, who then forwards the communication to a senior manager and the issue gets resolved quickly.
In fact, I have a beauty of communication which I may one day publish on Medium. Which outlines the how someone went above and beyond not to win my business. I'll be framing this email in my office for sure!
Other great examples are when I am trying to clarify a question and highlighting something in a faq or a webpage and then I get that url link right back at me with the same quote. As if they are copying and pasting me wording from a support document. Which quickly leads me to believe VA's are handling the support and they immediately lose my interest.
Finally, the best ones are when on the vendors side, the communication goes cold. That they just are not interested in getting back to you. Which I can't understand. I want to give them lots of money!
Don't be one of these companies. One lesson I have learnt in the past. Is that if someone approaches you to make money, don't immediately turn them down. Even if they can't help you right now. They may do in the future and it may be really beneficial to both parties then!
Work out simple and efficient ways for rock solid end-user experience. Anticipate lots of time spent with customers.
Help others, friends are the most valuable. Protect your plans in the early phases and be prudent with your capital, prepare for the long term. Do not be afraid in taking risks, patience will pay.
Do: Create something you would buy yourself!
Just because you are good at something doesn't mean you should be focusing on that thing and leave the rest for later.
Best advice I can think of is to not think generally about what is good strategy, or anything of that sort, but about what makes your product valuable in the lives of the people you hope to make it for.
The rest will sort itself out.
This can be any method of marketing you want, but you need it and it needs to be effective. The odds of being the exception that does not need it are low.
Unit economics: http://blog.samaltman.com/unit-economics
When you leaving the company - you and your partner/partners HAS to agree on a price.
Remember this in your paperwork (where you try to think of all kinds of breakup)
But the best article I read some time ago: he said that a man does not need to earn more than 3000 euros per month to be happy.
Starting the first company may be the most difficult thing. Once you are in the entrepreneurship loop, it must be easier to fund new businesses.
I'd like to have been exposed to Steve Blank's works, The Four Steps To The Epiphany and The Startup Owner's Manual sooner. They are BTW, both the same book and not the same book. That is, TSOM is sort of the 2nd edition of TFSTTE, so in that sense they're the same book. But while there is a lot of overlap there's also plenty of material in each book that isn't in the other. So for anybody who is interested, I'd actually encourage you to read both.
Likewise, I would have liked to have been exposed to Jeffrey Thull's selling process, "Diagnostic Business Develoopment", which is described in his book Mastering The Complex Sale, Exceptional Selling and The Prime Solution. I'm a fan of his model and while I can't claim to have empirical proof that it works yet, it feels right somehow.
I would also like to have had the chance to read How To Measure Anything by Douglas Hubbard sooner. It's not a book that's about entrepreneurship, selling, or anything of that nature, but the ideas in the book strike me as broadly applicable to many domains. To give a tl/dr; it's roughly something like "use calibrated probability assessments to generate initial estimates, build a model possibly incorporating nth order effects, and then use a monte carlo simulation to build a probability distribution using the estimates and the model". There's a little bit more to it than that, but that's the gist (as I understand it anyway).
Finally, I'd say that I'd like to have been exposed to the ideas in *The Discipline of Market Leaders" earlier. The core idea in that book is that there are different bases for competition. One (obvious) one is price, and another pretty obvious one is "technical (product) superiority". But the book makes the point that there are other, less obvious ways to compete, like "operational excellence" (basically, running leaner and managing costs/defects, etc. better than the competition) and - my favorite - "customer intimacy". The last one basically means being more knowledgeable about your customer's business, making more tailored solutions, and basically becoming more of a partner than just a vendor. That happens to align well with the whole "Diagnostic Business Development" idea that Jeff Thull pitches, so I think these ideas complement each other well.
Outside of all that, my advice, FWIW, would be to say "you can't learn and understand enough about marketing and sales". Seriously, building technology comes easily to us... doing sales and marketing does not always do so. But I firmly believe that this stuff can be learned, and I think that if you're selling something you're actually passionate about (and if it's something you built, you probably will be) then you can learn to sell it without being a "natural born salesperson". Yeah, maybe some personality types take to selling more easily than others, but I think pretty much anybody can learn to sell to some degree... and in the early days of a startup, unless you're lucky enough to partner with somebody who is a "sales guy" type already, you probably will have to do the initial selling.