What needs to go into the next great field data app?

Chris Low, Product Manager, a la mode , inc.

Maybe I shouldn't do this, but I'm about to reveal a "secret" of how I do my job. Many years ago I attended a seminar for software product managers from all over the country. At the beginning of the meeting, an "expert" in the field stood in front of the group and began the class by telling us what he called the Number One Rule For Product Managers. And this was the rule: "Your opinion, although interesting, is irrelevant."

Once I looked past my own ego and supposed expertise, I realized he's right. I can design and build and roll out software, but I'm not the person who will use it every day to survive in the workplace. My opinions of how the software should work or what it should do may be interesting and had better be well thought out, but that means nothing unless it meets the end–user's needs.

That's the main reason I work here at a la mode . Every solution we do here is customer–centric. And it's one reason why we've started this labs initiative. It gives us a better format to try out ideas on real people and get real opinions (not just fake ones like mine).

Last month I wrote about how gathering data in the field is more "engineering" than "formfilling" and how we're looking into ways to make the field data gathering chores more efficient. By taking advantage of improved mobile technologies in the industry, there are a lot of potential solutions to tap into. I asked for your ideas, feedback and suggestions. Many of you did write back with some great ideas.

I've compiled your feedback into a basic list of product items. Here's a summary of what you sent. Let's consider this the ideal list of how a field data gathering application should work:

• A field application should contain screens that are designed solely for the input of data items you gather away from your desk. The screens should follow a basic workflow of how you work in the field, starting with data on the neighborhood and site, and working towards the inside of the property.
• The application should allow data to be collected in a "room by room" type of workflow — and that's vastly different than the way data is input on a form.
• The application should support some level of customization. No two of you described the same kind of data items that are collected in the field. Each of you look for and and record different data items. Some of you even asked for the ability to design or modify a simple field data gathering form.
• A field data gathering application should have a simple interface for gathering info on each comp you observe, and allow for data collection on as many comps as needed. It should prompt for items like conditions observed from the street, landscaping, visible defects, and even allow for the attachment of a photo.
• There should be support for photo attachment to the data file. Subject property and comp photos should be easily imported. It could even support Bluetooth cameras and automatically download the photos if there were a Bluetooth connection.
• You should be able to "pre–load" the application with relevant data items before heading into the field to do an inspection. For example, there should be the ability to send it the property address, client contact info, and a list of potential comps with their addresses and directions.
• A field data gathering application should have a way to record the lat/long from a GPS and then geocode that data to a property address, whether it be for a subject property or a comp.
• You should be able to output all the data in a standardized format, so that it can be imported easily to your formfilling software. Notes gathered in the field could be added as an addenda item or as part of the workfile, if desired.

That's just a basic overview of the feedback you've sent us. It makes for a fairly comprehensive list of how the product should function. We anticipated a lot of these ideas and combined with your feedback, we've started to work on a prototype. If all goes well, we should be able to demonstrate the prototype to you soon and elicit even more refined feedback. So please stay tuned. As always, your comments are most welcome.

* * *

While many of you already have mobile devices such as Ultra Mobile PCs, Tablet PCs, and Windows Mobile Devices, quite a few of you that I spoke to do not. Most of you who don't have them are concerned with the cost of a mobile device and whether an application justifies the purchase price of the hardware. This is a valid concern. The last thing you want to do is spend hundreds on hardware that, when implemented into how you work, doesn't save time or make things any easier.

And this goes back to the beginning of this article. Gadgets are cool and fun, but irrelevant unless effective in saving time. Most of us can't afford new tools just because we're "tech heads." That's the critical rule we'll keep in mind as we design a field data gathering app in the labs.

Later on, I'll post articles on this site that show examples of field applications running on mobile devices like TabletPCs, UMPCs and PocketPCs. Here's some information on the basics of each platform:

Tablet PC: http://www.microsoft.com/windowsxp/tabletpc/evaluation/about.mspx

Ultra Mobile PC: http://www.microsoft.com/windows/products/winfamily/umpc/default.mspx

Windows Mobile Devices: http://www.microsoft.com/windowsmobile/default.mspx