1. Code is 5% of your business: no, it isn't. If you have a watchmaking company, is making watches 5% of the business? Marketing, sales, and operations are only important as long as you have a quality product.
2. Design is everything: it can used to great advantage, but let's keep it real. There are plenty examples of successful "gray boxes" applications, don't confuse aesthetics for usability. We are here on HN, aren't we?
I think his exact number, 5%, may be a little low, but the sentiment is right. The article is addressing the change from programmer to entrepreneur, and I think it is very common for technical founders to care too much about what they are most experienced with: the code.
He even acknowledges the importance of code quality ("It has to be high quality code that isn't filled with bugs or is insecure.") but his point is that, as a first-time entrepreneur, you will be overwhelmed with the other aspects of a business that have to developed, and you will tempted to focus yourself in the area that you have specialized in for years prior. As a founder that has recently began the transition from programmer, I can certainly say there are times that I've failed at this, and I'm sure it happens a lot.
Code can be 5% of a business, while the entire software part is a much higher proportion. The software concern of a business encompasses way more than just coding: testing, environment building and maintenance, source control, backups, security, and much more. Realizing that the actual executable code is such a small part of delivering a software product is a really important step in maturing from a code-monkey programmer to a capable software engineer.
Your watchmaker analogy is actually a pretty close parallel to software. The mechanical functioning guts (executable code) of the watch, the gears and ratchets and springs and all, probably are about 5% of the business. But the entire watchmaking concern, from supply of materials to fashioning the face and wristband to final assembly and inspection, encompasses much more.
We're on the same page then: when you say code, I regard it as everything involving code, including the testing, provisioning, maintenance, versioning, security, deployment, etc, even design. The "not code" part is marketing/commercial/operations.
I believe he is warning against the Coffee Shop fallacy. IE, you may like coffee, but if you think running a coffee shop is a good way to enjoy/experience coffee, you are unlikely to be in business long.
It also seems like he's saying that "code" as an aesthetic principle is a very small part of your business. Your code is a means to an end (for your users), and does/should not hold much of your attention as an intrinsic ideal.
Excellent mention of the coffee shop fallacy. I think you nailed the point perfectly. Coffee making is only 5% of running a coffee shop. Dealing with customers (i.e. sales and marketing) is the majority of the work. People can get coffee anywhere; they go to your shop because of the perceived value of your product. Coffee (and code) becomes a commodity. While there is some really brilliant artisanal coffee (and code,) the general public doesn't usually know enough to tell the difference.
You have to keep in mind that he wrote this after a few years in business. After creating the product, programming takes up less of your time in day to day operations. HelpSpot is business software, and Ian was running it as a one man shop for a while. When you have to do the marketing, customer support, accounting, and, well, everything by yourself, it just plain takes up a lot of your day.
No pun intended but finding out how to "do the business" after I already created it doesn't really bring much value. The article itself is called "10 Tips for Moving From Programmer to Entrepreneur" (i.e. how to do it, not what to do after)
Several points are hit here (some I said in a previous comment):
- get to know the customer (build MVP ...), see what they want, make a product not a Software Design masterpiece
- prioritize correctly (and oftentimes - especially after you built the product - the biz is more valuable)
Anyway, my experience is that even if one knows this theoretically, he will get it after the practical experience. Good luck building!
I think he is referring here to setting the priorities straight: focus on growing the business and what people want/appreciate; code only the most important part (the entrepreneur himself)
Also, this reminds me of the "nail it, then scale it" approach. Don't focus on scalability when you don't have customers.
Exactly, I recently had a startup with approx 0 users try to recruit me by arguing that building the web app was "programming 101... we need someone who can architect for massive data volumes". I didn't take the job. That kind of attitude is going to cause them serious issues.
Exactly my point. Not all products need great engineering, this is a poncho made out of blanket material and their production, marketing and sales team have managed to shift millions of units with ridiculous margins.
Why crazy? It looks like a modern incarnation of the Poncho, a common garment in southern south america. I have one since childhood, it's great for the winter :)
On what basis are you disagreeing with #1? Experience? I'm on company #5 right now and I'd say he has it about right.
There are in fact plenty of businesses where a quality product is not particularly necessary. I'm sure you can name some.
Even when quality is important, it is often not what a coder would identify as quality. As long as your customers receive what they perceive as quality, you've got a business.
And even when you're talking about the kind of quality your customers are seeking, that still doesn't cover all of the time and attention you will have to spend on things that aren't code.
Design for any reason other than UX is just vanity. You're confusing aesthetics for design. Design is not color scheme and fonts unless those color schemes and fonts enhance the UX. Good usability is good design. They are one and the same.
As an entrepreneur, code isn't your product. Your product is how that code is packaged in terms of solving a customer's pain point. Finding and convincing users to use your solution is 75% of business -- that means sales and marketing. 10% is fundraising or otherwise finding capital to pay the bills if you're pre revenue. 10% is helping retain existing users (i.e. support) and 5% is the actual code writing.
The code part of the original Facebook was no big accomplishment. Getting millions of users was. Those users didn't come because Zuck and Co. wrote great code; they came because the product was something that did what they wanted and was marketed in a highly effective and viral way that drove users. Coding isn't business, it's just one of the inputs that goes into a business.
To use a watchmaker example, an anonymous watchmaker that has a fantastic watch will never grow his business despite an amazing piece of 'code' -- it takes marketing and sales to make it happen. It also takes distribution, billing and administrative support. Code is a minor part of the business.
I think the word "Design" is being thrown around a bit too liberally. User experience is what people mean when they talk about design because the former covers more than aesthetics and is an essential part of a software program's usability. Any mundane looking yet extremely utilitarian command-line based software program needs to be usable, especially in the middle of a heavy-duty workflow.
This article seemed to miss what to me has been the biggest change: redefining yourself. If you're like me a lot of your self image is tied up in being a programmer and being very good at it. Being an entrepreneur means giving that up. It means not knowing what the cutting edge is any more, not knowing your way around every library, etc. Worse, it's not like you become a good entrepreneur overnight. So you go from being excellent at one thing to mediocre at many things. That's hard for a lot of people to accept.
The biggest problem I had - one I'm battling with right now - is that when you move successfully from being just a programmer to being an entrepreneur who sells software, after a while the software part becomes less important. You start thinking: If I can do this with software, I can do it with OTHER STUFF. And then you drift away from code and software entirely, as you realise your new entrepreneurial skills can be put to better use in other areas.
It's a huge thing to stop being a programmer, when you started out thinking it was the only path open to you career wise, and that you would be in the software business in one form or another for your entire career. But cutting that cord - as difficult as it is - can be liberating. Cause face it - if you can sell software that you wrote yourself, you can sell anything online.
As a single founder I am sort of confused about these things too.Here is what my plan is -> Basically become a code monkey for a first four-five months and do minimal promotion marketing.Once MVP is ready then do full time marketing pitching and fix bugs once in a while.If you get funded hire more people and more coding.
What you're proposing is a little like building a house to see if a customer likes enough to buy it, without letting them pick a layout/blueprint they like, or the conversation that goes into the blueprint of ensuring the customer would want the house.
First, find a target customer. Learn what their painpoints are. See if they're willing to pay for that painpoint. Then, build something to sell to them. This allows you to explore multiple hypotheses, instead of going to them with your idea that ends in a yes or no. By involving customers from the get go, they are more engaged, invested and committed, especially if it could make their life easier.
You will find that this path will reveal to you a completely different set of priorities and pain points that would be small to do, but have a huge impact, which is a great basis for an MVP.
By doing it doing it in reverse, you're hoping you take a stab at it and it pans out, at the expense of not doing the idea development upfront before writing a single line of code. The best way to "market" is to do it as you explore what to do and build a mailing list. Share your journey through a blog focussing on the life and business problem you're solving (not your code or tech breakthroughs).
Learn about your customer instead of guessing your way through what someone might want. Having domain knowledge in a field that you build something for could be helpful but you still have to validate, first, if anyone will pay for it. That's the scary, and what makes it a real business (self sustainable and makes money for you).
My approach (if you haven't already) would be to essentially get pre-sales. Cold call potential customers, or talk to people, with your 30-second elevator pitch. Get to the point where people tell you they want to buy your product as soon as it's available-then build, iterate, etc.
Build a really cool marketing website, an awesome promo video, then buy google ads to test how many people click the 'sign up' button that says 'Coming soon - give us your email here so we can let you know when we launch.' Divide amount spent on ads by number of emails and you have a cost of acquisition. See how this compares to potential ad income / user monthly cost. If the latter is higher than the former, you have a quantitatively-substantiated profitable business model, and you should then talk to an investor/angel.
As hard as it is to admit as a programmer, I think it can be smarter sometimes to flesh out the idea and get a feel for the market before spending much, if any time coding. Building wireframes and screenshots can be enough to show investors if you're going that route.
Of course if it's just you and you're committed to launching your product regardless of whether you get investment or not, then you might as well code it up and see what happens!
I would say you put yourself at risk to have wasted the 5 to 6 months of programming. For some applications the risk is low or the possible loss acceptable.
A preferable approach is if you can test the business/app soundness before investing 5 to 6 months in programming effort. If you can test two or three app ideas in that same period you significantly increase your chances to hit gold.
You are wasting your time by building the product first. You have to do the inverse. Become a marketing money for the first four to five months and do minimal coding (that is why its called an MVP). Once you have people buying your product, then you focus on improving it (or refactoring to rails, for example). If you do get funding, then use the money to grow the business and software at the same time/ratio.
Reason why this may seem a bit alien to you is because it requires you to go into marketing mode from day #1. Something you may not be comfortable doing.
Plus, marketing a product is just not about adwords, blog posts, and link on hacker news. It requires you to actually talk to other people directly. This is where a lot of introvert hackers ( like me ) quit.
I disagree. You would have an MVP. Something tangible to sell. Vapor-ware is software/hardware that is sold before it is built.
The purpose of the MVP is to get something good enough out of the door so you can focus on testing. Testing sales, marketing, user experience, etc. Once the initial testing is done, and the product has proven itself to be profitable if not then iterate/pivot), then you go and refactor the software if, and only if, the costs of doing so are worthwile.
I know of products out there that are complete and total bowls of spaghetti that make a lot of money and would be re-written by most of us. But they are profitable, and that is the ultimate test for a product. Does it sell?
Not to nit-pick to much, because I agree with your basic point, but I think the ultimate test for a product is does it profitably deliver value. Every scam artist in the world is profitable, and I see too many people go wrong by pursuing pure profitability. Coughzyngacough.
You have a big assumption: Product X will be valuable enough that people in group Y will pay for it. Your way of testing that assumption is to spend 5 months coding plus N months trying to sell it.
So at the end of 6-12 months, suppose you discover that Product X is in fact not valuable. All of the coding time and a substantial portion of the marketing time will be wasted.
Ask yourself: what's the cheapest possible way to test your core assumption?
I feel like if you cut off time programming and spend that time working on building hype you might be able to earn a bunch more of customers earlier, which might turn out to be the difference between not needing external funds and needing them. Or the difference between being able to getting them and not getting them, if that's what you want.
Thanks for the advice.Can you please point me towards where I can find some knowledge about building hype.I have seen some companies do this (Recent Example - LightTable).
In my case my product is really different and I dont know how I can get people to understand what it is without actually getting them to play with it.My belief is that my MVP will be the best tool for building hype.
Unfortunately, I can't find the initial promo of dropbox : " throw away your USB drive". It is also not accessible on the wikipedia page. This is a good example off startup project testing. They did so many things right.
Read the Lean Startup and learn what an MVP really is. And MVP can be built without writing any code. Your first few months should be figuring out what your customers want.
Regarding the 5% number, it might be closer to 20%. We spend more time reading about tools that benefit technologists than strategies that create value and convert into paying customers.
Most startups don't solve technically complex problems, except how the technologists are making their own lives easier through the latest language, tool or framework.
Building a project is different than a product. A product is not just the code. We see proof of marketing ruling with garbage products getting into customers hands and they have no idea of better solutions that are available.
The most important part of this journey is absolutely finding the customer, finding their need that they're willing to pay for, finding how to reach them, and then part addressing their need through code.
You need all of those to have a business that makes money, other wise you have a project you want to try to make money with, not a strategic approach to establishing a business.
Focusing on making money is terrifying to too many technologists. The only way you get there is realizing the product itself is 20% of your business and you will inevitably spend 80% of your time learning to get it traction and paying customers. Of course, it's easy to just code some more to add some "value". If that value doesn't reach customers, it's not realized value, just more potential that will sink.
I agree with the entire article except for the last point: read everything possible.
It's an epic waste of time to read about things in detail that you aren't looking to implement right away. Reading articles, especially if you don't end up acting on them is too often a waste of time because you have to come back to them later and re-read when you're ready to do something with them.
I use a slight tweak on the rule: Only read in detail what I need to do right now, or my next step. Only read things in general to understand where I am on the overall project.
I agree that code is not the only thing that should be worked on. Loving customers, treating them with respect and listening to them is also essential to me.
I am currently working on an idea and have a lot of questions on different aspects and don't even know where to look for answers. Is there some online resources related to the different aspects of an online business? (understanding a service that you pay for and use online, such as BaseCamp from 37signals). For example, should you start to give a service for free at the beginning and then monetize it when you have a lot of users, if you do so, is there some legal issues following this way? Another example, the disclaimer: how do you manage this, does it really protect the entrepreneur? I feel like there is a lot to considered out of the code itself and the marketing.
I do not have any fund and have a job, but I was thinking about starting something aside of my job and try to make it known. The biggest problem for me now is not technical, I could write an app to develop my idea and put it online. The problem is that I don't know what I am allowed to do or not allowed to do as an owner of a website/webapp that I put for free online. If you take for example the case of Craiglist, someone will put an ad to sell something, and potential buyers will contact this person. How does the website discharge itself from being responsible from any failure in the process? Every law related question are pretty hard to find an answer to.
>Treat it like you are learning to program all over
I really love this part, diving into the bigger world of building sth real and serve people directly, with the same passion and curiostiy for coding itself.
Stating how much of your business is code, design and hustle is extremely relative. The relative proportions of each are a lot like fertilizer numbers. Some plants require one ratio of nitrogen, potash and phosphate and others require a completely different ratio of each. The ratios are a function of things like audience (awareness, inertia), competition and the status quo of your market.
You're arguing with something he didn't say. Nowhere did he advocate non-native UI widgets. He's just saying that in the eyes of your audience, your product should look better than the competitors.
1. Code is 5% of your business: no, it isn't. If you have a watchmaking company, is making watches 5% of the business? Marketing, sales, and operations are only important as long as you have a quality product.
2. Design is everything: it can used to great advantage, but let's keep it real. There are plenty examples of successful "gray boxes" applications, don't confuse aesthetics for usability. We are here on HN, aren't we?