How FREE can kill innovation & your startup

June 4, 2009 at 5:21 pm | Posted in Sofware Startup | 2 Comments
Tags: , , , , , , ,

A strange dynamic has taken hold on the internet.  Just as people expect sunshine and air to be free, they also expect internet based software applications to be free.  Ok, maybe not completely free… they agree someone should pay, just not them.  Damn you Google, damn you Yahoo! why did you do this to us?

With companies left and right offering full versions of their products for free,  users have been conditioned NOT to pay for anything.  This conditioning can be seen across everything from social media sites to messaging to business applications.  The problem with this as I see it is the negative impact on innovation.

Users think that they win by getting free software or services, but do they really?  If you ask me the only real winners in the free ecosystem are the investors behind well funded companies.  By locking down markets with free offerings companies can effectively prevent new entrants from emerging.  This stifles creativity and innovation.

In a meeting a few months back with a partner from Benchmark Capital, I found out that on average they see 3-5% conversion rates on FREE offerings within their investment portfolio.  For most of us this is rather daunting news.

Let’s do some quick mathematics.  Let’s say that you are getting started and you have 2 servers from Amazon Web Services (1 web server/app server and 1 db server). Your monthly cost is going to be around $200.  Let’s now assume that your multi-tenant application can handle 100 accounts on that server, simple math $2 per account cost.  Now you go out and offer your service FREE and you have some success.  Let’s say you sign up 1,000 free accounts.   You scale your costs linearly so you are now spending $2,000 a month to support those free accounts.

You get 5% to upgrade (eventually) to your paid account of say $20/month – at this rate, even with success it costs you $1,000/month just to keep the lights on. Now add to that your Google Adwords budget, your credit card processing fees and the dozen other bills you have each month and you find yourself quickly in the hole by several thousand dollars a month.

Now what happens if you get slash dotted or an article about you ends up on ReadWriteWeb?  Your monthly costs can zoom beyond your meager savings account, all without any real revenue in return or an endpoint in sight.  The end result of your short term success will be the failure of your start up because you ran out of money.

There is also another aspect of the “FREE” account that costs you time and money.  To support a layer of free accounts you have to write code to restrict or to compartmentalize your solution.  This takes your valuable development resources and shifts them from building killer technology to building layers of management so you can support the free users.

I just heard you shout…”But David, you must have a free version or no one will use your software!” I disagree my new friend.  If you look at the Salesforce.com pricing page they don’t have a free model. Neither does Netsuite. These companies are in business to make money, not give away software.  I like this model and hope to see more and more start ups follow it.   At my start up project MioWorks.com, we are holding to this model and offering a free trial to introduce users to our software.  I feel this is an acceptable compromise because it has a definite end period and you don’t have to over-provision your computing environment to support thousands of free accounts in perpetuity.

As for you users out there, don’t be shy to actually pay for something you like to use.  You don’t think twice about dropping hundreds on a camera but you won’t spend $20 a year to store and manage your photographs in an online application.

In the past year or so, Apple has shown us that users will actually pay if the paradigm is broken.   The Apple AppStore is a great example of how to break the cycle and get users to  pay for technologies.  As entrepreneurs we need to watch how this model is evolving and how we can capitalize on it to help fund our ideas and companies.

My last word of advice helps both the user and the start up.  Users, if there are vendors with products you just love but they are too expensive, then tell them.   Tell them the price point that would be of interest to you.  Tell them how to get your business.

The end result of spending money on products you like will be a wider variety of products with more and more innovation.  And who doesn’t like variety! Maybe Google.

Extranets allow Start ups to bill more hours

May 27, 2009 at 9:44 pm | Posted in Sofware Startup | Leave a comment
Tags: , , , , ,

Hey did you know that the term “Start up” isn’t exclusive to technology companies?  I was shocked earlier this week when a few accountants wanted to have coffee and discuss their start up.  Immediately my brain started to think about the types of software they must be creating.  As I entered the local coffee shop and met the duo I quickly realized they were starting up an accounting practice.

It was amazing.  Two guys with a skill set outside of technology that were creating a new practice from the ground up.  They called it a start up.  After I got over my initial shock and awe, I settled into the discussion and quickly saw where they were going.

The pair was ready to leave their corporate jobs and continue their practice full time.  They already had a dozen clients and had dozens more ready to jump when the time was right. The reason they pulled me into a meeting: they were scared.  Not scared of leaving their jobs or starting up a new business. They were scared that they wouldn’t be able to meet the needs of their clients.  They were scared because they knew they  couldn’t scale as quickly as they needed to.

