Startup geek around town

Completing the elusive first version of a web application

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!