I've got an awesome idea....

(http://xkcd.com/827/)

I hear the words in the above title all the time.  We love awesome ideas at OS-Cubed - it drives our (and our client's) passion.  But what about all those ideas that you have that never end up getting made, what happens to those?  Today the process of getting a patent on something, especially a "business process patent" is fraught with difficulty.  You have the burden of proving there is no prior art that shows that your idea hasn't already been thought of by someone else, and of actually prosecuting any perceived infringement on your own nickle.

Truly your best defense against someone else taking your idea and running with it is doing it yourself - sooner rather than later, and better rather than poorer.  This is why most venture capital companies won't sign a non-disclosure or a non-compete.  They know that there is an unlimited supply of ideas, but a very limited supply of entrepreneurs with both the passion and ability to turn those ideas into cash.

That means really letting your great idea take hold and putting your full passion and energy behind making it happen is the best way to be sure no one steals it.  This is not to say you shouldn't pursue a patent if you really believe it's revolutionary enough to get one. Being first to market AND better to market though will make up for a lot of lost revenue fighting over lawsuits.  And no - you can't just get someone to send you money if they later "take" one of your ideas and make it happen.

Oh, and as an added aside - be sure to actually CHECK the market to see if there's a competing product already there.  I can't tell you the number of times we've been approached to create a reinvented EBay (with no significant difference from the real EBay), a new PowerPoint (with the same features), or a new version of an existing site.  These aren't revolutions and they won't capture the hearts and minds of users unless there is truly a pain being serviced, a product being sold or a methodology being used that is new and different from the rest of the marketplace.

The four partners in entrepeneurial success

When engaging an outside vendor to do development for you - how do you balance the needs of the four partners in development - and who are they?

Each development project requires key ingredients.  Combining the right ingredients, in the right proportion can create value and further your project towards profitability.  Combining the wrong ingredients, or choosing the wrong proportions can spell disaster.  So what is the recipe?

First let's list our ingredients:

• A passionate committed entrepreneur with a strong sense of mission and a specific goal for success
• An entrepreneur savvy development team that concentrates on closely managing cost and delivering best value for the dollar
• A technology platform that can implement, support and handle expansion of the proposed solution
• A source of money to fund development, with a target goal for the next funding step

The first question to ask is are all these ingredients required and have we missed any ingredients? Let's examine each one. 

The passionate entrepreneur - the entrepreneur comes to the table with the business idea, and the passion and commitment to make that work.  Don't underestimate an entrepreneur's passion in the importance here.  An entrepreneur with no skin in the game, and without the passion to work through tough problems and make tough choices can kill the project.  Some of the negative qualities we've seen in entrepreneurs is the idea that they expect the world to develop their software for them for free or for a "piece of the pie later".  In 90% of entrepreneurial endeavors - later never comes.  Other entrepreneurs show the "everything must be done by me" syndrome.  They are generally very smart people who refuse to accept help and assistance from those around them because no one can do it but them.  They must also have a CLEAR VISION for exactly what they want in a development effort.  They need to be able to articulate and/or document this vision for the developer in terms they understand and can commit to delivering.  The entrepreneur must also trust and accept the evaluation of the development partner.  When the partner says "this can't be done for that amount of money" they must realize that the only alternative is to pare down scope to fit the project within the budget.

The Development partner - A development partner needs to look at this as not only an investment in the future, but also a source of immediate income.  If not - they aren't a business they're a speculation company, and worse yet one that has no control over their own destiny.  To succeed in the entrepreneurial world, and succeed at business as a developer, they must create rigid standards for their development process that includes scope control, agile development with incremental improvement, the ability to help the customer understand and make tough technical capability choices, the ability to not only see the individual tasks on the table but the big picture goal of what each next step must be, and the ability to add value to the project where it is appropriate - without treading on the entrepreneur's vision.  The developer must also be forceful when a client proposes doing too much for too little dollars.  Every entrepreneur is going to ask for this.  Every developer must learn to be straight up and let someone know what the investment will be and what the limitations of the delivered product will be.

The Technology Platform - let's face it, while the other three items are important selecting the right platform is equally important.  We must pick a platform that satisfies the immediate needs of the development effort, and can potentially expand to service the needs of the next level of development.  The platform must be scalable - at least enough to satisfy next stage growth needs.  This means that in the long run, you may select different platforms as you move up the food chain in complexity, capacity, security and capability.  A well designed solution allows you to adapt individual parts of your platform to new, better platforms as they are either developed and made available or better suit the needs of the market, end user, developer and entrepreneur.  You might well select a different platform for your initial demo than you do for your final production.   In some cases as some famous companies have done you may even wholesale replace the back end while leaving the front end intact or vice versa.

Money Management - Money is the great limiter, the great motivator and one of the best ways to keep track of your goals.  Having a specific development budget allows you to control scope in your final outcome, allows you to deliver the best product for the money you have, and gives you a specific focus for each round of development.  You must understand not only the cash flow and dollars of the original development effort, but also where the next "lump of development money" is coming from.  The entrepreneur and the developer must always keep in mind what they have right now to spend on new features and what they need to deliver to secure the next level of spending.  When requesting dollars, whether it be through the grant process, angel money, customer funded, etc.the developer and entrepreneur must work together to form a reasonable request that can be accomplished within the limited budget.  If that doesn't happen they may well get that next level of funding, but never be funded again.

So giving that, what is our formula?  Here's my proposal for it:

Success = (Entrepreneur x 3) + (developer x 3) + (platform x 1) + (money management x 2)

This weights the Entrepreneur/developer relationship highest, followed by money management, and finished off by platform choice.

It's the platform right?

One of the challenges of working with entrepreneurs as clients is that their methodology, purpose and culture for building software are different from your average everyday business or web client.  OS-Cubed has built their methodology, culture and tools around being able to service the entrepreneurial client.  In our case, since we are a small group - we chose ONE platform to support (DotNetNuke on IIS with a MS SQL Back End).  We didn't choose that casually.  We wanted to remain in the well supported (from a developer and a client's point of view) paid .NET development arena.  We wanted to build on software for the back-end that was scalable and reliable.  We wanted to build on software (on the front end) that was open source and optionally free.  And we wanted something that wasn't so proprietary that we couldn't hand it off to another team when the time came.  We also wanted a platform we were experts in hosting - as well as configuring.  We've done things with DNN not even Facebook or Twitter have done - and we did it all on a shoestring budget compared to those sites.
A lot of times our clients end up in our shop because they've gone through one, two - even three or four - developers who have let them down.  They tried the cheap route with programmers from India.  They tried the expensive route with high end business consultants.  They tried hiring "the guy down the street" or the guy from Belarus to build software for them.  Frequently these forays are wretched failures - the entrepreneur-developer bond is a very specific one and if either side doesn't understand how the other thinks and works - you can end up with a real disaster.

Recently a customer came to my office (through a local referral) who was a perfect match for us - they had a site that was created by at least 4 different programmers doing different tasks (in this case all badly or with the wrong tools).  They were ALREADY ON DNN!  Their product was in the educational marketplace - awesome I already have an educational entrepreneurial client so I know the culture and subject matter.  We didn't even need to convert them to the platform, just fix what had been done wrong and adapt it. 
They had some simple, easy to repair (if you know what you're doing) systemic problems that were bringing their site down and making it unreliable, and they were on GoDaddy for hosting - possibly one of the worst hosts in the world.  Amazingly though we were able to take them from a wretchedly unstable DNN install to a stable one in a matter of a couple of days - identifying and either fixing or documenting what needed to be done to get them running and meeting their goals.  We unraveled the hosting issues, and the stability issues, got them up and running and all prepared for future growth.  Perfect right?

A quote from the customer: "WOW!  We love your process.  You keep us informed, and almost seem to have a second sense for exactly what we need.  You let us know before accruing hours that something might go over an estimate, and you work with us - and our other vendor partners - in a kind and courteous way as you have done this - paying attention to our priorities.  You've done more in the last 48 hours for our site than has been done in 2 years of development."

Awesome.  Our customers say the best things about us and we love them for it - and when we get a compliment like that it lets us shine up our white armor and say - see we CAN ride that horse!  But the customer didn't stop there.

"I'm sorry to inform you however that the board has decided to move from the DNN and MS SQL to a php and mysql platform, because of all the frustrations we've had with DNN.  We just want to stabilize the current install while we develop a replacement in another languague." 

WHAT!? Hold the horses.  The problem isn't the platform - it's the programming teams.  It's not whether the platform can do what you want - it's whether the team you had used the platform to it's best advantage, using pre-programmed tools when appropriate and developing custom modules where they are needed.  It's whether the team understands your requirements, budgets and goals, and works with you to make all 3 fit into the same project iteration.  It's whether the team building your software knows the ins and outs of the platform to really take full advantage of it.  And it's whether you trust the people building stuff.  It won't matter if you move to a new development platform if your developers don't know, understand and live these precepts.

I haven't closed the loop on this yet - I'm still hoping to convince this client (through references from  other clients) that it's the team not the technology.  Wish me luck!

So for all of you out there right now cursing your platform (whatever it is) just be sure that the problem is really technical not cultural.