The purpose of this blog is two-fold. The first is to inform you of what's happening here at Puzil and anything of related interest to the project.
The second is more broad. It is to look at how the company progresses from initiation to startup and the journey in between. The difference in this blog from many entrepreneur blogs however, is that i will discuss things from a software perspective - very much a living experience as the company runs. In other words, how does writing software for a startup differ from other projects? Expect to see other things in here too, but I hope we can share and learn in developing innovative software.
Something i have learned over the past few years is a bit about how to construct a project for a startup - having been involved (and continuing to consult on) large enterprise projects I have learned the two are very different beasts.
In an Enterprise project you are typically writing towards some external specification, have limited expansability and do the work to earn a salary. You may get excited and interested and even innovate in the creation of the solution, but it is not yours. You cannot one day drop a part of it (unless you are the boss!) and start again when you see a potentially better solution.
In a startup the ideas are yours to shape and believe in. You create, believe, get more encouraged and put in real effort and thought. If you are working part-time on your project, you really need to put in the hours to get the project done. You must pick not only the parts that will get the project completed, but the parts that will give you most inspiration - and ideally inspire others. Believe and other will follow.
As a startup you need to get the ball rolling, but often being the creater and owner of the ideas makes you think you can start writing software quickly. After all, you know what you want the software to do, you have a business plan - or at least something that states your intentions.
However, again from experience, you really need to think about modelling. UML style, iterative perhaps 3 to 6 weeks cycles. The first iteration is typically the most challenging as you try to align your ideas, so expect this to take a good couple of weeks to model and refine.
Choose the highest layer that you can show. Develop facades - interfaces to parts you, or someone you bring in at a later date, can implement. Don't make it throwaway though, really put in thought up front. If your idea takes off you need to be able to scale, so make sure your software can scale right from the start - just don't write it all yet!! Who knows. If your software returns a recommedation based on 5 parameters, who knows that you hardcoded it rather that used some smart object that will come along in 2 months!?
On the other hand, don't over-engineer. In companies you may have heard "You're not writing a flamin' operating system". Perhaps your start-up is, but even in that case you need to think hard about exposure. What can you expose as early as possible to get clients, investors and thinkers to comment on your work. On more than one occassion i have written something fairly neat only to be told something very simple is of higher priority.
Around three years ago I wrote a product called TESARAC which was an enterprise level collaborative blogging tool. It allowed you to create private blogs and different groups could share information. It was running as a beta product in a large Government enterprise. Upon adding some funky text editing facilities to the project as well as some enhanced ontology's to group posts, the reaction i got was cool. What they in fact "wished" they had was an ability to email the blog. So i added a facility to allow them to email the blog and have the data published. They loved it.
[ TESARAC is still running, but when certain individuals left the company the replacements didn't have the same vision and investors couldn't see it working. Roll on 3 years and what's everyone talking about ?? - lesson here is to think of something people really need now and get them using it!]
Take shortcuts, but make sure you allow those to be filled in when you get the time. You want the shortest path to getting a working application, but once you get there you don't want to have to start again. Google have more betas than any company i have ever known, but what's the difference between a beta and a production version? Beta has come to mean "see what they think, evaluate the customer" more than "this may break". Get to beta. Fast.
To start with, we will look at the inception of your project and what to create first.
No comments:
Post a Comment