I thought to myself what a great problem to have.  But the more I chatted with the pair the more I realized how smart they were.  They knew that there was a finite limit to the number of hours they could spend in the office every day.  They knew that there was a correlation between billable hours and happy customers.  They knew that to be successful and still be able to see their kids, they needed to take advantage of the internet and get customers to help themselves as much as possible.  They wanted to know about the technology I was working on and how it applied to their practice.

Instead of launching into a sales pitch I really wanted to find out where their non-billable time was spent.  As Certified Public Accountants the team had both individuals and companies as clients.   Each client could have dozens if not hundreds of documents over the course of their relationship.  Clients constantly call looking for a copy of their quarterly statement, access to documents or information from last years tax return.  Storing, finding and moving around documents between clients was a tremendous headache that eMail was not well suited to solve.

The second biggest challenge for the pair was after hour phone calls. For some reason clients always have their questions at 9pm at night.  As a start up the team wanted to give the best service possible yet they didn’t want to keep answering the cell phone at all hours of the night.

It was clear to me that an extra-net could really solve these problems.  Extra-net you say?  Is that some new clever concept?  Is that Web 2.0? Web 3.0? Alas, I must come clean.  The concept of an extra-net is not new.  It’s not shiny and all twitterly.  It’s a proven technology that gives customers a private place to do business with a company.  Extranets used to be expensive and only available to the big companies with giant IT budgets.  But with the adoption of Software as a Service and the ultra low cost of online applications, extranets are now available to even the smallest of businesses.

I showed the two an extranet style application that I’m invoved in called MioWorks.  We quickly entered the information for a few of their clients,  clicked to enable the private portals, uploaded documents and sent private messages.  It took about 5 minutes for the light to come on and the pair to exclaim “THAT’S IT!”.

Here it is two weeks later.  As I sat at my desk this morning the phone rang.  It was one of the accountants.  He thanked me for taking the time to talk to them about their business.  He also wanted to tell me that over the weekend the pair made the final leap.  Our discussion and the technology I showed them made them feel comfortable that they could scale and deal with the needs of their clients.  The felt that they could maximize their hours, spend less time on the phone with clients and do more billable work.

Just before we hung up the phone, they asked if they can add me to their MioWorks portal!

Collaborative development – the power of beta testing

April 26, 2009 at 3:13 pm | Posted in Sofware Startup | Leave a comment
Tags: , , , , , , ,

Don’t underestimate the power of beta testing to a wide range of people. Consider it collaborative development. Open your software to a broad range of people inside and outside of your target market and you’ll be amazed at what you get back from them.

A perfect example is my current project MioWorks.com. We opened up for public beta testing a couple weeks ago. In that time we have been getting amazing feedback that has allowed us to direct our development resources to the must have features of a target set of users.

Now you can’t just run off and implement every feature that is throw at you by the beta group. But you can listen to them as a whole and look for trends and commonalities. For us, we knew that we needed to implement ways to improve data manipulation and the feedback gave us the exact path to take. As we complete the development and roll it out, we are extremely confident that this effort will be well received by our beta group.

So open yourself up to critique and criticism early in the process.  You may also want to adopt some not-so-traditional approaches by using social media.  We encourage our beta group to use Twitter to spout off feature needs and questions in real time – all they have to do is respond @Mioworks and we collect that data and use it in our analysis and product planning.

In the end, no matter how you do it, building software should be a collaborative process that takes into account your target market.

Startup Exchange – the best two hours of the year

March 18, 2009 at 4:54 pm | Posted in Sofware Startup | 1 Comment
Tags: , , , , , ,

Last night I attended my first Startup Exchange meetup organized by the Software Association of Oregon.  The meeting was held at the offices of Chime Software hidden away in Portland’s East side warehouse district.  The Startup Exchange is for entrepreneurs only, no service providers allowed.  It’s a chance for peers to get together, ask questions and share their knowledge.  The group consisted of both technical and business folks representing start ups ranging from one man ventures to several year old thriving multi-million dollar businesses.

The format of the meeting is loose.  We started out enjoying an adult beverage in a green glass (well it was St. Patrick’s day!!) while meeting and networking. The organizers made a few announcements and clued us into an event on Thursday 3/19/2009 at 5pm called STARTUP NOW: What would you do with $250,000.

