Archives for posts with tag: agile

Kickstart business development for your webapp

January 18, 10 //
3

We’re building a new webservice called Qloudwatch. It’s a webservice to monitor your cloud resource usage. For now it’s dedicated to Amazon Web Services. The objective is to give team members financial insight in their cloud usage.

Our approach to these projects is agile, basically we start building and model the service to the needs we have in our own company. For now that means:

  • Creating projects and easily add Amazon resources via the Amazon Web Services API
  • Add members to projects and track which instance is added by which member
  • Notifications for unknown instances (currently only for instances not added to projects)
  • Get insight in our non-billable and billable costs

We love work in progress. Meaning that we always will keep innovating our webservices. We think this also applies to the business model, in which we didn’t found that much innovation just jet.

In order to build and grow webservices, you need to test their profitability. But how does this work? You just can’t start with some premium versions of accounts and change them every month. So there applies a different strategy here.

A business model needs to be straight forward, prepared for growth and should scale with your webservice. One of the most important things to keep in mind is that your webservice and business model are connected, more than you think. So prototyping webservices is fun, but so is prototyping business models :-)

Here is how we work in order to bootstrap a webservice:

  1. Get your first users for the webservice and actively engage to research for new features and business oppertunities
  2. Introduce your first paying model, this should be the basis that probably never will be revised
  3. Reach break-even based on the monthly cost running the service (don’t calculate your time invested time and resources building the service)
  4. Turn your webservice into profit (this is where you take your past investments and envisioned future innovations into calculation)

We envision the following guidelines when we apply the steps above:

  • Quality of service is important, people are paying so there should always be a tested and stable version available
  • User feedback is guiding. Feedback leading to more paying customers is valued over gadgets, gizmo’s etc
  • Update often and fast, visible progress is valued over small tweaks. Paying customers that join early love to pay for the product, but love to see progress even more

This week I’ll write a post on how we envision the first business model of Qloudwatch.

Embrace change and start developing for point of sale, not plan

January 11, 10 //
3

When developing new businesses or web services most of your time goes into planning. During the planning phase, people collaborate and take decisions based on the information available to them. Combined with their visions they decide what needs to be done and when it needs to be finished. Resulting in overcomplicated long documents and compromises so everybody stays happy developing the plan.

Described above is how I see traditional planning processes. Not particular bad of course, markets like the medical industry have compliance obligations and thus it’s hard to be agile (not impossible). This post is about one of the important aspects of running agile projects: decision making.

I’m taught to plan projects in advance. Describe what we’re going to do, what the goal of the project is and when it needs to be done. After some projects in school, I already learned that it’s just not the way to go. The plan changes all the time and time will never be on your side. The point here is, that when you change plans you need to update all your documents and re-run it through the complete team. Making it a complicated and dull task. Project managers should be working on stimulating collaboration in the team, not (re)writing documents.

The style above is based on developing to ‘point of plan‘. In other words, you work to create what is fully envisioned in the original plan according to schedule.

For every project success is determined by execution and results. You only reach good results with the right execution. Projects are successful when the end result is accepted by the people that have to work with it / use it. That’s why it’s important to stay in touch with the end user. They need to ‘buy’ what you’ve build. If they won’t ‘buy’ it, you’ve been building your beautiful plan but eventually end-up failing your project.

The economy is a turbulent place. So every piece of information available to you in order to create a plan, is probably old by the time you’re four weeks into execution. Methods that embrace change and promote to work independent are needed. Within the project team there needs to be a central understanding of what is build and what the project envisions. Plans should provide the minimum information that people need to make independent decisions.

The goal in these projects is reaching ‘point of sale‘, which means that a project aims to appeal an audience that accepts what is created and starts using, promoting or buying it.

Be agile, not rigid. Get the right people that know what they’re doing and trust them with making their own calls and decisions throughout execution.