Product-centered versus project-centered business models
A long time ago, when WireSpring first got started, we focused primarily on the interactive kiosk space. A lot of our early product development work went into making our system easy for others to develop on. In theory, the software we were selling would just be a platform, and the apps would be written by customers or integrators intent on fielding a finished solution. Our thought was that by focusing on the platform, we could keep our development team small and deadlines tight, while punting the hard and time-consuming work of project definition, management and development to the client or their consultants. Kiosks were a regular topic on this blog in those early days (e.g. the importance of a call to action for kiosks and digital signs), and we hoped that our tips would help customers plan and execute their projects.
Of course, it didn't work out like that, and almost everyone who bought our platform eventually came back to us for project work as well. We consequently built everything from interactive, digital movie posters to electronic news stands, and did project plans for many more. Our goal of keeping a small team exclusively devoted to our own product development was also shot, and we spent as much effort on our clients' projects as we did on our own (if not more).
Now, having a consulting business is not necessarily a bad thing. But my partners and I never planned for this scenario (though looking back, we clearly should have). We were geared up to build a product-centric company, and none of us were looking forward to constantly prospecting for new projects with which to feed our marching army of developers.
When the digital signage market began to develop, we were excited by the prospect of once again being able to sell a turnkey solution that didn't require constant customization and project work to win every sale. In essence, "digital signage" just became one of our standard applications, built on top of the same platform that we've always used. Of course, we continued to evolve the product over the years, but now the bulk of our resources goes toward improving our product for all of our customers. Writing custom code is now the exception rather than the rule.
The difference between a digital sign and an interactive digital sign
In the middle of the last decade, as more of our revenues shifted away from what we'd call "kiosks" and toward what we'd call "digital signs," interactivity never really disappeared. There was always some interactive project being worked on. But we've noticed that as things like gesture recognition, large-format touch displays and other new means of interactivity have flourished, so too have the RFP's and customer inquiries about writing shiny new apps that can use them. Frequently, these inquiries come from people who are well enough acquainted with "regular" digital signage, and thus know that they need to feed their networks with fresh content and the like to stay relevant. But perhaps because of this familiarity, they don't quite realize that someone has to program the system in order to get it to do precisely what they want from a user interface perspective. Whether that's us (the vendor), them (the customer) or some third-party integrator is largely a matter of preference. But the bottom line is that -- as we learned from our kiosk experience -- digital signage software vendors can't possibly build out prefab interactive apps as quickly as new customer requirements come in.
Where are the opportunities right now?
So, you want to get into the interactive signage game, eh? Well, your best shot is in one of these niches:
- Ready-made interactive apps: Much as an ecosystem of content providers has emerged in the past few years, we'll need a new group of companies to provide extensible off-the-shelf interactive apps, expressly designed for running on digital signs in public environments. HTML5 and Flash seem to be the obvious choices for platform development, but I'm guessing that we'll see a bunch of other things emerge, too.
- Application development/integration Once an ecosystem of ready-made apps becomes commercially available, most end users still won't have the time or expertise to actually make them work. Expect current VARs to add some new skills to their repetoires. Either that, or expect a whole new crop of VARs to sweep in and handle these requirements.
- Web app development: There are already quite a few digital signage platforms that will let you drop a web page or web app into a playlist and have it appear on-screen. Consequently, it wouldn't be too much of a stretch to imagine that current web application companies might want to enable specific features or tools in their products to make them better suited for these kinds of projects. With so many companies and products out there already, if even a small handful of them gave some attention to our space, we'd quickly have a large portfolio of available apps to work with.
- User experience design: Just because you can get an interactive app to show up on a big touch screen doesn't necessarily mean that you should. It will take a new team of user experience designers to try out apps, suggest venue- or vertical-specific customizations, run split tests, and figure out what really "works" when it comes to putting interactive apps on a big screen in a public space. Eventually, it'd be great to see somebody establish a set of guidelines for gesture-based apps, NFC-based apps, and touch-based apps much as we've done for non-interactive digital signage. (And indeed, some of this work has been done before in the kiosk space, but there are so many new ways of interacting with a device that a lot of that information is now incomplete or even obsolete).
How do you find the low-hanging fruit when it comes to interactive digital signage projects? Leave a comment and let us know!
Comments
RSS feed for comments to this post