Then after a round of introductions we split off into two groups, one focused on business issues and one focused on technical issues.  Mentors split themselves between the groups and off we went.  I went with the business group since my start up MioWorks.com is just about to enter beta phase and we have most of our technical aspects covered.

For the next hour we went around the room.  Each entrepreneur had the opportunity to ask the group a question, or ask for advice on any topic.  It was really good to see how so many others are challenged every day with identical issues.  As the discussion progressed and the group offered advice it was clear to see how valuable this session was starting to become.  Even though I only asked one question, the issues plaguing the other entrepreneurs were issues that I deal with too.  As a matter of fact, it was a reminder of the old adage “you don’t know what you don’t know”.   For me, this was one of the best meetings of the year for one simple reason.  It made me challenge my existing assumptions on a few topics and apply a new filter to my logic.

After the session there was a little more time for networking and then out the door to get to the next meeting on my agenda.   If you are an entrepreneur in Portland building a business, you should put the Startup Exchange on your calendar.  Without giving up any of your stock or hard saved money you will have an opportunity to gain insight from people who have already been down your path.

To join the Startup Exchange group you don’t need to be a member of SAO.  You can request access to the online networking group or contact Bryce Yonker of SAO with any questions.

Top 10 legal related mistakes startups make

February 11, 2009 at 7:23 am | Posted in Software as a Service, Sofware Startup | 4 Comments
Tags: , , , , , , , , , , ,

Today I ventured out to Beaverton to attend a lunch and learn sponsored by OTBC.  The topic of the discussion was “Top Ten Legal-Related Mistakes Startups Make”.  The talk was presented by attorney Jon Summers of the firm White & Lee.   Now before I summarize the talk for you please remember that this information is for your consideration.  I make no claim that I am an attorney, CPA or any authority what soever that you should follow direction from.   This is just my understanding of what was presented today.  For complete and accurate details and advice, please consult your own legal counsel and CPA.

OK, so now that I’ve made it clear that I’m just the messenger let’s talk about the lunch. This was my first OTBC lunch and learn and it was definitely worth my time.  The presenter was well organized and extremely knowledgeable about the subject.  He even took questions during the presentation and tried to answer each and every one of them.  Jon spent nearly an hour discussing the ins and outs of organizing tech startups to avoid legal pitfalls.  At the end of the presentation he wrapped it up with his David Letterman style top 10 list.  Since most is covered in the summary, let’s dive into Jon’s option on the top 10 mistakes that startups make.

10 – Missing the 83(b) election deadline

When it comes to stock and stock options, the IRS rules are long and confusing.  This is yet another one of those loop holes that if you miss you’ll pay dearly for.  This applies to the purchase of restricted stock or the early purchase of stock options by employees.  The net of the 83(b) is that when you make this election you are telling the IRS that you elect to take the income difference between the purchase price of  your shares and their fair market value.  Typically this is a net zero election that does not result in an income event.   But if you don’t take the election, you will be paying the IRS taxes on the difference between the strike price of the stock and fair market value of the stock EVERY time you vest.  OUCH.  The time frame is 30 days from the time you purchase your stock.  So….if you don’t get all of this stock mumbo jumbo…consult an accountant or an attorney to make sure you file your IRS 83(b) election in time.

9 – Selling stock to non-accredited investors

There are two types of investors in this world according to the SEC.  Accredited and non-accredited.   An accredited investor (person) is one that has over a million dollars in assets or earns over $200k a year individually or over $300k jointly with a spouse.  Everyone else is considered a non-accredited investor.  The rules for selling stock to the non-accredited investor is significantly more strenuous and can have negative ramifications when it comes to any potential liquidity event (ie sale of your company).  Jon’s advice…just don’t sell stock to non-accredited investors, period.

8 – Forming the business entity as an S Corp or LLC

Number 8 on his list brought up some discussion with the group and a little controversy.  Jon stuck to his guns and said that in most cases he recommends a C Corporation.  The basis for his recommendation is that fact that professional investors demand C Corporation status before they will invest.  He went on to say that the main reason is that with an LLC the profits of the company are passed back to the partners of the LLC and that has cash flow implications.  Another approach that was discussed was to start with an LLC and then prior to taking any type of capital investment, the company may switch to a C Corporation.

7 – Failing to register the stock option plan with the State of Oregon

The State of Oregon requires that stock option plans that meet certain criteria be registered.  Jon said that this was probably the single most common mistake found among the startups he works with.  So if you have a stock option plan, find out if you are subject to the registration requirements before you find yourself with a steep fine or worse yet a roadblock to a funding or liquidity event.

