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!

Checklist for starting the business (and their costs)

January 5, 2009 at 11:54 pm | Posted in Software as a Service, Sofware Startup | 1 Comment
Tags: , ,

Here is my checklist for getting the business formed and off the ground.  I also detailed what it cost in ()’s. 

1.  Determine business structure, submit paperwork via legalzoom.com, obtain articles of incorporation from State ($400)

2. Contact IRS and obtain taxpayer identification number for the business (No cost) 

3. Open bank account and make initial deposit (No cost but added 2 months of expense money as initial deposit) 

4. Apply for Portland Business License from the city (No cost) 

5. Obtain business insurance ($2M liability policy cost approximately $25/month) 

6. Find appropriate office space, sign lease, move in (Leased a small office for approx $1,000/month) 

7. Establish account with phone/internet provider (Installation was $350, monthly costs $150) 

8. Secure domain name for 3 years ($100) 

9. Establish account with Amazon Web Services for application hosting ($120/month and will grow) 

10. Setup online account for code management, repository and project management ($30/month subscription) 

11. Setup online marketing database and eNewsletter system ($30/month subscription) 

12. Obtain a merchant account for payment processing from your bank/provider (No charge) 

13.  Establish a payment gateway account to integrate with the software to actually take credit card payments. (No charge) 

14. Establish a method for recording all expenses related to the business. 

15.  Determine budget (1 month, 3 month and 1 year) so that all partners are on the same page.

16.  Determine how you are going to fund everything going forward (ok – this was actually step 1 but I forgot to put it up there and I’m too lazy to re-number everything)

Dual tracks – build an application, build a business

January 5, 2009 at 4:11 pm | Posted in Software as a Service, Sofware Startup | Leave a comment
Tags: , , , ,

Within a few weeks of putting the team together the software application was under development.  The technologists began building the data models, security frameworks and application frameworks.  The designer came up with what I think is a terrific visual for the application and the pieces were starting to progress.  Everything was humming on the product side.  Now it was up to me to build the business.

The business is the part of a start up that is hardest for innovators.  Unfortunately there are hundreds of moving parts, legal issues and other issues that must be taken care of before you are really a company.  This can be a full time job just to get things established.  I’m fortunate that I learned all of these pieces while working for other companies.  We knew what needed to be done, it was just a matter of making decisions and putting everything together.

Our first major decision was on business formation.  In the USA we have several options on how to structure the business.  Partnership, Corporation, S Corporation and LLC are just some of the options.  In our case we decided that a Limited Liability Company was our best course of action.  The main reason is that the company is owned by the founders and we want to keep it that way.  In an LLC the profit/loss of the company is passed directly through to the members (owners) of the LLC.  We felt that this structure would minimize double taxation (as in the case with a Corporation).  We also felt that the LLC supported our goal of building a software company from the ground up using our own resources.

Once we determined the type of business to create now we had to decide what state to establish the LLC in.  After some research and forward thinking we decided to create an Oregon LLC.  I utilized LegalZoom.com for the formation, filled out the online forms and paid the fees.  A few weeks later the name Mio Partnerz LLC was secured and the paperwork was filed and approved by the Secretary of State in Oregon.  Once the articles of business formation were received I then contacted the IRS to obtain an employer identification number for the business.  This is necessary for opening a bank account so it’s important to get it right away.

With the business formed and the IRS number in hand I went off to a local bank to establish an account for the business.  The process was relatively simple.  I provided copies of the paperwork and the Tax ID Number to the bank along with about a hundred forms of my personal identification (ok – more like 2 or 3).  Within a few minutes the bank account was established.

Meanwhile my marketing counterpart was taking care of getting us office space to call home for our business.  We found a perfect space on the East side of Portland in a converted warehouse project.  To secure the space we had to execute the lease individually.  They wouldn’t allow us to execute it as the business.  This is a downfall because it makes us personally responsible for the lease term, but there was no way around this.  We also had to obtain business insurance at this point to take possession of the space.  A few phone calls to local insurance agencies and we wrapped up a million dollar liability policy for around a hundred dollars a month.

