As part of the Happy Birthday VPS celebrations this week, we decided to give you an insider’s view of our virtual private server platform, including the biggest highlights and challenges in getting it set up.

Like all our projects, our virtual private server platform was developed in-house by a small team of highly talented people, and as well as a closer look at VPS, they were happy to give their best tips on how to price your products and services, manage projects effectively, and much more.

What was your role within the team?

Craig:

Jarrod:

Rik:

Matt:

What were the highlights of working on the project?

Rik:

Jarrod:

Matt:

Craig:

What’s your favourite thing about the VPS platform and why?

Craig:

Rik:

Matt:

Jarrod:

Can you describe some of the changes have taken place since the launch?

Jarrod:

Rik:

Why do you think the team worked so well together?

Matt:

Jarrod:

Craig:

Rik:

Matt, one of the biggest pitfalls of announcing a new product is overhyping it. How did you ensure enough buzz was generated before launch without blowing it out of proportion?

As long as the product fulfils the promise, you’re fine. As soon as you over exaggerate what a product can do, you are in trouble when the customer finds they can’t use it how they had anticipated. Apple are a great example of this. Every new product launch is pitched as revolutionary, which was fine with the initial iPhone and iPad launches, but they keep doing the same with what are essentially minor upgrades and it is creating dissatisfaction amongst their hard core customers.

Jarrod, how much existing dedicated server infrastructure did you use for VPS?

There’s a mixture of new and existing behind the VPS infrastructure. It was an aim to try to take the bits we thought worked well on our dedicated server platform and apply it to VPS. For example, we already had install servers available for machines and know how to network boot and install the CentOS and Windows operating systems, so that was very useful. The standard “out of the box” software we put on a Centos dedicated server is almost identical to that on a VPS.

Rik, you worked with Craig on the user interface. What was involved?

We used a very iterative approach. Craig and I chatted and worked out the broad concept for the control panel, order interface and so on – and then I went and mocked up some basic designs (just by making the initial web pages – I skip Photoshop as I’m no designer and would waste too much time in it!). Craig then used his deep customer knowledge to communicate improvements and changes – and so the cycle went on.

Craig, how did you decide on pricing for VPS, and what tips would you give to a web professional looking to price their own products and services?

We wanted to offer VPS at a price point that would allow our resellers to make a profit on them, whilst at the same time providing us with enough revenue to continue to develop the platform. We looked to our main competitors – and decided we had to do one of two things: be cheaper, or offer more for your money. The risk of going ‘too cheap’ is that you have to over-contest your hosts – and whilst this may work for certain virtualisation technologies, KVM is not one of them. With that in mind, we designed our base level product to offer a very high resource allocation for the money.

As for pricing your own products, decide ahead of time how you want to compete – will it be on pricing, or service? Are you entering a contested market, who are your direct competitors? How price sensitive do you think your customers are? If you’re providing a commodity (cheap) service, your customers are going to be extremely price sensitive, make sure you spend some serious time calculating your costs. Bigger companies are going to have lower fixed and marginal costs, and they will beat you in a race to the bottom. As a smaller venture, you will typically offer a specialised service, ensure that you do not undervalue your time. Don’t promise a 24/7 managed service for pennies. If you do, then your service, your sanity or most likely both, are going to suffer.

What advice would you give to someone about to start managing a big project?

Involve your technical staff from the get-go, and don’t think you know best just because you’re in charge. Don’t gloss over the difficult bits in the planning stages – the more you hand-wave at an early stage, the more you’ll be in trouble when it comes to implementation. If you’re versed within any particular branch of project management (e.g. Prince2, Sprint, Agile) – make sure that everyone in your team understands all the terminology, and the methods that you’ll be using to manage their timeand the way in which the team will be working. Make sure your approach isn‘t over or under-engineered. You probably don’t need massive risk analysis and big control documents if you have a team of 3-4 and there is norisk to customer safety.

The better you know your team and their strengths and weaknesses, the easier you’ll be able to manage a project. Some staff are able to self-manage with ease, and only require gentle direction, whilst some may need a defined plan of work. Using the wrong method with the wrong person is going to lead to dissatisfaction and conflict. No one likes to be micromanaged, but some people need more direction than others.