6 – Waiting too long to form the business entity

Jon made it clear to the audience that the first thing you should do is create your business entity.  His rule of thumb was that whenever a business had two or more people, is creating intellectual property or is transacting business with others – they should have a business entity established.  The main reason is for protection of the business.  Once an entity is formed then there is liability protection for the principals, there is a place to park the intellectual property, there is investor appeal, survivor-ship upon death and business can be transacted more easily including contracts and employees.

5 – Failing to vest founders stock

The vesting of founders stock was an interesting recommendation that I really never paid much mind too.  But after Jon explained a few scenarios where founders decided to leave the company after a short tenure, it sure made sense.  Imagine if you and your friend started a company and split the stock 50/50.  After a year your friend decided to go off an pursue a different idea.  If you granted the founder shares on day 1, half of your shares would be walking out the door no longer providing value to the company.  If you vest the founders shares say over 4 years, then the company would get at least four years of value from the founder or have the option to recover some of that stock if the founder decided to leave.

4 – Bringing in tainted people

Hiring was an interesting topic during the conversation.  The discussion revealed an important piece of advice for each of us running a company.  Jon’s advice was to make sure that we get a copy of every potential employees non-compete/non-disclosure agreement PRIOR to making them an offer.  He said that the burden is upon the hiring company to make sure that they aren’t hiring tainted employees (ones that may be subject to non-compete or non-disclosure agreements).  When the audience was surveyed no-one had either asked for or given a copy of prior agreements.  I guess this is something we all learned.

3 – Disclosing information without a sufficient Non Disclosure Agreement

Although the risk of someone running off with your business idea after a presentation is small, it is still there.  A simple NDA can ensure that this won’t happen.  Jon said that small companies are usually at the will of the bigger companies when it comes to the legal forms.  He did offer the advice that before we sign a “standard” agreement from another company we look out for what he called dangerous terms.  These include residual clauses, independent discovery clauses, non-solicitation or other restrictive provisions as well as short lived terms.  By watching out and preventing these elements from slipping into NDAs you’ll be better protected.

2 – Missing the non-compete window

In Oregon the window of opportunity to have an employee sign a non-compete agreement is very limited.  As a matter of fact there are only two times where an employer can get an employee to legally sign a non-compete agreement.  The first opportunity is prior to hiring of a new employee.  There is a two week waiting period from the time the new employee is alerted to the requirement of the non-compete to the time that they can sign it and join the company.  The second opportunity is when there is a significant promotion of an employee.  As the discussion continued and Jon explained how non-solicitation agreements really work, this is one of those areas you really need to pay attention to.  There are several restrictions of what makes a non-solicitation (non-compete) agreement enforceable.  And there may even be compensation required on the part of the company enforcing the Non Compete.  So when you are ready to head out to your next gig and your employer tries to force you to sign a non-compete on the way out the door, you can rest easy that it won’t be enforcable in Oregon.

1 – Waiting for funding to fix problems

As Jon wrapped up the talk he finished his top ten list with the most obvious mistake that startups make.  He said that too many times startups will allow problems to compound themselves with the hopes that it all will get figured out AFTER funding.  Well there is a fundamental problem with this line of thinking.  Unless there is a magic wand, companies who have not paid attention to legal issues up front will never be getting that funding they were hoping for.  The only course of action for a company is to correct all of the problems before they can finalize funding and this can mean months of delays, expensive penalties and missed opportunity to close the finance deal.

My thanks to Jon for providing us with the information at the lunch and learn and thanks to OTBC for organizing. Much of the content in the article above comes directly from Jon’s talk, so I attribute this article to him.  Finally a bit of promo since we were able to absorb some free advice…..If you are in the Portland area and need legal assistance with your startup entity formation, stock plans or IP protection, give Jon Summers a call at White and Lee.

TechStars make available their seed funding documents

February 10, 2009 at 6:39 am | Posted in Software as a Service, Sofware Startup | Leave a comment
Tags: , , , , , , , , ,

A bit of interesting news from startup land.  The tech incubator TechStars has released a set of documents to be used as a model for early stage startup companies.  These documents include articles of incorporation, bylaws, subscription agreement, election consent and even a sample term sheet.  

If all of these document titles are greek to you, then go visit the TechStars site where you can download them and get your legal groovy on.  I do recommend that those thinking about venture funding should download these documents and actually read them.  It will give you great insight into what will be required once you sign on the dotted line.   A big thanks to the team over at TechStars for making these documents available and helping to reduce the cloud of uncertainty around venture funding. 