At the beginning of December we made our trips to Ikea and got the basics we needed to setup a small office.  We moved into our space and began calling it home for Mio Partnerz.  Both tracks were now well under way but there is still a big moutain ahead of us to climb.

Idea in hand now what?

January 1, 2009 at 9:46 pm | Posted in Software as a Service, Sofware Startup | Leave a comment
Tags: , , , ,

Once I had the idea in hand I needed to find a team of people that could help me build the application.  My skills are all on the product strategy, design and marketing side of the house.  So I needed to find someone to be the technology leader and then a few others with skills that could compliment each other.  I determined that I needed at least four people to get things started – the technical lead, a ruby on rails programmer, a designer/graphic artist and an HTML developer.  I was excited about the idea and I wanted to try and find other enthusiastic entrepreneurs in the Portalnd area to get on board with the project. The only way that I could make this work without begging for money from the VCs or Angel investors was to get people to do the project as a partial owner of the business.  This turned out to be much harder than I thought…

Being new to Portland I didn’t have a big network to rely on.  In my short time in the city I had attended a few beer and blog meet ups and a social session with the Legion of Tech brigade.  I decided to keep on poking around this group and see if I could find people interested in starting the side project.  Week after week I met new people and had a good time enjoying a beer or two.   But I couldn’t find anyone willing to get involved in my project without regular compensation.  I was frustrated to say the least. I then changed my tactics and started looking through the network of people that I had met over the previous year.  There were consultants in Romania, there were innovators in the Philippines, there were software consultants in the USA.    As I combed through my list of possible alternatives I ended up convincing one of these contacts to join me as my lead technologist.  Quickly after he signed on to get involved in the project we were able to convince a strong developer to also lend a hand.  Back in Portland I was able to convince a friend to join us on the marketing side so that we could really focus on doing the right type of marketing from the get go.  He agreed and jumped in with both feet.  After a few weeks of the three of us fumbling around with designs, wireframes and HTML we realized that we didn’t have the critical element we needed to really get things underway.  So once again I dug into the world wide web and linked up with a consultant that could deliver on our first layout/design.  It cost some money but it was worth it to jump start the whole program.   Finally the team started to take shape.  Unfortunately it wasn’t in Portland like I had envisioned.

How it all started

December 31, 2008 at 5:07 pm | Posted in Software as a Service, Sofware Startup | Leave a comment
Tags: , ,

Knowing that my tour of duty at the VC funded startup was coming to an  end, I started to think about what to do next.  The thought of working for a big company didn’t really do it for me and with the economy in shambles, the small companies would be holding back on adding any executives.  I decided that it was up to me to make something happen.

The first thing that I had to do was formalize the idea that I had.  After years of working in the software business and watching the trend towards Software as a Service, I knew that this was the place I should go.  I began to do my research to determine where the gaps were and what type of application could be successful.  I looked at the leaders like Salesforce.com and SugarCRM.  I stepped back and looked down market at companies like Zoho and 37Signals.  The research all led me to one place and it was that one idea that became the foundation for our concept.  I won’t reveal the concept until the software launches but I can still explain the process we took to get to where we are today.

With idea in hand I set out to write out the story of the application.  I created a document that explained the concept and how users would use the solution.  I detailed why they would want to use it and how they would interact.  I talked to a few people I knew in the industry and got their feedback.  I used that feedback to flush out the concept even further.  I then used Keynote to mock up the wireframes that would represent the pages of the application.  All in all the initial version of the wireframes represented about 50 different application screens. The process to discover the idea and get to this point took me about a month.    I now had my idea in a form that I could share with others.  But there was one big problem it was just me.   I had no team.

Blog at WordPress.com.
Entries and comments feeds.