Archive for March, 2010

Worry About Scaling Later Just Build Your Product

Wednesday, March 31st, 2010

Just a short post today as there is not a lot to say on this topic.

I think too many start-ups worry far too much about scaling. My advice would be to just get your product built and worry about scaling later, if you have scaling problems it is a nice problem to have as it means your app is successful. If scaling issues occur you probably have huge traction and a lot of users so you will have the resources to deal with scaling. I would estimate that the majority of web apps that are built never encounter scaling issues. The MySQL vs NoSQL debate has perpetuated the scaling discussions but you need a lot of traffic before you consider a huge architectural change to a schema less database.

There are some simple tips you can use to speed up your site and deal with moderate scaling issues:

  • Have a separate file server for your static files (running nginx or lighttpd NOT Apache)
  • Get a decent server with good ram
  • Use memcache or some other object caching system for templates and database calls
  • Find bottlenecks in your code and optimise them
  • Tune your existing servers
  • Have a load balancer for your requests
  • If you have separate database and webserver then make sure they are all with the same hosting company to keep latency low

A really basic architecture would be:

  • One load balancing server
  • Two web servers
  • One database server
  • One file server

You can then add to each of the clusters as you need to e.g. you can add another database server or another web server. It is obviously not as easy as that but that it is the basic concept.

Explosive Development – From Idea To Protoype In One Week

Wednesday, March 24th, 2010

A couple of years ago I heard Obie Fernandez (from Hash Rocket) talking about rapid prototype development and that sparked a huge interest in me. Ever since I have been investigating and involved in rapid software prototyping and have learned a lot of lessons through experience, trial and error.

In the last year I have been working with various companies and projects to deliver working prototypes of software in one week! It can be done and in fact I argue should be done. I love the work that Eric Ries is doing with lean start ups. I share his opinion that you need to increase the learning of the organisation and test all your assumptions quickly so you do not waste resources.

Preparation, preparation, preparation

Everyone needs to be prepared in advance of work starting. Ideally a kick off meeting is arranged about a week before the start date and the whole team needs to be present. This should be a short meeting and will cover:

  • team introductions
  • the problem you are trying to solve
  • the scope of work (feature set)
  • the process for the week
  • the roles of the team members

What I have found is that after this meeting the rest of the week before development starts your subconscious mind will start to generate ideas, start solving problems and make sure you are ready when development starts.

Everything needs to be ready when development starts, the room you are using, meals, communications, servers etc. These items can eat into your valuable time.

Focus and prioritise

The only way to get to a finished product in one week is to make sure that you only build the bare essentials. This means heavy prioritisation and focus on what is important.

First focus on the problem you are trying to solve and then make sure that you product solves that problem elegantly. Every feature should solve the customer’s pain or it should be removed from the feature list.

This is the idea of the minimum viable product (MVP), the smallest feature set you can get away with to solve problem. You are not looking to the world here and there will be plenty of time in the future to add features and polish the tool once you know you are on the right track.

This is where the project manager needs to really steer the ship and make sure that progress keeps to the agreed tasks and features.

30 minute meetings

If you must have meetings they should be kept to 30 minutes maximum, this will keep everyone focused and prevent people going off topic. It is important that someone chairs the meeting to make sure that the schedule is kept to and that the focus on meetings is making decisions and moving forward.

Most of the time we have the rule that once a decision has been made in a meeting then it is final, you do not have time to constantly debate the options and waste precious brain power pondering if you have made the right decision.

Mixed team of experts

In order for the this process to work you have to only have experts in the team, people who know the tools and processes that you are using like the back of their hand. It is also helpful if the team have worked together before so they know each others working practices and styles of working.

It is also essential to have a mixed team ideally consisting of:

  • 1-2 developers (who build the code)
  • 1-2 designers/ front end developer (to design the screens and build front end)
  • 1 project manager (manage communication, brainstorms and tasks)
  • 1 client (at least one member of the client team)
  • 1 customer (at least one customer)

Feedback loop

The whole objective is the make sure that all that the product you build solve the needs of the user. This can only be done if you have end customers in the room working with you to give you feedback.

It makes no sense to write hundreds of lines of code only to find that the customer is actually indifferent about the feature. This feedback loop can be short circuited by using wireframes, html mock ups and design screens to make sure the interface meets the customers needs before you spend time building it in code.

No distractions

This seems like an obvious one but in practice is hard for people to do. Ideally no emails, phone calls or other communications outside the project. You need the team to be totally tuned in to the project so that all their conscious and sub conscious thoughts are tuned into making progress and moving forward.

Automation tools and frameworks

You do not have the time or the energy to re-invent the wheel, so you need to automate and remove common or repetitive tasks. This is where a good framework like Django (or Rails) can make a big difference.

We also have a library of code we can call on, CSS snippets, user authentication, common JavaScript libraries that also reduce repetition and give us a huge head start.