As a side note, TechStars is taking applications for their Summer 2009 funding round.  The summary is that TechStars picks a small number of projects to help get off the ground.  They fund up to $6,000 per founder up to a maximum of 3 for a total seed round of $18,000.  Take a look at their application and read about how they help companies get off the ground.

A lesson from ma.gnolia

February 7, 2009 at 5:03 pm | Posted in cloud computing, Software as a Service, Sofware Startup | 1 Comment
Tags: , , , , , , , ,

As the veil of silence surrounds the catastrophic data loss at ma.gnolia it gives us all a time to think about our approach to protecting our users & customers.  In the Internet arena, there are dozens of moving parts that no single company has complete control over.  There are hosting providers with power sources, data stores, network routers and firewalls, there are backbone providers, there are big switches in the sky, there are pipes under the sea, there are gremlins on treadmills, well you get the idea – the list goes on an on.  And if there weren’t enough variables already, we throw in cloud computing with its instant on, instant off dual personality.

With all of these moving parts and potential for disaster, it is a tremendous feat that more catastrophic data loss doesn’t occur.  Maybe it’s luck or maybe many companies are doing it right.  This failure at ma.gnolia is a reminder that as providers of Internet based services it is our burden to minimize the impact of failures or we shouldn’t be in business.

Since I am proponent of cloud computing, I want to focus on backups in the cloud for this article.  The cloud is a tricky monster.  It is ephemeral and unrelenting when it has a hiccup.  But the power of cloud computing is too tempting not to leverage it.  The fact that we can launch server after server for a dime an hour is down right amazing.  Small companies like mioworks.com don’t have to raise a million dollars just to get started.  We can create an account at Amazon Web Services and within an hour have a full data center up and operational for next to nothing.  But when you choose to use the cloud for your solution, you must be diligent in the way that you handle your applications and your data.  Simple backups are not enough anymore.  And testing must be done on a frequent basis.

I have to admit that I have come close to the brink of disaster with cloud computing  but through a stroke of luck was able to recover.  The scenario that bit us started out with outages at Amazon.com’s web services.  Due to automated shut downs of servers we lost our database.  Poof it was gone in an instant.  All the alerts and alarms went off and our recovery procedures kicked into action.  We all thought it would be ten minutes until the blip was over and operations would be back to normal.  Well that wasn’t the case.  During the restore we found out that one of our system administrators made a few changes to “improve” things.   According to the change logs, he successfully completed the backup solution, it was testing and working properly.  But when the catastrophic failure occurred the primary backup system didn’t restore the database image as planned.  Instead we had to take a different route to replay every single transaction that had occurred with our production database since it was created.

We were lucky that we had this data squirreled away in a cloud data store as a backup to our backup.  Yes it cost a hundred bucks a month to maintain this archive but it was well worth it.  The end result was a return to normal service for our customers, but unfortunately for some of them it was only after a three day outage. Ouch.

My error as the leader of the brigade was that I didn’t demand a full scale test of the disaster recovery on an ongoing basis.  As I ponder the entire episode it’s one of those moments when you say to yourself “you know better”.  Yet, it still went untested and unproven until it was exercised and failed.

So my advice for everyone who uses cloud computing.  Don’t go running scared and return to buying servers and disc arrays.  Spend an few extra weeks and a few extra dollars on disaster recovery planning, implementation and testing.  Implement competing backup solutions so that you have backup to your backup.  Go ahead and get fancy with your up to the minute on the fly backup scheme, but also implement the daily/hourly workhorse backup.   Make sure that your team has the backup and the restore fully figured out, and make them prove it to you. Don’t take their word for it. I’m SERIOUS here.  I know we all like to trust our techies, but sometimes they do make mistakes.

So, physically terminate the servers on them and watch them go to work. Or the friendlier approach is to have them launch a new set of servers in the cloud and replicate the environment from backups.  Have them do this on a bi-weekly basis.  They will get good at recovering the system and in the event it happens for real it won’t be a scramble.  With this extra workload the team may be unhappy at first, but it’s much better than suffering a fate like ma.gnolia.

Portland Web Innovators – Bootstrapping & Business Models

February 5, 2009 at 7:39 am | Posted in Software as a Service, Sofware Startup | 4 Comments
Tags: , , , , , , , , , ,

