Tuesday, December 16, 2008

Prioritizing features

So we've built our list of (it turns out) over 85 new scope features that the site should someday have (through "pie"-in-the-sky brainstorming). How do you prioritize 85 new features? Which ones should we concentrate our efforts on - which are more or less important than others. Basically this can be done with a "factorial decision tree". Let's take a more manageable example. Say I know I like 5 pies, but can't decide which one to eat. My list initially looks like this:

PiePriority
Cherry Pie
Peach Pie
Pecan Pie
Blueberry Pie
Apple Pie

So the next stage is to take our first table item and compare it to each other item below it in the list. If we HAD TO CHOOSE and we could include only ONE of the two items in the final product (or in this case to eat) which would we choose. If we chose the first item we flag that one, and if we like the second item we flag that one instead. So for our first comparison we compare Cherry to Peach Pie. If I had each in front of me and had to choose one, I'd choose Peach. I'd score a 1 for peach and not points for cherry. Our next comparison is Cherry to Pecan. I'd prefer Cherry, so I score one for cherry, and none for Pecan. My next choice is Cherry and Blueberry, etc. till I reach the end of the list. So after round one we should have as many hash marks as (# of items - 1):

PiePriority
Cherry Pie1 1
Peach Pie1
Pecan Pie
Blueberry Pie
Apple Pie1

After round one is done we go to the second item on the list and compare to everything under that. Peach to pecan, Peach to Blueberry, etc.:

PiePriority
Cherry Pie1 1
Peach Pie1 1 1
Pecan Pie
Blueberry Pie
Apple Pie1 1

You continue to work your way down the list until you've done all the comparison. Here is my final result:



PiePriority
Cherry Pie1 1
Peach Pie1 1 1
Pecan Pie1
Blueberry Pie
Apple Pie1 1 1 1

We then translate the priority hash marks into numbers that are the final weighting of each item:


PiePriority
Cherry Pie2
Peach Pie3
Pecan Pie1
Blueberry Pie0
Apple Pie4

The final weighted and rated rankings end up as: Apple, Peach, Cherry, Pecan, and Blueberry. If we wanted we could do a run off with matching choices if we had lots of choices by using the same methodology to choose one over the other and scoring it. And now you know I like Apple pie.... :)


The last step will be to add scope and complexity measurements to the lists. That we'll reserve for next post.

Friday, December 12, 2008

Customer loyalty vs product features....


My good friend Bill Self, in his thinkinglikeacustomer.com blog has a great article on the difference between product focus and customer focus. I recently had a brainstorming session with my long-time customer Knowledge Athletes. We were trying to look further out than the next funding round so we could prioritize scope and determine what things to concentrate on after completing the scope we'd already committed to. We also wanted to be sure we weren't looking at the trees and forgetting about the forest.


We started with an hour or so on mission statement. KA has a GREAT mission statement to start with, but it's useful to periodically review your mission statement to be sure that as you develop new ideas your mission doesn't change. By publicly declaring the mission statement we also gave ourselves a measurement to determine if each presented idea fit within that statement. This stayed on a whiteboard during the entire session.

Our next step was a brainstorming session to get down ideas for the product. Ideas were contributed by the business folks, educational leader, programmers, advertising, customers, sales and marketing. The rules were as follows:

  • There are no bad ideas - we're putting them ALL up there, and we'll judge them later.
  • We're not evaluating ideas - no judgements on how hard they are to implement, whether they complicate or simplify the user interface, or whether they add value or not. Just get the idea on paper (or in this case spreadsheet). We'll evaluate later.
  • View the feature from the customer's point of view - at this stage, since we're looking at features (rather than infrastructure) we're suggesting features only from the point of view of the customer. "If I were a customer I'd love it if the product can do X (and define X)." This is the part that relates to Bill's article.
  • Don't dig too deep - while we're capturing input on the ideas, don't start speccing the whole idea out - we just need to get the gist of the idea to prioritize and evaluate it. We can dive into the nitty-gritty of what the feature does and how it does it later. This requires a moderator to call "time out" if the topic strays.
  • Use end-user input data - During the brainstorming phase we extensively used the vast amount of research data KA collected during our initial proof-of-concept phases. What did users stumble over? What did they have a hard time learning (IE not intuitive)? Where did the product complexity not solve their problem or issue? What suggestions did THEY have for improvements

