All advice is a two-way street. I think at this point, the proverbial "advice market" is saturated with this idea that "doing" is far superior to "thinking". This is because, traditionally, hackers tend to lie squarely on the "thinking too much" end of the spectrum.
I'm interested to read at least one post on the opposite advice -- what happens when you're too heavy on the "doing" end of the spectrum? Are there examples of startups failing because of too much emphasis of execution? At the very least, the "ideas are nothing, execution is everything" meme is clearly logically flawed. You can execute as fast as possible while creating zero customer value.
> Are there examples of startups failing because of too much emphasis of execution?
Plenty, and we see it every day, except they don't call it "failure by doing too much". They call it things like "not understanding the target market" or "focusing on features rather than experience" (more generally "not thinking enough")
This is exactly what the Lean Startup talks about. Granted, I feel like the post was targeting the topic of procrastination more so than anything else. By Sam's logic, brainstorming and analyzing your business's market would fall under the territory of "doing", while reading and writing on hacker news may not.
"what happens when you're too heavy on the "doing" end of the spectrum?"
I can't think of a startup, but I can think of people like that. The first people that come to mind are the Mythbuster people. Very handy, very good at cranking out their ideas into meat-space - but my impression is that there is very very little critical thinking. This is probably in large part due to the demands of TV (You need cool gadgets and experiments - who cares if the experiment is poorly conceived when it looks cool?)
But a lot of hobbyists also fall in to that category: doing projects that have already been done, or ones where the solution isn't particularly intellectually exciting/innovative/stimulating but just mostly takes a bunch of time (ex: spending your weekend programming a PLD to control a stop light).
It's kinda hard to accuse these people of "doing" too much.. b/c doing is better than just sitting watching TV. But say instead of programming a stoplight all weekend you for instance read some textbooks and learning some higher level math, or read some blogs to get some inspiration, or read some scifi to get in a more creative mood - It gets kinda harder to make an objective comparison of which is "better".
Technical Debt = When you coded without thinking AND your project is successful and growing. It's debt because now you have to go back and fix/change the code.
Technical Grant = When you coded without thinking BUT your project is NOT successful and fails. It's a grant because it saved you time.
Most projects / startups fail so for most people "Just Do It" works better. Plus the product you envision is almost never the product you end up with. So all that thinking you invested can be a waste of time.
Have you ever heard of the concept of Technical Investment? Sometimes one's skill level simply makes it really difficult to avoid technical debt, but as you gain experience, your skill level rises and your code begins to minimize debt more and more. Rather than spend your time refactoring, if you spend that same time improving your skill then the loss of debt in the future may outweigh the debt you've already accumulated at each step.
Improving skills can take the form of learning a new tool (css -> sass), a new programming pattern (like currying and monoids in functional programming), and more along those lines.
Granted, a huge problem with technical debt comes when your playing with a team, and if X people are going to be using your code, but it takes Y time to explain how that code works, then if takes Z time to refactor that code, and only W time to explain after the refactoring. Then, if XY > Z + XW, refactor every time!
It almost sounds to me like if the product we end up with isn't what was envisioned, then it wasn't executed properly. I'm not saying that's a bad thing, since how it ends up is usually due to the market guiding the product's development; and if the market is holding your hand, you're probably making some money, which is the goal of most startups.
But I would bet that if you let the market dictate too much too soon, it will be harder to truly innovate, which is usually what the original vision was about. I'm obviously making some pretty big assumptions here but people know only what they know, and sometimes it takes carefully timed and constructed execution to snap them out of it to create a new paradigm and take things to the next level.
I believe the best solution right now may be to get an MVP without worrying about technical debt too much while not purposely doing things to step on your own feet while acknowledging you'll need to do a full rewrite before 1.0.
I used to think that way, then I realized that I should worry about building a product people will pay for before worrying too much about technical debt.
It's almost a Maserati problem when you think about it.
i think that is the right way to think on most software projects. But on projects that require rapid iteration and user testing(such as hit-based projects like games), technical debt could cause your iteration rate to be slowed to a crawl, and in the end you produce an inferior product.
Had the technical debt been paid up front, the iteration rate might have been much faster (e.g., good encapsulation and abstraction allows you to switch out things quickly to test different mechanics in a game), leading to a better end product that people will pay for.
I am of the opinion that "ideas are nothing, execution is everything" grows in part out of the lack of adequate language and mental models to distinguish amongst ideas of the armchair politician variety and ideas with legs. There are some words to distinguish such things, like hypothesis and theorem, but they mostly don't apply in the realm of business. I have been trying to sort out how to do a post on that very topic but I am not ready for it.
That is very well put. I am often amazed what a big difference certain ideas make it possible to build complex things quickly and with low amounts of bugs. For example building a parsing subsystem "properly" as taught on compiler courses vs haphazard combination of regexps. It is mentally much more demanding, and requires more effort up front, but then to your surprise, every change you make just works almost immediately, and there are no hairy corner cases to resolve (this is kind of declarative vs imperative, but not quite). Another example is mathematical models, such as Markov Models and the like, where you can have a really complex behavior, but your parameters are simply matrices and all operations are some sort of matrix algebra. Difficult to understand at first, but very powerful and "clean" once you do.
In contrast, as you say, there are huge amounts of armchair ideas that are not worth very much even if they are correct. For example "software will eat everything" is something I believe is mostly right. It is also a business idea with direct implications for action. Despite this, it is only valuable to set the general direction (let's do software), but not any specific cases. It does not mean that every case of transforming a traditional business into a software one is going to be a grand success, or even profitable. In fact, these types of ideas have a tendency to cause one to forget the exceptions from the rule, and thereby being actively harmful.
True indeed. Some ideas are really valuable, and I think it's mainly those that are well-informed, committed to a specific market (typically a niche) and ripe for execution.
Maybe it's because many of the ideas in the "ideas are nothing" category are twitbook/fourit/squaresnap/flickchat/... clones, rather than ideas like "let's build a product for market X using tech Y to reduce problem Z".
I think it's a little more complicated than that. If you pay close attention to behavior, you can infer what people really think, on a deeper level than what they admit to. We have concepts for that in spiritual and psychological realms but not really in the realm of business. We have ideas like karma and Akashic records and the subconscious and Freudian slips. In crime/law (police, courts), we have ideas concerning motive and intent. We don't have ideas like that in business, at least not in a well developed, formal fashion. I think those deeper patterns determine whether an idea has legs or not and it is those deeper patterns we need to figure out how to talk about, how to mentally model, etc. Those patterns are the ones that are not armchair politician style pontification but we don't really have a formal framework for examining ideas deeply and thoroughly for business purposes.
(Edit: In some ways we do have such a framework. For example, I am sure that venture capitalists have a lot of paradigms for doing just that. But this meme of "ideas do not matter" still persists and is oft repeated by venture capitalists themselves.)
We do have a word for that in econ/business: revealed preference. In the business world and the ones you mentioned, however, it's not always a reliable indicator; people routinely do things they do not want to do due to loyalty, face saving, fear, coercion, group pressure, and a pile of other things.
This morning I talked about working as a dishwasher in a restaurant with a coworker. I last did that when I was 18, more than 25 years ago, but I remember how hard it was (busy Chili's on University Drive in Fort Worth TX, next to TCU). There was a lot of working, but not a lot of thinking. And you get wet too.
I think the point is: you should measure success by the things you've gotten done. Thinking has no value if it doesn't lead you to do anything. If stopping and thinking leads to a better product (and I think it usually does), then it's worth doing.
Not enough thinking leads to less consideration of alternatives and vaguer goals.
That being said, it's very, very difficult to dismiss mistakes, as wastes of time, as everything is a learning opportunity in the end. Of course mistakes have consequences related to resources (time, money, etc.), so it depends on how long your game is (and therefore how large of a margin for error you have).
I think it's very easy to get into a mode of selling something that cannot scale. If it's genuinely valuable to the customer you might be able to figure it out, but if you cannot somehow get LTV - CoCA positive then you will die painfully.
I've seen too much companies fail because of spending too little time of thinking what the customer actually needs. They just do what they like. In fact when studying UX, I've noticed a lot of companies don't actually even know who their most important client is and what (s)he wants, what her fears and motivations are and how she will go about getting what she wants. Creating a ux vision and strategy makes a lot of difference. (Based up on talking to actual potential clients Not based up on imaginging).
About every hacker starts by doing too much. We work very hard to learn to think before doing, so if you want to know how it feels to do too much, just remember the times before you learned to think.
Groupon (and everybody else looking at it) never stoped to think if their business model was good. They were so good executing it that no one thought it wouldn't.
Groupon had (in q3 2013, the latest I could find) 595M in revenue and 14M in operating income, an EPS of 0.02 excluding "excluding stock-based compensation
and acquisition-related benefit", and 1.1B in the bank.
Not a smashing success, but is it a failure? The jury is still out on this, imho.
> Not a smashing success, but is it a failure? The jury is still out on this, imho.
Given that success and failure are both relative terms, I would say Groupon is only a "failure" if you're measuring it by the perceived success it would have. So I would say that if you expected Groupon to be a $10bil company, they are a failure...but if you expected Groupon to be a normal company of a few million in revenue, then they are an amazing success.
Although Groupon may not have had the most lucrative business model in the world, I still feel like they've done a great job at "sticking to their guns" and not trying to enter all kinds of other markets (and failing miserably).
I found out my mother was replacing thousands of duplicate rows in excel by hand, had she thought about it and googled the problem she would have been done in a few seconds, instead of a few days.
I'm interested to read at least one post on the opposite advice -- what happens when you're too heavy on the "doing" end of the spectrum? Are there examples of startups failing because of too much emphasis of execution? At the very least, the "ideas are nothing, execution is everything" meme is clearly logically flawed. You can execute as fast as possible while creating zero customer value.