The best way to answer this question is to break the three concepts you've raised into separate pieces.

VALIDATION

You say you've validated an idea, but I'd like to know how. Did you run a kickstarter? Do you have a landing page up? What is the sample size? What metrics did you track? Do you already have people willing to pay? What other evidence have you collected to prove the market opportunity is real?

Reading between the lines, my instinct is that you haven't yet validated the idea and are early in the process. Validation should be your absolutely top priority. The other parts come later once you know the market exists. There is lots of material available to walk you through the validation process.

SCALING

You are right in the second part of your question. As a founder, you have to find ways to make your company scale. And note: it's not the product that scales, but the business model and operations behind it. Products don't scale themselves; that's the "build it and they will come" mentality. With physical products it's even harder than pure tech because you have the additional complexity of solving all the supply chain issues of production and delivery. It is possible to scale product companies, but the products definitely don't scale themselves.

So (1) a "product" won't scale, a business model does; and (2) you won't be able to know in advance because it's your responsibility to design a scalable model that will help you deliver the physical product in line with demand, on time, at quality, and at a profit.

CROSSING THE CHASM

Your reference to innovators and early adopters refers to the technology adoption life cycle covered by the book "Crossing the Chasm". There is an important note here: the "chasm" is not between early adopters and innovators, it's between those two groups and the mainstream (ie, the "early majority" or "pragmatists"). The reasons early adopters buy a product is different to the mainstream. Finding a product that appeals to a small group, but does not yet appeal to the mainstream's higher demands for quality, support, less behavioral change, etc is where companies get stuck.

It comes back to validation again. Who did you validate with? Just a group of 15 hyper adventurous tech-friendly boffins with a special interest in your area ... or are you solving a problem millions of people have and you can prove it because you've found 10,000+ of them willing to give you a down-payment?

Mass market appeal is tough to get. Pebble arguably never got there, but Coolest Cooler arguably has. They are the two most successful kickstarter projects ever and both achieved 62-68k backers. But mass market appeal? I'd give it to Coolest.

One final thought on crossing the chasm is that it's easier with product iterations. Version 1 might suit the early adopters, V2 might earn higher market share among the early adopters, V3 might be where you start to see mainstream sales starting. Each product needs to improve and adjust to customer feedback.

--------
Happy to go into more detail on a call.

There is a legendary example of this: Jack Dorsey being the CEO of both Twitter and Square simultaneously. Yes, it is possible to hold two jobs. It's even possible to be the CEO of two billion-dollar companies. It's far from easy, but it's possible with an extreme dose of discipline and time management.

I heard Jack personally tell the story of how he managed his time at a fireside chat he did in New York. The closest I can get to an online article that talks about it is this: http://money.cnn.com/2011/11/13/technology/dorsey_techonomy/

Take a look at the way he splits the days of his week into themes. Each of his 6 working days has a purpose.

Monday: Management meetings and "running the company" work
Tuesday: Product development
Wednesday: Marketing, communications and growth
Thursday: Developers and partnerships
Friday: The company and its culture
Saturday: (no work)
Sunday: Big picture strategy

But he then goes next level and splits his time between two companies by alternating mornings and afternoons in each office. The article mentions him working 16 hour days – 8 hrs at each company – but when Jack told the story himself, he said he was splitting mornings and afternoons between the companies.

Monday Morning = Twitter
Monday Afternoon = Square
Tuesday Morning = Square
Tuesday Afternoon = Twitter
Wednesday Morning = Twitter
etc

This might be an approach you can think of taking. It means you make it clear what your schedule is, when you will be working on different aspects of each job, and then be incredibly disciplined about sticking to the schedule so other people can accommodate and work with you.

This is a very interesting question and a tough problem for many entrepreneurs.

It turns out I wrote a detailed blog post on the topic just a few days ago. See the link here for full details: http://stavreas.com/designing-strategic-partnerships/

In short, I believe there is a 4 step process an entrepreneur can go through to propose, design and negotiate a strategic partnership:

1) Identify an opportunity which is unattainable to both parties, but attainable if they combine forces. If both parties are excited about the opportunity, they'll sit and talk. The un/attainable opportunity is the "pitch" that will get the parties to the table.
2) Identify the "interests" each party has in pursuing the opportunity. This is crucial. You have to look past "asks" or "wants" and find "interests". Underneath every ask is a reason. Get to the reason, it will give you huge flexibility to come up with a creative solution for working together.
3) List all the assets each party can contribute to a partnership. The can include knowledge / relationships / cash / distribution / IP / brand, etc. This will let you understand what you can both offer to a partnership, and also help to determine how the value (profit/revenue) should be shared between the parties. You can think about the assets you need to chase the opportunity to also select targets to propose the deal to. No point pitching to a group that doesn't have the right resources.
4) Develop a few combinations of those assets into a "combined activity" (ie a merger, JV, partnership, contract arrangement) that is perfectly suited to chasing the opportunity. This step will help you draft a term-sheet to capture the nature of the partnership.

