48 ms·

Ask HN: Best business advice for software developers

• apstyx 10y ago
  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
  • zabana 10y ago
    Thanks for your insight !
  • deleted 10y ago
    [deleted]
  • throw20161123 10y ago
    Regarding (6), what were a few brutal truths you had to confront?
    • ar15saveslives 10y ago
      For me it was "nobody needs my app, except myself"
    • apstyx 10y ago
      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.
• TimJYoung 10y ago
  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.
• bpizzi 10y ago
  That you already know how to build a software, and what you do need to learn is how to sell a product.
• 1ba9115454 10y ago
  Marketing. A developer with marketing skills can build products and achieve revenues far in excess of their skill set.
  • jordz 10y ago
    This is excellent advice. As a startup with some extremely talented engineers we build amazing products but if no one knows about it, then you've got a bigger problem.
  • codebeaker 10y ago
    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 10y ago
      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 10y ago
        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-traction-93c762d19339 https://medium.com/@yegg/the-19-channels-you-can-use-to-get-...
• astoilkov 10y ago
  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
• g105b 10y ago
  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.
  • NKCSS 10y ago
    It's too bad I can only upvote this once, great advice and a clever way of looking at things!
    • g105b 10y ago
      Thanks! It's advice that changed the way I saw business.
  • napoleond 10y ago
    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_Revisited http://www.goodreads.com/book/show/81948.The_E_Myth_Revisite... On Amazon: https://www.amazon.com/gp/product/0887307280 https://www.amazon.com/gp/product/0887307280
    • g105b 10y ago
      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.
• nslindtner 10y ago
  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)
• altharaz 10y ago
  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 :)
• pavlov 10y ago
  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.
  • davzie 10y ago
    Really interested in hearing more about this. Do you have any examples of who is pitching this?
    • pavlov 10y ago
      Pitching? I don't know if there's really anything to pitch here. It's the kind of thing I've been told over lunch a few times, and seen happen in practice. That's all.
  • chrisco255 10y ago
    I think this is a rough rule of thumb, obviously there's nothing magical about the $10K figure, but it does get you thinking in the right direction.
  • matthewking 10y ago
    $10k MRR in 3 months seems like a lofty goal to me. Is that from product launch? or from day 0? with or without investment?
    • pavlov 10y ago
      From product launch. The point is to launch something that you can imagine selling $10k/month; that you have some kind of plan how to get to that level of sales; and that you'll hold yourself accountable after three months if it fails (and figure out what to do next, not just stick to the thing that wasn't working).
• p0nce 10y ago
  The most important question to ask might be "Do you imagine buying this? Why not?"
• spcelzrd 10y ago
  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.
• g105b 10y ago
  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.
• joelennon 10y ago
  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-cbfa73f9c25f https://hackernoon.com/shit-startups-do-episode-1-cbfa73f9c2...
  • arethuza 10y ago
    "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....
• jp_sc 10y ago
  Find customers first, THEN build a product
• jargnar 10y ago
  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
  • monk_e_boy 10y ago
    Being able to stand up in front of people and tell them something. And make them laugh. Listen to people, figure out what 90% is bullshit or irrelevant and what 10% is interesting business opportunity.
  • 19eightyfour 10y ago
    This is great, thanks! Could you do a blog post or something. :)
    • screature2 10y ago
      https://bothsidesofthetable.com/most-startups-should-be-deer-hunters-7fdecf58f4f6 https://bothsidesofthetable.com/most-startups-should-be-deer... 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.
  • petepete 10y ago
    Thanks for the list, I'll refer back to it
  • 10y ago
• mmcconnell1618 10y ago
  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 10y ago
    > 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.
  • RhodesianHunter 10y ago