After we concluded our brainstorming session we had over 70 new features to evaluate. Note I didn't say add - we still needed to look at what is more important, what is easy or hard to do, and whether the addition of a feature adds or removes user complexity and capability. Obviously the budget doesn't support all these new features so we also have to prioritize them. I'll address how we went about that process in my next post. In the meantime be sure to check out thinkinglikeacustomer.com - it's an awesome blog.

Friday, December 5, 2008

What does it really cost....

One of the most frequent enquiries we get from web and software entrepreneurs is "how much would it take to build something just like X". Leaving aside the implication that you could penetrate a market someone else has already occupied with a "me-too" product, in most cases the would-be entrepreneur can answer this question themselves! It's actually really easy in today's world. Let's say you wanted to build a product just like the popular restaurant reservation system Opentable.com. (Or just like it with some difference or tweak you think will make it better). Here's how you find out what kind of investment you'd need to make to build it:

  • Fire up Google.
  • Now put the following phrase into the search box: Opentable venture funding. You can also try Opentable angel funding.
  • The first article that comes up is a press release from Open Table indicating that they received in 2000 a $10M venture capital infusion, after a $2M initial angel and VC round.
  • The $2M was probably pretty close to the cost to build out their initial demo/proof of concept and implement it in a small controllable beta (probably by region), and some portion of the $10M was used to make that scalable, fully featured, and to build the sales, marketing and business arm of the company to make it huge. There was probably an additional initial investment in Friends, Families and Acquaintances dollars (typically under $1M).

You can use this same methodology to find out the initial venture funding of most of the companies out there that have received venture dollars in the past. Sometimes you have to dig a little deeper, or you might have to go through a few articles to find either the actual or estimated dollar amount (except for public companies they're not required to report it). Alternatively you could look at other similarly scaled apps and check their funding.


The mix of how they spent their venture might be a little trickier, but most start-ups are spending the bulk of their initial cash on initially building software, and the bulk of their second round on infrastructure, scalability, marketing and sales. A me-too product would probably have to spend even more money on marketing and sales to be successful, since they'd have to fight off competition the first company into the space didn't have.


So what does that mean for the would-be entrepreneur? It means you'd better have something so interesting, new and revolutionary that no one else has thought of it if you expect to get funded and bring the product to fruition. Google took over the search market from Yahoo by presenting a simple semantic search interface instead of yahoo's structured/categorized search. It changed the world, but most of the success stories today are for new ideas no one ever thought of before.


Assuming you do have that revolutionary idea, be prepared to invest some serious dollars into making the thing a world-wide success. Treat the development effort and the business model development as the serious task that it is. Do some due diligence, market research, business planning, and specifications work before you jump into the development process feet first. Be sure you're prepared to stay the course and hear NO a lot before you dive into the Venture and Angel Capital fray - there are a very few applications that get funded, and the better prepared you are the more likely you'll be to be one of them.

Wednesday, November 26, 2008

DotNetNuke Corporation gets Series A financing

According to CMS Reports DotNetNuke Corporation whose principals are the progenitors of DotNetNuke, the open source platform that OS-Cubed does much of it's customer facing web development on, has acquired Series A Financing from August Capital and Sierra Ventures. Sierra originally invested in companies such as Symantec, Cisco, and Barnes and Nobles. August has invested in more recent start-ups such as Splunk and eBates.



"This initial funding comes at a key juncture for DotNetNuke Corporation, as the use of DotNetNuke continues to accelerate and we must scale to meet the needs of our rapidly growing community and ecosystem," said Shaun Walker, Chief Architect of DotNetNuke Corporation and original creator of DotNetNuke. "With an impressive track record of growing early stage companies into market leaders, August Capital and Sierra Ventures represent valuable partners and resources for DotNetNuke Corporation. We look forward to working closely with these firms to build on our past success and strengthen our position in the Microsoft ecosystem."



At the same time DotNetNuke Corporation announced that they will be releasing a "professional edition" of DNN 4.9 which will come with technical support and official bug-release level backing of the company. In keeping with the spirit of the open source development model, the core elements of the commercial distribution will continue to be licensed under the permissive BSD open source license and the company will work continuously to provide new innovation and increased value in the free, open source core product.



OS-Cubed looks forward to exploring just what this means for the future of DotNetNuke, and are excited to see the product move into the professional arena. We congratulate Shaun and the other DNN inventors on their success, and hope that same success extends to our clients who continue to use and create awesome software on the DNN platform.

As an amusing sidenote, the blogger suggestion for correcting the spelling of DotNetNuke is "Detonating" :)

