I understand that Hacker News is mostly targeted towards the startup crowd, but asking _hackers_ to have a business model before they write anything is completely backwards to me.
Hackers don't write code because they want to make lots of money. Hackers write code because they are hackers. Building a viable business on top of that code may be a nice side effect of this.
This sentiment is a bit like saying "sailors don't sail because they have somewhere to go. Sailors sail because they want to sail."
It may be true if you're on a lake or in a bay, know the area well, and your intention is to just go and flex your sailing muscles. To practice, enjoy, check out something you're aware of but haven't actually navigated, or something else that's similarly within easy reach.
It loses its applicability when you consider that, no, some sailors actually do have destinations. And some trips are long or difficult enough that they do in fact require planning, specific goals, timelines, and all manner of other preparation.
I'm sure it's not a perfect metaphor, but the point is that the artificial limitation of "hackers hack to hack" is short-sighted and fundamentally flawed. Some do, some don't, and I would say most are somewhere in between. But please don't make the mistake -- on behalf of others -- of defining the entire community in terms of your preconceptions about what hackers do or don't value or attempt in an absolute sense.
Yes, comparison is flawed. Imagine Torvalds starting to work on git. Is he sailing to go somewhere? Certainly. Has he a full business plan with all the bs about customers? Certainly not. He sails because he is a sailor, and sailor are explorers too. (Not in real life, but in this comparison)
However Linus built git for himself, not for others, therefore he doesn’t need to go through this because he will be the first customer once this product is finished and released.
This article is aiming for entrepreneurs who are building a product for others because no where in the article did he infer any possibility that the product/service is something they want regardless of others.
"However Linus built git for himself, not for others..."
No, Linus built git to address the needs of a large community of Linux kernel developers:
Git development began after many developers of the Linux kernel chose to give up access to BitKeeper, a proprietary SCM system that had previously been used to maintain the project. The copyright holder of BitKeeper, Larry McVoy, had withdrawn free use of the product after he claimed that Andrew Tridgell had reverse-engineered the BitKeeper protocols.
Torvalds wanted a distributed system that he could use like BitKeeper, but none of the available free systems met his needs, particularly in terms of performance. Torvalds took an example of an SCM system requiring thirty seconds to apply a patch and update all associated metadata, and noted that this would not scale to the needs of Linux kernel development, where syncing with fellow maintainers could require 250 such actions at a time. His goal was for patches to take three seconds.[1]
I write code so I can make money... so that in the future, I can write code without worrying about making money. if that makes sense. Because right now, the vast majority of hackers spend 90% of their living hours writing code that doesn't satisfy them intellectually.
Makes perfect sense to me. Though every once in a while i run into coding job that i actually find satisfying. Like recently made a research project involving a multiple AI agent envoronment
No, I don't think it's backwards thinking to me, but I do agree with you. People loving hacking because it's a fun thing to do. And most of the times, building a business isn't even the point of it all.
The problem I have with this article and your comment, is the generalization of the term "hackers". Is anyone that codes in their free time, a "hacker"? Is a software engineer that works full time at a company, a "hacker"? What about UI designers that write CSS? What about business guys who throw something together in HTML and jQuery? Are they hackers as well? Different people have different goals for what they are building or hacking on. I really don't understand how we are still throwing such vague terms around like we all fit in this one category of people, and we all want to achieve the same things.
A "business model" can mean a for-profit enterprise as well as an open source project solving a pain point and showcasing your skills. The questions customer development asks can be used for the open source project too, with great effect.
yep! that's how good useful open-source code (especially APIs) are built! I mean dont u want people to actually USE what u took time and effort to write? You may not have written it for money, or to make a business, but you would want people using it. So when you code AFTER knowing what people need, the feeling is way more awesome! i mean think about it, u wanna make something really cool that no one uses? or something everyone agrees on is super cool, and would love to actually use?
I actually spent nearly an year writing a rather powerful and challenging mathmatical reasoning engine (heck it can not only solve but LEARN mathematics!) but i had no users in mind. So i could never explain to people why anyone wud want to use it. and that didnt really feel that good
It depends on your goal. If you're just writing code for yourself, then yes, because you are your own customer at that point. If other people happen to share your sentiment, awesome. If you want to start a startup because you think you have a good idea that other people will want, then do the market research first and make sure people actually want it. If it's something you're doing for yourself, then you probably don't need monetary motivation to do it, even if you're the only one using it.
That's kind of the point of this article though. He's pointing out the flaw in the "code first" approach. He started out that way and wound up wasting years of his life. The "hackers" of news.ycombinator.com are (or should be) business-minded hackers (it's kind of the point of ycombinator). This kind of reminder is always helpful.
Also, writing enough code to build a minimal demo is often necessary to validate technical viability and to ease customer development, as having something to show helps kickstart the conversation and stimulates feedback.
everyone should do what they enjoy, then money will follow. there are niche business areas. i.e. creating apps useful to you, creating an algorithmic trading bot to work the market
I can't wait to see the "Write code first" article later this afternoon. </sarcasm>
There are no concrete rules in life, I get it. If you are trying to make money, all he is saying is find out if people are actually willing to pay for this. However, like other's have pointed out, sometimes we write code not driven by monetary rewards but just the joy of coding. There are no concrete rules, sometimes it's a great idea to write code when the idea comes into your head, sometimes it's not. The hard part is figuring out when to do which.
> I can't wait to see the "Write code first" article later this afternoon. </sarcasm>
== Don't go looking for customers before you have working code. ==
Years of experience show sales and investment rounds go better if you can show an actual, working software. The solution doesn't have to be complete, nor perfect fit for this particular customer, but nonetheless, if you pitch, you better be able to back your words with something concrete.
Don't even attempt to set pricing or commiting to delivery deadlines unless you have at least sizeable chunk of code working. At the very least have third-party libraries ready and pick a platform (hardware, OS and UI toolkit) that provides most of what you need.
Beware that quite often what seems an easy endeavour upfront, show to be quite complex, perhaps even unachievable, as you start coding. Thanks to the halting problem, it's not possible to find that out without actually implementing the important parts of your software.
Last but not least, before you start selling, have had written and delivered at least a few similar pieces software. Having experience in problem domain is crucial for producing commercial-grade software.
# # #
Phew, easier than it seemed -- which goes to show how little value is in such generalizations. At least in general ;-)
Sometimes it is easier to find out if people are willing to pay for it by writing a little bit of code. The challenge is knowing how much is a little bit and that "proof of concept" applies just as much to possibile-to-sell as possible-to-implement.
There are some assumptions in the story. The first is that you/your team is able to communicate your idea verbally (maybe with some mockups) clearly enough that people understand it fully. This isn't always the case, and it's certainly not always the case with engineers. We're in this process right now and I tried to explain exactly what the product is verbally to potential users, I just couldn't.
The second assumption that seems to come into this argument is that ideas for products are stand-alone and don't evolve through experience in a domain and feedback of pain points on existing products (prior to where we form the idea).
You either put up a landing page and say give me your email, or you build a minimum viable product as with feedback as you build.
So we built the minimum viable _prototype_. It's not the MV product, anyone using it gives up within 3-4 minutes. But combined with me talking directly to the user, I can now hear that lightbulb turn on as they get what I'm talking about.
Simply, it's a continuous spectrum between the two boundaries and you need to pick the right point for your product. As a contextless headline, this is bad advice.
The point isn't to get them to confirm what you want to build is the right thing, it's to learn more about their problems to find out what you should build.
I really don't understand all of the negative feedback to this post (maybe I didn't see the old title, as it has evidently changed).
It seems like this is straightforward honest advice when you're trying to solve somebody else's problem(s). Some other folks have mentioned other products as examples of build first, but those all seem to have been people solving their own problem/desires.
If you're trying to create a business that attempts to solve other people's problems, this approach would be excellent. The example that the author used (Movie theater) illustrates the point of view perfectly. I suspect none of us have ever had the problem of watching a movie and being distracted by the fact that we didn't purchase enough snacks. That is not a problem a 'user' has ever thought of, but I would guess theater owners think about it a lot.
Ah, ok, thanks. I see now why there would be a harsh reaction. I will re-title my forthcoming post from "Why only stupid dummies do 'x'" to something more nuanced. :-)
You did the right thing honestly. The rules seem to indicate matching the source title is the defacto right thing to do.
All the same, I think in cases where responses start reacting to the title and not the content, it makes sense to moderate it, but then again, I am biased.
This whole "everything has to be a business" mentality can get pretty toxic. It's perhaps the root cause for all sorts of things like proprietary software (not inherently evil, but by definition cannot be trusted), software patents, DRM and whatnot.
A hacker who has an idea will do it regardless of whether it'll make them money or not.
> A hacker who has an idea will do it regardless of whether it'll make them money or not.
That's exactly the motivation that drives me to create side-projects. But it's still a bummer when nobody uses them.
The point is not about money, but creating value. Hackers don't always want to create things just for flexing their technical muscles. In the end, we all want to provide value in one form or another. If no one is using your software, then it's wasted effort.
You could modify the approach outlined in the post and just verify peoples' pain-point and see if they'd be willing to just use your software instead of asking them to commit to paying for it.
Some people on this thread liken hackers to children/babies. Doing things out of fun and compulsion without thinking too much about the net result. That is hardly true (as you say)
The last time I talked with 5 potential customers they all agreed that my idea would really fit their needs but they can't see how this ever would work. Explaining to them couldn't change their mind.. I like your approach, but sometimes a little demo is necessary.
edit: I'm dissapointed this isn't about entity framework ;)
People don't always know what they want. People have trouble seeing which of their needs can be feasibly addressed. People are bad at imagining how new ideas integrate with their established way of doing things. If, 10 years ago, you'd asked every current smartphone user whether they needed a multi-hundred dollar phone that does mostly the same things as their laptop, the vast majority would say no.
Hackers don't always know what people want. Hackers, having hammers, will only see the bits of problems that look most like a nail. Hackers, having hammers, will forget that other people don't like to deal with hammers. Hackers, having hammers, say things like:
"For a Linux user, you can already build [Dropbox] yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem."
(https://news.ycombinator.com/item?id=9224)
The real lesson is to integrate users in every part of development. Targeting a specific user group? Talk with them, try out products they use, and try to grok their needs, values, and relationship with technology. Trying an innovative interface? Throw together a minimal, flexible mockup (just enough to facilitate a conversation), and find out how people react.
Whether you should start with users depends highly on the product, but get users involved throughout the design process when user input is needed.
I think you should always start with users by having a deep understanding of their problems. That may come from domain expertise or from talking to them. But if you don't start there, you're going to make a lot of incorrect assumptions.
A lot of successful things have been built before there was customers. Some people just enjoy building cool things and when they start don't really care about customers; Minecraft springs to mind.
Minecraft is an example of a game at the right place, at the right time. Indie when indie was the hot new thing, 3d voxel, when gaming was tiring of FPS's, and cheaper than most console games.
It is not a model others, or even Mojang has been capable of replicating.
Minecraft is an example of a game at the right place, at the right time.
A great number of products and business ideas spring from noticing that something seemingly necessary doesn't exist, which, said another way, is recognizing that there is a right time out there waiting for the right thing to come along.
I see the battle here as a conservative/liberal one. Not politically, necessarily, but of personal effort. Do you research and line up customers and let people wait for the product to arrive, and in this way creating a right place for a product to occur in (hopefully) the right time? This i see as conservative with ones own efforts while beign liberal with other peoples' time and attention. Alternatively, being liberal with one's own efforts in creating a product that can be presented in a turnkey fashion, effectively treating the customer's time and attention conservatively. There's no right answer.
The problem is that other companies are trying to replicate a model.
Mojangs model wasn't really a model, they needed money to continue the development of Minecraft. People really liked the idea of a voxel creative adventure game at the time and spread the word. Now the market is saturated with them, yet Minecraft is still on top.
Expecting the model to play out the same again is stupid, because the original conditions that caused Minecraft to be successful have changed.
At the time, Notch just wanted a game that played the way Minecraft did; he was focused on building something cool that played into his nostalgia.
I understand the spirit of the post, but it's not so black and white. You should think about what you really need to do, and then do it. That might be writing a little code first, and then focusing on the customers.
The reason is that a lot of the time you need to technically validate an idea. You have a great idea for a product but you have no idea if it's even possible. You have to write code to understand what your product is even going to be ("these are the 3 most important features, can we actually do them?") Maybe these are features that depend on an external service and you need to make sure they provide the right info.
I feel much more willing to sell an idea when I have a vague idea that it's possible.
But yes, only write as little code as possible at first, and expect to throw it all away. It's just part of the research process.
> The reason is that a lot of the time you need to technically validate an idea. You have a great idea for a product but you have no idea if it's even possible.
I agree that things are rarely black and white, but because hackers tend to default to their comfort zone - code - and because (in my experience) technical risk is usually a non-issue, the biggest risks are finding a large enough market, a set of customers willing to pay, and a way to profitable reach them. Since they're usually the biggest risks, it makes sense to tackle them first.
Definitely agree that most technically-focused people fall into the trap of writing too much code too early.
There's the other end too, though: you get so wrapped up into an idea and sell it too hard and end up not delivering because you were detached from the technical reality.
I think you just need to be smart about switching contexts, especially early on in the game. Using a little bit of code here and there to stay well-grounded, while focusing on customers to validate the idea. Early on you definitely should be spending most of your time engaging future customers.
> Early on you definitely should be spending most of your time engaging future customers.
100% agree. Though my approach is less about selling and more about learning: are we solving a valuable problem? Are people willing to pay for it? Do we have some ideas about how to scalably reach those folks? Etc
That's true. I guess because I'm a "hacker" I just don't know how to ask those questions without involving the technical merits of the product.
I have a specific question, as I'm in this phase right now. I need to validate my product and demographic. It's a finance app targeted towards developers. I'm still working through the core feature-set (on paper, and a little code). It needs to differentiate itself in the details; the market is somewhat saturated. I also don't see how I can make a landing page without screenshots.
Now, how do I validate it without writing any code? I have already written some code because I need to make sure I could get certain info from banks. I need to make a landing page to get people to sign-up. Can I really do that without screenshots (even if it's mock-ups, I need to think about the UI a little)? I need to "sell" it on a few features; writing code has helped a ton to sift through my ideas. How do you flesh out a landing page when you just have an idea?
> I also don't see how I can make a landing page without screenshots.
Use thumbnails with copy about benefits. That's what we did.
> How do you flesh out a landing page when you just have an idea?
We talked to customers about their problems - we reached out to people through our networks and cold emailed them. We understood their problems first, then were able to create a landing page with fake thumbnails of the interface. We wrote copy detailing benefits (save time / save money / make money) of the product. The goal of the landing page was to get more people who we could talk to to validate our idea.
It didn't matter that the product didn't look anything like the thumbnails.
The only code we wrote was to hook up the landing page to Mailchimp.
Sketch first means you're thinking about a product and hunting for a customer. Customer first means you're thinking about a problem first then building a solution.
Honestly I think we're just bike-shedding at this point. There are tons of companies that started with a sketch of a product (to solve a known problem) and evolved it based on customer feedback.
[Full disclosure- my company teaches big companies about this stuff. We publish a lot of free content as A) Content marketing, but B) as a way to help our startup friends.]
What's ironic here is all the push-back from people about why you seemingly don't need to think about anything but code. There's a bunch of hacker and code-specific reasons not to write code first he doesn't even mention.
- To provide a usable product for your customer you need to ask them what they want. I can't tell you how often I see tools that are practically unusable for the target audience because the devs were just writing with devs in mind and couldn't be bothered to take a couple days to do interviews. (I'm looking at you, every-open-source-tool-that-gets-shown-off-on-HN)
- Writing code first also means you probably didn't have a plan for the entire design flushed out, which means hacks on top of hacks, which is equivalent to a giant Jenga stack with half the pieces missing.
- How will this code be used in 10 years (if at all)? In 20? Is it going to be made obsolete, or will your users and their needs change? (think multimedia, transportation, competing market forces, legislation, etc)
"Talk is cheap. Show me the code" Torvalds, Linus (2000-08-25)
Surprised this quote didn't get mentioned already.
FWIW... on a first glance, i parsed the submitted title as
"don't write, code first".
lol.
On a more serious note, I wonder if the folks at Xerox Parc would have created the mouse/various interface hacks had they thought about the biz. On the contrary it was the "business concerns" that decided to not continue it further.
That said, code itself has its own consumers/customers who will use what you create. And that's selling in its own right. eg: jQuery's decision to incorporate chaining, selectors, more functional aspects.
When i write frameworks or libraries, I always try to start with the api/wrapper first, and then work on the internals. can't remember the threads, but am sure there have been a bunch of HN threads on just this subject.
I've always been mystified by the oddly specialized approaches that come across as a "one size fit all" claim.
Just like pure Agile, Waterfall, etc methods aren't complete solutions, we seem to have the tendency to try and redefine "good software development" every other month.
The most important thing is to do what works the best with your team; and even this varies from project to project. Sometimes coding out a half baked idea into a POC is better than spending hours on a whiteboard, just to get stuck at some unforeseeable roadblock as soon as the code hits the editor.
Sometimes, you need to hash out a problem on paper before devoting coding time. Proclaiming absolutes as gospel is a little dangerous.
If i remember correctly, they wrote BASIC for it, (language design) and then pitched it to altair, who then gave them an actual altair to implement it on, no? Btw, wasn't programming without actual access to a PC, pretty common back then too? (even decades later, when u had decent computers). From what i hear from my dad, programmers wrote it out on paper, and sent it to the data entry people who would type it in, run it, and report any bugs etc. Heck, imagine debugging without access to a PC!!
Given the state of today's technology, I'm kind of surprised that this viewpoint would be expressed in such absolute terms. Here are a few companies I can think of in which "build first" seemed to permeate the enterprise at the very start:
Facebook wasn't "build first" in any appreciable sense. The prototype features were outlined in a well received editorial in the Harvard Crimson in December of 2003.
There was widespread outcry for the administration to build what Zuckerberg realized he could build faster.
Further, there were existing prototypes in house facebooks.
All of those, including Google are B2C companies at its core(I know the first 3 sell ads, but they'd be useless without consumers).
If you're selling to consumers, you need to know what they want, because asking them won't yield useful answers. Who would have told you "I want a text box where I can type 140 characters about how I feel" 6 years ago?
If you're selling to businesses however, you need to do customer and market research.
Really depends on the type of product, if you know it's something that the whole world would benefit from then maybe build first makes since, but if your targeting a niche market then for sure you want to get a barometer if your product is going to be needed and what the biggest pain points of those who would use it are.
People who, unlike a successful drug dealer, actually want to use their own product? I agree that if you are someone with desires not shared by the rest of society, you should probably go and talk to people and see what they desire...but it's also quite possible to think of something you and maybe some of your friends would use and have that be the guiding force in development. The problem with asking other people whether they'd like it, well [insert apocryphal story about Henry Ford and people wanting faster horses].
It's not either-or, it can be a mix. But it's not beyond the capacity of some hackers to hack on something they care about and, at the same time, have it be something that others will care about, unless all they're doing is trying to make a quick buck in the startup rush.
I understand that for the author of the article the goal is to make a product that people use and that entails a financial return.
I just want to say that building a software from scratch, even if doesn't end up used by millions of people, is worth doing for the process itself. Not just for the fun of it, but especially because you learn a lot during the process. I don't consider learning a waste of time nor a fool somebody that is motivated more by learning than by fame and money.
True header. Don't write code first. First write the docs to understand the problem domain from the other side, the user, and come up with a better API. Then write the tests to support this API you came up with, and help structuring the code into small testable units. And lastly write the code. The business model needs not to be written, it must be simple enough to stay in your head and explain it to anybody in two sentences anyway.
This is interesting. I have applied to YC and have not written code first. I have talked to customers and found out they need. We will see if these quotes hold true because in interviews I read YC likes when something is already coded a bit.
I think this applies to startups that target businesses, and this is generally good advice for that segment. It doesn't really apply to consumer products like Facebook, Google, Minecraft etc.
Is this really a one-size-fits-all advice because I always seem to be presented with it as being such. Clearly there must be edge cases where this advice doesn't apply (?).
Yeah, I don't think it's a one size fits all. However, if you can present a solution to a person's problem, and that solution does instantly resonate and it becomes obvious that such an app/website can exist to solve it, people will want it badly. -- and that becomes obvious.
I basically think it ties back to becoming an expert on the problem. Instead of the solution.
Low comment count is frequently an indicator of quality on HN.
Contentious, heat-generating (as opposed to light-generating) discussions, often political and / or emotional in nature, tend to produce the most comments, and are the least useful to read or get involved in.
Tons and tons of things make it to the top with no comments, I'm always curious as to why they are there and have 20 points (not sure of the accuracy of that) within 8-10 minutes but no comments.
Though this is just a delicious linkbait-y title so that probably helps it...
Becoming a better developer requires a certain level of self-criticism and willingness to improve and learn. Just writing (lots of) code alone will not.
Hackers don't write code because they want to make lots of money. Hackers write code because they are hackers. Building a viable business on top of that code may be a nice side effect of this.