Through a special arrangement, what follows is a summary of an article from Retail Paradox, RSR Research's weekly analysis on emerging issues facing retailers, presented here for discussion.
Back in February, I wrote a piece outlining why co-development can make sense for a retailer. I discussed its value for the retailer, and quickly glossed over why it might make sense for a vendor.
The fact is, co-development can also make sense for a vendor in many cases.
I started out thinking that the reasons would differ depending on whether the vendor was just starting out or was an already established player in the space, but I realized the differences are all in the priorities involved.
Establishing credibility: We always advise our start-up vendor clients that it's really important to have a "poster child" — that's an early adopter willing to exchange reduced costs for mentions. It's unrealistic to expect vendors to work for free, but certainly it's realistic to expect them to work for cost, or something less than cost, in exchange for a strong endorsement from a well-known successful retailer. For their part, retailers are generally not keen on being pioneers.
Established vendors also need the credibility associated with the first install. When SAP rolled out its new Merchandise Planning system, it helped to know that Nike had been involved in the process. Similarly, Manhattan Associates and Oracle Retail have also praised their co-development partners as they roll out significant new releases.
Getting it right the first time: Nothing is worse than developing in a vacuum. I was recently contacted by a member of the press asking about a mobile application failure at a very large retailer who shall remain nameless. Apparently, the application was virtually unusable by consumers. My first observation was that, "Clearly the retailer did not try the application out on its own store personnel. They would have told the developer immediately that it wasn't usable by an average person." I was correct, but that's cold comfort for the retailer and vendor alike. The new application could have been brought to market more quickly and for a lot less cost had a co-development process been followed. And that brings me to my last point.
Insure that people involved in co-development are the right people: What's intuitive to an IT person or executive may be completely counter-intuitive to an end-user. Beyond applications to be used by store personnel, it can happen in other departments as well. This is particularly important now, as a generational shift is occurring in the workforce. Boomers are moving out of the workforce, and being replaced by Generation X, Y and Millennials. In the age of tablet computing and the smartphone, preferences have likely changed. So while executives might still be comfortable with the spreadsheet paradigm, the rank and file is likely more interested in graphics.