Ian Landsman is Starting From Scratch, October 5, 2006:
10 Tips for Moving From Programmer to Entrepreneur
If you're in the market for a powerful and user friendly Help Desk solution, please take a look at my company's flagship product HelpSpot.
Many of the people over at BarCamp are working on/struggling with the transition from programmer to entrepreneur. While I was never a truly “hard core” programmer (meaning lock me in the basement with Mountain Dew for a week and I’ll come out with 100,000 lines of code) I did have to make this transition. Also, doing the entrepreneur thing for the last few years with HelpSpot has really given me some insights into why many people fail at this transition. So here’s a few observations:
Code is 5% of your business
One of the biggest issues I see is developers getting caught up in the code. Spending countless hours making a function perfect or building features which show off the latest technology. Now you have to write code to be in the software business. It has to be high quality code that isn’t filled with bugs or is insecure. However, the best code in the world is meaningless if nobody knows about your product. Code is meaningless if the IRS comes and throws you in jail because you didn’t do your taxes. Code is meaningless if you get sued because you didn’t bother having a software license created by a lawyer.
I see way too many entrepreneurs in the forums and blogs talking about code issues when they should be discussing and learning about the business aspects. Of course that’s harder then talking about code, but nobody ever said this would be easy!
Design is everything, relative to the competition
Your product has to be nicely designed. Standard programmer square boxes with gray backgrounds don’t cut it! Remember though that your design only needs to be nicer than the competition. So if you’re building a back office IT system there’s no need to bring your design all the way up to the level of a 37 Signals type app. Of course it’s great if you do, but the goal here is simply to make it clear for your customers that you have the nicer design when they compare your product to the competition. People DO judge books by their covers.
Get used to thinking long term
There’s nothing a programmer likes better than turning code around fast. Getting bugs in and squashing them. The problem is that most non-programming related tasks in a small ISV don’t happen quickly. You really need to think long term. Things like getting your marketing and product positioning in place can take months to years. There’s no instant gratification like you get from writing code, so you must always force yourself to think long term. Where do you want the product, marketing, and sales to be 6 months from now?
Admit that you don’t understand the end user and rectify that
There’s a good chance that the software you are writing is in a domain you are not an expert in. That’s where the opportunities are and that’s great, but you have to realize that you need to do more than just research the market. You need to understand the actual customers. Talk with them. I know you don’t want to but it’s an absolute must. Without talking to the actual end users you’ll never know what features you’re wasting your time on and which ones you don’t have that are critical.
A big mistake people make here is implementing the feature set of the competition to get started. That’s a bad move. It’s like when you copy your friends homework. You both end up with the same mistakes. By talking to the customers you can avoid the mistakes your competition has already made.
Love your customers
Many software developers come from a back office IT background. In most of the IT shops I worked in there was generally disdain for the customer (internal customers). It’s not surprising since IT is often asked to do far too much with far too little.
It’s time to put all that aside though. I see a lot of ISV’s who seem to carry this over and there’s no place in commercial software for it. The only way to be successful is to love your customers. That means meeting their needs as much as possible and going to great lengths to do so. When you can’t you need to explain why. When they choose a competitors product be respectful and remind them the visit you again if that product doesn’t end up meeting their needs. I’ve found that I’ve switched lost sales back to me simply by being nice to the customer on their way out the door.
Remember to design for ease of use. Even advanced users like easy.
Your user interface is no place for fancy technology tricks. Keep is simple. Advanced users love simple just as much as newbie’s. The most important reason to keep is simple is for your trial users. A trial user is only going to give you a few minutes of their time. If you waste it by making them figure out a complex interface you can bet they’ll be off looking for another solution.
Remember to bounce your ideas off people who aren’t working on the project
Make sure to always take time to show off your latest builds to someone who’s not very involved with the project. Fresh eyes will often find big holes in your user interface. Even if the person doesn’t know much about your domain, you’ll be surprised at how many issues they’ll point out that you’ve never seen before!
Don’t be afraid to pull things out
There’s nothing I hate more as a programmer than pulling perfectly good code out of an application. Alas, you’re going to have to do it. Through the process of developing you’re going to discover features that should never have been. Ideally you’ll find this out before actually shipping. When you find these features you need to pull them before they cause any trouble.
For example, when I was half way through developing HelpSpot I discovered that one of my features just wasn’t working. I had built this tool for importing customer information into HelpSpot. This was a bad idea because it basically turned HelpSpot into a half baked CRM. It meant my customers would have to keep HelpSpot in sync with their real CRM and generally made the UI more complicated. So I scrapped a few weeks of work and pulled it out.
It turns out to be one of the best decisions I made. Rather than the syncing I came up with the Live Lookup system which allows customers to run queries against their existing CRM from within HelpSpot. It’s turned out to be a unique feature which is used by the majority of HelpSpot installations very successfully.
Patience is a virtue
There’s invariably a lack of time to get all the things done you need to. What would normally take a day takes weeks. Try to learn patience. I’ve found that I have to actively work at this or I get frustrated that I’m not making enough progress. Avoid setting up dates and expectations with your customers when possible. Don’t promise something in a month if it might take 3. I’m still working on that one myself 
Treat it like you are learning to program all over
Remember when you first learned to program and you read every book. You bought 8 different books on that first language all of which basically said the same things but you read them all anyway because you couldn’t get enough. That’s how you have to treat the transition from programmer to entrepreneur. Read everything you can get your hands on about your target market, running a small business, marketing, general management, time management. Ideally you should read it before you even start coding. The mistakes you’ll be able to avoid by doing so are well worth the time commitment.
As always I look forward to your feedback. If you have made this transition yourself, please add your tips for others to learn from.
Discussion
Excellent post Ian -- some great advice, and everything rings true to what I've experienced as a programmer/entrepreneur.
One way I like to sum it up is that the traditional programmer focuses on the process of creating a product while the entrepreneur has to focus on how the customer will interact with the product. A lot of this ties into design, as you've mentioned. I haven't met a customer yet who cared about my development framework, design patterns, or what version XYZ I used behind the scenes -- their main concern is, "does it work for me?"
By the way, I don't think there's a programmer out there who wouldn't be more successful if they thought this way -- entrepreneur or not.
Created by Ade on 10.05.2006 11:02 pm
Ah, excellent point Ade. I agree completely that if programmers put a bit more thought into the end user that the products they produce would be superior. A lot of that has to do with their management structure as well. I think this relates a great deal to this article by Eric Sink.
http://www.ericsink.com/No_Programmers.html
Created by Ian on 10.05.2006 11:10 pm
Good stuff Ian. I think this applies to almost anyone wanting to do business. I can apply nearly every one of your ideas to a design firm producing things for clients.
The more I step into dealing with the business end of things the more I see how valuable these ideas are for all business people, if they want to succeed.
Created by Mike Rohde on 10.05.2006 11:13 pm
Thanks Mike. I hadn't thought about it in that context but I suppose you're right. I love the different perspectives having a blog brings into the conversation.
Created by Ian on 10.05.2006 11:16 pm
Great post. I especially like the 'pulling features out' part since I recently spent a whole day putting in some features, and after they were done I realized an alternative way of doing things which would make things a lot simpler, without the need for the new features. Well, next time I'm going to spec first!
Created by Ali on 10.06.2006 7:14 am
Interesting post, as I am nowadays more of an entrepreneur than a pure programmer (at heart, at least). Read up on stuff - that's good advice. Don't read just one or two books, this way you'll end up thinking "wow that author is a genious" because everything is new and you are excited to learn it. Then you find yourself locked in some (possibly very biased) authors narrow view of such a vast topic as entrepreneurship. Read a lot, and take your time doing it.
Created by Ville on 10.06.2006 7:38 am
"When you write a book, you need to have more than an interesting story.
You need to have a desire to tell the story. You need to be personally
invested in some way. If you’re going to live with something for two
years, three years, the rest of your life, you need to care about it."
–Malcolm Gladwell, author ( from A Few Thin Slices of Malcolm Gladwell)
Jim
http://www.runfatboy.net - Exercise for the rest of us.
Created by Jim Jones on 10.06.2006 3:17 pm
If you make the real transition and manage to have your business really take off you might not ever be able to get back to coding again, instead you'll be in charge of those who are code for you. Once you realize that you actually are now running a business you are halfway to the top.
Created by Richard on 10.06.2006 3:28 pm
I have an idea for a website that I think I can make some money off of, and eventually it may replace my current job. I am going to print this post off and hang it on my wall.
Thanks
Created by Joe on 10.06.2006 3:30 pm
Thanks Joe, that's really cool!
Agreed Richard, it's hard to make that jump when you've gone your entire life working for someone else.
Created by Ian on 10.06.2006 3:35 pm
That was a great article! I really appreciate it. I am a programmer attempting to turn entrepreneur with my own idea and I have actually found myself falling into some of the holes that you pointed out. Great read!
Created by Nate on 10.06.2006 3:41 pm
"Code is 5% of your business". So true!
-kak
http://www.kennedyandkate.com
Created by kennedy & kate on 10.06.2006 3:41 pm
A great read. Thanks for the advice.
Created by Kris Keen on 10.06.2006 3:44 pm
Another important thing to worry about: spelling and grammar. Like saying "to" when you mean "too. Not good.
I see way to many entrepreneurs in the forums
asked to do far too much with far to little
Created by ricket on 10.06.2006 4:06 pm
True advice for most anything actually when in a commercial based situation. I would put the number at 15%
Look at Intel chips, or books or any product. If you want money you need to also do everything to support that cash flow, and thats 85% bigger than the product itself.
However, the one point I would also point out as a coder myself. Coding isn't always about the business, its about the challenge of the code itself the puzzle of putting together a viable system of logic.
As a result many engineers or programmers do not make good business men since often times it's a different type of thinking required. Similar but different enough to matter.
Engineers are about the love of the product not the marketing...Which is why you should stress a good partnership between a technical guru and marketing whiz is really the best key to success.
Casey
http://www.personaltao.com/
Created by casey Kochmer on 10.06.2006 4:15 pm
Good post Casey. I think the number is actually variable based on the product. Some products "are" the code and in those products the code is probably 30% and other things where the code is a tiny little part. Say something like MySpace. The code is way less than 1% off that business. In some ways even the features are outside of the code.
I agree a good partnership is ideal, but that's now always available. My normal readers are mostly one man ISV's. Digg has brought over a bunch of other demographics which is interesting, but the article was really written with my traditional readers in mind.
Created by Ian on 10.06.2006 4:22 pm
I have not had the same experiences as I went from Artistic Director to entrepreneur to produce clipart products for specific niches.
I have Beta tested many programs and I can stress that UI is one of the biggest things for a customer. I just will not purchase anything that doesn't have a good UI. I do not care what it does and how well it does. If it is painful to use I just will not use it. The best systems I have seen have some flexibility in UI. Programs that have a beginners mode and an advanced mode are good. Larger programs that allow you to tweak your UI are good. Programs that have "Mode" buttons so you get a specific subset of the toolset that suits the job are good.
Most programmers consider screen space a cheap commodity. It is not for most of your customers. Art programs are only used by graphics pros. They all have huge screens. You will find many work on laptops with limited resolution. Making the buttons small but numerous in advanced mode gives the tools to the artist but allows as much "WORK SPACE" as possible. The artist needs those tools, but their work space is the canvas itself.
Talk to your customers is good. This is the first thing I do when starting a new project. They often do not know what they want, so talk to a lot of people until someone tells you what they want and then run the idea past more possible users for their reactions.
The last thing I would like to add, and this is important as it is the only other reason I will not pay money for a product. You either need a kickarse UI, or a completely new feature for me to buy your product. If creating a graphics program, you are just going to recreate a subset of Photoshops features and keep a similar UI, don't. I can buy Photoshop and it is the industry standard. Photoshops UI is the worst I have ever seen in a bitmap art program so there is room in UI. I have found that programmers, for whatever reasons, will absolutely not create an original tool that a user suggests. Programmers seldom add original tools when they have the idea themselves. Give me some tools that Photoshop does not have (and there are plenty) and your program may become a must have tool.
I used art programs as just an example. Listening to your customer and offering them something that isn't a photocopy of what they already own should get more sales in every category.
Created by polyfrolic on 10.06.2006 5:16 pm
Hi Ian
I thought about that after I posted, that most people don't have the option to form a partnership.
At the same time if you are one person doing this like yourself, or myself, you have to perform two different roles which require different styles of action. It can be very difficult to do this, and I feel this is why many fail: Due to the difficulty of constantly switching roles.
I felt it important to kinda add the more general point (which you do cover in specific examples):
Success requires a practice of balance between your business and programming styles so the two don't conflict and cause you to stumble.
Nicely Post , enjoyed it.
Casey
http://www.personaltao.com/
Created by casey Kochmer on 10.06.2006 5:35 pm
Ian,this is an excellent article to make entrepreneurs to introspect and do things right way.
Created by Santosh on 10.07.2006 7:05 am
So so true. good advise. It's something I knew already, but was not prepared to listen to my own advise! Well put togther.
I found though that when you are too involved in the detail, that its difficult to see the big picture. Therefor the transition away from being the "producer" to "creator" is for me a seemingly perpetual one.
Created by Pradesh on 10.07.2006 6:55 pm
Hi,
What are the things needed when you start up a company? Is a company Website essential? Can we start with just a handful of programmers and build up as the profits come in or is it better to start big?
I would love some thoughts on these questions.
Created by Bikash on 10.10.2006 5:16 am
Very nice article 
Keep up the good work
Created by Sanjay Kattimani on 10.10.2006 6:28 am
In addition, one must has the right determination - determination to do bussiness and be an entrepreneur, not determination to code.
Created by Susy on 10.10.2006 6:58 am
I see many of you are coming in from some type of email newsletter. I'm curious as to which newsletter this is, if someone could post a link that would be great!
Created by Ian on 10.10.2006 8:36 am
I got this link in the "CodeProject Insider" (http://www.codeproject.com).
Created by Crum on 10.10.2006 9:27 am
Nice article. It might be from CodeProject's http://www.codeproject.com Insider daily newsletter. If you haven't been there it is an amazing developers website.
Jeremy
Created by Fuzzychaos on 10.10.2006 9:30 am
Ah, thanks guys it must be http://www.codeproject.com. I'll definitely have to check them out.
Created by Ian on 10.10.2006 9:34 am
Hello, with regards to hiring a lawyer
to create a sound license, what if you
can't afford this, (i.e. your business is a one or two man operation)?
I assume it would be very expensive.
Created by Ian W on 10.10.2006 9:40 am
Well Ian W my business is a one man operation for the most part. I don't really think it's an optional step. My recommendation is to save up enough to do it right. It's really not that expensive, it cost me about $2500 but that's here in NY. If you live in another part of the country you can probably have it done for even less.
I know some people use free ones that are available, but those aren't going to fit your exact software. I think it's best to have a license which is exactly matched to your software. If you're serious about being in business this is simply one of the costs you have to absorb.
Created by Ian on 10.10.2006 9:46 am
$2500 is not too bad actually. Thanks,
I've bookmarked your blog. Always good
to see another Ian out in the wild
Created by Ian W on 10.10.2006 10:17 am
Great article very inspiring.
Created by Ray on 10.10.2006 10:28 am
Ian,
Great post.. It's always refreshing to hear developers be honest about how there is a lot more at stake in managing a business than just the code you produce. We're building products for real people... not machines that need hand holding.
You might consider joining the Dialogue-Driven Development project..
Created by Robby Russell on 10.10.2006 12:42 pm
"Even advanced users like easy."
Very well said. I've been trying to find an easy way to say this for years now.
Created by Mr Analogy on 10.10.2006 7:34 pm
"Well said Ian"
Well I am fresh graduate working in a small ISV . I am bit confused after reading this article, whether to focus on programming or also on other non-coding part as you mentioned. i.e. i mean is it the right time to think of entrepreneurship or just concentrate on developing programming skills ?
Created by Nagaraj.G.T. on 10.11.2006 2:11 am
My experience at Nevant (http://www.nevant.com) is:
10-20% code
10-20% to 50-60% product (code + marketing materials + message)
50-60% to 70-80% defining and creating the necessary infrastructure to operate thee business.
70-80% operating the business (basically promotion, presales and sales)
Created by Lucas Rodriguez Cervera on 10.11.2006 7:07 am
Hello,
I am new Enterpreneur and all the above points are really making their sense as i mostly get cought with problems of business 
Created by Farrukh Shahzad on 10.11.2006 7:41 am
Cannot agree more, it all looks simple BEFORE you actually start working IN your business 
Created by Marcin Brzezinski on 10.11.2006 11:14 am
>Code is 5% of your business
Only if your business relies on 5% of its revenue from code.
Businesses often rely on software as a tool; accounting for example, and in that case perhaps your statement
is accurate.
If your business makes the bulk of its revenue from a software product, then it's probably a good bet that code is a hell alot more important than what you make it out to be. Sure, the worlds greatest software is useless if no-one uses it, but it is certainly won't last very long if it is given 5% of attention.
>One of the biggest issues I see is >developers getting caught up in the code.
One of the biggest issues I see is software-product managers trying to pretend like a software product is simply a collection of widgets, like a hardware circuit. If you're developer, then there are times when getting caught up in code is good, that is your job after all. Lets not try and pretend good software
can be created from vapor. I do agree that *at-times* developers are too narrowly focused (see my blog entry Mistakes we developers make 5- "Thinking too
narrow" : http://bubbler.net/5A-notes/560399/932802/).
>Design is everything, relative to the >competition ... Remember though that your >design only needs to be nicer than the >competition.
Seems like a contradiction, if the software needs to be 'nicer' than the competition, maybe a developer should get "caught up" in some UI code
>There’s nothing a programmer likes better >than turning code around fast. Getting >bugs in and squashing them.
Man you've worked with short-sighted programmers. Some developers, like me, enjoy ripping *out* code, it makes things simpler, and usually safer. Refactoring
code is a cornerstone of good software development, it is an ongoing process and leads to cleaner code in the long run.
Interesting article none-the-less, I'll forward it to my boss
Created by mario contestabile on 10.11.2006 2:29 pm
Hi Mario,
It sounds to me like you're a developer, but not an entrepreneur. Nothing wrong with that. In that case code is 80% of your time. That's not my point. It's not even my point that code should only be 5% of your effort. The point is that your success is only slightly determined by the quality of your code.
Everything else is more important in determining if your business will be successful. Great code doesn't sell software, certainly not by itself. Having a great story on how you solve your customers problem is what sells software. Having the code to back that up is of course important, but if you don't even get the potential customers in the door then everything else is moot.
Created by Ian on 10.11.2006 2:40 pm
Hi Ian,
Indeed, "having a great story on how to solve your customers problem".
A customer really doesn't give a cr*p what language was used, or how it was used.
I do think that if you are an entrepeneur, *and* the reason your customer is happy is due to software your company writes, be aware of what that implies.
A milk farmer has different concerns than an poultry farmer; each has its domain specific problems; sometimes software tends to creep up and bite you in the entrepreneurial a**.
Created by mario contestabile on 10.11.2006 2:53 pm
Ian
I couldn't resist - had to put in my two cents.
I think a top-ten item you missed (in my experience) is this: Communicate as well as you can code.
Your software interface will certainly provide a 'wow' factor (or at least an 'ok - this software doesn't look like it was written by some guy in a basement, I might buy it').
Ultimately, your knowledge of your product(s), and your communication skills, will make the difference (in sales dollars).
Therefore, be prepared to learn to communicate with (can I say it... dumb prospects). Get rid of the tech talk unless your end-user is a techie just like you (and if they are, watch out for 2 hour chats because you actually have a live one to talk to -- it can get lonely when you are on your own since you are not surrounded by fellow developers 8 hours a day like when you had your day job).
Communicate at the proper pace of your prospect (their paces will be all over the map, from 'what does right-click mean' to 'how can I edit the backend data file for my purposes').
I fear that many developers preparing to go on their own are not used to, or have no desire to communicate directly with customers (I didn't -- I just wanted to code until bedtime). They don't see the need for the communication and marketing. They may be awesome coders, and have a fantastic product, but that is rarely enough.
Along with this comes producing excellent documentation (I think you and I may have chatted about this before). I can honestly say our sales nearly doubled once we offered professional documentation (and to be honest, it still sucks). Thousands of pages of manuals just to sell a product -- yuk! However, they are sales tools that help communicate the benefits of your software, day after day, your mini-sales department, and your mini-support department as well. Like it or not, if you want to grow the business, get used to writing them now (I personally hate it, but I have people do most of it for me now).
Created by Anthony Dunleavy on 10.13.2006 11:31 pm
The 5% thing is almost right with the following assumptions:
Do no count critical programming functions such as reading blogs at work, collecting caffeinated soaps, refrobbing virtualization and system libraries, and dunning the sysadmin for quarantining some of your email.
Do not count methodology steps like design, review, caffeinating the VCS, and watching the movie clips of cool UI bits that the client sent.
Derate code done for clients you only love 7%, say; perhaps they abuse your creation in ways that can only be understood by working with the Ethiopian IME, but pay net 3 days out for each work milestone and send canneloni dishes, eclairs and spare creme fraiche visiting on tuesdaya. How else would you write off raging tangents to try and generalize to/with aramic, Hebrew and sanskrit stuff.
Do not count client washup. This is programming done in order to help explain what it is you do to satanic sprites that e-mail or IM or blaze on in the door from your client contacts; maybe a visiting nephew, maybe her mom, who knows, but they want to know exactly how you comply with DB2 best practices when you use sleepycat databases. Maybe they want all demos to yse curses libraries (more or less ASCII text.) Getting to no doesn't count, somehow.
Now, if programming (with the design bits) and sysadmining are 50% of what I paid for, we have a decent business relationship; because wild rides and meetings with (all of the) city administration are for Mr. Toad.
Created by Steve Nordquist on 10.15.2006 5:13 am
Great point Anthony. You're so right and I should have swapped that out for one of the others. I'm glad you got it into the comments, because I think it will be very helpful to others. I could not possibly agree with you more.
Created by Ian on 10.17.2006 8:50 am