
Ask HN: Best business advice for software developers - zabana
For those of you who made the jump to entrepreneurship, what is the one thing you wish you knew before starting out ?
======
mattjaynes
Since this is an audience of passionate technologists, here's the top piece of
advice I have:

 _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.

~~~
20years
This is excellent advice. There is a local company near me that has been
working on their SaaS for almost 2 years now and still yet to launch. They
started it on Angular 1 and are now re-factoring it on Angular 2 (or maybe 4
now). During this time they released a small open source Angular library but
not even an alpha release of their own product. Keep in mind their product is
not gear towards devs. They also hit every Angular conference they can and are
always doing dev meetups. That is fine for after you launch and are making $$
but seems like a lot of wasted time and money when you have yet to release a
product after 2 years.

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.

~~~
wiradikusuma
May I know what you built and they're building? Maybe different product easier
with different tech stack?

I use Scala because Google App Engine didn't support PHP for example. It's an
Android app, so I use Kotlin for that.

~~~
20years
Both SaaS apps. Different markets but one of mine is similar in complexity to
theirs. They could have launched a year ago if they were not wasting time re-
writing the app in Angular 2 & 4 and spending time open sourcing Angular
libraries.

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.

------
jargnar
It's a skill that can be learned like every other skill. You can take the "in
21 days" route or the MOOC / University course route, or constantly read
business articles, Steve Jobs videos, etc.

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

~~~
afshinmeh
Nice, but I'm not entirely sure about this one:

> * 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.

~~~
komali2
A full time job is a 9-5. Let's say you commute from 8-9 and 5-630. That means
you can gym from 645 to 8 (including travel time), eat decently, do some
coding, hit bed around 1030, and be sleeping around 11 (so you have enough
time in the morning by waking up at 7). Cook on the weekends, code on the
weekends, social life Friday and Saturday night...

Do you work more than 40hrs a week? Why? Sounds like you're creating someone
else's brand if so.

~~~
gressquel
In my country I work from 08-15, excercise 1 hour. I still have 6 hours left
for cooking food and coding before i go to sleep 22

~~~
GoodbyeEarl
Let's say you have half of this spare time to work on your side project, that
is 3 hours. Excluding weekends, how much time would it take to build a
business out of your 15-hours-per-week side project?

~~~
komali2
Well, typically building a business is a full time job. I'd recommend someone
make extra money in their spare time to facilitate a work-break rather than
trying to do two "full time" jobs at once.

------
g105b
I found out pretty soon that setting up a successful software development
business only receives 20-40% of your time developing software.

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.

~~~
napoleond
For anyone who's interested in more advice like this, your friend's trick
almost certainly originates from Michael Gerber's book _The E-Myth [Re-
visited]_. Highly recommended reading for anyone starting a small business.

On GoodReads:
[http://www.goodreads.com/book/show/81948.The_E_Myth_Revisite...](http://www.goodreads.com/book/show/81948.The_E_Myth_Revisited)

On Amazon:
[https://www.amazon.com/gp/product/0887307280](https://www.amazon.com/gp/product/0887307280)

~~~
g105b
Yes! I didn't make the connection having not read the book, but The E-Myth is
another bit of advice that the same friend is always touting.

Thanks for the links, I may actually get around to reading this one soon.

------
segmondy
If you build it, they will not come!

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.

~~~
ohstopitu
I have seen this advice throughout this thread - "first find customers, and
then build it" but I can't seem to understand the following:

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) ?

~~~
keenrodent
When people say, "first find customers, then build it", they mean find people
or businesses with problems that they will pay you to solve. With this in
mind, your questions have sensible answers:

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.

------
pavlov
The best advice I've had (and seen applied in practice) is this:

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.

~~~
the_bear
This seems _really_ aggressive, especially for bootstrapped companies. My
startup took 31 months to hit $10k MRR, and now we're at ~$130k MRR. I'm
really glad I didn't quit after three months. I barely even had the product
built after three months.

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).

~~~
matrix
I strongly agree. Let's do the math: With a brand new un-proven product with
an unproven pricing model, how many customers does it take to get to $10K MRR?
In three months, how many _qualified_ leads can you find and reach, and what
percentage of those will close? (with an unproven product in an unproven
market, 2% is probably a realistic estimate).

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.

