Features, features, features…
Since we’re late anyway, we have time to add more features, right? — more than one Marketing person
Every single time I do anything in the world of mobile vending, whether it’s attending a Food Truck event, going to a farmers’ market, attending a First Friday event here in Las Vegas, or event interacting with various people in social media, I come away with another idea. A classic engineering problem with product development, we love to have functionality. A program manager would usually step in somewhere and point to a release schedule and a feature set that has been crafted to align with a release date… as my own program manager, you can probably see the weakness in this arrangement.
Easy vs Difficult
The platform architecture, which I commenced hacking on way back in 2011–2012, was modular and hub-like from the start. The ability to connect people, events, and vendors is the core of the design, which is sensible since that is why this whole project started in the first place. This design allows for a fairly straightforward extensiblity, which was the goal. What this design does not automatically provide, though, is easy feature implementation.
Menu items was an easy feature that got added a long time ago… individual menu items and then grouping of menu items into menu boards, and then varying those boards per event. Made sense, it was easy to attach to the data model, and the user interface is only slightly difficult depending on just how complicated it should become. Luckily in the easiest use cases, it’s not very complicated at all, and who understands their menu items and menu boards better than my customers?
Almost as easy was extending the model to include any mobile vendor. With a flexible data model already in place for mobile food vendors (Food Trucks, Food Carts, Foot Tents, Trailers, Bikes, Boats…), adding variations for non-food vendors (think Boutique Trucks, Merchandise Tents, and other vending schemes one might find at a faire, market, or other similar event) was not difficult at all. As with menu items (which, by the way, become inventory items for merchandise…), the data model lends itself easily, the user interface is the challenge and that is far easier to change with feedback from my customers.
Slightly more difficult is social media integration. Difficult mostly because the landscape of social media and their changing limitations imposed on their API features and usage, make the utility of these other platforms a moving target. Add to this the fact that it’s difficult (not impossible) to judge the value of social media interactions directly, and it becomes a minor challenge to evaluate the ROI for social media integration and automation. It is still a feature, but it’s a feature that will require some re-evaluation in the near and medium terms and with each platform (think Facebook, Twitter, Instagram, and others). The same goes for email, when you think about it… what sorts of engagement make sense for different customers of my customers? Nobody wants to get blasted with private Instagram messages all day, do they? Or maybe they do? Making that determination becomes important, maybe even critical, when trying to take advantage of inbound and conversational marketing opportunities.
More difficult is integration with mapping services. This will require a real demonstration to make sense so instead of going into detail here, we’ll have to wait a bit. But suffice to say that here again, the data model is just great for connecting venues and locations (or lots and stops, or any variation of these terms), but an authoring experience that works for my customers to communicate geographical information is non-trivial. This will take some evolutionary adjustment over time to get it right.
Localization is as well a difficult challenge, but every bit as important as the geographical connections… in fact, they go together in one sense, but physical location is not the single determining factor for localization. As a traveler myself, I know that a vendor I wish to patronize doesn’t always speak a language I am familiar with, the same is true of any mobile vendor and their customers anywhere on the planet. Getting localization (and really the challenge is the translation part of localization) right will be an ongoing effort, of course, because language is a tricky thing.
The two features I’ve added into the mix (which may or may not be ready for the initial release, which is still happening Real Soon Now) are social media network analysis, and a multi-vendor loyalty program capability.
Social network analysis is exactly what it sounds like. Find social media accounts that are linked (following, liking, whatever) and determine over time and data which social media accounts are more interested in mobile vendors and mobile services. For example, if someone were to follow my personal Twitter account (https://twitter.com/DanHugo) one might find that I follow more than a few Food Truck twitter accounts, and perhaps more interesting, that some of them follow me also. I might be an example of an interesting Twitter user in the context of mobile vendor interactions… I might want to learn about mobile food events, local faires and markets, new food trucks coming out, etc etc. I might also be interested in learning more about FoodTruckYP.com, and in fact I might even want to sign up to take advantage of the person-focused features available to me there. This will be important, since Food Trucks and other mobile vendors and events have typically reached out to their fans and customers via social media, but the Call to Action and Conversions are not so easy to measure, and in fact it’s not always a simple matter to determine which among a set of social media contacts actually wants engagement.
And then there’s that Conversion goal. Does having loads of followers on Facebook, lots of Likes on a status update, or tons of re-tweets matter? Somewhat. Do they result in new customers? Increased sales? More bookings? Is there a way to measure that? Loyalty programs are one way, and they already exist. Loyalty programs tailored to mobile vending that include vendors, organizers, and hosts, though… that might be something new. Integrating the feature into the data model is not too difficult, but it’s not so easy either, because now we want flexibility and granular access to metrics, but we do not want to sacrifice user privacy, nor do we want to sacrifice customer privacy (remember, it is always the vendors who are FoodTruckYP customers… our users are your customers and we want to be correct with everybody). Secondary concerns are potential integration with PoS systems like Square, how to best implement the UI for the person side and the vendor side, etc etc etc. This will be an important and infinitely useful feature, it requires a lot of attention and likely iteration, and thus is it a difficult feature.
Whenever I have set a goal for this elusive event, circumstances scuttle the effort. Without getting into great detail, a solo developer isn’t developing when “life happens,” and it often does. However, the launch of Version 1.0 is fast approaching, and with this first alpha release I hope to entice many vendors to sign up and support this effort in exchange for some long-considered ideas to grow business and to offload some of the daily administrative grind. “Just launch it and fix it later” is not the ideal way to do something like this, and so the schedule has slipped more than the most clumsy person might in a banana peeling factory.
While you’re waiting…
Go visit a Food Truck or other Mobile Vendor. If you can’t find one easily, well… these tools will be well worth the wait.