Digging my own Ditch

I had to pleasure recently of being part of an Economist Intelligence Unit interview on virtual working.

At Aroxo we have a wholly owned off-shore development centre based in India and therefore virtual working is an important part of how we run and manage the continued evolution of Aroxo.

On the panel we had Jasmine Whitbread, the Chief Executive of Save the Children, Ghislaine Caulat from Ashridge Business School and myself. It was chaired by Denis McCauley, the Director of the Economist Intelligence Unit.

You can view the full panel discussion below:

So, big day here at Aroxo Towers! We’ve been a very busy bunch and the results are really starting to show, more people, more sales and more products on the site!

The main reason for this post is to tell you about some really exciting new features we launched today! Here’s what we’ve done:

1. News about products we sell
2. Top Tens
3. Introductions to the top makes on Aroxo
4. Lot’s a performance improvements

News, news, news

At Aroxo we know that it’s really important you get the best information available when you’re trying to decide which product to buy. To help you choose we’re now tracking news from all the different makes and brands on Aroxo.

You can see our full news feed here and it’s kept up-to-date in real-time! In addition to this you can see the news for just your favourite make and follow it, all on Aroxo. Here an example news feed on Samsung. Be careful with the RSS feeds though – they’re not quite working right yet…

Top Ten madness!

On Aroxo we currently have 76 DVD and blu-ray players. Not only is that quite a lot, but it’s about to be expanded out with hundreds more, so how do you decide which one to buy with so much choice?

It’s a big problem, to help make this decision easier, we’ve added in Top Tens for all of our products! You can see the Top Ten DVD and Blu-ray players here.

But not only that, we’ve got an incredibly flexible system for Top Tens, and we can do cool stuff like the Top Ten Sony Bluray players, the Top Ten Sony products, or even the Top Ten Silver Bluray Players!

Guides to all the main makes

Next we’ve been really busy creating lots of new content for you with introductions to all our Top Makes on Aroxo, including introductions to Apple, Samsung, Sony, etc, etc. We’ve got lots more coming too, with more and more product guides and information about individual manufacturers product families too.

Performance improvements!

Finally we’ve done a lot of work to make Aroxo faster to use and enjoy! Because of all the changes we’ve been making the site was getting slow in fact at one point it was taking 10 seconds for a page to load, which is just not good enough! I’m pleased to say that, thanks to a lot of work an effort from our development team, our pages should now be loading in less than a second! Much better!

We’ve still got loads more to come, and we’re trialling out a few new features on the site even as we speak! You might bump into a few of these as you surf around!

I’ve got a nice shiny new bunch of Google Wave invites:

Google Wave invites available

I know that many people are desperate to get their hands on one. So, if you want one, simply blog about this post which I wrote about Google Wave, happy if you disagree or leave you thoughts, just credit me back with a link and I’ll send you an invite!

Matt.

Like thousands of people like me a few weeks ago I got my Google Wave invite, I logged in clicked about, played with a few Waves, had some conversations and signed out.

Overall I was a combination of slightly bermused, impressed by the technology bowled over by the real-time goodness and the slick UI, but fundamentally unsure of what I was supposed to use Google Wave for.

But what actually went wrong here? I’ve got a theory and it’s not what you might expect – valid though those criticisms are. Google Wave went wrong, not because of what it is, but because it didn’t harness any viral power:

1. Invites are not sent fast enough
2. Wave is closed
3. Wave has no pointers

Google Wave is first first and foremost a communications technology, which means for people to really see the benefits they need to be communicating with people they know.

When you join Google Wave you receive 8 invites, when you’re through those you get another 12. But when you send the invite they don’t arrive for several days. Meaning you’ve got practically no-one of significance to communicate with when you’re first into it*.

So your first experience of Wave is with strangers.

The second problem with Wave is that you don’t know when you’ve got an unread Wave. You signed in first time around, played around a bit with a few people you vaguely know online, and sign out. If someone now communicates with you whilst you’re signed out you’re not informed.

No email, no RSS feed, no Tweet, nada.

So you don’t sign in and respond and you don’t slowly fall away from being a Wave user.

The final thing which they got wrong is that there are no easy to follow pointers to get your started, clues for intentional uses, a quick “first action”.

When people first use a technology they are in a state of mild stress, in short they don’t want to publicly demonstrate that they don’t know what they’re doing and therefore look stupid. So they want something easy to do, figuring out the complex stuff afterwards. This is as true of techie geeks as it is of our non-techie friends.

Google Wave doesn’t supply these pointers.

What’s important about what I’ve said here is that all of this is entirely fixable, and there are plenty more people who desperately want to try out Google Wave. With any luck the feedback from the 2nd and 3rd round of adopters will be a lot more positive!