Where possible use web services or common webservices such as Amazon S3 or the Yahoo developer tools to offload some of the development.

Don’t work all night

Initially we thought that it would be a lot better to work every hour of the day as time was so limited, but we soon found that actually that was not the case. Having time off in the evenings and getting a good nights rest meant that you could actually do more with less time. Now that does not mean that sometimes you will not have to work long hours especially if things are not going to plan but it should not be the norm.

Conclusion

Building a prototype in a week can be done but it requires a lot of discipline, focus and an amazing team to make it happen.

The only way to make sure your company succeeds is to make sure that you are making products that solve your customer’s need. The faster you can get feedback from the customer the better, don’t spend months writing code only to find it actually is not fit for purpose. Get something basic product to your customer, learn from their feedback, refine your product and then continue this cycle.

As I said at the beginning you need to increase the speed of your company’s learning, the faster you can learn and make adjustments the more relevant your product will be to your customers.

The Problem With Unsupported Software For Businesses

Monday, March 22nd, 2010

Recently I have been trialling some content management systems for some very small websites that do not warrant custom development. I have looked at some of the big players like Expression Engine, Joomla, etc as well a lot of others.

In the end I found one that I really liked the look of, it seemed perfect for my needs so I tried to install it. I went to the set up screen and it was totally blank, so I followed all the advice on the forums, read the docs and still had no luck.

Here is where things went wrong, I immediately went to the site to look for support and there wasn’t any support only a support forum. So I posted a message and waited, and waited. In the end I got three replies pretty much all saying the same thing; read the docs and post your server config, both of which I had stated in my original post. After two days of waiting I gave up and chose another solution that had better support.

The lessons here are that if you cater for businesses you need to:

  • Solve user issues quickly
  • Provide support (even if you have to pay for it, I would have paid for support)
  • Provide multiple channels for a user to reach you, having a forum is not enough
  • Give people an idea of time scales, there is nothing worse than not knowing

Please do not get me wrong, communities and forums are superb, and I am grateful that someone took the time to reply to my forum post. But they are just not good enough if you have a business requirement that is time sensitive.

You need to know who your users are and what is important to them; price, time, operations, task completion etc and make sure you communicate how you solve issues if they arise.

When Did Failure Become Desirable?

Wednesday, March 17th, 2010

I have been reading some books and blogs recently and I have come across a recurring theme of failure:

  • Fail fast
  • Fail often
  • Aim for failure
  • Fail in order to learn from your failure

Listening to some people at events recently it almost feels like people are aiming to fail! Almost like it is a badge of honour.

Don’t get me wrong when things go badly lessons can be learned, but I would much rather things went right. I think some people overlook that fact that you can learn a lot from your successes as well. Find the things that are working and do more of them.

If you aim to fail chances are you probably will. If you aim for success chances are you more likely to reach your target.

Try the success cycle instead

So I suggest a new formula, a success cycle:

  • Aim for success
  • Succeed often
  • Learn from your successes
  • Do more of the things that are working
  • Rinse and repeat

Start Up Business Phases – Early Stage, Seed Stage to Rapid Growth

Wednesday, March 10th, 2010

I have been consulting recently with some start ups that have all at different stages in their development cycle. Something that I have found some business founders overlook is that your strategy, approach and focus need to change depending on the phase your business is in.

Typically you would classify your business into the following:

  1. Conception or Early Stage
  2. Seed Stage
  3. Series A (or Funded) Stage

You need to know which stage your business is and align your operations and strategy to your phase.

Stage 1: Conception or Early Stage

Funding: Usually from savings or friends and family
Revenue: None / very little
Team: 1-3 people (founders)
Financials: Keep cash burn low as possible

Objective: Build the product

In this bootstrapping phase you are mainly focused on building the first version or prototype of your product. It is a lot easier to test your concept and raise seed funding if you have a tangible product. This is why I think it is essential that the founding team have at least one or two people who can build the product themselves; you cannot have founders who are all ideas people at this stage everyone needs to contribute to the product.

Quite often in this stage you will be working in small home office, bedroom or out of your garage.

This stage is about also about finding your working styles with your co-founders as usually you will not have employees apart from the founding team. After this stage you will really know if you can work together and you may find that you have to make the tough decision to remove one or more of the founders.

This stage is all about doing and action, there should not be lengthy debates or lots of planning, you need to build your product and build it fast. Think about the features you want to have in your beta version and then cut the feature list in half, you want to have the minimum viable product for your launch.

Stage 2: Seed Stage

Funding: Friends, family, angel investors or seed capital
Revenue: None / very little
Team: 2-7 people (mostly engineers)
Financials: Prove revenue model

Objective: Prove the concept

Now you have a working prototype you need to take your product to market and test your proposition. The whole approach is build, test, refine and build again in short cycles. You need to really communicate and listen to your early users and offer incentives for feedback.