Dateline: Wednesday, February 4, 2009 – conference tables at Cubespace in Portland, Oregon for the Portland Web Innovators Meeting

The early evening meeting of the Portland Web Innovators group was attended by about thirty people with a mix of developers, designers and business folks.  The conversation centered around money.  Having it, not having it, making it and spending it.   Carolynn Duncan (@hundreddollar) lead a talk that took the group through the paces on bootstrapping a company.  Here is my rendition of her talk slightly condensed and sprinkled with colorful commentary from yours truly.

Carolynn began the conversation with a slide that says “Bootstrapping is good. Having a revenue model is better.” This set the tone for ensuing discussion.  Carolynn’s opening volley was to set the stage for what bootstrapping really is.  For many of us that are familiar with the “golden days” where VCs just through out cash to any idea, we have a warped perception of bootstrap.   Back in the day we would outline all of our wishes and wants to make sure we could pay salaries, get comfy offices and attend trade shows.  We would then double that amount and go look for funds in the amount of millions of dollars.   Carolynn reeled us in and helped us to think in terms of reality and today’s economy.  She defined bootstrapping a business as determining the bare minimum amount of cash needed to get a solution to a point where the revenue model out paced the expenses.  What a novel concept.  Spend as little as possible and make as much as you can.  Although this is inherent to our every day lives, for some reason the tech start up world forgot about this basic business tenant and it’s about time the tech community was told straight up to change their ways.

As Carolynn continued she explained that the equation for bootstrapping your idea was rather simple.  You need to determine the core ingredients necessary to get from point a to point b in your project.  For every item on your list you should determine if you must pay cash for that item or if you can get creative to minimize your expenses.  She offered suggestions of using less than perfect hardware for certain tasks, bartering or trading for needed services or leveraging external services where you can create a win/win situation without the exchange of cash.  She warned the audience of a failure of many companies; not exchanging value for value received.  She explained how even the most ambitious company has a limit to what they can endure when it comes to helping out your business.  Be cautious of what you are asking of your network and your suppliers and make sure that you know where to draw the line and cough up some of your hard earned money to keep the circle of life spinning.

Carolynn then displayed a simple ratio graph where she explained that a half ass product would require less than prudent sales tactics that would then result in a negative income stream which would eventually result in poverty and unhappyness.  On the flip side, she said that with some planning and an idea of what you are selling and knowing why they want to buy it (remind you of any previous blog posts?) then you can flip around the equation.  She demonstrated that a strategic product offering based upon a customer need could result in the pursuit of a working revenue model & customer acquistion strategy.  The end result of this type of planning and smart approach to development could lead to a much improved income stream resulting in the minimization of poverty in your household.    Simple concepts, yet another data point behind my continual harping in my blog that you should know your customer and determine what problem you solve BEFORE you write any code.

As Carolynn began to wind down the talk she posed one rather forward question.  The question was “Why build something if you don’t know how you are going to make money from it?”  You could hear the slight groans from the audience as our Portland based freedom fighters wrestled with this concept.  Now to be fair, there are times when people build things without the intention to ever make any money from it.  They are building things for the greater good and to enable them to contribute to the world at large.  But today’s talk was about money and making money, so in context of the meeting – her question was tremendously relevant and to the point. Carolynn also offered some great lists of what not to do when determining your business model.  Again the simple was supreme.  Don’t creat a new model.  Don’t be free.  Don’t seek double revenue models.  Don’t have special rates for friends and family. She also went on to discuss what does work and offeres 23 ways to think about revenue models. In her presentation she then gives us her insight on what she has seen work with 43 ways to get customers.  To see all of Carolynn’s tips and tricks you can visit her blog at www.bigpaperblog.com or follow Carolyn on twitter @hundreddollar

Thanks Carolyn for sharing you knowledge with the Portland Web Innovators and I hope that your advice will be put to good use by the brilliant minds in the audience who are almost all working on side projects or startups.  I loved your goal of seeing 10 new MILLION dollar businesses in Portland within in the next year.  I know for one I’ll be following your advice to make sure that MioWorks.com makes it into that short list.

Telling your story – episode 1

February 4, 2009 at 10:59 pm | Posted in cloud computing, Software as a Service, Sofware Startup | 2 Comments
Tags: , , , , , , , , , , , , , , , , , ,

