Most product business start with people scratching their own itch. This was the case with Mobiscroll too. We started exploring the Mobile Web space a couple of years ago and went on this exciting journey of writing our first mobile web app. Having a background in web development this was a natural move for us, and with all the great things coming from the W3C it was a great thing to start exploring.

So we have built a pretty cool proof of concept. Our clients were blown away. The app worked in occasionally connected mode and it looked great on those nice handhelds. Everybody was drooling over their screens. There were a couple of issues though. Entering date and time with the keyboard was cumbersome and finicky… so we needed to fix that.

The obvious first question was, how does this work in a native app? We looked and we liked it. This is pretty cool, can we do this in Javascript? Well… let’s try. So we ended a up with a pretty basic scrolling list which looked great and worked reasonably well.

Our clients started using it and they loved it. It was the native-like experience they were looking for. We thought - since we didn't find such controls out there - probably a lot of people are or will be walking in our shoes, and it might help them. So we decided to open source it and with time we built up a fan base. Since then our whole product got bundled, de-bundled and went through a ton of changes. (More about the things we learned on the way in later posts.)

This is where things get complicated!

When you are the beta tester and you use your product all the time, you must have a good feel on how to make it better. Right?

Now the thing is, that driving innovation based on our own experience turns out not to be the best thing. We use our products in a certain way, and we know how they are supposed to be used (because we built it), but will people use it in the same way as we are and are they using it for the same reasons? Are they hiring your product for the reason you think they're doing it? Probably not.

How do we know?

When we have something that people actually like to use and it is helping them, it is time to start the conversations and learn why they hire your product. This should be the driving force of product development instead of your gut feeling. Everything you do should enforce the job your customers are hiring it to do.

As an example: if the job of your product if helping people pass the time when commuting or waiting, you don't want to make the experience faster, you don't want to take pleasure away from them. You might want to make it more fun. But making it faster, because faster means better in your eyes would be harmful.

So what is the job?

People have different stories, but it boils down to the same emotional triggers. If you ask your customers directly why they hire your product, they will tell you something which is mostly wrong. Finding the job is a matter of going deep enough, unpacking their stories and seeing the similarities.

Dogfooding is great, but our own experiences should not be the sole driving force for building products.

What are your thoughts on dogfooding and product development?