Posted by Charles Green on September 14, 2012
In my recently published report (SVM's New Stakeholder: Product Development) I argued that product development will become a crucial new stakeholder for sourcing and vendor management (SVM) professionals in the next few years. And we're already seeing some interesting indications that this is starting to happen. For example, I recently came across this job description: Manager, Product Development & Sourcing.
Look at some of the elements of the job description for this sourcing professional:
- Manages the development process.
- Partners with the design team.
- Improves processes and increases efficiencies by partnering with design, merchant, color, and technical design teams.
These are not typical responsibilities for SVM. But as more product development teams engage with third parties, such skills will be increasingly required. Sourcing is ideally placed to help product development better manage vendor relationships, as well as avoid vendor-related disasters. And as a result, I suspect such job descriptions will become increasingly prevalent.
Crucially, as these two functions start to interact to a greater extent, it’s going to require an understanding of the values of product development. For instance, does SVM know and understand the product development vision? What customer segment is being targeted? How will this change in the future?
Product development looks to suppliers who can provide the most value add. Cost is simply not as central a concern as the skills and capabilities that the provider can bring to bear. This will mean a shift away from the traditional focus on cost to rather which supplier can provide the necessary domain and vertical expertise for specific capabilities. Thus if SVM is seen to be a bureaucratic organization, beating up providers on price, then it’ll be no surprise if it sees itself being passed over. Developing a valued partnership with product development will be a process, and one that will require an understanding of new processes and requirements that are inherently different in product development than in IT.