• danieltillett 10y ago
  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.
  • monk_e_boy 10y ago
    Industry loves a solution that works. If your grassroots customers are happy they'll tell people. Keep it cheap and keep it good.
    • charlesdm 10y ago
      You mean, keep it good. Keeping it cheap is almost never a good idea if you are able to sell it expensively.
      • skynode 10y ago
        I'll never understand why developers almost always underprice themselves.
  • infinite8s 10y ago
    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 10y ago
      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.
• corobo 10y ago
  Talk to an accountant and/or someone that knows business. You know software but you (probably) don't know business.
• lazyjones 10y ago
  - 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).
• pryelluw 10y ago
  Nothing is at it seems. Remember that above everything else.
• ryanSrich 10y ago
  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 10y ago
    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
• dawie 10y ago
  Sell, sell, sell. Learn how to solve painful problems and sell the solution.
• hd4 10y ago
  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 10y ago
    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 10y ago
      >If you are working a day job as a programmer (while setting yourself up to go down the startup route)
  • rohitv 10y ago
    Any advice on how to transition from a day programming job to contracting? Any useful resources? Where to find contracting jobs/ through agency or directly approaching clients?
    • hd4 10y ago
      Only just noticed this, I guess if you check your comments you can pick this up at some point. 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.
• id122015 10y ago
  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.
• amorphid 10y ago
  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
• lprubin 10y ago
  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 10y ago
    Can you elaborate on what you mean by improving your agency process?
    • jrs235 10y ago
      > Can you elaborate on what you mean by improving your agency process? I think he means what this person said: https://news.ycombinator.com/item?id=14147079 https://news.ycombinator.com/item?id=14147079
    • lprubin 10y ago
      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?_encoding=UTF8&btkr=1 https://www.amazon.com/dp/B000RO9VJK/ref=dp-kindle-redirect?...
• gtycomb 10y ago
  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.
• deleted 10y ago
  [deleted]
• cdicelico 10y ago
  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 10y ago
    "There are maybe a handful of books and blog posts that are really worthwhile." Can you recommend one or two favorites?
    • 10y ago
• contingencies 10y ago
  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.
• skdotdan 10y ago
  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.
• maxxxxx 10y ago
  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.
• tylercubell 10y ago
  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.
• buro9 10y ago
  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.
• goatherders 10y ago
  No one cares about your code. They care what it does.
• segmondy 10y ago
  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.
  • educar 10y ago
    In my experience, finding customers without code works only for specific products. Best of luck trying to find customers for stripe or intercom without any code. Better advice is to work on them in parallel.
  • ohstopitu 10y ago
    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 10y ago
      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.
• dboreham 10y ago
  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 10y ago
    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 10y ago
      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.
• danm07 10y ago
  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.
• corford 10y ago
  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.
• adeelraza 10y ago
  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-successful-entrepreneur/ http://adeelraza.co/blog/can-a-software-developer-be-a-succe... 4 years later, happy to report that I have a successful startup.
  • lacampbell 10y ago
    Congrats
    • adeelraza 10y ago
      Thanks!
  • pmarreck 10y ago
    It's rare that I ask someone to self-promote, but what do you do? :)
    • adeelraza 10y ago
      I founded an email marketing / lead generation startup, MailMunch. We saw 1 billion unique pageviews in the last year :)
      • pmarreck 10y ago
        Awesome!
• latishsehgal 10y ago
  * 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-and-random-thoughts-on-bootstrapping/ http://www.dotnetsurfers.com/blog/2016/03/29/lessons-learned...
• benmorris 10y ago
  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.
• libertymcateer 10y ago
  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.
• lpolovets 10y ago
  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 10y ago
    I think your last link for Traction is incorrect.
    • lpolovets 10y ago
      Fixed. Thanks for letting me know!
• deleted 10y ago
  [deleted]
• wonderwonder 10y ago
  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.
• paboopie 10y ago
  https://webmethodologyproject.com/guide/they-hired-captain-not-sailor/ https://webmethodologyproject.com/guide/they-hired-captain-n...
  • grzm 10y ago
    It would be very helpful if you included some comment on why one would choose to follow this link.