Thursday, November 20, 2008

Do you remember this?



This month in 1977 the Cray 1 supercomputer was released.
It was 6.5' tall, and almost as wide
It cost 8.8 Million dollars
It did 80 million floating point operations per second



The PS3 pictured above cost $399
It is barely 1' tall and 4" wide
It does 218 BILLION floating point operations per second


So the next time you complain your computer is slow...... think about it.

Saturday, November 15, 2008

What to write on next....

I've gotten some interesting requests for topics to write about. I thought I'd put it up to my readers for comments about what items they are most interested in hearing about:

Some great ideas from Sharon Flank:

  • How do you be sure your entrepreneurial site is secure and can't be used for illegal purposes?
  • Should you partner with an outsource firm that retains some ownership in the final product?
  • Outside reviews of scope to help control scope creep
  • Reserving development dollars to implement ideas from user testing
  • Software documentation do's and don'ts

Other ideas:

  • What makes a great programming team?
  • Version Control: protecting your assets and maintaining a development audit trail
  • FFF funding - opportunity and challenges
  • Why use the Microsoft platform
  • Mixing open source and proprietary software

What are your ideas? What would you like to hear about next?

Wednesday, November 12, 2008

An agile programmer team room

I've been reading and admiring the quick article on http://www.scissor.com/ about building an Agile Programming team room. While we have many of the same elements in our development environment there are many ideas here that I'd love to steal er borrow :)

I was surprised by how much their offices look like ours. We also have an open floor plan, tons of natural light, dual monitors at every workdesk, lots of available whiteboard space. One of the things I loved about their space is the overall storyboard with colored cards, and the weekly iteration rollover plan. Very nicely laid out.

Agile or XP is a methodology frequently used in early stage (and some late state) startups to rollout product effectively, iteratively, and with stable solid builds. The idea is to rollout stable usable versions of the application almost weekly. OS-Cubed's methodology definitely adopts many of the great ideas of XP, but we're always learning new things about how best to develop software.

I'm going to challenge my programming team to take a look at this and see what elements they feel might help them keep on track and develop better software. Thanks to scissors.com William Pietri for revealing some of their "inner geek"...

Saturday, November 8, 2008

Followup on usability testing... and a bit of a break

I'll be taking a bit of a break for a week as I take some time to relax, but in the meantime you might want to take a gander over at Lightspeed Venture Partner's blog. They have a great followup to their recent usability testing article which I commented on here.

