In math, 4+4=8. But, not just 4+4. You can arrive at at the same outcome in several other ways: 1+1+1+5, 2+6, 10-2, etc. When creating a startup, you want success, but there is no clear cut path to the solution.
What's important? Identify a problem. Work at it like a puzzle and create a solution. But, create a crappy solution and employ your customers to help drive the direction of your product. Don't be a yes man and don't be afraid to say no to feature suggestions.
Be passionate. If you're not passionate about building something, you'll lose motivation. If you're not motivated, find another problem and work on building a solution for that one.
Trying to come up with what is the most important field is a very open ended question. You could spend a year learning a field/technology/programming langauge and then find out you don't need it. Build something with what you know. Don't prematurely learn something. Learn enough to get started and then only learn more when you need to.
If you think you need to learn a certain field in order to get started, you're procrastinating. You'll find yourself in an endless loop of "I'll start, but only when I start learning or have mastered X."
I suggest PP since there is no Scalability 101 that I know of, and PP really shows you limitations of current processors and how to get around them -If you understand replication and queuing at processor level you can implement them at "Enterprise" level".
Neither of those are new subjects, and although you can learn both of them "on the go" (Just ask the Twitter guys if they thought of database replication and sharding on day one) they will save you lots of time and money.
But there are lots of problems that stretch the mind. Perhaps you choose to spend your time learning about modern computer architectures. If this interests you, great. But from a startup perspective, it probably has a lower expected chance of spinning out a startup for you than say working on an information retrieval system.
But perhaps it is better worth your time just talking to people about their problems. I'm sure there are success stories on both sides of the spectrum.
It's more complicated than creating something that people care about. You need to solve a problem in a creative way, and also figure out a way monetize, while being passionate about it at the same time.
Think about web analytics. Google bought Urchin years ago and is somewhat the standard authority for web analytics. You would think all innovation in that market would come from Google. Then you have a company like Clicky (getclicky.com) pop up from nowhere. They do analytics, but they add a twist: real-time analytics.
Don't worry about thinking up something people will care about. You're not going to know whether someone will care about or pay for your product/service until you launch. Start by scratching an itch. Don't have one? Scratch someone else. If it were as easy as looking into a crystal ball and figuring out a solution that people would pay for, everyone would quick their jobs and create their own startup. Why did Facebook succeed where Friendster failed?
This is the importance of starting small, or everyone's favorite term, minimum viable product. What are the necessary features that someone will pay for? Maybe you launch with what you think is the MVP, but customers then say, "It's a deal breaker if it doesn't do x." This is the importance of starting small, you can change direction quickly. Tim Ferriss talks about preemptive testing in The 4 Hour Work Week.
>But perhaps it is better worth your time just talking to people about their problems.
Exactly. And the great thing about this is that there are a ton of problems outside the realm of IT that need to be solved, where we have a chance to make a difference and build solutions that matter.
The takeaway is that the barrier to entry is very, very low. A little bit of money and some elbow grease can take you a long way.
Good luck!
So, less emphasis on theoretical math, more on applied statistics. Distributed computing. Experience in huge data sets and the infrastructure technologies to analyze them.
You also need in-depth understanding of a specific application domain, your choice, but it should be one that interests you because you are going to be involved for a long time.
Startups succeed on the basis of solving a problem that is big enough and common enough to get lots of clients who are willing to pay heaps. Do yourself a favour, read up Steve Blank's customer development process if you haven't already done so.
This is the essence of a software start-up, the freewheeling idea factory, that does not have layers of bureaucracy and work that does not readily translate directly into a product.
You have less people with their hands in the produce so the layers of documentation, design and communication do not have to be as stringent as it does in the enterprise. Even in the enterprise it is overdone due to the pushing of best practices by enterprise vendors with some snake oil to sell.