~~~
pavlov
It's certainly not a hard goal -- I wouldn't pretend that even SaaS businesses
are all that similar. (The degree of reassessment after 3 months is up to you,
after all.)

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?

~~~
GoodbyeEarl
Have you already accomplished such a goal?

~~~
pavlov
Yes, but no thanks to myself. I wasted about a decade being a crap
entrepreneur that didn't have such goals. It was easy to rationalize spending
time on the work I liked doing under the pretense that I was improving the
product's fundamentals. In retrospect, I would have been much better off
facing my fears and doing clearly delineated 3-month efforts with revenue
targets rather than persisting with products that don't quite work.

I'm still a crap entrepreneur, but I've become slightly better at teaming up
with people who can make it happen.

~~~
GoodbyeEarl
Have you started a side project and after 3 months you were making 10k per
month?

~~~
pavlov
No, but I've been in a startup that got to $10k MRR in under three months
after launching the product... And that opened my eyes to what all the talk
about the mythical "traction" actually meant.

If it's a side project, that's a different game. A side project doesn't need
traction to be successful for its creator.

~~~
catmanjan
3 months after launch is a lot more specific, your first comment suggests 3
months after starting...

------
mmcconnell1618
1) Figure out who you are selling to and what problem you're solving for them
BEFORE you build something. It's very easy to fall into a routine of building
the best software ever while forgetting you need someone to buy it.

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.

~~~
monk_e_boy
> Figure out who you are selling to and what > problem you're solving for them
> BEFORE you build something

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.

------
lpolovets
I was a software engineer for 10 years (first 10 engs at LinkedIn -> first
10,000 at Google -> first 10 at Factual). After that I was about to start a
company but fell into venture capital instead. Here are a few things I've
learned about business from the VC side that I didn't appreciate very much
when I was an engineer:

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](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](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](https://www.amazon.com/dp/B000FA5TTM),
brief notes: [https://codingvc.com/the-art-of-
profitability](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/](https://www.amazon.com/gp/aw/d/B00TY3ZOMS/))

~~~
dkrich
I think your last link for Traction is incorrect.

~~~
lpolovets
Fixed. Thanks for letting me know!

------
lprubin
If you choose to run a software development agency:

\- 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.

~~~
akulbe
Can you elaborate on what you mean by improving your agency process?

~~~
lprubin
There are certain core things that your agency will have to do in order to
succeed. Some high level examples:

\- 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.

[https://www.amazon.com/dp/B000RO9VJK/ref=dp-kindle-
redirect?...](https://www.amazon.com/dp/B000RO9VJK/ref=dp-kindle-
redirect?_encoding=UTF8&btkr=1)

------
latishsehgal
* You get to be your own boss, but that’s not always a good thing. Because being your own boss does not mean that you are a good boss.

* 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...](http://www.dotnetsurfers.com/blog/2016/03/29/lessons-learned-and-
random-thoughts-on-bootstrapping/)

------
chuckus
We've already established that the main thing to know what makes your customer
tick so I'm surprised this isn't mentioned yet:

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.

------
joelennon
Beware the dangers of the green field. It seems to be every developer's dream
to have a green field for a project. You're there at the beginning, so you
think you can spend the time to make the correct design decisions early on to
ensure you don't end up with the kind of technical debt you've seen at the
companies you've worked for before. You'll thoroughly enjoy being a
perfectionist, refactoring your code to your own idea of code standard bliss.
Immersing yourself in code will keep you busy and make you feel like you are
doing important work. The thing is, you're probably not.

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...](https://hackernoon.com/shit-startups-do-
episode-1-cbfa73f9c25f)

~~~
arethuza
"It seems to be every developer's dream to have a green field for a project."

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....

------
altharaz
I would say: be patient and determined.

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 :)

------
cdicelico
I have been walking the line between technology (working software engineer my
whole career) and business (small business owner, technical cofounder, startup
employee several times over) my whole life and if I had one thing that I wish
I had known earlier it's this: trust yourself! Just go, learn, and repeat -
action is king.

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.

~~~
germinalphrase
"There are maybe a handful of books and blog posts that are really
worthwhile."

Can you recommend one or two favorites?

~~~
cdicelico
Sure. I like Hello, Startup by Brikman and Zero to One by Thiel and follow Y
Combinator's content on YouTube. I also love Disciplined Entrepreneurship -
the book used in MIT's Entrepreneurship 101, 102 & 103 courses. There's a
corresponding workbook, too. A lot of this stuff is subjective, though. That's
the stuff that has proven useful to me, personally, but as always, ymmv!
Anything on basic business & economics is probably enough for a smart person
with a good head on her shoulders to get going & pick up the rest on the move.

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.

------
ryanSrich
The number one thing is understanding what customers want. Every business guru
and product person in the valley will tell you to "talk to your customers".
The major exclusion there is how you talk with customers. Simply asking people
how you can improve your product or being more deliberate and saying "what do
you want? If I could add any new feature, what would it be?" is wasted time.
These questions feel normal and correct, but they'll lead you down the wrong
path. What you instead want to figure out is the contextual situation which
has lead your current customer or prospect to you. Figure out what that
customer wants out of that product _for them_. That's how you start to build
great products.

~~~
spIrr
Two books that can help understand it in more detail:

. 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

------
novaleaf
1) make an MVP. minimum viable PRODUCT (not prototype)

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

------
danieltillett
That it takes industry longer than you expected for it to move on to the next
new thing.

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.

~~~
infinite8s
Regarding your particular circumstances, is it because sequencing centers are
slow to upgrade to the newest sequencing technology (probably because the
investment in the last-generation is so large)?

~~~
danieltillett
No. It is because the next-gen sequencers just don't do what the old
sequencers (sanger) do (sequence small regions of DNA at high accuracy). The
new machines can sequence a whole genome, but if you only want to look at
small part of a genome then there is no replacement for Sanger sequencing.

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.

------
dkural
If I had to pick one piece of advice for software developers looking to jump
into entrepreneurship, it is that most companies fail because they build
something no one wants. In fact they build it really well.

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.

------
apstyx
I know you said one thing, alas here are 6 one things

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

~~~
throw20161123
Regarding (6), what were a few brutal truths you had to confront?

~~~
apstyx
Sales is tough.

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.

------
tylercubell
Coming up with the idea is easy. Sustaining the motivation to grind over long
periods of time is hard. Entrepreneurship is an internal struggle more than
anything else.

------
hd4
If you are working a day job as a programmer (while setting yourself up to go
down the startup route), go with contracting as soon as you can, the rates are
what you set them at and you should always set them high.

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.

~~~
fecak
OP is talking about a jump to entrepreneurship. Why would an entrepreneur talk
to a recruiter about their salary?

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.

~~~
hd4
>If you are working a day job as a programmer (while setting yourself up to go
down the startup route)

------
1ba9115454
Marketing.

A developer with marketing skills can build products and achieve revenues far
in excess of their skill set.

~~~
codebeaker
I can't speak highly enough about
[http://tractionbook.com/](http://tractionbook.com/) which I recently came
into - it has pragmatic advice on marketing approaches and systems justifying
with real data how and why to do what.

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.

~~~
exceptione
A lot of the reviews are positive about the first 2 chapters, but complain
that the remaining chapters lack depth. I would like to own a good marketing
book for techies written for this age, but I like to see concrete advise.

How do you feel?

~~~
rayalez
This book is great. First few chapters outline the general framework and give
you the overview of strategies("traction channels"), and the remaining
chapters just explore each strategy in more detail.

Definitely worth buying even for the first two chapters.

If you want a TL;DR:

[https://medium.com/@yegg/the-19-channels-you-can-use-to-
get-...](https://medium.com/@yegg/the-19-channels-you-can-use-to-get-
traction-93c762d19339)

------
c0achmcguirk
SHIP IT. Even when you are embarrassed about it. Ship it and try to sell your
ugly baby. If you can't sell it, ask why and iterate on that.

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.

~~~
rubenrails
I agree. I developed a Pinterest-like app around the same year they launched.
I even had a perfect domain name for it. Being a perfectionist, I never
shipped. I was worried about things like scaling to support tens of thousands
of photos, a "similar images" feature, etc. A few years after abandoning the
project I discovered Pinterest. ¯\\_(ツ)_/¯

~~~
dzonga
sad, but made me laugh

------
inopinatus
* Learn to say "no" to feature requests that don't fit.

* Look after yourself. The body supports the mind and vice versa. Neglecting one is neglecting both.

* Delegate.

* 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.

------
baccredited
I posted to my twitter/medium but will copy here:

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.

------
g105b
I assume your software development skills are second to none and you could
apply them to any problem.

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.

------
buro9
Sales.

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.

------
ChuckMcM
mattjaynes nailed it pretty much. On a slightly different spin though on the
'wish you knew vs what you know' my journey was a bit different.

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.

------
lazyjones
\- that it's all going to be worth it in the end (it would have been
comforting during those 100-hour-weeks)