Over the past few months I have been watching new technologies come to life  in the silicon forest of Portland.  Although I see some great new solutions that actually have a fighting chance, it has become clear to me that messaging is something that eludes even the smartest of the entrepreneurs.  It seems to me that there is almost a void when it comes to the concept of marketing with the small teams.  The focus remains on the technology for the duration of the project and only at the very end of the cycle the team spends a morning at a coffee shop trying to figure out how to market what they have built.   In a three part series of posts beginning with this one, I plan to  offer a bit of my assistance to help the young company come to grips with the fact that marketing must be part of the bigger process.  Marketing must be something you think of when you start your project, as your build your project and even past the day you launch the project.  Marketing isn’t just using twitter to tell your peeps about your cool application, it’s a process that takes some thought and process.

Now don’t get me wrong.  Marketing isn’t always about yelling “Sunday Sunday Sunday, big monster trucks in the mud.”  Marketing is as subtle as a simple story that explains what you are doing.  Unfortunately many think that marketing is rather simple and doesn’t really require much thought.  This would be yet another one of those mistakes that the entrepreneur can make.  Creating your story takes a little patience on your part and an understanding of what your target market wants to hear.  Creating the story is more than telling the world why you build something or what it actually does.  Telling the story is explaining why the software will help the user in terms that the USER understands.

Let me offer a scenario to make my point.  You are at a cocktail party and you are mingling around the group.  As you make your way across the room you are approached by the slick salesman wearing his pimped out suit and shiny shoes.  He introduces himself and starts to tell you all the great things about his condo project.  The earth quake proof building and how it took a design team 5 years to architect it.  He talks about the two story glass pool.  He talks about the great access to public transportation and the soundproof walls and the high speed elevators.  He goes on and on about the condo project.  You sip your drink and smile politely waiting for the opportunity to escape.  After he divulges all these great amenities he asks you if you would like to stop by to see the project.  You politely decline, telling him you like your home and aren’t in the market for a new one.    Finally you walk away and think to yourself, wow that’s 5 minutes of my life I’ll never get back.

Let’s make the correlation to what I see with software companies.  Many of the companies are just like this sales guy.  They start to spew out feature after feature hoping that something in there will gain interest by someone (I think we call this throwing s*&t against the wall to see what sticks).  They think to themselves “If I show all the features or how many whiz bang buttons I have, the audience will see for themselves that our solution is vastly superior and they will use it instead of the competitor.”   DING DING DING….wake up! This won’t happen.  Success isn’t a magical event.  It’s a planned strategy that takes time, hard work and great timing.

To create your story, the first step is to define your audience.   I won’t harp too much on target market, but if you have read my previous posts you are starting to see a pattern.  Once you know who you are speaking to, you will have the insight to speak to them in the terms that they will understand.  Your story should use words that make sense to the audience. If you are speaking to small business owners, drop the techno-jargon.  If you are speaking to doctors, talk about patients, medical records and insurance forms.    Do a little research about your target markets and find out how they refer to the issues or challenges that you solve.  Create a list of these keywords to use later in the process just like you would create simple functions to use later in your code.

As an example, if your application manages documents then get more specific based upon your audience.  In the case of MioWorks.com, we help to manage documents between companies and their customers across six verticals. But instead of just saying documents we look deeper at our target markets and find out the types of documents they use on a day to day basis.  This allows us to talk to our customers in terms that they will associate with and easily draw conclusions between our software and their business.

Now that you know how to “talk the talk” it’s time to take a walk through your own solution.  Put on your customer hat and view your application as if you were a customer.  Think about a day in the life of that person.  Think about how they would actually use your software.  One ritual I always perform with my applications is to physically set up an instance as each customer type.  I then try to mimic their use of the solution.  I also try to find a few people I know to help me simulate the role of the customer.   Afterward we have a chat about what we thought were the most compelling reasons for using the software.  At the end of this session you should have the foundation to your messaging and this is what we need to move onto the next step of creating your story.

Stay tuned for episode 2.

Completing the elusive first version of a web application

January 29, 2009 at 10:13 pm | Posted in Software as a Service, Sofware Startup | 1 Comment
Tags: , , , , , , , , ,

It’s just a bunch of web pages, right?  Why do developers struggle with getting these pages completed?  Why do the the developers go back and do rewrite after rewrite?  Why has the team missed three deadlines and are telling us it’s another six weeks?   

Do any of these questions sound familiar? 

Well, don’t feel bad.  In all my years in the software industry I can confirm that this syndrome hits every company from the smallest to the largest and every generation.  It started with mainframe applications for 3270s, then continued to plague developers in the client server era and now continues with web applications.   The struggle to deliver a product on schedule  seems to be the monster lurking behind every side project, start-up and well funded corporate effort.  But don’t despair, there is a way out of this seemingly endless maze. 

