Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We are constantly hearing advice like "Scratch your own itch," "Find problems close to you," and "Code what you know," which is all good advice for finding a startup idea.

What then, do you do if you're not exposed to much?

When I spent time talking to people in SV 2 months ago, I noticed something I never expected: lots of people have very little exposure to "real world" problems.

People come up with "me too" startups because that's all they know.

Sure it's easy and cheap to start a business, and if you're smart and can hack, all the more reason. But what about the giant issue hardly anyone mentions: real world experience.

I've been doing programming work in real businesses for years and still get excellent startup ideas from my customers almost every day. In the past week alone, I have been challenged with problems I've never seen before that are really affecting these people. Just a couple of quick recent examples:

- One customer is preparing blanket purchase orders for '09 models, but since the SKUs change every season, their ERP system is of little help.

- Another is setting up a new warehouse, but their app won't allow bulk updates so they have to hire clerks just to enter 10,000 new bin locations.

- Another has a call center whose response time has doubled with an upgrade to their app. Now they want the new release's functionality with the old release's interface.

And this is just one week! People will pay big bucks for technical solutions to these real world business problems.

My advice to a young hacker with lots of skill but not much experience (outside of college apps): you may want to consider getting a job for a year or two. I know, everyone wants to start the next <whatever>, and get rich now and no one wants to sit in Megacorp's cube farm. And a startup, even a failed one, may be a better education.

OTOH, you will acquire dozens of great startup ideas (and contacts) and avoid the "me too" trap. Something to think about.



I agree with all of this and would add just one observation: All of these valuable, profitable ideas will probably seem really boring to (e.g.) the audience at the typical Web 2.0 conference. SKU's, yawn. Call centers, yawn. Warehouses, yawn.


"Boring" is in the eye of the beholder.

Once I really understood relational data base theory, those things (SKUs, call centers, warehouses) became exciting to me. A chance to practice what we preach. My customers are laboratories, much more so than Carr Hall 203 was in college.

OTOH, most people I know think everything we do is boring. They'd rather watch TV and talk about each other. Fortunately, we know better.


Dude...I understand relational database theory, and those things are boring. I'd rather gouge out my eye with a rusty spoon than normalize schemas for SKU databases at BigCo (I wanted to gouge out my eyes when we used them as case studies while learning relational database theory!)

That's not to say that there aren't interesting engineering problems buried in there (e.g. how does one build a high-performance, distributed database architecture that can support tens of thousands of concurrent users, blah blah blah), but for the most part, the interesting portion of that kind of work is done by the (small) company that developed the scalable database technology in the first place. When you're hired as the guy who puts it all together as BigCo's real-time widget tracking system, you're mainly splicing together chunks of other people's previously interesting work.

Most paying work is boring -- that's why it pays. But if you can eliminate a class of boring work with a good piece of software, then you've got a business.


Dude...there are 2 kinds of things we can work on: things for ourselves (internal) and things for others (external).

"Building a high-performance, distributed database architecture that can support tens of thousands of concurrent users, blah blah blah" is an internal project. One we do for ourselves. So that we (as users) have what we need to do our jobs for others.

Personally, I prefer external projects. Both of my mentors were engineers. Everywhere we went, they had something to say about what they observed:

"I wonder what would happen if they put a Coke machine right there..."

"The plane landed 17 minutes ago, and so far 0 bags have been removed..."

"If we move the inspection table to the center of the department, we will save an average of 116 steps per person per inspection..."

That's how I think now. I have real world customers and prospects with problems like these all the time. I love it. I'm always on the lookout for problems to solve with my apps.

I simply don't care about working on any internal projects unless I have to. There is probably a solution somewhere that one of you guys already did. So I'll use it to help me do my job.

Sorry you find what turns me on as boring. I guess that's what makes horse races.

If we ever meet, remind me to hide all the rusty spoons.


I'm puzzled by this whole "external" vs. "internal" dichotomy that you've built. Perhaps noticing that your plane isn't being unloaded quickly is "external", but the likely solution to the problem (building some sort of high-performance, distributed database-backed scheduling architecture that track thousands of bags, flights and people in real time) seems to become "internal" very rapidly. Where's the line?

Moreover, what you describe as "external projects" sounds suspiciously like "walk around and fix individual problems in the world". That's great, but it's not scalable -- it's consultancy. Somebody hires you, and you tell them to move their Coke machine to save 116 steps per inspection. To me, the difference between that and an interesting software problem is the difference between noticing that a Coke machine needs to be moved, and writing a pedestrian traffic simulator that can be used to optimize the positions of Coke machines in any context...but maybe we're saying the same thing?

In any case, it's never a good idea to let your spoons rust.


Those were just examples of what others did to influence me. That's all.

I used to have to write the tools I needed first just to be able to do my job. No longer. Almost all of my tools are available.

What you call "walk around and fix individual problems in the world", I call "find problems anywhere, then build scalable solutions". Sorry if I didn't make that clear.

It's the antidote to OP's original complaint of "me too" solutions.


This is good advice. Founding a business takes skills, desire, and vision. Knowing what people actually need(rather than guessing) is part of the vision.


It's true. Sometimes the echo chamber out here can be almost deafening.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: