Back in February, I wrote a piece outlining why co-development can make sense for a retailer (When Co-Development Makes Sense). I discussed its value for the retailer, and quickly glossed over why it also makes sense for a vendor.

Last week, I was reminded by Alexander Pelow, Solutions Director, Stores and Commerce for Oracle that I had planned to write a follow-up piece specifically focused on the vendor. Thanks for the reminder, Alex, and here is the promised piece.

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 as I thought through this piece, I realized there are fewer differences than I thought. The difference is all in the priorities each will place on each reason.

• Establishing credibility: At RSR, we always advise our start-up vendor clients that it’s really important to have a “poster child. ” That’s an early adopter who is willing to exchange reduced costs for mentions. We usually say “Expect to give the first one away. ” Now, 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. Retailers are generally not keen on being pioneers. They want to know that someone has walked the road before them. And it is very helpful if that someone is what RSR calls a “Retail Winner ” – a retailer who is demonstrating year-over-year comparable sales increases.

It turns out that 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’ early Distributed Order Management adopters helped the company quantify incremental sales numbers that would have otherwise lacked credibility. Oracle Retail too has always talked of its own co-development partners as it rolls 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 “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.

I haven’t followed the re-implementation of that application, but I’m sure a lot more time and money has been spent doing what should have been done the first time. What’s the bottom line? 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. We’ve found this consistently with applications to be used by store personnel, but it can happen in other departments as well.

This is particularly important now, as a generational shift is occurring in the workforce. Back when I implemented a planning system for the first time, I was really intrigued by the graphical representation of the planning numbers. I loved that you could drag the lines on the graph up or down and the numbers would actually change. I thought this would be a winner for sure. It turned out that the planners and buyers were far less enamored with a graphical representation. They liked the familiar rows and columns of the spreadsheet view.

I can’t say the same would be true today. Boomers are moving out of the workforce, and being replaced by Generation X, Y and Millennials. In the age of tablet computing and the smart phone, 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. So while executives may hold the power of the pen, it’s the end-user that will dictate success or failure.

I hope you’ll find this bit of common sense useful. May all your co-development efforts be successful ones.