Learn how procurement can build a supplier partnership to co-develop a key product feature, manage IP and risk, and move successfully from concept to launch.
LHTS procurement framework
Primary procurement role: Tactical
Supporting role: Procurement Management
Procurement process connection: Need definition, supplier assessment, sourcing strategy, contracting, implementation, supplier management and supplier development
Learning level: Advanced
Related online course: Supplier Management from Learn How to Source. The course explains how to differentiate supplier relationships and improve supplier contribution, providing the foundation for the more advanced co-development model described in this article.
Quick answer
A supplier partnership in product development is a structured relationship in which a buying company and a supplier combine knowledge, resources, and capabilities to develop part of a product or service.
When a supplier provides a feature that will be important to the customer proposition, the relationship must be managed as more than a normal purchase. Procurement should help establish the commercial model, decision rights, intellectual-property rules, development milestones, risk controls, supply arrangements, and lifecycle obligations.
The objective is not simply to maintain a friendly supplier relationship. It is to create customer value while protecting both organisations from unclear responsibilities, uncontrolled dependency, and commercial disputes.
When a supplier becomes part of the product offering
Companies increasingly depend on suppliers for more than materials, components, and production capacity. A supplier may contribute specialist software, electronics, materials science, industrial design, data analytics, manufacturing technology, or other knowledge that the buying company does not possess internally.
In some cases, the supplier’s contribution becomes a key feature of the finished product. Examples include:
- A sensor supplier enabling predictive maintenance in industrial equipment.
- A software provider adding automated optimisation to a physical product.
- A battery supplier extending the operating time of a mobile device.
- A materials supplier creating a lighter or more sustainable product.
- A specialist manufacturer designing a module that improves the customer experience.
At this point, the supplier is no longer only delivering against an existing specification. The supplier is helping shape what the company will offer its customers.
This can create important benefits. Research into supplier involvement in new product development has associated early and extensive involvement with opportunities to reduce cost and development time and improve quality. However, the results depend on supplier selection, the nature of the technology, the development model, and how the relationship is managed. Early involvement is therefore not automatically successful involvement. Not every important supplier should become a partner
A collaborative partnership requires management attention, technical resources, information sharing, and mutual commitment. It should not be applied to the entire supply base.
The appropriate relationship depends on the commercial value, supply risk, technical complexity, uniqueness, and strategic importance of what is being purchased. The CIPS relationship spectrum places collaborative partnerships toward the high-commitment end of supplier relationships, where trust, transparency, information sharing, and mutual dependency are significantly greater than in transactional relationships. Partnership may be justified when several of the following conditions apply:
- The supplier owns knowledge or technology that is difficult to replace.
- The contribution has a direct effect on customer value or product differentiation.
- Joint engineering work is required.
- Development costs or risks must be shared.
- Switching suppliers after launch would be expensive or slow.
- The supplier must make dedicated investments.
- The product roadmap depends on continued supplier innovation.
- Product performance depends on close coordination between the two companies.
Calling every supplier a partner weakens supplier segmentation. A partnership should be a deliberate sourcing decision, not a polite description of a normal commercial relationship.
Three ways to involve a supplier in product development
The company must decide how much design responsibility the supplier will receive.
Supplier consultation
The buying company retains design responsibility and asks the supplier for advice about materials, tolerances, manufacturability, cost, available technology, or alternative solutions.
This is appropriate when the company owns the core design and needs specialist input without transferring responsibility for the feature.
Joint or grey-box development
The supplier’s specialists work with the customer’s engineering, product, quality, operations, and procurement teams. Requirements, interfaces, risks, and design choices are developed jointly.
This model is often appropriate when the feature is new, strategically important, or technically interdependent with the rest of the product.
Research comparing supplier-integration models found positive innovation effects from grey-box integration, where suppliers worked alongside customer engineers. The same study did not find an equivalent innovation effect from fully delegated black-box development. Supplier selection based on product-development capability was important for both models. ractical inference is that joint development should be the starting point when a supplier technology will become a key element of the customer proposition.
Delegated or black-box development
The customer defines performance requirements and interfaces, while the supplier develops the component, module, software, or service with substantial independence.
This can work when:
- Interfaces can be specified clearly.
- The supplier has proven development capability.
- The supplier’s solution can be validated objectively.
- The buying company has enough internal competence to challenge requirements and assess results.
- Intellectual-property and continuity risks are controlled.
Black-box development can reduce the customer’s engineering workload, but it can also create knowledge dependency. The buyer must not confuse transferring design work with transferring accountability for the finished product.
Where procurement adds value
Procurement should not normally act as the sole product owner or technical authority. The function’s role is to create the commercial and relational conditions in which successful development can occur.
Product management should own the customer problem and value proposition. Engineering should own system architecture, technical integrity, and validation. Quality should own appropriate assurance methods. Operations should confirm manufacturability and supply readiness.
Procurement should lead or coordinate:
- Supplier-market analysis.
- Supplier capability assessment.
- Relationship segmentation.
- Commercial strategy.
- Cost and investment models.
- Negotiation.
- Contract architecture.
- Intellectual-property discussions with legal specialists.
- Capacity and continuity commitments.
- Supplier governance.
- Performance management.
- Supplier development.
- Escalation and exit planning.
The strongest arrangement is therefore cross-functional. Procurement provides commercial leadership without attempting to replace product, engineering, legal, quality, or operations expertise.
A best-practice process for supplier co-development
1. Define the customer outcome before discussing a solution
The process should begin with the customer need, not with a supplier presentation.
The development brief should explain:
- The customer problem to be solved.
- The expected benefit.
- Target users and use cases.
- Required performance.
- Product and system interfaces.
- Safety, regulatory, sustainability, and cybersecurity requirements.
- Target cost and business-case assumptions.
- Expected launch date.
- Forecast volumes.
- Conditions that would cause the project to be stopped.
Use performance requirements where possible. Over-specifying the technical solution can prevent the supplier from contributing its knowledge. Under-specifying the outcome can produce an impressive technology that does not solve a commercially relevant problem.
2. Decide whether the feature is core, enabling, or non-core
There is an important distinction between core and non-core capabilities. However, the decision requires more nuance than simply outsourcing non-core work.
A feature may be outside the company’s current technical competence while still being strategically important to the future product offering.
The team should ask:
- Will customers choose the product because of this feature?
- Could the feature become a platform for future products?
- Does it create important customer or operational data?
- Would supplier failure damage the company’s brand?
- Would changing supplier require a product redesign?
- Could the supplier offer the same differentiating feature to competitors?
- What knowledge must remain inside the buying company?
The answer determines how much technical control, IP access, internal competence, and continuity protection will be required.
3. Select the supplier for development capability—not only current performance
A supplier that performs well in serial production is not automatically the best innovation partner.
The assessment should cover:
Strategic fit
Does the supplier’s technology roadmap support the buyer’s product roadmap? Is the customer important enough to receive technical attention, capacity, and senior-management support?
Development capability
Review engineering resources, development methods, systems competence, prototyping capability, test facilities, previous launches, technical documentation, and programme management.
Commercial strength
Assess financial health, ownership, investment capacity, pricing approach, cost transparency, and willingness to share development risk.
Intellectual-property position
Confirm which technology the supplier owns or licenses, whether third-party rights are involved, and whether the supplier has freedom to commercialise the proposed solution.
Industrialisation capability
Determine whether the supplier can move from prototype to stable production at the expected volume, quality, lead time, and geographic scale.
Collaborative behaviour
Evaluate openness, response times, problem-solving behaviour, willingness to share risks, cultural fit, and the ability to work in cross-company teams.
Risk and continuity
Assess single points of failure, sub-suppliers, key-person dependency, cybersecurity, business continuity, product obsolescence, and alternative production options.
Supplier development is resource-intensive and should be concentrated where value and improvement opportunities justify the effort. CIPS recommends considering value, opportunity, complexity, supplier cooperation, and risk when choosing suppliers for development. It also recommends raising development expectations during tendering and incorporating them into the contract.
4. Agree a collaboration charter before detailed development begins
The parties should create a short project charter before major resources are committed.
The charter should define:
- The customer outcome.
- Scope and exclusions.
- Development model.
- Named project leaders.
- Team members and required capacity.
- Responsibilities and decision rights.
- Initial milestones.
- Budget assumptions.
- Information-sharing rules.
- Escalation routes.
- Conditions for continuing, pausing, or terminating the project.
This is not a substitute for a contract. It creates alignment while the detailed commercial and legal structure is completed.
ISO 44001 provides a recognised framework for identifying, developing, and managing collaborative business relationships. Its relevance is that partnership should be treated as a managed business system rather than as an informal dependency between individual employees.
5. Build a joint business case
Both parties must understand how value will be created and how each company will benefit.
The business case should cover:
- Customer willingness to pay.
- Expected sales or retention effect.
- Target product margin.
- Development expenditure.
- Tooling and capital investment.
- Unit cost at different volumes.
- Certification and validation costs.
- Ramp-up assumptions.
- Warranty exposure.
- Ongoing software, service, maintenance, or support costs.
- Cost of delay.
- Cost and consequences of project failure.
The financial model may use one or more of the following:
- Customer-funded development.
- Supplier-funded development recovered through unit prices.
- Shared development cost.
- Milestone payments.
- Tooling amortisation.
- Minimum volume commitment.
- Royalty or licence fee.
- Gain-sharing based on measured value.
- Conditional exclusivity in return for volume or investment.
The commercial model should create balanced incentives. A supplier should not be expected to finance an uncertain development programme without a credible opportunity to recover its investment. At the same time, the buyer should not accept permanent exclusivity or uncontrolled unit prices simply because the supplier contributed to development.
6. Use the right contract architecture
A normal purchase agreement is rarely sufficient for a joint innovation project.
A robust arrangement may require:
- A confidentiality agreement during initial discussions.
- A joint development or collaboration agreement covering development.
- A supply, licence, or service agreement covering commercial use after launch.
Depending on the feature, these may be separate agreements or coordinated sections of one contract.
WIPO describes collaboration agreements as arrangements in which parties combine human, physical, financial, and intellectual-property resources. The legal framework should address objectives, ownership, access rights, benefit and risk sharing, and commercialisation rights. development agreement should address the following topics with support from qualified legal counsel.
Background intellectual property
Background IP is the technology, software, designs, methods, data, know-how, and trade secrets that each party owned or controlled before the project.
The agreement should identify:
- What each party is bringing into the project.
- Who owns it.
- How the other party may use it.
- Whether use is limited to development or includes production, service, and future products.
- What happens to access rights after termination.
Foreground intellectual property
Foreground IP is created during the collaboration.
Do not rely on assumptions about who will own it. Decide:
- Whether ownership follows inventorship or authorship.
- Whether one party will own all resulting IP.
- Whether ownership will be allocated by technical field.
- Whether the parties will jointly own specific results.
- Which licences the non-owner receives.
- Who may use the results in other products, industries, territories, or customer segments.
- Who pays for filing, maintaining, and defending registered rights.
WIPO emphasises that trade secrets can exist as both background and foreground IP. Collaboration therefore requires deliberate rules for access, confidentiality, modification, protection, and use. Commercialisation and field-of-use rights
Ownership alone does not answer every commercial question.
The agreement should define:
- Who may sell the feature.
- In which markets.
- For which applications.
- Under which brands.
- Whether either party may license it to third parties.
- Whether the supplier may offer the same or a similar solution to competitors.
- Whether exclusivity is global, regional, industry-specific, or time-limited.
Conditional exclusivity is often preferable to permanent exclusivity. It may depend on launch timing, minimum volumes, market investment, or continued purchases.
Development deliverables and acceptance
Each phase should have defined outputs and acceptance criteria, such as:
- Requirements specification.
- Architecture and interface documentation.
- Prototype.
- Test results.
- Regulatory evidence.
- Design files.
- Software documentation.
- Production process.
- Control plan.
- Training material.
- Service documentation.
- Approved production sample.
Payment should be connected to meaningful and verifiable progress rather than elapsed time alone.
Change control
The parties need a formal method for proposing, analysing, approving, pricing, and documenting changes.
A change request should explain:
- Technical reason.
- Customer or compliance effect.
- Cost impact.
- Timing impact.
- Quality and supply risk.
- IP consequences.
- Required validation.
- Responsible decision maker.
Supply and lifecycle commitments
A successful prototype has limited value if the supplier cannot support the commercial lifecycle.
The agreement should cover:
- Capacity and ramp-up.
- Lead times.
- Forecasting rules.
- Pricing and cost-review mechanisms.
- Quality requirements.
- Service levels.
- Warranty responsibilities.
- Corrective action.
- Product changes.
- Obsolescence notice.
- Spare parts.
- Software updates and cybersecurity support where relevant.
- Business continuity.
- Transition assistance at the end of the relationship.
7. Establish joint governance and stage gates
Trust is important, but trust should not replace governance.
A practical governance structure can include:
Executive steering group
Meets monthly or quarterly and handles investment, strategic alignment, unresolved risks, major scope changes, and commercial escalation.
Joint project team
Meets weekly or at an appropriate project cadence. It manages technical activities, dependencies, actions, risks, cost, and timing.
Defined workstream owners
Engineering, quality, operations, procurement, product management, legal, cybersecurity, regulatory, and service responsibilities should have named owners.
The development should move through agreed gates, for example:
- Opportunity approval.
- Concept selection.
- Technical and commercial feasibility.
- Business-case approval.
- Design freeze.
- Prototype validation.
- Production readiness.
- Launch approval.
- Post-launch review.
APQP is one example of a structured concept-to-launch approach. AIAG describes it as a method for moving development projects toward launch while reducing lead time and start-up problems. Its current guidance also incorporates sourcing, change management, risk mitigation, programme metrics, and gated management. Although developed in the automotive environment, these principles can be adapted to other industries. ate should be a real decision point. The choices are to proceed, proceed with conditions, revise, pause, or stop.
8. Validate the complete product—not only the supplier’s component
A supplier may successfully meet its own specification while the overall customer product still fails.
Validation should therefore cover:
- Feature performance.
- System integration.
- Reliability.
- Safety.
- Regulatory compliance.
- Cybersecurity.
- User experience.
- Manufacturability.
- Serviceability.
- Scalability.
- Supply-chain readiness.
- Total cost.
- Failure and recovery behaviour.
The buying company remains accountable to its customers. Supplier approval is an input to product approval, not a substitute for it.
9. Manage the relationship after launch
The relationship changes when development becomes serial supply or ongoing service.
The post-launch scorecard should extend beyond price and on-time delivery. It may include:
Customer and product results
- Feature adoption.
- Customer satisfaction.
- Product reliability.
- Warranty rate.
- Customer-reported incidents.
Development performance
- Milestone achievement.
- Speed of engineering-change response.
- Validation success.
- Number and quality of new ideas.
- Roadmap alignment.
Supply performance
- Delivery.
- Quality.
- Capacity.
- Lead time.
- Continuity risk.
- Corrective-action closure.
Commercial performance
- Target-cost achievement.
- Product margin.
- Cost reductions.
- Investment recovery.
- Forecast accuracy.
Relationship health
- Decision speed.
- Action closure.
- Transparency.
- Executive engagement.
- Cross-functional collaboration.
- Dispute frequency and resolution.
The partnership should be reviewed periodically against the original business case. A relationship may need to become closer, remain stable, return to a conventional supply relationship, or be concluded.
Practical example: a supplier-enabled product feature
Consider a manufacturer of industrial pumps that wants to offer predictive maintenance.
A specialist sensor and analytics supplier proposes a feature that monitors vibration and temperature and warns customers before a likely failure. The feature could create a significant advantage for the pump manufacturer, but the company does not possess the required sensor or analytics capability internally.
Step 1: Define the outcome
The product team defines the customer outcome as fewer unplanned shutdowns. Engineering defines the system interfaces, operating environment, accuracy, safety, and cybersecurity requirements.
Step 2: Select the development model
The companies choose grey-box development. The supplier owns its sensor platform and analytics engine, while the manufacturer owns the pump-system architecture and customer application.
Step 3: Build the business case
The companies estimate development cost, expected product volumes, customer value, support cost, unit price, and the potential for a paid monitoring service.
Step 4: Agree IP and commercial rights
The supplier retains ownership of its existing sensor and analytics technology. The manufacturer retains its pump data, product architecture, brand, and customer relationships.
New interface designs are owned by the manufacturer. Improvements to the supplier’s generic analytics platform are owned by the supplier, but the manufacturer receives defined use rights. Pump-specific models developed from the manufacturer’s data are allocated contractually.
Exclusivity is limited to a defined industrial-pump application and depends on the manufacturer meeting launch and volume commitments.
Step 5: Develop through gates
The project moves through feasibility, prototype, field trial, design freeze, production readiness, and launch approval.
Each gate assesses technical performance, customer value, cost, regulatory compliance, cybersecurity, production capacity, and unresolved risk.
Step 6: Protect continuity
The supply agreement contains product-change notice, support obligations, data portability, transition assistance, and defined access to essential technical information if the supplier stops supporting the feature.
In this example, procurement does not design the sensor or decide what customers need. Procurement creates the supplier assessment, commercial structure, IP process, governance model, supply commitments, and continuity protection that allow the technical teams to succeed.
Common mistakes in supplier innovation partnerships
Treating trust as a substitute for a contract
A good relationship makes collaboration easier, but it does not resolve future disagreements about ownership, exclusivity, cost, liability, or commercialisation.
Selecting the incumbent without comparing capabilities
Familiarity can be useful, but the existing supplier may lack the development maturity, technology, resources, or strategic interest required for the project.
Involving procurement after the design has been fixed
Late involvement reduces the ability to influence the commercial model, supplier dependency, cost, IP position, and alternative sourcing options.
Granting exclusivity without receiving measurable value
Exclusivity should normally be limited by field, territory, time, performance, or volume. The buyer should understand what it receives in return.
Leaving foreground IP undefined
Waiting until the invention exists makes negotiation more difficult. Ownership principles and use rights should be agreed before major development begins.
Focusing on prototype success but ignoring scale
The supplier must demonstrate production capacity, quality controls, sub-supplier management, service support, and lifecycle capability.
Allowing one individual to own the entire relationship
A personal relationship between two engineers or executives is fragile. Governance, documentation, and multiple organisational connections reduce key-person risk.
Measuring only supplier delivery performance
A strategic innovation supplier should also be assessed on roadmap contribution, engineering performance, responsiveness, customer outcomes, and risk reduction.
Creating uncontrolled supplier dependency
Dependency is not always avoidable. It must, however, be understood, priced, approved, and managed through access rights, continuity arrangements, modular design, alternative capacity, or transition provisions.
Frequently asked questions
What is a supplier partnership in product development?
It is a structured relationship in which a customer and supplier combine capabilities to develop a product, component, technology, software solution, or service feature.
When should a supplier be involved in product development?
A supplier should be involved when its knowledge can materially influence cost, quality, manufacturability, risk, sustainability, time to market, or customer value. The timing and level of involvement should depend on technical complexity and the supplier’s responsibility.
What is early supplier involvement?
Early supplier involvement means engaging a supplier before important technical and commercial decisions have been fixed. It allows supplier knowledge to influence requirements, architecture, materials, manufacturing processes, cost, and risk.
What is grey-box supplier development?
Grey-box development means that supplier and customer specialists work together on the design. Responsibilities are shared and the supplier contributes directly to technical decisions.
What is black-box supplier development?
Black-box development means that the supplier receives performance and interface requirements and assumes substantial responsibility for developing the solution.
Who should own intellectual property created with a supplier?
There is no single answer. Ownership and use rights should reflect existing IP, technical contributions, investment, commercial strategy, and the need to use or develop the results in the future. The arrangement should be defined contractually with qualified legal support.
Should a supplier receive exclusivity for developing a feature?
Only when exclusivity is commercially justified and carefully limited. It can be connected to a specific application, market, territory, period, investment, launch date, or minimum volume.
Is supplier co-development a procurement or engineering responsibility?
It is cross-functional. Product management and engineering normally own the customer requirement and technical solution. Procurement owns or coordinates supplier selection, commercial strategy, contract structure, relationship governance, and supply risk.
How should a supplier innovation partnership be measured?
Measure customer results, development performance, quality, delivery, cost, risk, roadmap contribution, responsiveness, and relationship effectiveness. The measures should be connected to the original business case.
Conclusion
A supplier that contributes a key product feature can become an important source of innovation and competitive advantage. It can also become a source of technical, commercial, and supply dependency.
The solution is neither to keep the supplier at arm’s length nor to rely on informal trust. The relationship should be designed deliberately.
Procurement should help the organisation:
- Select the supplier for development capability and strategic fit.
- Choose the appropriate development model.
- Create a shared business case.
- Establish decision rights and stage gates.
- Define intellectual-property and commercialisation rules.
- Protect quality, capacity, continuity, and lifecycle support.
- Measure whether the partnership creates customer and business value.
The practical next step is to review one current strategic supplier and ask: is this supplier simply delivering a specification, or is it helping determine what our customers will be able to buy from us in the future?
For a structured introduction to supplier segmentation and the selection of an appropriate supplier relationship, continue with the Learn How to Source Supplier Management course.