* I totally acknowledge that there maybe good technical scalability reasons for this, but it doesn’t change the affect.

This article is part of a regular series on bootstrapping by Matt Rogers, co-founder of Aroxo. It continues from the previous post which looked at how to find off-shore developers.

Off-shoring your web-development is a great way to save money and, if you are bootstrapping a small start-up, it could be the perfect strategy to hang on to more equity and delay financing. However off-shoring your development is also fraught with risks, it is far harder to manage your development and communicate ideas, so it is vital to take proper steps to protect yourself. In this post I continue describing the system I’ve used several times in order to ensure that I get developers who are motivated, technically capable and trust-worthy.

You’ll find stages 1 and 2 discussed here.

Step 3 – Send the developers you’ve found a “Request for Information”

A Request for Information (or RFI) is a questionnaire to help you short-list developers. The objective of the RFI is to enable you to decide which developers can deliver your project in the right sort of price range. Your RFI should at least gather the following information:

• Hourly rates for different staff types
• Which currencies the developer can raise invoices in
• Whether they are prepared to set a fixed cost for the project (you want a fixed cost, right?)
• Between 3 and 5 customer references
• Information about the company (how long has it been running, how many people it employs)
• Information on their typical project (how big it is, how long it lasts)
• The development methodology employed and development technologies supported
• Whether they have a design house
• Their preferred development technology
• Any technology certifications which they may have
• a “difficult technical problem” which is related to your project, ask the developers to sketch out how they would solve it

I’ve included an example RFI in the documentation bank to help get you started.

When asking for references, try and get projects which are similar to yours. Also get a reference for a company which is physically near you and then arrange to meet up with them for a coffee and a chat.

Your RFI should also tell the developers all the key deadlines for the selection process. It ensures that the developer knows where they stand at all times, and it gives you targets and deadlines to meet yourself. When you issue it give the vendors at least 2 weeks to respond and an opportunity to ask you questions.

If you are worried about controlling your IP, then there’s no need to discuss what your actual business is in the RFI. However, you might want to describe in broad terms the type of business you are launching, or refer to some similar companies.

When you send the RFI out, update the vendor dashboard which you set up at the start of the process.

Note that not every company will respond to your RFI. Some companies will respond but fail to answer the final question, some companies will send you back documentation packs which probably contain the answers, but they’ve not bothered to put them into your format. All these companies should be immediately dropped from the list.

Step 4 – Short-list the developers

Two weeks after you’ve issued your RFI you should have all the responses you are going to get. I tend not to bother chasing any companies who don’t reply to the RFI and just stick with those that do. Your next step is to short-list the developers, you want to work through the responses until you have 4-7 companies to take through to the next stage.

Before you start short-listing the developers, you need to think about what your ideal company is. You might want to work with a small company, or you might be looking for a larger company with ISO or CMM certification, you may have a particular development methodology in mind, or you might want your system built with a particular technology, etc.  Collate all these thoughts to help piece together what you are looking for.

You are then ready to start “the sift”. First stage is to remove any companies which just aren’t right. Personally when reading through these responses I arrange them into three piles: yes, no, and questions. I then ask the questions and update. I continue to do this until I have only a yes pile and a no pile.

Remember to always check the references, this is one of the best signals of quality company. If they are in your country, arrange to go and see them, otherwise drop them an email. You want to know whether the developer delivered on time and to budget, if they still use them, if they’ve given them any new work and if they’d recommend them.

Keep working the list until you get between 4-7 companies. It is important that you don’t take too many vendors through to the short-list round as you don’t want large numbers of companies knowing what you want building. If you don’t have enough, approach more companies. Finally, ensure that you feedback to all the companies involved (good news and bad) and update the vendor dashboard to so can keep track of where each company is.

In next week’s post we’ll look at how to get a price for the development and how to select which companies is going to build your business.

Off-shoing your web-development is a great way to save money and, if you are bootstrapping a small start-up, it could be the perfect strategy to hang on to more equity and delay financing. However off-shoring your development is also fraught with risks, it is far harder to manage your development and communicate ideas, so it is vital to take proper steps to protect yourself. In this post I continue describing the system I’ve used several times in order to ensure that I get developers who are motivated, technically capable and trust-worthy.

You’ll find stages 1 and 2 discussed here.

Step 3 – Send the developers you’ve found a “Request for Information”

A Request for Information (or RFI) is a questionnaire to help you short-list developers. The objective of the RFI is to enable you to decide which developers can deliver your project in the right sort of price range. Your RFI should at least gather the following information:

