The cost of assumptions

I am in the final stages of launching OnCall, a tool for managing who of your staff is on-call.

Screenshot of scheduling

For the first iteration of the product I have focused on team management, scheduling and involving your team through notifications and easily available schedule overviews.

What I assumed

The problem I am trying to solve with OnCall is one that I have experienced most places I have worked as a developer. You have critical systems, and if something goes wrong, someone needs to take care of it. But too often the routines for handling problems that arise outside of 9 - 17 are lacking.

If a schedule is in place, it is likely to be in the form of an abandoned dusty spreadsheet residing in some dark corner of a shared drive. Knowing who is responsible is often unclear, both to the person responsible, service providers and customers.

In my experience this is a problem for small and large companies alike.

While the first iteration of OnCall is certainly useful and relevant for IT teams, I am looking forward to start implementing cool stuff like incident routing and telephone hotline routing.

My assumption was that the product will be insufficient for a lot of people when launching with the basic feature set described above, and that by launching early I would miss out on potential customers.

What I discovered

I haven't been doing as many pre-launch activities as I ought to have. While I have been discussing the product with friends in the business and gotten valuable feedback, I haven't done much to validate the product outside of the IT industry.

A few weeks ago I started to build a mailinglist of potential customers. I've put up a landing page, started spreading the word and buying some traffic through Google Adwords.

To my surprise the interest I've been getting hasn't been from IT people only. Many seem to be from other industries, like the manager of a hotel signing up using his work e-mail address.

Lessons learned

By making the assumption that I am creating a product solely targeted at people in the IT industry, I ran the risk of postponing launch in order to cram in more features so the product would appeal to a wider audience within that industry.

The result could have been missing out on customers from other industries by specializing too early.

By getting the product out sooner I allow myself to keep an open mind and gauge interest before I make any decisions to specialize the product towards a specific industry.

The obvious take away here is that I need to improve my pre-launch activities, getting feedback earlier and from a wider audience.

As a product-oriented guy I need to be reminded of this from time to time.

View Comments