\- 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).

------
maxxxxx
I made the mistake to not focus on the business first. The tech is interesting
but priority number one, two and three should be the business. Finding
customers and serving them efficiently should be the main focus. Only then
think about what tech to use.

------
davidw
There's a ton of stuff in 'Start Small, Stay Small' by Rob Walling. It's a bit
dated, but lots of great advice.

[http://amzn.to/2pRPKey](http://amzn.to/2pRPKey)

------
adeelraza
I wrote a post on this topic back in 2013. Can a software developer be a
successful entrepreneur: [http://adeelraza.co/blog/can-a-software-developer-
be-a-succe...](http://adeelraza.co/blog/can-a-software-developer-be-a-
successful-entrepreneur/)

4 years later, happy to report that I have a successful startup.

~~~
pmarreck
It's rare that I ask someone to self-promote, but what do you do? :)

~~~
adeelraza
I founded an email marketing / lead generation startup, MailMunch. We saw 1
billion unique pageviews in the last year :)

~~~
pmarreck
Awesome!

------
dboreham
If you allow it, your customers won't always pay you the money they owe.
Always assume that if you don't have the money, it may never come, and arrange
your life around that possibility.

Disclaimer: in my experience small privately held companies do pay
consistently and on time. Other kinds of customer, not so much..

~~~
antaviana
Where are your customers based? Delinquency has never been an issue for us. In
some 25 years we only had one customer not paying us an invoice of USD 1,500
over accumulated revenues of US 30 million, and it was because the customer
went bankrupt the month after the invoice (unlucky). However we noticed that
US-based customers may delay payments sometimes for months but in Europe they
tend to pay on time.

