GE spent over $7 billion building its Predix industrial platform — and watched it collapse because no one bounded the requirements. What started as an Industrial IoT analytics tool expanded to compete with cloud providers, then sprawled until the company itself split into three. Meanwhile, Procter & Gamble used tightly defined "technology need briefs" to grow external innovation from 15% to over 50% of all new products, forging more than 2,000 partnerships through its Connect+Develop program. The difference was not talent, budget, or market access. It was requirements discipline.
Technology scouting fails when requirements are unclear. Scouts search broadly, evaluate dozens of options, but struggle to connect findings to actual R&D needs. The result: wasted effort, misaligned recommendations, and decisions that stall. Research shows that projects with clearly documented requirements are 97% more likely to succeed, while roughly half of all project rework traces back to requirements issues.
This worksheet helps document technology requirements before scouting begins. Use it to align stakeholders, focus search efforts, and ensure scouting results connect to real decisions.
The history of technology scouting is littered with expensive lessons. In each case, the root cause was the same: requirements that were absent, unbounded, or anchored to the wrong strategic frame.
GE Predix ($7B+ lost): General Electric launched Predix as an analytics platform for industrial equipment. Without bounded requirements, the project tried to be everything for everyone — expanding from IoT analytics into a full cloud computing competitor. The scope spiraled until the company split into three separate entities. Had GE documented clear scope boundaries from the start, the platform could have remained a focused, defensible product.
Kodak (bankruptcy after 130 years): Kodak held 7,000 patents and actually invented the first digital camera in 1975. But their scouting and R&D requirements were anchored to the film business. Every technology was evaluated through a lens of "how does this support film sales?" — which meant digital photography was systematically deprioritized until it was too late. Kodak filed for bankruptcy in 2012.
Xerox PARC (billions in unrealized value): Xerox's research lab developed the graphical user interface, the mouse, Ethernet, and laser printing. But there were no commercialization requirements connecting these inventions to market strategy. Steve Jobs visited PARC, saw the GUI, and built the Macintosh. Xerox's technology scouting worked brilliantly — it was the requirements gap that turned their inventions into someone else's products.
These are not edge cases. Industry data shows that 39% of project failures cite poor requirements gathering as a primary cause, and roughly 40% of corporate technology programs exceed their budgets due to scope creep that better requirements documentation would have prevented.
Scope creep: Scouting expands beyond original intent, diluting focus. Research shows that scouting projects without documented scope expand their technology domain by an average of 3x during execution — what starts as "find a better adhesive" becomes "evaluate all bonding technologies including laser welding and mechanical fastening." According to PMI, approximately 40% of corporate technology programs exceed budgets for exactly this reason.
Misaligned priorities: Scout evaluates on criteria different from stakeholder needs. Without documented requirements, scouts default to evaluating what they find most technically interesting, which may not align with the TRL maturity or business fit that stakeholders actually need.
Decision paralysis: Many options presented, no clear way to compare. When everything looks potentially relevant because there are no documented filters, stakeholders face an overwhelming evaluation task instead of a structured comparison.
Stakeholder surprise: Results don't match expectations because expectations weren't documented.
Organizations that get requirements right see dramatically different outcomes. BMW's Startup Garage documents specific requirements from individual business units before scouting, then scouts over 1,000 startups per year from 50+ countries. The result: more than half of their startup alumni secured paid follow-up projects. Unilever's Foundry uses a structured pitch-pilot-partner process, and of the 3,000+ startups engaged, roughly 50% of pilots have scaled. Companies with dedicated venture client units that use structured requirements achieve 10+ pilots at a rate of 64%, compared to just 20% for those without — and their first purchase orders arrive in under 12 weeks versus 26+ weeks.
Focused search: Clear criteria direct effort to relevant technologies instead of casting a net so wide you can't process what you catch.
Efficient evaluation: Can quickly filter non-fits against documented must-haves, reducing evaluation time by 50% or more versus unstructured review. Half of all project rework comes from requirements issues — getting them right the first time eliminates the largest source of wasted effort. Use TRL criteria and weighted scoring to add rigor.
Aligned recommendations: Results map to documented needs, so stakeholders can see exactly how each option addresses what they asked for.
Faster decisions: With clear criteria established upfront, stakeholders see how options compare on their own terms — not on whatever criteria the scout found most interesting.
This section establishes the strategic foundation for the entire scouting effort. P&G's Connect+Develop program credits its success to requiring teams to write concise "technology need briefs" before any external search begins — a discipline that helped them build over 2,000 partnerships and drive more than 50% of innovations from external sources. Without clear context, scouts default to their own assumptions about what matters. A brief that states "we need a faster curing adhesive for automotive trim assembly to meet a 2027 production line redesign" gives scouts something to work with. A brief that says "explore adhesive innovations" does not.
Technology need description: What capability or solution are you looking for?
[Free text description - 2-3 sentences]
Business context: Why is this technology needed? What problem does it solve?
[Free text description]
Related projects or initiatives: What internal efforts connect to this scouting?
[List relevant projects]
Key stakeholders: Who will use the results? Who approves technology selection?
| Role | Name | Interest/Concern |
|---|---|---|
| Sponsor | ||
| Technical lead | ||
| End user | ||
| Other |
Timeline and urgency: When are results needed? What's driving the timeline?
Results needed by: [Date]
Decision needed by: [Date]
Driver: [Why this timeline?]
Technical requirements are where scouting efforts are won or lost. A NASA study on technology scouting practices found that most internal scouting was conducted on an ad hoc basis with no structured information sharing — teams would scout independently and never document what they found or what they were looking for. The result was duplicated effort and missed opportunities. The antidote is specificity: write requirements that a third party could read and understand without a phone call. For example, "corrosion resistance in salt spray environment per ASTM B117 for 1,000+ hours" is testable. "Must be durable" is not.
The must-have vs. nice-to-have distinction is critical. If everything is mandatory, nothing helps you filter. BMW's Startup Garage works because business units define non-negotiable technical criteria upfront — scouts know exactly what to screen for, and startups know exactly what they need to demonstrate.
Functional requirements - Must Have: What must the technology do? (List specific, testable requirements)
| ID | Requirement | Verification Method |
|---|---|---|
| M1 | ||
| M2 | ||
| M3 | ||
| M4 | ||
| M5 |
Functional requirements - Nice to Have: What additional capabilities would be valuable but aren't essential?
| ID | Requirement | Value if Met |
|---|---|---|
| N1 | ||
| N2 | ||
| N3 |
Performance requirements: What quantitative performance is needed?
| Parameter | Minimum | Target | Units | How Measured |
|---|---|---|---|---|
Constraints: What limitations must the technology work within?
| Constraint Type | Description |
|---|---|
| Physical (size, weight) | |
| Environmental (temp, humidity) | |
| Interface/integration | |
| Regulatory/compliance | |
| Other |
Technical fit means nothing if the commercial terms don't work. This section prevents the common scenario where months of scouting produce a technically perfect solution that the organization cannot afford, cannot license on acceptable terms, or cannot source from a supplier that meets procurement requirements. Kodak's failure was not technical — they had the digital camera patents. It was commercial: their requirements never addressed how to monetize technologies that would cannibalize their core film business. Be honest about budget constraints, preferred engagement models, and supplier requirements upfront, so scouts don't waste cycles on solutions that will fail at the commercial gate.
Budget guidance: What financial parameters apply?
Development cost range: [$ to $]
Unit cost target: [$]
Total investment ceiling: [$]
Licensing acceptable: [Yes/No]
Business model preferences: How do you prefer to access this technology?
Timeline requirements: What development/implementation timeline is acceptable?
Prototype needed by: [Date]
Production ready by: [Date]
Maximum acceptable development time: [Duration]
Supplier requirements: What attributes must a technology provider have?
| Requirement | Mandatory? | Notes |
|---|---|---|
| Geographic location | ||
| Company size/stability | ||
| Certifications | ||
| Existing relationship | ||
| IP ownership model |
Without pre-defined evaluation criteria, technology selection becomes a debate about personal preferences rather than a structured comparison. Unilever's Foundry has scaled roughly 50% of its startup pilots in part because its pitch-pilot-partner process defines evaluation criteria before the first pitch — not after the team has already formed opinions. The State of Venture Client 2024 report found that companies with structured evaluation processes issue their first purchase order in under 12 weeks, compared to 26+ weeks for those that figure out criteria after the fact. Define your weights and scoring definitions now, and use them consistently. The weighted scoring template provides a detailed framework for this step.
Weighted evaluation criteria: How will you compare options? (Weights should sum to 100%)
| Criterion | Weight | Definition | Scoring Method |
|---|---|---|---|
| Technical fit | __% | 1-5 scale | |
| Maturity/readiness | __% | TRL or custom | |
| Cost/value | __% | 1-5 scale | |
| Supplier capability | __% | 1-5 scale | |
| Risk | __% | 1-5 scale | |
| [Custom] | __% | ||
| Total | 100% |
Scoring definitions: Define what each score means for consistency
| Score | Technical Fit | Maturity | Cost/Value | Supplier | Risk |
|---|---|---|---|---|---|
| 5 | |||||
| 4 | |||||
| 3 | |||||
| 2 | |||||
| 1 |
Search parameters turn your requirements into an actionable scouting plan. This section prevents two common problems: searching too broadly (drowning in results) and searching too narrowly (missing viable options in adjacent fields). BMW's Startup Garage scouts over 1,000 startups per year from more than 50 countries — but they can handle that volume because each search has clearly defined parameters from the business unit that requested it. Without defined search parameters, scouts tend to search the sources they already know, in the geographies they're comfortable with, using the terminology they're familiar with. Document your parameters to push beyond those defaults.
Known technologies or companies to evaluate: Starting points for scouting
| Technology/Company | Source | Priority |
|---|---|---|
Search keywords and terms: Technical terms to use in searches
Primary terms: [List main keywords]
Secondary terms: [Related/broader terms]
Exclusion terms: [What to filter out]
Geographic scope: Where to search?
Technology maturity range: What maturity levels are acceptable?
Source priorities: Where should scouting focus?
| Source Type | Priority | Notes |
|---|---|---|
| Patents | ||
| Academic research | ||
| Startups | ||
| Established companies | ||
| Research institutions | ||
| Industry consortia |
The final section is about accountability. Define what scouting will produce, when stakeholders will review progress, and who makes the final decision. Without this, scouting efforts often run indefinitely or produce deliverables that don't match what stakeholders expected. Structured review checkpoints also serve as scope-control mechanisms — they are the moments when the team formally checks whether the original requirements still apply or need adjustment based on what scouting has revealed. Skip this section and you risk the most common project failure pattern: ongoing effort with no clear path to a decision.
Expected deliverables: What should scouting produce?
Review checkpoints: When will stakeholders review progress?
| Checkpoint | Date | Participants | Deliverable |
|---|---|---|---|
| Kickoff alignment | Requirements sign-off | ||
| Search strategy review | Search approach | ||
| Long list review | Preliminary candidates | ||
| Short list presentation | Evaluated candidates | ||
| Final recommendation | Selection recommendation |
Approval process: How will final decision be made?
Decision maker: [Name/role]
Decision criteria: [What determines selection?]
Approval required from: [List]
Complete an initial draft based on available information. Don't worry about perfection — it's a starting point. The goal is to get something on paper that can be discussed, challenged, and refined. P&G's technology need briefs typically start as rough two-paragraph descriptions from the business unit, then get sharpened through review.
Share with key stakeholders for input:
This step catches misalignments early. It is common for the technical lead to prioritize performance while the business sponsor cares most about time-to-market. Better to surface that tension in a requirements review than in a final presentation.
Update based on feedback. Get explicit agreement that requirements are correct and complete. This sign-off matters — it creates a shared reference point that prevents scope creep and protects the scouting team from shifting goalposts.
Use the documented requirements to:
When presenting options, show how each maps to documented requirements. This keeps evaluation objective and aligned. BMW's Startup Garage and Unilever's Foundry both use this approach — every candidate is assessed against the original brief, not against each other in a vacuum.
Vague: "High performance" Specific: "Throughput > 1000 units/hour at < 2% defect rate"
Specificity is what makes requirements actionable. Compare "we need a lightweight material" with "we need a material under 2.5 g/cm3 density that maintains tensile strength above 300 MPa at 150C." The first gives a scout nothing to filter with. The second lets them eliminate 80% of candidates in the first pass.
Everything can't be mandatory. Force prioritization — it enables practical tradeoffs later. A useful test: if a solution meets every other requirement perfectly but fails this one, would you reject it? If the answer is no, it is a nice-to-have.
If you can't measure a requirement, you can't verify it. Include how each requirement will be assessed. For example, "compatibility with existing ERP system" becomes testable when you specify "must support SAP S/4HANA integration via standard API with response times under 200ms."
Understanding why helps scouting teams make judgment calls when exact matches don't exist. A scout who knows "we need this adhesive because our current one fails at high humidity in Southeast Asian factories" can spot creative alternatives that a scout who only knows "must bond at 90% RH" might miss.
Requirements may evolve as scouting reveals what's possible. Build in review points to adjust. The best requirements documents include explicit "hold" designations for criteria the team expects may change once the market landscape is clearer.
Problem: Requirements so detailed they exclude viable options. Better: Focus on outcomes, not implementation details. Example: An automotive OEM once specified "must use laser sintering with titanium alloy powder, 40-micron layer thickness." What they actually needed was "structural component under 1.2 kg with fatigue life exceeding 10 million cycles." The outcome-based requirement opened the door to three additional manufacturing approaches they hadn't considered.
Problem: Requirements so vague anything qualifies. Better: Include enough specificity to filter effectively. Example: "We need an AI solution for our supply chain" is not a requirement — it is a topic. "We need demand forecasting for 5,000+ SKUs with 48-hour prediction windows and MAPE under 15%" is a requirement that scouts can actually work with.
Problem: Requirements from one perspective miss other needs. Better: Include all relevant viewpoints before finalizing. Example: An R&D team scouted a promising material that met every technical specification, but procurement had not been consulted. The sole supplier was in a restricted trade zone. Three months of scouting effort was wasted because a five-minute conversation didn't happen upfront.
Problem: Everything is "required" so nothing helps filter. Better: Force stack ranking or weighting. When a team insists everything is mandatory, ask them: "If two solutions exist, one meets criteria A, B, and C but not D, and the other meets D but not A — which do you want to see?" That question surfaces real priorities.
Platforms like Wicely help execute technology scouting by:
Start with clear requirements, then leverage tools to find and evaluate options efficiently.
Detailed enough to filter options but not so detailed you miss good alternatives. A useful benchmark: could a scout who has never spoken to your team read the requirements and begin a productive search? If the answer is no, add more context. If requirements take more than 2-3 pages, you may be over-specifying. P&G's technology need briefs are typically one page — enough to direct the search, not so much that they constrain it.
Document the disagreements explicitly and escalate to whoever can resolve them. Don't proceed with conflicting requirements — it leads to unsatisfying results for everyone. One effective technique: have each stakeholder independently rank requirements by importance, then compare the rankings. Disagreements become immediately visible and often easier to resolve when quantified.
Generally yes, at the appropriate stage. Consider formalizing requirements into an RFP when engaging vendors. Shared requirements enable vendors to self-assess fit and prepare relevant information. BMW's Startup Garage shares specific challenges with startups, which is a key reason they attract high-quality applicants — startups can see exactly what problem they'd need to solve.
Review at planned checkpoints. Major changes should be explicitly agreed — avoid scope creep through informal adjustments. If scouting reveals that a key requirement is unrealistic (for example, no technology at TRL 7+ meets your cost target), that is valuable information. Document it, bring it back to stakeholders, and decide together whether to adjust the requirement or accept a longer development timeline.
Re-examine which requirements are truly mandatory. Consider if requirements were realistic given the current state of the market. Recommend the best available option with gaps clearly noted and a plan for closing those gaps. Often, a solution that meets 90% of must-haves with a clear roadmap for the remaining 10% is the right choice.
Effective technology scouting starts with documented requirements. The organizations that do this well — P&G, BMW, Unilever — share a common discipline: they define what they need before they start looking. The worksheet above encodes that discipline into a repeatable process.
Take time upfront to clarify what you need, align stakeholders, and define evaluation criteria. The effort pays for itself in focused scouting, faster decisions, and outcomes that actually match what the business asked for.
Download or adapt this worksheet for your organization. Customize sections for your context but keep the core discipline of documenting before scouting.
Wicely's Solution Scouting platform helps you translate documented requirements into structured searches, finding technology solutions that match your specific needs.
Learn the fundamentals of technology scouting for manufacturing R&D. Discover how to systematically identify, evaluate, and acquire external technologies that accelerate your innovation goals.
Learn how to build a systematic supplier evaluation framework with weighted scoring criteria. Includes templates, scoring rubrics, and practical guidance for technology vendor assessment.
A practical checklist for assessing Technology Readiness Levels (TRL) in R&D and technology scouting. Includes detailed criteria for each TRL level, assessment questions, and common pitfalls to avoid.
See how Wicely helps R&D teams discover technology opportunities and make smarter investment decisions.
Book a DemoWicely monitors patents, research papers, and industry news across your product lines - and delivers tailored conclusions specific to your business. Not data lists. Conclusions.
© 2026 Wicely. All rights reserved.