Web consultancy based in Tel Aviv, Israel, and Berlin, Germany.
About us.
Read about
how we work
with our clients.
Contact us, we are friendly.
We're hiring.
Read our blog.
Hi all,
There are 2 major approaches to developing a business those days
predictive development
roll out 800 pages spec, work on it’s implementation for couple of years, then release it to public and think you done. This is a way the sofware was developed in early 70s and is still developed today in many cases
adaptive development
roll out some close approximation as fast as you can, and then iterate until perfection
While predictive development has it’s niches, like programming this box with wheels that goes for Mars, in 99% of apps it’s worse approach. It tries to guess solutions to imagined problems instead of finding out what the real problem is and what solution is really works in this specific case.
We at Astrails actively participated in building stratups for the last 5 years, and based on what i’ve seen, most stratups, and almost all successfull ones are choosing to use adaptive development.
Teams that choose adaptive development suceed again and again in taking their products to market faster, products are way better answer the pressing needs of their target audience and the budgets are way lower.
And they can call it whatever buzz term is popular right now, it may be extreme programming, agile development, scrum or mega-hiper-ultra-kickass-development, the main principals are very similar.
Let me go over some of the major steps of adaptive development and then i’ll come back to kick predictive development a bit more.
So how i would build a startup today?
It would be best if this is your problem, something that bothers you personally. But it doesn’t have to be.
Go talk to whoever might have the same problem and ask them - does this solution would solve it for them.
Google it, try to find something that already exists and solve this problem. Even if you found something like that - study it and see if you can solve it better.
Minimal thing that shows your way of solving the problem. It doesn’t have to be pretty, it should be a proof of concept.
Show the prototype to people, ask them, whould it work for them? What can they suggets to make it better.
Work on the feedback you get, refine your prototype.
Stop when you think you have a minimal thing you can call a solution. This one should be pretty. It should work and solve the problem and solve it good. But it should be with minimum amount of bells and whistles that no directly solve your problem. You will have time to add those later, if you fill they will help.
It’s time to let early adopters to start using your service. And it should be as early as possible. I heard someone say that of you launch your product and not ashamed a little bit of what you launching, you do it too late. I totally stand behind it. Your main concern at this point should be not whether it feature complete and totally 100% bug free, your main concern should be to get your real users feedback as early as possible.
And then the real work begin.
Yes, again. There are many “get feedback” slides here, and this is not coincidence. I think that constantly getting feedback, digesting it and make improvements to your solution based on it is the most important part in success of any startup, or for that matter, any product at all. They even coined a term for it now, it’s called “customer development”, but call it as you like, until you get your product to it’s users and ask them again and again what works for them and what not, you can’t get your best possible solution.
After you talk to your users, make improvements to your product and make them available for users. Iterate on this upgrade/get feedback cycle until perfection.
Iterations should be short, don’t hold your imrovements inside for too long. We usually work in 2 weeks iterations, at the end of each iteration there’s small set improvements done, tested and ready to be launched to public. I heard that others work in 2 days iteration. There are even teams that deploy every small improvement to users. So choose what timeframe suits you best, but the main point is that it has to be short, you users should see constant and rapid improvement based on their feedback.
That’s at large the steps that i see many successfull teams take to create their product.
Let’s see how it can be done on a more low level, how we use technology and infrastructure available today to our advantage when building a product.
I’ll talk about web applications here, cause that’s what we do and what I know best. But same applies to other products as well.
We start from a short description of what problem the product should solve and the way it should solve it. It should be really short, 1-2 pages is usually enough. It is a waste of time to write long detailed functional specs, cause the very nature of adaptive development dictates that everything will changed once and again during the lifetime of the product. And on the other hand i believe less in fuctional specs cause they are an abstraction. The same descriptions could be interpreted in many ways, they are just words, they not real.
What is more real?
When a person sees a design there is much less space for interpretations.
And more important, i strongly believe that UI design and usability of the product is one of the most important things. It can build and ruin otherwise identical products.
What was legacy flow regarding the design?
Advanced teams got one step further.
This is wrong
Need to start with design. Design key pages first, those are most important or most complicated pages. Have at least mockups of all pages.
Then you need to choose platform/frameworks to use.
I can see only one reason to not go with open source today. And it’s when you have proven, professional team that works with something like .NET Other than that open source frameworks offer more innovation, effectivity and productivity boost today.
PHP/Rails/Django
Build for today - there is known problem with programmers, they always want to build a framework instead of solving problem at hand. Don’t build for tomorrow, build to solve your problems today. Otherwise they might be no tomorrow for your product if you stuck on optimizations and generalization today and loose the momentum.
Scalability - important to not build a service for a million of users from day one, but have scalability plan. Always know how many users your current setup supports and what you will do when you will be approaching this number. But don’t implement it yet.
Scalability problems are actually good, they mean you’re growing fast enough.
Take twitter for example. They were not ready for the user growth the saw, they had terrible scalability problems, there was time that their service fell apart in front of their eyes. But they here today and rule the microblogging world. If they would spend more time on getting their service more robust, someone else would stole all the buzz and their users and they would be left with great robust and scalable service that no one knows and remembers.
Security - never forget about security. The bad people on the internet are always waiting to get you.
Outsorce everything that is not related to your main business.
Today everything can be online. We manage our emails, documents, code repositories, project management tools, bug tracking solutions - everything is online.
Hosting - there is a great service from amazon called EC2, or Rackspace Cloud or even Azure from Microsoft that allow you to scale fast and manage all your servers and infrastructure needs effectively. There is even greater service fron companies like Engine Yard that provide a managed hosting and allow you to outsource all your system administration needs.
Using all this today allow for building new products really fast and relatively cheap. We build a typical product for $40-$60K and in about 3 month. I’m talking on production quality service, stable, beautifully designed, actively used by it’s target audience.
Big companies stuck behind and don’t use all these field proven methods that work for smaller startups.
And while i understand that requirements might be different, i think that a lot of teams that still work using predictive development can use some of those tactics to drastically improve their product, lower time to market and lower budgets.
Thanks.