If you follow these 4 steps, you'll be miles ahead in designing a partnership that will work for both companies and will help you get to a term sheet. When it's time to bring the lawyers in to draft up legal docs, their job will be pretty easy.

The key to success is staying "interest based" as opposed to "positional" in your negotiation. A great book to read on interest based bargaining is Getting To Yes, a foundational theory that came out of the Harvard Negotiation Project. Highly recommended.

In my blog post I introduce a canvas which can be used by a team to work through these steps. Have a look and let me know if this helps. Happy to help you brainstorm if you want to share the specifics of your situation.

This is a common question for first time founders. Unfortunately, some people misinterpret the Lean Startup Methodology and dive into *coding* an MVP far too quickly.

Rookie founder = (Code —> Design —> Marketing —> [Problem] —> Customer Development ) + only enough cash for one pivot = Quick way to die

Experienced founder = (Customer Development —> Design —> More Customer Development —> Sales —> Code —> More Sales) + cash for 2-3 pivots = Better way to build sustainable company.

Gaining a deep understanding of your customer is the most important first step. See if you can identify a painful and unsolved problem they have, then design a solution and try to sell it. This approach creates demand driven business – as opposed to solution driven – before any code is written.

In my experience, the concept of the MVP is widely misunderstood. MVP’s are not a fully functioning product; they are experiments. Many MVP’s do not involve any code at all. Your MVP might only be a set of mockups done in Balsamiq or Illustrator/InVision.

Learning the Customer Development process is inescapable in today's startup environment. The most helpful resource I’ve found is Steve Blank’s Udacity Course called “How to Build a Startup”. His book "Startup Owner's Manual" is a comprehensive guide through the Lean Startup process, complete with sequential checklists. Both resources are highly recommended.

Link to the video course is here: https://www.udacity.com/course/ep245

I encourage you to not build any code until you have gone through the Udacity videos, started the customer development process, know your customer, and have found people that are willing to pay you for a solution. Code is the most expensive activity to execute, and the hardest to change. When people start begging you for the product, code like there’s no tomorrow!

Happy to share my personal experiences directly with you if you like.

The simple answer here is there's no one-size-fits-all ERP solution, and it very much depends on the specifics of your company. There are several major considerations including how large your company is, the degree of complexity of your business, the volume of data, the need for company-wide integration, and the price you are willing to pay for software.

From what you've described, the feature set you need is (1) financial accounts (2) hr management and (3) productivity management. If these are the only three sets of features, you may be better off going for point solutions that specialize in each.

If you have already determined that a point solution is not enough and specifically need integration across the whole company, then take a look at Netsuite. It is widely used for companies that outgrow Quickbooks and need more integration beyond their financials, particularly among the Inc5000 community.

Bottom line: picking an ERP is a very important and tough decision to make. There are hundreds of alternatives on the market and you need to develop a detailed set of requirements and compare several of the main contenders to see which fits your circumstances. You do not want to make a decision and change to another system later, transitions from one system to another are a nightmare.

I am currently working with a company who made the wrong choice. They purchased a product based on the prior experience of an employee, and battled against the complexity of the system for 18 months. It has caused incredible frustration amongst the internal team, and causes lost productivity of >20% across the company. They have had to build their own internal system and are diverting tech resources away from their product to do it.

No-one can really advise you without more detail. Your best bet is to develop a detailed spec list, create a shortlist, and carefully evaluate the main contenders. This is one of those decisions that's important to get right the first time.

I had a conversation the other day with a UX specialist at Google. He has itchy feet and wants to leave. He happily told me he has a developer friend and a biz dev friend, both from Google, that are happy to jump ship with him. His major motivation "is to make a lot of cash".

The one thing lacking from his story is vision. In my experience, if you don't already have the friends (as the UX guy did), vision is the most powerful force for finding talented co-founders, partners and employees. The best developers I know (and I know some of the absolute best) are motivated by a desire to have an impact on the world: they want their code to mean something. They don't want to write code for code's sake. They want to leave a mark. Code is their vehicle.

My suggestion is to immerse yourself in the local scene. Make friends with the local tech guys at meetups and hackathons, at parties and dinners, and put yourself in a position where you can talk about the impact you want to have on the world. Irrespective of the platform or circumstance you use to meet someone, there is no escaping the reality that you need to have an inspiring story about how you want to make a change in society. If it's good enough, that story will spread and you'll get an introduction to someone that's interested.

Keep in mind that the best guys are employed and are being headhunted every day for big dollars. The best chance you have of finding a technical co-founder that is prepared to leave that massive paycheck behind is through a vision and credible story about how you can have broader impact.