~~~
dboreham
Silicon Valley typically but also the East Coast, and also the mom and pop
individuals we used to provide internet service to locally weren't always
great at paying. Note that I don't necessarily mean customers won't pay ever
(although that's happened many times to us), but rather they will pay
randomly, not according to the agreed payment terms, treating you as a free
bank to fund their working capital needs; a way to improve their cash flow
position when they're being acquired; and on and on.

------
mindhash
Most common advice is find a customer and then build...This is like most
difficult and could turn out to be time consuming...I would twist it to
say..Find a prospect, talk to them and then build...With so many people trying
to do stuff or saying they want to..A lot of trust on whether someone will
really come back with a software is less...And being first timer very few will
pay you.... There are exceptional cases where you might find a customer..But
then it turns into a service contract than a product development..

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...

------
d_burfoot
My slogan about startups:

> 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.

~~~
farhannyc
That is debatable. If you are going from 0 to 1, a lot of times new technology
is created. It may not be something revolutionary and ubiquitous like the
internet or the wheel, but it may be some form of vertical integration, such
as Tesla Cars or the iPhone.

------
DenisM
Business is market [1] + product [2]. _Don 't start with product, start with
market._

[1] Market is a group of people whom you can reach and who have a problem you
could probably solve.

[2] Product is whatever thingamajig that solves the problem market has.
Probably software, but don't force it.

------
benmorris
I learned some lessons 5 years ago when my initial plan was to do software
development on my own after I quit my job. I have concluded a much more
fruitful way to go is to develop your own product in a niche and pursue that.
Perhaps even multiple products. There are numerous pitfalls to developing on
your own that don't have anything to do with software development. Things like
getting paid, dealing with customers, scoping projects, conducting
meetings/phone calls, providing dead end quotes, etc. When I quit my day job I
also hedged my time by building my own products, as of a year or so ago I
washed my hands of all freelance development and focus on my own products.

------
p0nce
The most important question to ask might be "Do you imagine buying this? Why
not?"

------
poirier
Know with more clarity than anyone else on Earth: Why.

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.

[edit: formatting]

------
astoilkov
You could check out Indie Hackers. It's the most amazing place for software
developers to learn from example.
[https://www.indiehackers.com](https://www.indiehackers.com)

------
brightball
For what it's worth, I wrote in a lot of detail about my experience a few
years back. Might save somebody here from learning hard lessons.

[http://www.brightball.com/articles/what-exactly-happened-
to-...](http://www.brightball.com/articles/what-exactly-happened-to-
brightball-for-hire)

[http://www.brightball.com/articles/a-study-of-pricing-and-
bi...](http://www.brightball.com/articles/a-study-of-pricing-and-billing-
models-for-the-web)

------
bpizzi
That you already know how to build a software, and what you do need to learn
is how to sell a product.

------
clubminsk
Probably, the best business advice for software developers "Solving the
problem that frustrates you - may be one of the best ways of finding an idea
for your startup". Look at these software developers who acted accordingly
before they found success. [https://belitsoft.com/php-development-
services/saas-ideas-st...](https://belitsoft.com/php-development-
services/saas-ideas-startups)

~~~
clubminsk
One more great advice: 1. validate your idea first and focus on the main
features before launching a startup. 2. find paying customers before launching
a startup [https://belitsoft.com/custom-application-development-
service...](https://belitsoft.com/custom-application-development-
services/successful-saas-startups-mvp-lean-paying-customers-first)

------
jpatte
Knowing how to sell/market your product is more important than having a fully
functional or carefully engineered product. Nobody will give you money for
your (master)piece of software if they don't know what it does or what it's
for. Sounds trivial, and yet the better you are at software development, the
harder it is to keep in mind.

Just because you are good at something doesn't mean you should be focusing on
that thing and leave the rest for later.

------
TimJYoung
It will be 20 years next year for me.

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.

------
jiahen
"TALK TO REAL CUSTOMER AS SOON AS POSSIBLE" before I started this Venture. It
seems that I have this barrier to reach out to them. For my case, it is
architecture and construction industry. With luck + lots of meetings with
people in this industry. I found my navigator of this industry, he is now my
advisor. The company is generating 6000 dollar now and 1000 dollar monthly
revenue and it is growing.

------
wj
Some industries have incredibly long sales cycles and you will use up all of
your savings and then some getting your first customers.

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.

------
wonderwonder
Understand that marketing is as important or more important than creating an
elegantly coded product. You can have the most amazing product in the world
but if no one knows about it or is sold on it, it will never go anywhere.

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.

------
lostatseajoshua
\- Speak only when you know you have something useful to offer. Speaking at
meetings just to get a word in can lead to others not paying attention over
time due to the lack of useful information that is shared. If you are 100%
sure of a subject/fact or you have a very useful thing to add to the
conversation then try to get it out in the least amount of words. Others will
build trust that anytime you speak it is useful information so they will pay
attention and listen.

\- 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.

------
franze
Not: Create something you would use yourself!

Do: Create something you would buy yourself!

------
madiathomas
I am able to deliver features and fix bugs faster when programming in C#.NET
and ASP.NET MVC. I am able to administer MS Windows Server with my eyes
closed. SQL Server too. That's why I chose MS technologies for my startup.
That's what I know best. Use technology that you know best. You wouldn't use a
language you hardly know to write a book. You wouldn't want to experience with
a second language. Why on Earth would you want to use a sexy and cool tech
that you hardly know?

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.

------
seajosh
it's worth repeating:

Take cash over equity. Drop acid or shrooms at least once. Don't get married
young.

------
amorphid
Off the top of my head:

\- 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

------
andreasklinger
Surprised nobody mentions it. The #1 rule i needed to learn:

> 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)

------
libertymcateer
I'm a software attorney - I negotiate software development, installation,
support and licensing, deals, including agile software development, SaaS,
PaaS, API agreements, SLAs - you name it. I was also in house counsel for a
group of tech startups for five years prior to my current role. Finally, I
write software, actively - these days in Node - yes, I know this is an
invitation to mockery, which I welcome. All of this is a long-winded
introduction to try to say I know a thing or two about this.

tl;dr: _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.

~~~
truetraveller
Thanks for the long post. Somewhat OT, but interesting.

------
pbiggar
The only thing that matter is validating. Don't write code if you can avoid
it, try to validate for cheaper. "Will someone use this" can be better
answered by calling them first, then build with their feedback.

------
dawie
Sell, sell, sell. Learn how to solve painful problems and sell the solution.

------
no1youknowz
Haven't seen this mentioned yet, so I thought I'd bring it up.

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!

------
gtycomb
Instead of your 7th new programming language, learn accounting, read annual
reports of corporations, write a profit and loss analysis for three years
forward (this will be vague, nevertheless spell it out the best you can) and
know worst-case scenarios.

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.

------
danm07
There is no clear cut definition of "business." You have a picture in your
head of what you want the future to look like, and "business" is all the
actions associated with making it come true, and this can vary dramatically by
sector.

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.

------
yodha77
I have felt identifying your target customer quickly is the most important
step in transitioning from developer to business. Target customer definition
should be as narrow as possible and you should be able to list them (like
atleast a hundred of them in a spread sheet with contact information). This
helps you to talk to them, validate the problem, get feedback to your solution
and sell it to them.

------
cbasoftware
Before you hire anyone make sure you just can't live without them and then
wait longer. Before you hire your first developer read the Mythical Man Month.
Yes, it's old, it still applies. And, especially today, try your best to use
contractors. And, make sure you have a Work for Hire agreement!

------
dorianm
Make something people want:
[http://paulgraham.com/good.html](http://paulgraham.com/good.html)

Unit economics: [http://blog.samaltman.com/unit-
economics](http://blog.samaltman.com/unit-economics)

------
contingencies
Even if you build something on a "build it and they will come" premise, you
are right, and there _really is_ demand, you still have to spend time and
money to use it - ie. don't forget to test, measure and allocate time and
money towards marketing channels.

------
iluvdata
Here are some thoughts for engineers to broaden their horizons -
[https://www.linkedin.com/pulse/differentiation-age-
commodity...](https://www.linkedin.com/pulse/differentiation-age-commodity-
inder-singh)

------
nsarafa
Be conscious of your core values. Let them permeate the story you tell, guide
your key performance indicators, and become the foundation for your company'
culture. When you feel your values are being violated, it may be a sign to
take a step back and reflect.

------
blunte
Learn to talk to people. This leads to networking (and intentional or
unintentional marketing). Talking to people, getting to know them, making an
effort to remember and contact them periodically... opens doors in the short
and long term.

------
nslindtner
It's no sustainable to own part of small company, you're not actively working
for !

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)

------
id122015
I did read a lot to understand business and the billions of funding that one
day must be paid back.

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.

------
paboopie
[https://webmethodologyproject.com/guide/they-hired-
captain-n...](https://webmethodologyproject.com/guide/they-hired-captain-not-
sailor/)

~~~
grzm
It would be very helpful if you included some comment on why one would choose
to follow this link.

------
corford
Relationships, networking and face to face advice matter (a lot). Put the time
in to build this up, ideally starting before you've quit your day job and
jumped in to building a business.

------
haribabug
Why not seduced by technology ? As a engineer we create new technology and try
our luck if it makes business. If we compromise on that basic fact, we end up
as that one of avg business guy

------
skdotdan
Awesome thread!

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.

------
EternalData
I wish I knew that 80% of impact really does come from about 20% of work --
and I'd have organized my work life accordingly.

------
corobo
Talk to an accountant and/or someone that knows business. You know software
but you (probably) don't know business.

------
jp_sc
Find customers first, THEN build a product

------
jv22222
\- Shift your mentality from developer to founder \- Do something every day to
maintain momentum

------
cpolis
Users care about value add, not features. Remember this when selling and
planning development!

------
panste
Make your customers happy. Learn about Marketing, it will show you how to do
that.

------
knodi
Do nothing without contracts!

------
pryelluw
_Nothing is at it seems._ Remember that above everything else.

------
spcelzrd
Not a one thing, but I would suggest reading, or at least skimming, The Ten
Day MBA. Really good overview of everything that goes into running a business.
It's dated, but mostly just in the case studies.

------
goatherders
No one cares about your code. They care what it does.

------
matt_lo
All the false positives from perceived success.

------
rongenre
Understand basic accounting. At least the difference between profit and cost
centers. Be the former.

------
mindcrime
_what is the one thing you wish you knew before starting out ?_

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.

------
nsarafa
Go at your own pace.

