You know, one of these posts pops up on HN every few months, and every time it kind of annoys me.
If I'm building a project for fun at home, then it's typically specifically to learn about a new thing (which I kind of assumed was the case for most people); either a new programming language, or a new editor, or a new library or two. If I short-circuit and "just build the product", then that is sort of negating the purpose of the project.
If I wanted to "just get something done", I probably wouldn't have done any projects in Haskell (back when it really sucked for tooling), I wouldn't have learned category theory, and I wouldn't have gotten any work in research.
This post isn’t for you. This is for the people that want to ship a product to paying customers and also want to learn a new technology doing it. In my (and what I’ve seen from others) experience, the programmer never ships the product because they’ve exhausted their time and energy on understanding the new technology, understanding the technology to do something they know how to do in other technology. The product never gets shipped and remains with the other projects that were never shipped.
I have ten of the next big things sitting on my computer anywhere from 10%-80% finished. Some are using new technologies, but many are using tried-and-true. It didn't matter.
I've been racking brain cycles the past few weeks trying to figure out how to solve this problem.
- Amount of dev time needed to ship an MVP
- Lack of a business partner
- Not having a pilot customer lined up
- Getting old
Those are some of the issues I see as a far bigger hinderance than any tech stack stuff. Shit, when is the last time (have I ever) tried doing a no-code MVP. Not always possible, but I'm sure somewhere in that stack of unfinished projects I could've come up with a no-code or very limited code MVP...
> If I'm building a project for fun at home, then it's typically specifically to learn about a new thing (which I kind of assumed was the case for most people)
While I do sometimes get excited about learning a new technology, the most fun projects for me are where I already know all the tech required, and all the new ideas relate to whatever I'm building.
And I had assumed that would be the case for most people.
I see the differences between the two as:
1) Learning a new technology is kinda like reading a sci-fi short story to me: it's mostly about getting some interesting new idea, with the added benefit that it may apply favorably to my future work.
2) Building something new with known technology comes with the kind of unstilted, gratifying fun experienced when exercising well-developed skills in service of producing something. Often this comes with flow states; internalizing new concepts and practicing new techniques on the other hand are not ideal for this.
They both have their merits but to my mind, the second one is on another level, and I'd recommend to anyone using their fun projects only to learn knew things to try exercising their already established skills to build something they'd just like to see running, or to share with friends etc.
Edit: just to give an example: I had a lot of fun building this game where I learned no new technologies, and in fact had already built basically the same game 12 years prior (with different tech and far less knowledge). Instead I explored ideas related to the architecture that I thought might generalize, and enjoyed myself developing the algorithms and aesthetics that made the thing work: https://github.com/westoncb/under-game
It annoys me as well, and I think the intent is that "just build the product" is about avoiding shaving the yak.
Some of us poor bastards have to invent the stupid things that let people get things done, and it isn't exactly clear that the stupid thing is even good in the first place.
For instance, right now, I am in the process of inventing my own programming language. I've done this in the past with varying degrees of technical success, but it tends to get deep into the weeds of shaving the yak and polishing it up.
I'm have a hell of time to pull myself from the technically interesting problems to focus on the product that this language enables, and I find myself having to balance between fixing the language idioms and building the product.
Balance will be a key thing to focus on if I make this product a real thing for real customers... very challenging future ahead of myself.
> It annoys me as well, and I think the intent is that "just build the product" is about avoiding shaving the yak.
I think discussions in general on Hacker News, blogposts and Twitter is missing context. Everyone assumes that others context is the same that you yourself has. So posts like this make sense, if you're in "startup - lets find market fit - need growth - just build the damn thing" mode, which is probably the mode the author is, or the context would have been set in the blogpost.
In the comment you're replying to, the context is a "explore an idea and learn something new" with no intention on turning that very thing into a product that sells to people. Maybe that will happen, but it's not the intention.
In the end, two very different contexts, both valid, but they are both talking past each other. All the people using different social networks (HN included), usually miss the vital piece of context and just proclaim "You should do X, because of Y". Then people defend their context, because life is never "Always do X" and will never be.
Good point. But isn't it the author's job to establish context? Otherwise what they're saying is typical "thought leader" platitude nonsense.
Here's another way of looking it. Shipping a product involves thousands of decisions and course corrections. Sometimes technical decisions like deciding on a build system or programming language. Other times product decisions like deciding to ship without user login and use an email "magic link" instead. And other times it involves building no product at all and just gathering some user feedback on the idea.
So if you look at it that way, "just build the product" is total nonsense no matter what context you're in. It's the ability to make good decisions that matters. What's a good decision? One that produces the results you're happy with (expected or not).
How do you make good decisions? Well, that's the hard part. The OP doesn't help at all. It's just fluff.
Example: You're working on a product idea. One of the core features is a DSL/language that the user types in a GUI to make some magical thing happen. Immediately you're faced with choices about your DSL/language. Should it be a subset/superset of another language? Should it be totally custom? Should you write your own parser? Should you use a parser generator? If you use a parser generator, how will you handle lax/incremental parsing?
If it were me I'd spend a couple weeks researching PL theory. In the process I might learn about the tradeoffs of choosing LL/LR/LALR grammars. Maybe I'll learn about state of the art grammar generators that'll save me weeks of coding and months (cumulatively) of debugging. Did I waste my time or did I just greatly improve my core product?
Another week later you're faced with decision of choosing a build system. Since your product will only ever run on AWS somewhere you write a simple Makefile and move forward. No point in diving deep into the likes of CMake/build2/etc if you don't have to. Could it bite you later? Maybe. If it does you'll deal with it.
Where does "just build the product" help here? Building the product is making these decisions thousands of times.
Good decisions come from wisdom. Wisdom comes from making bad decisions. Just make the decisions and learn from that. That's my interpretation of the post.
I sometimes do projects to learn new tools, and sometimes just to try to make something I want to play with. Sometimes it's good, sometimes it's not. But a couple of years later I might come back and revisit it with new knowledge and perspectives.
It's easy to get lost in the labyrinth of second-system syndrome and analysis paralysis and not really do the thing at all. Maybe better to do it with tech debt and sort it out later if it's worth it, and if not then learn from that. But still with a focus on the goals, not the means to get there.
You're so right, it really is talking past each other. That plus having the conversation in a way where we sort of pretend we aren't aware of the varying contexts.
What kinds of problems are you trying to solve that would make solving the (rather large) meta-problem of creating a /whole new programming language/, easier / more effective / more clear / more profitable - especially when compared with "just solving the problem with more established tooling"?
I don't ask this critically. I am genuinely curious. I wonder about this a lot; there are so many languages that solve the same problems in slightly-different ways, that I'm always curious as to the motivations behind creating another new language.
So, I have a particular domain where I hope to combine actors and data in a novel enough way. I'm not targeting 'general computation', and I'm defining a hopefully new market. It is very abstract at the moment, but I do intend to quit my job to pursue in 5 to 8 months.
The problem of them not being as good at creating a new programming language as they want to be.
So many amazing projects started as someone scratching an itch, often completely unrelated to the eventual product. And even if a project doesn't take off, if the goal was to get better at programming (and not marketing, project management, etc) it may be still be a success. Both forms of projecting have value. It all depends on personalities and where people are in their careers.
You're inventing a programming language? 1. That's awesome, seriously 2. What the hell real product are you working on that requires you to invent your own language lol?? I'm genuinely curious!
There will be posts in the future, but the problem space is related to actors and storage. I have to confine what is possible since there are a great number of ways to really mess up.
I see how you can find it annoying, but I have a friend that needs this advice (or a slap?).
He spends his energy lamenting over the "right" tools, to the point that he considers it a moral decision and part of his identity. He has trouble keeping work, because he's always looking for a company that uses the right tools instead of building the right thing. I'm sick of him lamenting "I could never work at [x] because they use java, and I never wanna see another NPE".
I personally constantly restart side projects, with different languages, or tools, or whatever because I read something about why {language, tool, whatever} is better than {what I was using}, so sometimes, it nice to remember that if its not a learning process.. it might just not matter :)
I think a lot of these posts aren't arguing "never build a side project to learn a new technology". I think they're arguing you should go into it eyes wide open, deciding if you're trying to learn new tech or build a side project. Because the first goal will interfere quite bit with the second goal. And more than a few devs have made the mistake of trying to start a new business on new tech and have blown their foot off.
As a software engineer, it's your responsibility to build the product according to the requirements. Sometimes that means it needs to be built it quick because it's likely to have a short life, or it needs to land quickly to market. Sometimes, you need to get things right, otherwise you end with an insurmountable amount of technical debt and a business that grinds to a halt.
Given this, you should make the analysis to understand the tools that you need. If that means learning, then so be it. Maybe you can keep going with superficial knowledge. Or, perhaps you need to find an expert, that's fine too.
As for growing in your technical knowledge, that should be agreed upon with your employer or whoever is paying for the work. If you find that you work somewhere that doesn't allow you to learn then perhaps it's not the right place to be.
The problem is it’s extremely hard or often impossible to know what are good choices before you’ve started building the product. This, combined with the fact that software is highly malleable, should lead one to highly prefer a bias towards action vs analysis. It’s not a hard rule, but it’s much more common for people to fail due to analysis paralysis than due to poor technology choices. If you are able to get any form of traction, opportunities open up to expand resources and time that will be needed to adjust technologies. It won’t necessarily be fun, but when going through such an experience I believe more often than not engineers have hindsight bias, not a true recognition that early choices were made objectively incorrect given the knowledge at the time.
I’ve seen plenty of project grind to a halt from bad decisions and high pain thresholds. I think you’ll find and even mix in the overanalysis crowd of white tower thinkers and people exhibiting allergic reactions. If you are seeing more of the latter I have two theories. One, those people gatekeepe projects, so once bitten twice shy (ie they accumulate and add friction) or two, you are looking at more early phase startups than me. A seed phase startup locked in analysis never sees my resume, so I don’t see how often that happens.
But the trick is to start with the new Reversible decisions.
We don’t always know which are the reversible decisions, but many of the irreversible ones are obvious. For some reason developers always focus on the irreversible one. We reason that we have to get this right, because it’s very important. And if it’s important, we should do it first.
No. No. No.
If instead you start tackling all the reversible decisions first, you can make those choices quickly (because changing them is cheap, spending a lot of energy on making them is a waste of time and capital). Start building something. Get momentum. Get the team and ideas to gel.
When you start to know what you’re doing, then tackle the irreversible decisions one at a time.
But typically, everyone wants to Decide. And they want you to decide on short notice, right now, like some sort of used car salesman. If we don’t tolerate this from others, why do we tolerate it from our teammates?
Deciding for the sake of deciding is not productivity. It’s painting a floor when you haven’t identified a workable plan yet. There are always at least four corners, and rarely more than two doors. The odds are not in your favor.
I'm having a hard time following what you mean. Could you give some examples of an irreversible decision that can be deferred in favor of some other specific reversible one(s)?
Interesting. You know, I would’ve sworn I had a pat answer to this question, but it turned out I had to think about a little bit.
They say that some of the most rewarding interactions for teachers are the ones where they learn something, not jus the student. Every once in a while I get an example of that in real life.
So what are some examples? Programming language is often difficult to change. This is sometimes listed as a pro for microservices. Because I get to change my mind for every new area of the app, which makes it cheaper to reverse directions.
The most obvious answers that I have are load balancers and external caches. I shouldn’t have a big knockdown drag out argument over haproxy vs nginx. Now, a load balancer is almost a given. It’s possible that someday in the future, someone will invent an SMP machine with 256 cores that gets some economy of scale by running a whole website on two machines. It’s easier to reduce the number of machines behind a load balancer than it is to add a load balancer to a mature product. So put one in, but don’t fight about which one. We don’t know if we need haproxy features, or if we want paid support from nginx now. Just flip a coin and move on.
Similarly, external caches are usually easier to turn off than internal ones. With internal caches, people start to pass around IDs instead of objects, assuming object lookup is “free”. It becomes integral to the information architecture. A rat’s nest of lazy and duplicate lookups. External caches are cheap but never free. Access tends to leave bigger footprints in the code. And there’s some small hope that you can get a direct lookup down to a small multiple of the cache lookup time if it really becomes necessary.
Database architecture is another big one, for certain dimensions. Going with Oracle is hard to take back. MySQL vs Postgres is smaller. KV store versus MVCC SQL database is also harder. For a prototype it might make sense to pick one that is obviously a placeholder, like SQLite, until you know what your customer’s needs really are. Do they need audit trails? Are they addicted to graphs? Multitenant security? On and on. You can stave off fights with SQLite because it’s effectively a promise to revisit this later.
If you thread this up to the product-level, opportunities abound. For example, instead of storing data for a feature, see if you can get half the feature without the data storage. Or, if a certain feature is going to require a major shift in the way the UI looks or works, perhaps there's a way to blend in a v1 to the existing metaphors that can be replaced later. Etc
Exactly. You should aim to build fast, at least at first, but it needs to be understood by all that this is part of “build fast and iterate”. It’s not just “build fast and stop”.
As a software engineer, it's your responsibility to build the product according to the requirements.
Ah, the solid, dependable base that is the requirements!
I'd question the reason to wait. Shove it out the door so you can learn. I say that because I'm a professional and I've seen many projects fail before seeing a single user. I've never seen insurmountable technical debt grind a business to a halt. Not once.
> I’ve never seen insurmountable technical debt grind business to a halt. Not once.
I’ve seen this happen more then once. The best and brightest tire of the crap and leave to go do other things; and those who stay erode the culture into a cesspool of negativity. Sure the business trods along for a while but often the products just enter a phase of slow death and irrelevancy. At some point there’s some kind of private equity acquisition or transaction which just temporarily delays the inevitable.
To be clear, I’m not arguing for “strict requirements”. Just that the professional engineer is who needs to distill the chaos into clear and ready action. And, that “just ship it” can sometimes come with cost.
These articles usually come across as flippant. They are written from a small business or early phase/unproven startup point of view. Sure, don’t waste all your time tweaking tools, but at the same time, make sure you’re not shooting yourself in the foot because of the 50 kludges put in place that overlooked security or performance considerations.
I guess this is just a way of saying “there is no silver bullet”. “Just ship it” doesn’t always work.
This article was shared by a product person in my team who was genuinely motivated by it to "ship more, ship often" as he described it. People are gullible af.
I couldn't agree more. For 5 years prior to 2019, I would routinely get excited about building a project. Despite being an experienced Rails developer, I'd spend hours upon hours researching and learning all the latest and greatest tools and languages. I did not even get close to shipping an MVP in all those years. In 2019 I realized enough was enough and started building my ideas with Rails. It has been a joy and I'm close to having my 2nd project up and running.
Imho it's far from "just". The advice works for short lifespan products and/or single "builder" and/or when requirements don't change much.
Getting the product fast out there is not enough. It's more important to make changes fast, to allow product be shaped and built further.
It should be a balance (see "golden goose" tale). If you have a team of "builders", than tooling becomes even more important, 1 person's extra effort will make others more efficient.
"Just build the product" sound like a consultant motto that ships by specifications, but only that. You could "just" build a product that needs 1 hour to be deployed.
Edit:
I would say a better advice to "builders" would be just focus on the scope, it's very easy to get exited and overengineer things.
Whenever someone asked me what language or framework they should use to build their project, my default answer is "whatever you are familiar with". The honest truth is that for the vast majority of applications I have seen, the risk is in building the wrong thing or getting wrapped around an axle trying to figure new technology out, not choosing an old boring technology that won't scale.
It's fun the first 2 times you do it as you like. Then you start thinking about doing it right.
Then you start thinking about building stuff right from the beginning which is basically intelligence you've gathered.
It takes finesse to craft things quickly but with quality.
Bias to do stuff quickly is very hard to let go off. Doing things in an organised way has its value. Basically if you're not going to rewrite something in the next year, do it right now. Otherwise you're just borrowing time from future.
After you learn some lessons, it's tempting to check any action against all of them. But that slows you down, the more experience you have, the slower you will be. You don't want to do that either.
Anyway, it is very hard to stay away from both extrema. It requires constant self awareness, and even more learning, of the hardest kind where you are required to feel stupid all the time.
There are path dependencies. If the short term hack accelerates your ability to get enough traction to increase runway, you may survive to see the “right” solution implemented. whereas if you pursued the “right” solution more directly from the beginning, the additional delays would have killed you. Good technical leadership embraces the short hack and guides the project through righting it when the opportunity is there. (To fail to do either is an equal failure, and both are hard.)
Anyone claiming there is a clear answer to these questions is deluding themselves. Tactically, the best weapon is to recognize your own weaknesses, and it seems to me that engineers often have more of a bias towards performing tool and technology analysis and research in the name of avoiding the hard and often humiliating task of shipping software that users will almost certainly hate in its earliest versions.
If you are interested in going further down the pit, you may want to consider joining an infrastructure team at a bigger company. This way you are able to use your skills at the bottom of the pit to enable many more people to build the product faster.
The point isn't "just start coding". The point is to focus on the product(customer development and all) and not the tools/technologies to build the product. I have seen many more focused on the latest and greatest stack instead of using the tools they are already good at.
As with most things in our field, the opposite of a bad thing is also a bad thing.
When stuff is new, people have a higher tolerance for repetitive, error prone things. For tedium. For bullshit. But over time a portion of your team will lose patience. Their allergy to bullshit will return. These are many of the same people who pull off productivity gains, hard performance fixes, who fix hard to find bugs. Who prevent whole classes of bugs. If they don’t get to fix the things that bother them, they will go somewhere where they can.
What will be left are the status quo people. If you don’t have your project in a good shape when that happens, it never will be. You will have achieved mediocrity.
If things are good and the allergic people are still pushing? At some point it’s appropriate to move on. Just make sure you know for sure things are good and aren’t just listening to feedback from the status quo folks.
I've been messing around with notions like radical inclusion and radical transparency, so just want to add that this article resonated with me. I've reached the point where I have all the tools in the world at my disposal and haven't gotten anything done in over 6 months. Most days are a complete loss: nothing accomplished, just treading water till the next day, hoping something will change and I'll get my motivation back.
It's weird to be writing this now, since I started out so ecstatic about tech that I annoyed people with my enthusiasm 20 years ago. But no more, now it's the opposite. A sense of loathing and dread when I think about writing code. My friends say maybe I should get out of programming, at least for a while.
So not really sure what to do now. I want to build things now more than ever. But it's mostly along the lines of building stuff in the real world. Writing code in any form lowers productivity by a factor of 10-100. Sure it's great once it exists, but teasing solutions out of the aether is like trying to sketch with Photoshop. The more advanced it gets, the further it strays from pencil and paper. And I just don't have the stomach to bash my head against the keyboard for hours trying to do the simplest things anymore. I feel the loss of time weighing on my shoulders more than the sense of accomplishment. Without the "aha" feeling, coding loses its luster. Without passion, coding may not even be possible.
The best thing I could do for myself is forget the last 20 years. But I don't know how to do that. Any suggestions?
Get a job( even if it's for a few days, evening, weekend or part time) in some completely unrelated field. It's fascinating how much you can discover when you step out of the world where a standard notion is to either automate stuff or to make some smart,yet complex solutions to most problems.
I would. And honestly, I can. But I'm not the owner/maintainer of the full pipeline that gets The Product into the hands of the end user. I write the code. Someone else wants it stacked in a specific way that matches the production environment.
But the path from my desk to that environment changes twice a quarter. And each change requires me to change something in the stack of tooling. Why? I honestly don't know. I suspect it's some kind of incompetence: employee turnover means less-experienced folks take over, and they don't know, or can't be bothered to learn, the previous guy's stack. Or the stack is chosen by the new Senior Middle Manager every time that position changes because he's not familiar with that last iteration of technobabble.
Whatever the case, it's really because the company has become too unwieldy, hiring too many technology employees, and far too many business folk. You want me to stop "playing" with tools? Let me get deep knowledge on one set and stop getting new ones. Let me actually build something instead of forcing me to navigate the org structure every time "one inconsequential end user" wants to make a change to a feature.
This rings a bell or two. After spending years of creating projects with Webpack and wasting tens of hours on configuration, I just started my new project with parcel, where I just run "parcel index.html" and I'm done. I had fun configuring all the stuff before, but now I just need to get the work done.
It saddens me to see people growing a business and having to make tradeoffs due to hosting costs or trying to catch up with new tech.
My (opinionated) take on this if you are just starting a new business:
0. Lay your foundation on something that is battle tested and well supported.
Rent/buy a real computer (dedicated/root server), not cloud.
Use software that is already included in major/stable GNU/Linux distributions.
1. Build your stuff.
Get used to writing things.
Beware tech news.
There's been a change in sentiment here. Just build the Product is still neat advice that needs to be repeated. Sometimes we get too caught up with the plan, perfectititis, and only ever fantasize about building it.
In contrast, the more experience you get building products, the more your repertoire of problems grows. You start to realize that the code is only one part of the problem. Interacting with people is what makes or breaks your product. So, you plan better, you meet the right people to talk to, you figure out when to outsource and when to do things yourself. You take more time to build stuff.
But, you can't do any of that unless you first build a product.
The first example I thought of was on the C=64, with assembly language. The second was on MS-DOS with C++ and assembly language.
> Creating something useful using nothing but the raw materials of ideas, with essentially limitless possibilities, with your own creativity as the only physical limit on what's possible.
As soon as there's an OS and compiler and runtime in between me and the computer, this all goes out the window. It's an artificial world with pre-built materials, and limitations everywhere you turn, and 99% of the ideas you work with will be someone else's, and how to fit in with that.
My view of a computer in 2020 is all about the tooling, and I spend the most time on that, because everything I touch is someone else's tooling. The "endlessly fascinating process" that hoodwinked young me into software no longer exists.
I didn't pick up the "C=64 Programmer's Reference Guide" because I mistook it for a business manual, or even because I wanted to build Amazon.com and just needed to write the infrastructure first.
That's technically true but I think it misses the point. A CPU (at least an older one) is simple enough that it can be fully understood by one person. It was probably designed by a very small team. If you want to know if something works, you don't have to read thousands of pages of documentation. You can just try it. Nearly any combination of operations you put together is going to do something.
None of that is true of the big complex language/library/framework/OS stacks we have today. Most of my effort programming today is on something simple to describe in words, but complex to encode in the language's type system, or the framework's classes, or the OS's security model.
I feel that Lisp is the closest I can get to those early systems I grew up with. It's based on symbols rather than bytes but the flexibility and coherence is the same.
Today we have different systems for different needs. You can use an interpreted language like Python to get simplicity or you can use something like Rust where a program essentially doubles as proof of correctness. Strong typing is really about managing complexity as the program grows. This was never an issue on 8-bit micros because there just wasn't that much room to grow anyways.
At the risk of seening facile, the "just" the title resulted in my being hostile to the article. But, to try to be fair, I read it.
After completing the toughest gig of my professional life to date, "just build the product" as an instruction/conclusion feels both useful and flip.
In my head, I have an idea for a product. Sod all money in it. But as useful tool for something I care about, the "just build it" mentality fits.
However, in the roof-over-head world of making something useful for an enterprise customer "just build it" feels trite.
I went in to as a software consultant/developer to a fairly non IT literate organisation and was tasked to deliver to their specs. The big and costly challenge was to discover the product. To understand and challenge their specs, see the gaps, refine the UX and deliver. In my naivety, I thought the the customer would be receptive to this approach. Turns out they were - but only because I shouldered the cost of doing so. A massive learning experience for me. The customer got a product that exceeded their expectations - but, for a fixed price gig, commercially a failure for me.
I wouldn't change my willingness to jump in this time around, but I won't repeat it - and would now walk away early from a customer that thought they had the solution all figured out (as opposed to having the problem figured out). In this circumstance "Just build the product" feels trite and self-indulgent. Clarity on what to build is hard earned. And the opportunities that iterative development affords to a a software development organisation are a hard sell to one whose core expertise lies outside IT. Possibly a failure on my part, certainly room for improvement on my part.
Sure, if the product is something you don't intend to make a business out of. Otherwise, you should be doing your homework ahead of time, and seeing if this is something people are actually in need of. Most ventures I've worked on have been derived from the immediate needs that I found not being covered in my day to day life from others.
This is the right advice if you want to nerd out on technology. But my experience suggests[1] that if you want to build a business it'll be cheaper to validate problem/solution with phone calls and mocks / designs before writing code.
This is because:
* It's cheaper to make changes before code has been written
* A functioning product isn't the best sign that you're making progress - paying customers are[2]
Don't get me wrong. I like to write code as much as the next guy / gal. But I've made the mistake of writing code first. And I've worked with clients who - despite my best attempts - decided to forego validation to build a product that they spent a lot of dev dollars on to fix once the market met it with a trickle of interest.
I read it differently--this is not targeted at founders trying to validate a business plan, it is targeted at engineers whose job it is to build the product, and he's saying to quit fiddling around with your tools and focus on building the product--which is more fun anyway.
"It's important to learn how to use your tools well, but once you have, stop prioritising that. They're good enough now, you know how to use them. Don't get trapped in this local maximum of optimisation. Go and build stuff."
10 years ago, I wanted to learn Ruby on Rails, so I bought my first MacBook Pro. Just grabbed it off the shelf at the store.
I got my first software development job, and everything was great. I thought it was odd that the other guys didn't know much about Macs (and didn't really seem to care), so when they'd upgrade the OS I'd have to fix everything for them, or they'd have issues with gems etc.
I started buying every MacBook as they were relased. Installing beta software, upgrading the RAM and HD just because I could. Spending countless hours reading reviews, posting on forums...
The other guys just wrote code. Eventually I got tired of keeping up with the crap (or maybe I just got older) and now I crank out code on my far-from-the-latest MacBook, running Mojave. shrug
It was fun stuff, but I could have spent that time (and money) more productively.
It's really funny to me that someone could get excessively sucked into tinkering with and "nerding out" over Macs, the desktop/laptop platform that's by far the least inclined toward that. Usually stories like this start on Windows or Linux and end up on Macs precisely to minimize time & brain space lost to tinkering and esoteric platform knowledge just to keep things basically working OK, as the appeal of that sort of thing wears off.
I don't mean that in a bad way! It's just one of those "huh, so many different experiences out there, who'da thunk it" things.
I've used Windows, Linux/FreeBSD, and MacOS (and heck, even Solaris) extensively as desktop OSs. Windows is only better than for MacOS for tinkering if you're not comfortable using the command line.
How do you get quality feedback? In my experience people will often say yes when asked or shown a mock up but will not buy. You don't find out who will actually buy until they try a functional product.
I really suspect that the lean startup method belongs in the early web era when there was a ton of low hanging fruit with simple market research and simple MVPs. All that low hanging fruit has been picked. Today it's pick your brutally hard problem and iterate for 1-2 years before you get a MVP that you can test.
> How do you get quality feedback? In my experience people will often say yes when asked or shown a mock up but will not buy. You don't find out who will actually buy until they try a functional product.
Ask them to pay you based on the mocks. If they say no, ask why. If they say yes, take their money and give it back in N days if you haven't built your MVP. I've done this BTW - it works.
> You don't find out who will actually buy until they try a functional product.
You'd be surprised how many people have gross business problems that some well-placed code would solve and they'd be thrilled to pay you for it because the other options suck.
I have real trouble wrapping my head around this kind of thing because I can't imagine paying for a product under those circumstances, no matter how useful it'd be. I get that it must work since so many people say it does, but it's totally alien to me.
If you don't have something to sell me, now, why are you asking for money? Am I an investor? No? Come back when you have a product. I'll probably still say no because I won't expect your business to last very long, but you'll be 100x closer to a "yes" than you are now, which is about as far from it as you could possibly be. Is this an unusual attitude?
Just build the product - the purest most minimal version you can. I mean be judicious with the knife, and slice like it's going out of style. Accept it - you're throwing out 100% of the code eventually - be fine with it; it's not ideal, but you'll ship and be live. Add the analytics you need - test hypotheses. Reach out to people who drop in and drop off, they're more valuable than features.
Don't agonize over "this isn't done", "this isn't perfect" or "it needs X to be useful". Get it out, charge for users, and you'll build a sustainable business, or it will fail quickly. Sure, this may not be VC sexy - but you know what, you can build product quickly, validate or toss and idea and move along or improve, based on feedback.
This ships. It ships repeatedly. It's not perfect, it's not awesome, but it works, always.
> Ok, now -- what language was it written in? Which editor did you use? Use any open source libraries?
> In the best way? How long did it take to run the build? Was it easy to debug?
> Was it as memory efficient as it could have been?
> Were you building it on a really slick machine? What was your keyboard set up?
This article is about your improving your life as engineer, questioning your technical way of working is how you grow, but not always the way forward. Search this article for the words "company", "business", "startup" or "customers" and you will find 0 hits.
As someone who built probably 10 apps / businesses before I read the lean startup, and learned to validate things first, I think "JUST DO IT" is about the worst advice anyone can give you.
Maybe I was and still am a complete idiot. But I think a lot of people would be like me and just assume that lots of people want X, Y, and Z -- so go out and build the thing, and then realize nobody wants X or Y, and no one is willing to pay for Z.
I started doing financial models when I get an idea. What I always find out is -- even in my wildest dreams -- these ideas wouldn't pay more than my current job.
Granted, I make a lot of money. But I think the vast majority of people on here make more money now than is reasonable to believe their business could ever make, if everything worked out.
How much of that is just people wanting to make their own mistakes? This is one of those things where people only learn from making the mistake themselves.
Most products are mainly built by people who face that same problem their app solves. This gives them a reason to build it. As worst, it's used internally. At best, it's a side hustle or much more.
Conversely, you cannot validate product market fit without a product. Validation via “Is this something you can see yourself paying for” isn’t really a substitute for actually getting people to pay for your product. At best it will filter out just the worst ideas.
I agree. Earlier in my entrepreneurial journey I've spent a year building a product without validating it properly or validating it with biases (validating it with like minded people) only to find that not many wanted it when the product was released[1].
Tangentially, recently this motivated me to build a platform for validating problems by making people post their problems and even validate startup ideas as solutions to those problems[2].
It's fair to say this is line of conversation is tangential to the original post, but respecting the passion of your reply, do you think ideas like those represented in The Lean Startup perhaps over-rationalise the creative process?
Like, taking a rough guess, I wonder if there aren't as many successful startups, as there are successful writers. But no one takes those guides to writing a successful book quite as seriously as those guides to running or starting a successful business.
Not every problem can be solved manually. There are many businesses where the technology itself is the valuable thing, not just glue between humans doing all the work. "Don't write code" is smart when the code could be replaced by a person and a spreadsheet but that is not always the case.
Examples include circuit board layout programs, finite element modeling, any engineered hardware product, entertainment (like computer games), or anything other than pure business, really.
> Examples include circuit board layout programs, finite element modeling, any engineered hardware product, entertainment (like computer games), or anything other than pure business, really.
"Don't write code" really means "prototype first for your potential users". So if your code won't have users/customers, then write away. But hardware and entertainment can absolutely have low-fi cheap prototypes.
This approach is designed to elicit learnings to make a better product that's cheaper and faster to build. Of course you can write code first, but my experience suggests that that's a slower and more expensive approach.
To further your point, there is always a risk that some assumption you're making will turn out to be wrong. You should build the product only when the risk of not building it is greater than the risk of your assumptions being wrong.
This is basically an attempt to gather more information before you act. In principle, that's an Obviously Good Thing. But you have to question whether that information is actually as conclusive as you want it to be, and whether you're changing the outcome by observing it. There's two problems with the information you gather by making phone calls and showing mockups/designs:
1. Mocks/designs only communicate a fraction of the product, and often the parts that aren't visible in mocks/designs are the most valuable parts of the product. Speaking in vague terms: I'm working on an app where the main value is that it calculates actionable numeric values that users typically calculate in spreadsheets. The UI is certainly a selling point, but users aren't going to easily understand the connection between the new UI and the old spreadsheet formulae without playing with the actual product. Phone conversations are likely even less communicative.
2. Communication is a two-way street: releasing early allows you to get information from your users, but it also leaks information to your users, which may not present the image you want. Kickstarter has shown that with good enough marketing you can get paying customers with literally nothing. But you can also burn customers so they never want anything to do with your product ever again. There are numerous high-profile failures-to-deliver that have killed not only products, but the reputations of individuals and companies. But failure doesn't have to be that catastrophic to lose customers permanently: all that has to happen is for someone to pay for your product, find it a bit lackluster, and decide to cancel their subscription. That user is worse than a non-user, because they are never going to be a user again, and might tell others about their experience. Short term success not only isn't an indicator of long-term viability, it can cause long-term non-viability.
Sure, it's cheaper to validate problem/solution with phone calls and mocks/designs, but you get what you pay for.
The best strategy probably lies somewhere in the middle: code a minimum viable product, but really make sure it's the minimum, and really make sure you think it's actually viable. A good compromise might be to release a discounted beta for select users--that lets you get feedback from paying customers up front, but also sets expectations so that users don't get the wrong idea about your product before it's mature enough for a real release. It also limits the exposure, so even if you burn a few beta users, you don't burn your entire potential user base.
> I'm working on an app where the main value is that it calculates actionable numeric values that users typically calculate in spreadsheets.
Even this sentence is a perfect tool for validating the market: I have no idea if the product is for me! ;-)
(I get that you may be keeping your product’s specifics vague here, but by doing so you’ve provided a contrived example of how a simple description of the product itself can help find information about the target market. I have no idea if I’m in your target market, for example, so if I’m supposed to be, that’s a problem.)
You probably are my target market--it's a pretty broad demographic. But if I showed the product to you now, you'd probably be unimpressed and forget about it, which probably loses you as a customer forever. Better to wait another few weeks and give you something that actually solves a problem you actually have.
There's only one chance to make a good first impression.
I'll write something (or even just put together drawings) for someone and the first review of something like really light prototype / sketch where I get direct feedback from decision makers and/or users is FAR MORE TELLING about where things are going to go than anything else.
I'd say if you have a set of features and a toolchain which enables you to build them then ofc go for it.
However that's not my usual experience with any of my projects even personal ones.
The thing is I don't know what I'm going to build, in the contrary, I am aware it will take several iterations to figure it out. Because of that I have to check out what is "out there" in the ecosystem to make sure I can change directions sometimes if I want to. I want to maximize my freedom in that niche. Because of that every time I have some additional information about the whole project (in which features come and go) it's an option to step back and reevulate existing possible solutions in my mind and go do some further research when necessary.
My experience is when parts are not thought out in a project then they will slow the entire workflow down over and over again.
Just build or just not to build: I think this is a wrong question. When start to build & how/what to research are much better I think - and with real examples its much more useful I think.
Eg.: I'm totally done with relational and document databases. To me it seems both suck hard so lately I am investigating graph dbs. No, I won't start a new project until stupid rigid schemas / migration problems / schemaless weaknesses (dupe) won't just go away.
Maintaining old shit is enough for me I really don't want a new broken system as technical/real life debt.
Ofc you can go out and build pages with jquery which do generate tons of money for you, but others will be able to do the same when they've figured stuff out. What then?
A lot of discussion of best language, etc, is just bikeshedding. (See Parkinson's Law of Triviality) We talk about technologies we use because it's easier and safer than talking about the actual product.
Yar, funny those people who comment "no never build the product first, do marketing and find if there are customers for it", don't read the page.
"davnicwil" is, guess what -> "Open source" "Freelancing" "Consulting"-> motto "I turn ideas into products"
He is just trying to sell his services to people who want to build the product, and guess what he advises them to do that, and that is his page. This is not some holy grail advice, get some context and step back people.
Ok I know everyone is reading only headlines here anyway...
That's not what TFA is talking about. This is not lean startup advice.
It is advice for engineers to focus on the utility of the thing they are making for other people, rather than focus on the toolchain that allows them to build the thing.
AAbundant past examples have shown if a business “just build the product”, it will soon does not need to build any product any longer ... since it will be belly up :-(
If I'm building a project for fun at home, then it's typically specifically to learn about a new thing (which I kind of assumed was the case for most people); either a new programming language, or a new editor, or a new library or two. If I short-circuit and "just build the product", then that is sort of negating the purpose of the project.
If I wanted to "just get something done", I probably wouldn't have done any projects in Haskell (back when it really sucked for tooling), I wouldn't have learned category theory, and I wouldn't have gotten any work in research.