In this post they go into depth on what sorts of testing are appropriate at various levels of development. Most of our work for entrepreneurs has focused on the Ideation phase of development, where LSVP recommends that you explore new ideas and opportunities, take the founders vision and add in the background developed during initial testing. Specifically Knowledge Athletes (aka KA one of our most successful clients - our first) has performed the following types of testing in their product roll out from LSVP's list:
  • Ethnographic field studies (KA's "in school trials")
  • Focus groups (KA has focus groups consisting of high school students at all levels, college students and corporate clients)
  • Diary studies (the unique nature of KA's product is that it IS a diary so users can comment and track their usage of the product IN the product itself)
  • Surveys (So far online user surveys have created a number of interesting new ideas for the product)
  • Data mining (As KA has created user experiences TONS of data is now available on how the product is used and when it has been successful. This data is leading not only to new development ideas, but also paradigm shifts in teaching methods)

Th original paper on this topic by Christian Rohrer of xdstrategy.com has a great chart that shows where studies work best and compares data source vs approach vs context of use. You can learn more about usability testing at this University of Texas site.

Alternatively Jakob Nielsen's book on usability testing (linked below) is widely regarded as being one of the best in the industry.



Monday, November 3, 2008

Analyzing software features

In my post on scope I discussed the idea of limiting scope - both to budget and to goals. Brad Feld in this post, mentioned an interesting methodology, which quantifies the method we've used in our projects in a neat and tidy way. Since we work with early seed companies and startups in the Family, Friends and Acquaintances funding mode, we are constantly working to see what features we can build into a project for a small dollar budget. Obviously we need to leave some features out, but how best to decide?

Brad neatly summarized the decision as chartable on 2 axis. Along one axis is appearance vs substance (though I prefer the term functionality), and along the other axis is what users say they want vs whether they are willing to pay for that feature.

I would add a 3rd dimension - what the cost to code, test, implement and train are vs the speed at which the new feature can earn back it's investment. I know this is a purely ROI sort of view of the data, but it lets you see whether it's really worth it to put limited dollars into a particular feature. Perhaps in Brad's discussion they were talking about once there is Venture money already in the development and it's more a choice based on having enough money to do everything but not wanting to overburden the product with features. In our world though it's literally what can we afford. If Feature A has strong functionality, and users are willing to pay for it, but it would cost 2x as much as we have in the budget for development - then trying to build it won't help anyone until we get more funding.

In any case, it's an interesting thought exercise, and one that each entrepreneur should go through as they try to narrow down their feature set and build their demos and proofs of concepts. Take each feature and chart it three dimensionally. This will help you visualize your feature set, and decide which features to build, and which to build first.

Sunday, November 2, 2008

Personal branding in the Web 3.0 age

I recently attended an event sponsored by The Rochester Professional Consultants Network (RPCN). I've been a proud member of RPCN for a number of years, though I've been able to participate more actively in past years. I was quite impressed by the event - both the caliber of its speakers and the organization - mostly a result of Emily Carpenter's hard work, along with her committee, and the other RPCN volunteers.

I especially enjoyed Neil Hair's segment on personal branding - both extending and controlling your personal brand. As a proponent of the use of personal branding to extend my sales network, promote OS-Cubed, and build a really fantastic network of resources to both draw on and assist, I really began to think about how the entrepreneurs we work with could benefit from spending some of their precious time on building their personal brands. I think it's interesting that Neil's talk was centered around how best to manage the online perception of you. Most of our largest clients have come from the internet in a variety of ways, and I suspect that some if not all of them checked out both OS-Cubed and myself extensively on the Internet before engaging with us. All of them are very interesting, engaging and intelligent individuals - and many know that people do business with people, so being transparent about who you are, what you stand for and what your capabilities represent can only improve your chances of having a successful launch.

One amusing thing was that Neil gave us a "checklist" of things you should be doing to manage and promote your personal brand. I ran through the checklist myself and found myself solidly in the "Psycho" section of the personal branding pantheon. My wife would probably agree :). If Neil posts his checklist, I'll present it here so you can take the test yourself. But in the meantime, ask yourself:
  • If you google your own name are you on the first page?
  • Do you have, and at least weekly maintain, a LinkedIn, and also a Facebook Account?
  • Do you have a blog?
  • Have you registered your own name as a domain?

If the answer is no to these, then you should consider adding these to your marketing portfolio. How else are your potential customers, investors and partners going to learn about you, your company and your ideas in today's internet age?

Saturday, November 1, 2008

We're even more certifiable....


OS-Cubed recently achieved the Microsoft ISV/Software Solutions competency. As a Gold Certified partner, OS-Cubed's new competency is joined with our Networking Infrastructure solution.

“Solutions competencies are an important way for Microsoft to better enable ISVs to meet customer needs,” said Sanjay Parthasarathy, corporate vice president of the Developer and Platform Evangelism Group at Microsoft Corp. “They allow ISVs to keep and win customers through their deep knowledge of solutions-based Microsoft platform technologies. Microsoft has a long history of working closely with ISV partners to help them deliver compelling solutions and applications to our mutual customers, and the Microsoft Competencies are an important step in continuing to enhance vital relationships with ISVs worldwide.”The ISV/Software Solutions Competency recognizes the skill and focus partners bring to a particular solution set. Microsoft Gold Certified Partners that have obtained this competency have a successful record of developing and marketing packaged software based on Microsoft technologies.

Additionally, OS-Cubed has the Networking Infrastructure Solutions competency. Microsoft Gold Certified Partners enrolled in the Networking Infrastructure Solutions Competency have proved their expertise in implementing technology solutions based on the Microsoft Windows Server operating system. These implementations may include crafting solutions that connect Windows-based servers, PC locations and the Internet; installing a server farm; or building a small-business Windows Server stand-alone solution that includes file and print capabilities.

Monday, October 27, 2008

Tooting our own horn...


One of our recent engagements was to develop a Green custom application for Alvarez and Marsal that would lower costs by allowing them to send expense reports to a Microsoft Exchange mailbox, and have the system automatically map the report to an expense ID number in their SAP system. The software works as a windows service that monitors a dropbox and automatically processes the information and creates an XML-Gram to deliver the data to SAP. Since the original project, A&M has engaged us to add additional features to the developed code. Jordan Hadas - our primary contact on the project had this to say about our performance:

" When we engaged OS-Cubed and discussed our requirements for a custom application, OS-Cubed delivered sound guidance and a well-organized proposal focused on meeting our needs and fitting our budget. They were timely through the development process; patient with our testing; and quick to resolve issues or add features. The solution delivered fully addressed the scope of the project in a clean, functional package without feeling inflated or delicate. Working with OS-Cubed was a very positive experience. -- Jordan Hadas, SQL Server Administrator, Alvarez & Marsal Holdings, LLC "

A&M found OS-Cubed through the Microsoft Partners site, an online repository of partner skills.

Sunday, October 26, 2008

Are you running a Windows Operating system?

If so you need to run windows update NOW not LATER:
http://viruswarn.blogspot.com/2008/10/microsoft-releases-out-of-band.html

Cheers,
Lee

Tuesday, October 21, 2008

How to limit scope to funding


One of the biggest challenges in your early stage development will be limiting the scope of your project to the budget you have. In this stage you're using your money, your friends, your acquaintences, or maybe you have a first round SBIR grant and have a few 10's of thousands to invest. While you may be able to build some types of software with a budget that size - realistically to build something scalable you should be thinking bigger in terms of budget.
As we pointed out in our second post, when entrepreneurs come to us and say "I have $10,000" and in the same breath they say "and I want to develop something just like ebay only better" we just cringe. We know that there's going to need to be some education going on before we get to someplace that will satisfy their need to get real funding to grow their concept, within the budget they have.

Like it or not, the days of having programmers around who will sack out with friends, eat ramen noodles and put in 80 hour weeks for no pay and the promise of "stock options" at some unknown later date is just plain gone. Programmers have to eat, and at least for the moment demand for developers is quite high - so they can make money doing other things. Sure you may find one or two passionate gurus, but building a team is a different matter. After programmers got burned in the 2001-2003 dot com implosion, most want a real salary.

So when someone has a giant bag full of cool tricks that they believe will revolutionize the web universe we usually work closely with them to try to identify the core unique part of their business model that makes them special. Is it some trick or gimmick, a unique view on a market, an interesting model for monetization, a new approach to real estate, or a great educational paradigm? Then we try to work out a budget for a limited demo version of that core idea that can be used to attract new investors, test the idea out on real users, and provide a demo portal for the entrepreneur to use.
We just keep dumping features out of the product bag until we have it's core at our heart. We build that core, and then we add the features into it incrementally as funding becomes available. Got round one for $50K? Ok we'll build out the base site and the most interesting and unique part of your app. Got SBIR Round 2 for $100K? Perfect, we'll rebuild the core to support more users or traffic and we'll add some additional features. To make that work of course and move on to each round, the software has to be built to meet the milestone requirements set forth in the grant or by the funders. We help achieve that by working closely on the proposals and presentations with you to be sure you set expectations that can be met within budget.

That's not all there is to it, but that's the core. We'll build the features out in a later post :)

Monday, October 20, 2008

The master at work....

Want to see how a real pro (Steve Jobs) pitches a startup. Check out this excellent post at VentureHacks.com.

Friday, October 17, 2008

Startup funding in a down economy...


I've so far resisted the urge to post polemic statements about the death of startup funding, or the alternative "perfect environment" to build a startup. My opinion doesn't much matter in the grand scheme of things, but I've been reading various blogs with a lot of interest, as they cover how economic down times may affect funding - which of course affects entrepreneurial software development. One of the most respected bloggers I read in the VC/Angel world is Brad Feld. Brad had an awesome, short post recently that featured an article that I feel really gets to the heart of the matter: in turbulent times are both the greatest threats, and the greatest opportunities. The wonderful thing about early stage startups is they already run lean. There is a tremendous amount of sweat equity, smart spending of your dollars, and concentration on getting to cash as quickly as possible already. That means that entrepreneurs are UNIQUELY positioned to achieve in a tough environment. This article by Paul Graham (pointed out by Brad) explains in great detail why - economy or not technology marches on.


If you wait - your idea will still be snatched up by someone else. And that idea will land in a market with less competition. So when the market and the economy DOES uptick - they'll be in a perfect position to capitalize on that growth. Where would you rather be - playing catchup? Or running with the bulls...

Tuesday, October 14, 2008

Usability testing in entrepreneurial software

Jeremy Liew of Lightspeed Venture Partners has an excellent blog post on Usability Testing and how it applies to building entrepreneurial software. In his post he mentions that it's not just about rapid prototyping and turnaround (which he approves of) but also says that at some point you have to step back and do surveys, and psychological profiles of users and see exactly HOW they used the site. This is a critical step in building software, and obviously (since Jeremy commented on it) important to getting venture funding as well.

At OS-Cubed, we believe that usability testing should be scoped into the project itself, and the amount invested in it should be scaled according to the entrepreneur's budget, but it should be conducted throughout the development process as you're building your demo or proof of concept and rolling out your RAD prototype. In the early stages usability testing does not need to be either expensive or costly. You can do much of the testing yourself with the demo as it's rolled out. Noah Kagan of Mint lays out the steps for you in his excellent post. They involve basically: determining what to test, finding a representative user base, and then testing by observing. Noah recommends using Webex products, so far we've been lucky enough to have user bases that are representative right here in Rochester.

As Noah points out - doing this can be frustrating for the observer. The observer needs to sit back and let the user do it - without intervening or showing them how.

In our experience most of the user testing we've done with KaJour our product for Knowledge Athletes has shown up issues in the scalability section - which you'd expect in demo software. We'd actually anticipated these issues but didn't have the budget to build production level. We consciously chose with the entrepreneur to build more features, rather than make the features we had more robust. The users have also come up with unique and interesting ways of using the product that we didn't anticipate and neither did the Knowledge Athletes staff. Through our user testing we've found new markets, new ways of thinking about what we're doing and developed new teaching paradigms for the community we're serving (at the moment mostly high school and college students with this product).

Although Jeremy points out the obvious benefits of using usability testing to be sure your software is stable and simple to use, he doesn't mention that really listening to your users can allow you to create new and better uses for your software, and take your product in an entirely new direction. To do that you need to truly listen to your users and find out what it is they need - what pain you are solving - and how you could do it better.

Saturday, October 4, 2008

So what about grant funding?

SBIR or Grant funding can be a valid way to finance software proof-of-concept or demo costs. SBIR stands for Small Business Innovative Research grant. Each year the government earmarks almost 2 billion dollars towards SBIR and STTR (Small Business Technology Transfer) grant funding. This money is given (with very few strings attached) to businesses with an idea that meets the requirements of one of the government funding agents. This means that SBIR money may not be available for you if you're not doing something truly innovative and research oriented in the field your application addresses.

For instance, it would probably be difficult to find grant money to create an MLM-based affiliate advertising program - it's just not innovative enough, nor would it be likely one of the agencies would have a similar requirement. On the other hand, if you have a great idea and want to build a proof of concept and the requirements DO fit the ask - then you have a great possiblity on your hands.

Not every grant application gets funded however. Grant writing is a precise science. Most grant requests that don't meet the rules are simply tossed. For instance if they ask for a grant with 1.5" margins of no more than 200 pages including appendices an you write one with one inch margins or that is 201 pages - they don't even read it. In this case it's a very good idea to hire a grant consultant to help you write (or write for you) the grant application. A good consultant will also look at your idea and help you find the right agency to approach and introduce you to the right people.

If you're doing STTR funding, then the best approach is to use your college connections (The STTR program is primarily targetted at commercializing college based research projects). Most colleges have full time grant writers on staff and this sort of thing would be right up their alley.

So for a software developers - what are the advantages and disadvantages of applying for and using SBIR/STTR grant funding for your development:

Advantages
  • Grant money is the cheapest money out there. You don't have to pay it back, worry about your relatives, pay interest, or give up equity.
  • Grant money allows you to pay yourself. We all like to eat. You can pay yourself out of the grant money so you make at least a nominal living.
  • Once you get the grant, as long as you meet the grant requirements the money should flow fairly quickly into your coffers after invoicing, and allow you to pay yourself, your subcontractors, and your employees.

Disadvantages

  • There are limitations for how much of your grant dollars may be spent with independent contractors, and on what specific activities.
  • You have to build a grant that has achievements you can actually create within the budget specified. You need to periodically report to the government what your progress has been, and your payment is held accountable to how well you perform to the grant requirements.
  • Each grant costs application requires a reasonable investment in grant-writing which you may not recover as part of the grant payments. There is no particular guarantee a grant will be accepted and you may have to wait several months until you find out.
  • Grant funding comes in dribs and drabs, released by your grant liason. As such it's difficult to use it for things like ongoing salaries or pre-pays, unless you have a cash stash that you're just replenishing from the grant.
  • The government expects you to give them pretty detailed reports on your progress, and on how their money was spent. Grant accounting and writing up results is essential to getting the second round of grant funding, which is usually the ultimate targets as it can be in the hundreds of thousands or millions range (rather than in the tens of thousands range).

Once you've succesfully written and delivered a first stage grant, it's an easier process to apply for a second stage grant - especially if you did a bang-up job on the first one. In addition, once you've received approval for any grant, you can reference your work when you apply for additional funding or grants. Successfully completing SBIR funding can be a plus when talking to other funding sources - it shows you've put work into building out the funding yourself without resorting to capital investments.

Here are some good links to get you started:

Wednesday, October 1, 2008

What is the typical funding cycle of a startup software entrepreneur?




More often than not when I get a question from a budding software entrepreneur the question is about funding: How to get it? What are the next steps? How can I be sure I'm getting the best dollar for my investment?

At OS-Cubed we only work with companies that have at least some funding. Not necessarily angel or venture funding - but FFA (Friends, Family or Acquaintences), self funded bootstraps, SBIR or STTR grant funded, or some other sort of funding mechanism. In today's Web 2.0 world, most of the "big funders" - the angels or ventures of the world - expect that you will have some "skin in the game" and already spent some dollars or sweat equity building the demo or proof of concept of your site.

Web entrepreneur and funding expert Brad Feld says that a typical Venture or Angel firm might see 2000 applications for funding in a year, and 15-25% of those will be for software development projects. If we take the 20% median that means 400 of those applications are for software projects. He also said that of those 400, 1/2 of them had already spent between $25,000 and $1M on building a demo or proof of concept for their site - before they applied for funding! That's 200 demos or proofs of concept per year - all funded by FFA, Grant or bootstrap dollars - and that's just for one firm.

So how does that funding actually work? We've worked with a number of entrepreneurs and here are a few models that can be successful:
  • Grant funding - public or private grants from interested parties that can assist you in startup. The most obvious of these is SBIR, but there are others.
  • Bootstrap funding - create a small app using FFA/Self funding, convince people to use it, use the revenue from the small app to pour back into the app itself, convince more people to invest, and build it bigger and bigger until you have a provable model that you can get funded for.
  • Sweat equity - give yourself and/or others a portion of your equity to build the first versions for free. Use that result to apply for other funding sources.

Each of these has it's upsides and downsides. We'll address each one in a future post.

Monday, September 29, 2008

How important is a proof of concept?


So just how important IS a working proof of concept to funders? Can't you just drop your idea on an investor and sell them on it - then get funding to build it? Well yes, you can -if you have a history of building software companies before and succeeding, or more rarely if you have an idea that's just so mind boggling that the Angels and Ventures just jump all over it. Pretty rare though. Most serial entrepreneurs (whether they have a solid record of success or even a spotty one) have a leg up on the rest of us when it comes to getting funding for an idea before they build it.

But let's face it - those folks already ran the funding gauntlet and convinced someone to lay down cash for them. For the folks that have a great idea but have never implemented before they have to "prove their creds". They have to show the potential funder that they have the ability to deliver on the promise.

One of the best ways to do this is to bootstrap a demo or proof-of-concept so that you can show your potential funders real numbers and testimonials, with real people using your software. A great demo will show investors that it's a cool idea that can generate revenue. The characteristics that make a great demo are as follows (and I'm always open to ideas about what else may make a great demo):


  • You must limit the scope of the demo to what you can afford. Many entrepreneurs try to jam as many features as they can into their demos - and none of the features end up working well because they really need the $$ the Angel or Venture will invest to build production level, fully featured software. In this case KISS is fine (Keep it Simple Silly).

  • You want to build something that has limited scalability (might service only a small audience), but that still shows the core feature(s) of your product and how it delivers revenue. You may end up tossing out vast quantities of what you develop when you move to building production software. THAT'S OK. What you're building in this round is enough of a system to convince an investor to give you the $$ you need to make the REAL software.

  • It's extremely difficult to create fully scalable business software on an FFA funding (Friends, Family and Acquaintances) budget. Building scalable software is not easy, or cheap. It takes a lot of resources, good management and a solid team to build, support and improve software that is scalable and stable. I love when people point me at a site that has had millions of dollars invested in it and say "I want to build something just like that only better" and I have $10,000 to do it. It's just not going to happen. Build something realistic.

  • Yes delivering revenue is important - even if that revenue is small. If you're building something based on an advertising click through model - having users click through in your demo is as important as whatever cool features you've designed to get them there in the first place. If you can show your funders that you have the ability to deliver not only on the the cool feature but on the revenue generation you'll be that much further along towards proving your model. You don't have to generate revenue but you must prove you COULD generate revenue and show how you will do so.

  • Although you want the demo to be as stable as possible, it's OK for it to have a wart here or there, or an unimplemented feature. You can still build a demo that proves your concept without spending the money to make it fully stable and scalable. Limit your target audience to one browser, a limited number of users, single language, one checkout system, etc. Be sure the functions within those limitations work well, and be clear about them if presenting. Don't promise Firefox compatibility if you haven't tested it and don't be shy about saying "At this time the demo only supports [Browser X], but once we're funded we'll expand support to browsers y and z."

  • Take the feedback of your beta testers seriously. If they never use a function that you spent a lot of time developing - consider throwing it out. It's never good to clutter up an app with features that users don't want or need. You don't have to run out and fix or change things in this round, but preserve all those comments and criticisms and be prepared to address them in future rounds or plans.

  • Don't forget about monetization. To ultimately succeed in the venture world you need a business model that supports 5x growth in initial investment. If your initial tests don't prove that out - you might be in the wrong business. Better to find that out now.

  • Build incrementally, and do it within the scope of the funding you definitely have - not the funding you hope to get. Release early and often.

Initial proof-of-concept and demo software is frequently created with FFA (Friends, Family and Acquaintance) or grant money. As such, it's typically limited in quantity, may be only available on a cycle or with a specific deliverable, and - especially with the FFA money - it can be painful to say you spent it on development and then never moved on to the next step where they might get their investment back. It's incumbent upon an entrepreneur to spend that money as productively as possible to ensure success.

Wednesday, July 30, 2008

Software Development for Entrepreneurs...

The topic of this blog will be about the entrepreneurial software development process. This topic is one that interests me both academically and from a business point of view. I'd like to explore the differences in developing software for an entrepreneurial idea vs traditional software development, the constraints and challenges that entrepreneurs who want to develop a software idea face, general entrepreneurial subjects, and how the software development process is different in the various phases of entrepreneurial software development.


We'll explore the subject together and hopefully have some great dialog.

Followers