One the problems I have always been concerned about is the hours you need to put in. When you are developing the software there are really no limits to the start and end hours, and when on a role you just don't want to stop (if software you wake up the next day and things all go wrong - it's now accepted practice).
The question is, do you need to put in 7 day, 18 hour days? What do you do when you have a family - does that preclude you from creating a startup?
The answer i always come to is to consider that disruptive innovation almost always comes from small companies, or niches of a larger enterprise. The larger companies have all the man hours in the world, but they don't have the focus. I recently heard Paul Graham say that a good software hacker can be worth 100 times a poor one. So make yourself believe you are now a 100 string company. Putting in a 10 hour shift can give you the equivalent of 10 days work - this is very true as the project gets going. I have been in many an enterprise where the process is so slow as to be painful - i once did something in 3 hours which had two weeks planned against it.
I tend to work based on inspiration and i feel that is key to most startup's success. We all know the chances of failure and success so the more you can inspire yourself the better. Use blogs, sites and news to inspire yourself - "That is just wrong", "They just don't GET it" and so on. Remember, if your idea is really that good then maybe everyone else is doing it wrong (so say Google).
Also focus. Select something no-one else is doing. Of course the irony is that there is always someone doing the same thing as you, and quite often they have more money. So as discussed yesterday, make sure you focus and get something out. The market always knows best and you can spend your highly productive time working on the things people actually want!
Wednesday, November 15, 2006
Tuesday, November 14, 2006
Build your business like a puzzle
The amazing things about puzzle's is that you can start at any age. Depending on the complexity of the puzzle and your past experience with them, you may or may not see the whole picture after just a few pieces. In very large puzzle's it may be impossible to know how the different pieces may fit together to for a whole picture - or even form enough of part of the picture to know what that part is. This is even trickier if you are an individual or very small team.
Consider this when building your software. You will likely build many pieces or components for your solution and in many situations many of those components can be reused. Always consider that as a whole your solution may not be quite the picture you expected, but individually you may have formed some excellent component pieces.
Perhaps one of those parts is what the industry is looking for. So rather than building a whole CMS solution, consider that it is composed of an editor, a version manager, an RSS aggregator, a novel UI and so on - individually those parts compose some of the largest software companies on the web (writely, bloglines etc).
So, multiply your chances by building your pieces so that they can stand alone and perform a well-defined function which may well be the one that is grown and becomes your idea!
Consider this when building your software. You will likely build many pieces or components for your solution and in many situations many of those components can be reused. Always consider that as a whole your solution may not be quite the picture you expected, but individually you may have formed some excellent component pieces.
Perhaps one of those parts is what the industry is looking for. So rather than building a whole CMS solution, consider that it is composed of an editor, a version manager, an RSS aggregator, a novel UI and so on - individually those parts compose some of the largest software companies on the web (writely, bloglines etc).
So, multiply your chances by building your pieces so that they can stand alone and perform a well-defined function which may well be the one that is grown and becomes your idea!
Master Story
The first model of your project is probably the most difficult. You need to have an intuitive idea of what best represents the problem you are solving. This is what you need to showcase. Funky algorithms and flash interfaces don't mean much if the core function is erroneous. Get something to people to comment on. Get a story to start from.
Typically start with a master story. A master story is a fairly detailed chapter of what you see the solution doing. Include everything needed to give a full picture of the solution - do look at how you intend to solve it (unless there are novel ideas that should be mentioned), but do go into expectations from all parties (admins, users, system etc). Someone should be able to read it and have a very good idea of the overall picture of your concept. Although it may be more technical than anything outlined in a business plan, it should be targetted at an audience with knowledge of the domain and/or technology - at a high level at least.
Note that we discuss some concept behind the solution, but leave the detail. There are other points around features such as registration, security and so on that could and should be discussed. Someone can read the master story and break it into many sections which can then discuss the detail - this means that all sections should be covered in some manner in the master story.
Next time we will look at creating sections and sub-stories.
Typically start with a master story. A master story is a fairly detailed chapter of what you see the solution doing. Include everything needed to give a full picture of the solution - do look at how you intend to solve it (unless there are novel ideas that should be mentioned), but do go into expectations from all parties (admins, users, system etc). Someone should be able to read it and have a very good idea of the overall picture of your concept. Although it may be more technical than anything outlined in a business plan, it should be targetted at an audience with knowledge of the domain and/or technology - at a high level at least.
AggregateIt will allow registered users to save a URL by right-clicking on any browser page and sending to a central database. The central database will store the URL with the users account and at regular intervals poll the site to check for RSS feed updates. Upon finding updates, the updates from all sites in some period will be aggregated and emailed to the user.
Note that we discuss some concept behind the solution, but leave the detail. There are other points around features such as registration, security and so on that could and should be discussed. Someone can read the master story and break it into many sections which can then discuss the detail - this means that all sections should be covered in some manner in the master story.
Next time we will look at creating sections and sub-stories.
Scope
Probably the first technical thing you should do is get an idea of what is in scope for the first release. Scoping is about knowing what you want to deliver in some duration of an iteration. You really wnat to make this as short as 1 - 2 weeks per minor version. The initial period won't be like that as you are still fully understanding what you are trying to create, but after this period (typically the first month) you should get to minor releases and many iterations.
The scoping document outlines the overall intentions of a full major iteration and the current release points. You may have many minor scoping documents within each release, but it keeps everyone (even it it's just yourself!) on track.
The key components are :
You can download a template for a scoping document from here or you can download from the "Templates" link on the right.
The scoping document outlines the overall intentions of a full major iteration and the current release points. You may have many minor scoping documents within each release, but it keeps everyone (even it it's just yourself!) on track.
The key components are :
1. Overview
2. Major Release
3. Current
Release
4. Schedule
5. Outputs
6. Next
Steps
7. References
You can download a template for a scoping document from here or you can download from the "Templates" link on the right.
Welcome to Puzil - a StartUp
This is a blog about Puzil. Puzil is a startup from Glasgow, Scotland looking to innovate in search technology.
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.
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.
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.
Subscribe to:
Posts (Atom)