• paboopie 10y ago
  https://webmethodologyproject.com/guide/they-hired-captain-not-sailor/ https://webmethodologyproject.com/guide/they-hired-captain-n...
• DenisM 10y ago
  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.
• iluvdata 10y ago
  Here are some thoughts for engineers to broaden their horizons - https://www.linkedin.com/pulse/differentiation-age-commodity-inder-singh https://www.linkedin.com/pulse/differentiation-age-commodity...
• lostatseajoshua 10y ago
  - 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.
• inopinatus 10y ago
  * 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.
• seajosh 10y ago
  it's worth repeating: Take cash over equity. Drop acid or shrooms at least once. Don't get married young.
• mattjaynes 10y ago
  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.
  • Kenji 10y ago
    >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. When I read this, a voice in my head yelled PHP.
    • horsecaptin 10y ago
      These days Ruby on Rails is fairly orderly as well.
      • wyc 10y ago
        Wrote about this here in an article titled Just Build it in Django or Rails: https://www.wyc.io/posts/just-build-it-in-django-or-rails/ https://www.wyc.io/posts/just-build-it-in-django-or-rails/ 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.
• c0achmcguirk 10y ago
  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 10y ago
    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 10y ago
      sad, but made me laugh
• rongenre 10y ago
  Understand basic accounting. At least the difference between profit and cost centers. Be the former.
• cpolis 10y ago
  Users care about value add, not features. Remember this when selling and planning development!
• davidw 10y ago
  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
• blunte 10y ago
  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.
• brightball 10y ago
  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-brightball-for-hire http://www.brightball.com/articles/what-exactly-happened-to-... http://www.brightball.com/articles/a-study-of-pricing-and-billing-models-for-the-web http://www.brightball.com/articles/a-study-of-pricing-and-bi...
• knodi 10y ago
  Do nothing without contracts!
• jv22222 10y ago
  - Shift your mentality from developer to founder - Do something every day to maintain momentum
• poirier 10y ago
  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]
• EternalData 10y ago
  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.
• franze 10y ago
  Not: Create something you would use yourself! Do: Create something you would buy yourself!
• novaleaf 10y ago
  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
• jpatte 10y ago
  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.
• clubminsk 10y ago
  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-startups https://belitsoft.com/php-development-services/saas-ideas-st...
  • clubminsk 10y ago
    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-services/successful-saas-startups-mvp-lean-paying-customers-first https://belitsoft.com/custom-application-development-service...
• cbasoftware 10y ago
  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!
• panste 10y ago
  Make your customers happy. Learn about Marketing, it will show you how to do that.
• baccredited 10y ago
  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.
• ChuckMcM 10y ago
  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.
• dorianm 10y ago
  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
• dkural 10y ago
  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.
• chuckus 10y ago
  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.
• haribabug 10y ago
  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
• andreasklinger 10y ago
  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)
• wj 10y ago
  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.
• matt_lo 10y ago
  All the false positives from perceived success.
• mindcrime 10y ago
  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.
• no1youknowz 10y ago
  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!
• pbiggar 10y ago
  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.
• d_burfoot 10y ago
  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 10y ago
    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.
• yodha77 10y ago
  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.
• jiahen 10y ago
  "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.
• nsarafa 10y ago
  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.
• nsarafa 10y ago
  Go at your own pace.
• madiathomas 10y ago
  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.
• beeenawhhhhhi 10y ago
  Hack into any school database and change university grades, no matter How secured - hack into credit bureau database and increase your credit score - hack any email or social network and know if your partner is cheating On you - hack into your partner's phone pics, text message and listen to calls to know if he is cheating - hack into any bank website - hack into any company website - hack into any government agency website - hack into security agency website and erase criminal records- Here; geniushack08@gmail or you can call or text (860) 272-6323.
• mindhash 10y ago
  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...