Much of the problem lies within the definition of “done”.  Developers want the product “done” before they release it to the world.  They don’t want to be judged on a design, a work flow or a business process that they aren’t 1,000 percent satisfied with. Product managers want the product “done” according to the precise specification they wrote.  Sales teams want the product “done” to satisfy that one customer who is on the cusp of a sale.   And executives and founders want the product “done” to meet their investor expectations.  Unfortunately if you line up the trajectory of each of these stake holders, more often than not you will not find point in time where they all converge.   This mismatch of expectations and understandings  result in missed schedules, arguments between teams, dis-satisfied customers and even worse, a company in chaos.  

The good news is that the solution to this problem isn’t new.  As a matter of fact it is well understood and has been tested over time.  The only problem is that as entrepreneurs we think that we can shortcut reality and just get the job done.  Well, let me warn you.  If you take this approach to your first version you will be very unhappy when you realize you are in the wheel of chaos missing deadline after deadline. 

History has told us that a good plan gets a good result.  Software development is no different, regardless of the medium.  After many lessons learned, I always guide my teams with a high level plan before we get started.  We answer four basic questions before we ever talk about a single feature or cool technology.  These questions include: 

  1. Who is our target market? And this isn’t just a label – it is the actual companies we want to sell to.  Names, locations, characteristics. 
  2. Why would these companies have an interest in this solution? – Get real here.  Don’t fantasize, explain it and see if you believe it yourself.
  3. What is the compelling reason they will use your solution? – Get away from your computer and go ask some people even if its only a dozen or two  This input  will give you insight into what the customer thinks and if there is something to your ideas. 
  4. What must the solution do for the target market to win their hearts?  Continue discussions with a few select prospects and see what really gets them excited.  Find out the “must have” elements to make them happy.  I will tell you now that customers need less features than you think they do.  Find out what drives them and what makes them excited about your idea. 

If you notice, I have not talked about writing one line of code, creating a single wire frame or thinking about color schemes.  The success or failure of the delivery of the first version lies squarely on the answers to the four questions posed above. 

For our application, the MioWorks.com team sat around a virtual conference table and talked about the type of customer we thought was being ignored by the Software as a Service marketplace.  That was pretty easy to define.  But we still had nothing more than a label that defined 100 million companies.  Not very targeted.  We then generalized the types of problems that were the most compelling to solve for this marketplace.  We then took it a step further and performed an analysis of dozens of verticals.  Finally we had our set of six vertical markets in a well defined geographic region that we thought would benefit the most from our idea.  

Once we had the answers to our question we were able to start to bring the idea to life.  We wrote a document that described the problems faced by the target market and what could be done to solve those problems.  Then we shared that document with all of our team members and consultants.  This set the foundation for all decisions to come.  At the end of the planning exercise we knew exactly what we should build to provide the biggest benefit for our target market.  

From the business definition we then began sketching our wireframes on paper and bringing together all of our ideas.  As new ideas came to light that were not directly aligned to our plan, we tabled them for a later time.  In our project management system we created an area called the “Idea Bin” that everyone could contribute to.  This allowed us to keep track of the great innovations that we can implement after the first version is completed.  As progress continued, we applied strong discipline to focus on our solution according to the plan we set out with.  I think that this is where many companies falter.  They have a “better” idea along the way and want to make wholesale changes to the application and the schedule.   

As our development continued and we broke through each of our milestones, we were challenged with potential schedule breakers. But this is where our plan and our answers saved us.  Every time we ran into a roadblock we took a step back.  We didn’t try to force a solution or try to build a bridge to cross a stream once.  We re-evaluated the software requirement and then looked at how it impacted the overall plan.   In many cases we were just trying to be way to slick for our own good.  We realized at times that using a piece of open source technology here or a library there would solve the problem and let us continue down the path to completion.   As problems arose we talked about them as a team.  We looked at options and the impact of each option.  We then made the best decision that would allow us to keep momentum and still satisfy the needs of the prospective customer.  

The process we follow with the MioWorks.com application may not work for everyone, but the guidelines behind the process will.  No matter what you are building, start with knowing who is going to buy it and why they will buy it.  Once you have that golden nugget of information, you can direct your team and make decisions much easier and get just a little more sleep!

Next Page »

Blog at WordPress.com.
Entries and comments feeds.