Recently we’ve received a fair number of inquiries from both retailers and technology vendors on the value of co-development. In plain English, co-development is a retailer and tech vendor working together to create a new version of a product, or even an entirely new product. Both have the understanding and expectation that the technology will ultimately be available to all retailers, while the co-developer retail partner will get first crack at specifications, roll-out and early value in exchange for reduced costs.

Co-development may not always make sense, but there are times when it works to both parties’ advantage. In this article, I’ll focus on the retailer side. In a future piece, I’ll turn to the vendor side in more detail. Let’s take a look at risks and opportunities.

More than one retailer has gained advantage from participating in co-development. Back when I was a CIO, there were times we’d agree to participate, and times we’d pass. Here are some questions to ask:

• Are you lagging in the market and recognize part of the reason is a big gap in your technology portfolio? Do you realize that while filling that gap may help you leapfrog your competition, it won’t be the magic bullet that solves your problems? If the answer to both these questions is yes, you can start the journey.
• Are you short of capital but long on big ideas? If the answer is yes, then you’ve got a lot to bring to the party and the opportunity for cost reduction in exchange for your participation will have a lot of value.
• Have you been approached by a vendor with a similar vision and resources to back them up along the way? Do you trust the people involved? The answer to both questions needs to be yes before you can proceed. There are many people and companies with spectacular vision who fail miserably at execution. If they’re new to this particular market, you might not know if they have the ability to follow through. You can reduce risk if you’ve had previous experience in some other capacity with the people involved.

The vendor’s financial resources are also worth investigating. If the company has few customers, but most of its development staff will be involved in your project, you’re probably safe, as long as you have a contract clause to keep the programming code in the event the vendor doesn’t make it. If the vendor feels spread too thin, you might want to pass. The worst of all worlds is to get half-way done and have the vendor go out of business. You might find yourself hiring the developers yourself in that case, and that’s potentially a big distraction.

• What’s the opportunity cost of not going ahead with the project? Back when I was CIO of a home furnishing chain, we had some requirements for receipt of drop shipped merchandise that a lot of other furniture retailers didn’t have at the time. We were spending a lot of extra time and money contorting the system into meeting our needs and throwing extra store employees at the problem. We co-developed with our ERP provider to include drop ship receiving processes in their application. It became a core part of their product when we were done. I’m sure by now other furniture retailers have discovered a similar need, but we got the solution when we needed it and saved a boatload of money.
• Are you contemplating an entirely new technology solution that will give you a competitive advantage? On the one hand, over the long term, by definition, no standard commercial package will give you a sustainable advantage. After all, by definition, it can be bought by competitors. But on the other hand, even an eighteen month head start is nothing to sneeze at. Eighteen months hence, you might be looking at the next big thing, while your competitors are absorbing your last big thing.
• Are you “married ” to a suite provider who is missing certain functionality, but willing to implement it with your help? This is the ideal scenario, really. You have experience with the vendor and know they have market staying power. You don’t want to incur integration costs associated with bringing in someone else’s platform, but you seriously need a tool they don’t have. That’s the time to not just think about it, but to actually approach the vendor and ask what his plans are. Don’t just talk to your account exec – work your way up the management food chain to decision-makers. You’ll all look like heroes when the job is done.

What’s interesting here is that the same retailer may come up with different answers in different situations. In my own career I said yes to some projects and no to others while working for the same retailer. My rule of thumb was for non-essential, non-differentiating processes, I’d let someone else blaze the trail. But if the ROI was obvious (as was the case for the drop ship PO’s) or the opportunity huge (early price optimization adopters reaped rapid rewards from their efforts), you’ve got to go for it.

In general, we’ll find many of the same questions apply to vendors as well. Right up front, I’ll say it’s really important to manage your development partner’s expectations. Our research has repeatedly shown that under-performers look for a magic bullet. Sometimes, lightning strikes, but without clear metrics for success enmity can be the end result for both sides.

I hope this has helped you create some simple rules of thumb.