At this stage you may have taken on seed funding so you can grow your team, most of your team will consist of software developers and designers as your focus is on developing and refining your product. I have seen some venture capitalists that value your business on the number of developers you have and then reduce that value for every person in a suit on your team!

This is a testing and feedback phase that applies to the whole of your business. You will want to test your marketing messages, marketing channels, operations practices and revenue model. You should start building your revenues and work on how you are going to refine your revenue model in later stages of business growth. This stage will prove if you have a viable business to grow in the future.

If you need to you should be looking at raising Series A funding, this can take several months so you need to start early before you run out of cash.

Stage 1: Series A (or Funded) Stage

Funding: Operating profit/ venture capital
Revenue: Moderate
Team: 7+ people (balanced team of engineers and business people)
Financials: Break even and move towards operating profit

Objective: Grow the business

Now you should have some real momentum behind you. Your product should be polished and you will have gone through several iterations using customer feedback. Your objective now should be to grow your customer base and grow your revenues (and operating profit).

Your team should start to become more balanced as well with a better mix of business people and engineers. You will need some people to deal with the sales, marketing and commercial side of the business as well as the technology side. Do not fall into the trap of growing your team too quickly as you may find that you run out of cash sooner that you think.

At this stage you should start to become self sufficient (if you haven’t already done so) and move from break even to profit. You need to generate enough profit to make your business viable. This is the really exciting phase where you really prove your worth and build a business for the long-term.

Django Developers and Coders

Wednesday, March 10th, 2010

If you are a Django developer check out Django Foo, I have been writing some posts on there recently with the rest of my team.

Everytime we solve a problem that is not well documented we post our solutions on there. It has started to become a really good resource for the community.

Freeing The Entrepreneur – Building a Team, Delegating and Outsourcing

Wednesday, March 3rd, 2010

Following on from my post last week I have been thinking about delegating and experimenting with personal outsourcing.

The stages of a business

When you start your business the founding entrepreneur is the face, soul and drive behind the business. As the business grows and more people join the team there is a point where the founder is stretched to breaking point. There is a moment in every business when the founder has to step aside and give more operational control to his or her senior team. This can be a very painful process and can be fraught with problems if you do not prepare for this well in advance.

Delegating and managing a team as opposed to doing the work is a real skill and something that takes time to learn. You need to have systems in place to help people do their job and you have to be on hand to troubleshoot and encourage.

A process for delegating projects

If you are going to move from the main operator of a company to more of a team structure there are a few things that I think might help you in the transition.

Build a great team

This seems obvious but it is hard to find great people. But more than that you need to have people in your team who are comfortable managing themselves and have attention to detail. You need to feel confident in your decision to give them more responsibility.

Design systems to support processes

If you have been doing all the work to date you will be best placed to know the ins and outs of every detail of the business. This makes you ideally placed to lay the foundations for systems and to write any manuals to those who will be stepping into your role.

Trust

Once you have starting delegating you really need to trust your team and have total trust in your decision. If you do not have trust then this new way of working will never work. There may be a period at the start where things do not go to plan you need to give it time as the benefits in the end will be worth it.

Do not micro manage or try to interfere

There will be a huge temptation to interfere and take over, this is the worst thing you can do. Firstly it shows that you do not trust in the person’s ability, and secondly you do not allow the person to learn if you keep jumping in and solving their problems.

Check in regularly

In the beginning you will need to check in with your team regularly to see if they have any questions, concerns or issues. You need to be readily available for people to ask questions. You cannot delegate and then think that you will not have to do anything until the project is due to deliver, there will be a period of transition. As your team get more confident you will need to check in less regularly.

High level overview

Once you have transitioned to delegating more you will need to get regular highlight reports from your team get a high level overview. I suggest daily emails on progress, any issues or items that need attention.

Now you should be free to working on growing the business and doing the things that will really make a difference to the growth of your business.

Personal outsourcing

As you may have read in a previous post I have been experimenting with a personal virtual assistant. The rationale is that you should try to outsource as many of your tasks as possible so that you can concentrate on the things that are really important in your life. This week I have used my personal assistant in India for the first time.

It was quite a learning curve and I think the next time will be a lot, lot easier. I emailed my enquiry to two outsourcing firms and the first one that responded I decided to use. Firstly the sign up process at VMG BPO was fairly painless, although PayPal rejected my card which was annoying.

Once signed up I read that in order to use the service I had to send an email to support. So I thought that I would start with something simple so I asked for someone to do some research to find an affordable Japanese restaurants near Covent Garden in London.

Then twenty-four hours later I had an email in my inbox with all the research I requested. I had a look through and the quality was superb and saved me quite a few hours. This was a very good start and cost me $6 (£4.50!).

I am going to try and use this service again in the future!