• Hourly rates for different staff types
• Which currencies the developer can raise invoices in
• Whether they are prepared to set a fixed cost for the project (you want a fixed cost, right?)
• Between 3 and 5 customer references
• Information about the company (how long has it been running, how many people it employs)
• Information on their typical project (how big it is, how long it lasts)
• The development methodology employed and development technologies supported
• Whether they have a design house
• Their preferred development technology
• Any technology certifications which they may have
• A “difficult technical problem” which is related to your project, ask the developers to sketch out how they would solve it

I’ve included an example RFI in the documentation bank to help get you started.

When asking for references, try and get projects which are similar to yours. Also get a reference for a company which is physically near you and then arrange to meet up with them for a coffee and a chat.

Your RFI should also tell the developers all the key deadlines for the selection process. It ensures that the developer knows where they stand at all times, and it gives you targets and deadlines to meet yourself. When you issue it give the vendors at least 2 weeks to respond and an opportunity to ask you questions.

If you are worried about controlling your IP, then there’s no need to discuss what your actual business is in the RFI. However, you might want to describe in broad terms the type of business you are launching, or refer to some similar companies.

When you send the RFI out, update the vendor dashboard which you set up at the start of the process.

Note that not every company will respond to your RFI. Some companies will respond but fail to answer the final question, some companies will send you back documentation packs which probably contain the answers, but they’ve not bothered to put them into your format. All these companies should be immediately dropped from the list.

Step 4 – Short-list the developers

Two weeks after you’ve issued your RFI you should have all the responses you are going to get. I tend not to bother chasing any companies who don’t reply to the RFI and just stick with those that do. Your next step is to short-list the developers, you want to work through the responses until you have 4-7 companies to take through to the next stage.

Before you start short-listing the developers, you need to think about what your ideal company is. You might want to work with a small company, or you might be looking for a larger company with ISO or CMM certification, you may have a particular development methodology in mind, or you might want your system built with a particular technology, etc. Collate all these thoughts to help piece together what you are looking for.

You are then ready to start “the sift”. First stage is to remove any companies which just aren’t right. Personally when reading through these responses I arrange them into three piles: yes, no, and questions. I then ask the questions and update. I continue to do this until I have only a yes pile and a no pile.

Remember to always check the references, this is one of the best signals of quality company. If they are in your country, arrange to go and see them, otherwise drop them an email. You want to know whether the developer delivered on time and to budget, if they still use them, if they’ve given them any new work and if they’d recommend them.

Keep working the list until you get between 4-7 companies. It is important that you don’t take too many vendors through to the short-list round as you don’t want large numbers of companies knowing what you want building. If you don’t have enough, approach more companies. Finally, ensure that you feedback to all the companies involved (good news and bad) and update the vendor dashboard to so can keep track of where each company is.

In the next post we’ll look at how to get a price for the development and how to select which companies is going to build your business.

I’m delighted to announce that on Monday May the 12th I became a father for the first time.

Hallam Rogers was born in Kingston General Hospital at 2144. Both mother and baby are doing well.

As you can see, he’s already an Aroxo fan!

 M.

A friend of mine mentioned something to me recently. He commented that a site he works with recently changed the text on their registration button from “Register here” to “Register for free” and, as a result, registrations shot up.

That really blew me away.

Clearly pretty small decisions can have an enormous and disproportionate impact.

This got me thinking and something else occurred to me, namely how a similarly small decision caused by search engine spam created the Web 2.0 phenomenon.

Back in January 1996, Page and Brin were busy building a new search engine. One that we now know as Google. Their starting point for this adventure was fixing the problem with the other search engines: that their search results were not very accurate.

There were two problems, firstly the search engines were happy to take payment from companies who wanted to appear in their search results and secondly the order of the search results was both arbitrary and easy for spammers to fool.

Companies which wanted to appear in the search results would just stock up their pages with the search terms they were interested in and, voila, in came the traffic. The problem was that the people using the search engine didn’t find what they were looking for. The existing search engines basically weren’t working.

This is where Google came in, they calculated the search engine positions by looking at how many other sites linked to the page, the text which the user clicked on, and how popular the referring page was. They built Google like this because (at the time) this had not been spammed.

This technique worked, web users were suddenly able to access the pages they were looking for and Google became massively popular. What also then happened is fascinating.

This decision encouraged genuine content producers to generate inbound links in order to get access to Google’s traffic. It drove more and more linking on the web, and instead of people getting annoyed about losing control of their content, they loved it. It drove greater sharing,
communication, and integration – the bedrock of Web 2.0.

This, small architectural decision has had a massive impact on the web, both its utility and its social impact.

I wonder whether Page and Brin considered this when designing Google?

Aroxo recently turned a major corner in its development, we moved from closed functional testing to using real live alpha testers, people who’d never seen Aroxo before.

Without doubt, this is one of the most revealing, painful, and valuable stages in creating your start-up, so I thought I’d blog about it.

When launching anything you want ensure that not only does it work, but people find it easy and natural to use. Your own functional testing should cover the first objective, your alpha testing should cover the UI.

At Aroxo we’ve employed four different techniques to get the system ready for launch:

Not only is each stage different but you get different learnings from it. I discuss each stage below.

(more…)

A really effective way of boot-strapping your start-up is to off-shore and out-source your development. But doing this also carries risks, how can you be sure that you are going to get a developer who’ll see it through and has the right experience? This post lays out an effective process to find the right developer.

From starting the search, to the first developer writing code should take around 3-5 months and there may be further delays whilst you complete your documentation. In this article I’ll talk you through what you should be doing at each stage, and what the objective of each stage should be. Here’s an overview of the process:

1. Build a long list of development companies
2. NDA all the companies on the long-list
3. Issue a Request for Information (RFI)
4. Analyse responses and short-list the developers
5. Issue a Request for Quotation (RFQ)
6. Analyse responses and select a preferred vendor and a spare
7. Negotiate contract with preferred vendor
8. Commence development based on your documentation

This is a long process, and therefore I’ve split it up into 4 sections, these will be posted each week for the next four weeks. Any regular readers can relax – the whole lot has been written in advance, so there won’t be any 1 month gaps in between!

Finding a great development company is one of the most important decisions your company will make. Changing developers mid-way through a development is near impossible and so it is important that you select a company which you are confident has the ability to see it through. The purpose of this 8-step process is to stack the odds in your favour by finding out as much as possible about the development company before you sign the contract.

At several stages I’ve included sample documentation to give you more guidance on what should be included. You can download these examples from the documentation bank on Aroxo.

Before we start, one word of advice. Running a vendor selection process will involve giving a large number of developers bad news (and only one company good news). When I first started doing this I found the process of giving bad news quite unpleasant. It is, but it is still important to do it. Vendors are used to receiving rejections, so they tend to take it more easily than expected and I also find that giving the bad news, along with some personalised feedback is always much appreciated.

Step 1 – Build a long-list

Before we start populating a long-list, it is worth spending a few minutes getting properly organised as running a vendor selection process involves a lot of time, organisation and communication. I find it easiest to run these off a spreadsheet which we’ll develop going forwards. There’s a sample vendor dashboard included in the documentation bank.

Building a long list involves populating this dashboard. The aim is to get 20-30 companies into the dashboard that satisfy your broad requirements for the type of system you want to build. You want to make sure that each company has:

1. Experience in building the type of system you’re looking for (if you think your system is entirely new, it almost certainly isn’t, there will be parallels which you can look for, even if those are purely functional elements)
2. Experience working with start-ups
3. Offices somewhere in the world you are happy doing business
4. Experience in the technology you want your system built in (if you don’t have a preference, then ignore this)

By far and away, the hardest of these objectives to meet is the first. You may need to contact many companies to determine whether they have built a similar application to the one you’re looking for.

In order to find companies, there are a few tricks you can employ:

1. Use your network – ask anyone you know who works in the software industry for 2-3 development company recommendations
2. Use referral companies to provide connections and act as a filter
3. Use associations to help pinpoint development companies
4. Use tools like eLance, Scriptlance and Rentacoder to find developers
5. Use Google to help find companies
6. When you’ve found a company you like, do a reverse search for their homepage on Google to see if they belong to any associations with links to other companies

You may need to look through a large number before you’ve found 20-30 companies which can meet the 4 requirements set out above.

Step 2 – NDA everyone

You’re a start-up (I’ll return to this point later), so an NDA offers no protection. If you’ve got funds to sue a company then, frankly, they would be better spent fixing the mistake with a new developer. However, it is still essential that you NDA all the vendors, even though you are not going to be providing them with any confidential information (other than of your existence, just yet).

First thing you’ll need is an actual NDA. There are plenty you can download for free on the web, so I’ve not provided one. Read it to make sure that you are comfortable with everything included in it. If you’ve selected a lawyer at this stage, ask them to provide an NDA, but don’t pay them to write out a new one.

Email it to all the developers on your long-list and ask them to fax or scan signed copies back, make sure there’s a deadline for return in your email. When you receive one back, open up the Vendor Dashboard and update it so that you don’t forget you’ve received it. Then print it out and file it.

When you hit the deadline, ignore any further submissions, if the development company can’t meet this simple deadline they are not going to meet any further deadlines.

In the post coming next week I’ll detail how to write and issue and RFI and then short-list your developers.