Agenda
PART 4 OF 7 · RUNNING THE PROCESS
Agenda
PART 4 OF 7 · RUNNING THE PROCESS
This part is the operational core of Venture Clienting: lead generation, sourcing, selection, PoC execution, and implementation, in the order they actually happen.
A PoC lead is a real problem inside the company that a startup solution might solve, not a startup someone likes the look of. Leads come from three starting points: a stakeholder bringing a problem directly, discovering an interesting startup and working backward to find who might have that problem, or outside-in analysis of common industry challenges.
Seven methods to surface leads:
Quality over volume
Three high-quality leads with clear ownership, real urgency, and allocated budget teach more than twenty vague pain points, and each pursued lead consumes real time from the team and attention from stakeholders. Consequently, a lead should be killed if it fails any of five tests:
Leads don't stay qualified. Stakeholders move, budgets disappear, urgency evaporates, so re-qualify every six weeks or after two weeks of inactivity, and document why a lead was killed.
A simple kill log shows discipline and reveals patterns: if leads are consistently dying for lack of authority, for example, that points to sourcing from department heads rather than individual contributors going forward.
A needs assessment is a structured conversation with the stakeholder who owns a problem, aimed at understanding four things before committing sourcing resources: what the problem really is, what kind of solution might work, whether it's worth pursuing, and what constraints exist. It acts as a filter — some leads that look promising in a brief conversation fall apart under harder questions, and others become crystal clear.
A hard "no" on any of these gives clear guidance: park leads without urgency, involve the real decision-maker when authority is missing, clarify who could fund it when budget is absent, and ask directly what changes if the problem is solved when impact is unclear.
The actual conversation unfolds in five steps. First, introduce the purpose and set the tone. Then, understand the problem through open questions, resisting the pull toward whatever solution the stakeholder has already imagined. From there, understand what a dream solution would look like, separating must-haves from nice-to-haves. Next, check compliance and technical non-negotiables, such as data residency, integration requirements, and security certifications. Finally, request supporting materials (process diagrams, current tool lists) anything that helps a sourcing partner move faster.
A few habits sharpen the output: summarizing back what was heard in your own words often surfaces a more precise version of the real problem; thinking in the stakeholder's language rather than innovation jargon builds trust; and keeping the requirement list to five to seven items avoids both an under-defined problem (two or three requirements) and an over-constrained one (fifteen or twenty).
Once a lead is qualified, the job shifts to finding startup solutions. With roughly 1.3 million new startups founded globally each year and hundreds of thousands of documented corporate-startup partnerships already on record, full market coverage is impossible — the goal isn't finding every possible startup, it's finding the right ones with confidence.
A startup doesn't need to be large to be a good PoC candidate. It needs to have demonstrated maturity to deliver (completed PoCs with other corporate customers, an understanding of corporate decision-making pace), credibility with clients (real references you can call), and the resources to show up (a dedicated team, not one juggling twenty other pilots). A four-person startup with three successful corporate PoCs is a better bet than a thirty-person startup with none.
DIY sourcing (researching the market via Google, Reddit, LinkedIn, Product Hunt, and similar public sources —) takes one to two weeks, builds real market knowledge, and works well for specific problems or as a pre-filter before a professional handoff.
Its limits are real, though: startups that aren't visible on public platforms are invisible to DIY search, and it's time-consuming at scale (sourcing three PoCs a quarter this way adds up to six to nine weeks of research a year).
Professional sourcing works differently: hand a needs assessment to a dedicated sourcing team and get back a curated shortlist in five to ten business days. It meaningfully improves the odds a PoC becomes an implementation. PoCs sourced professionally see a 50–60% implementation rate against roughly 40% for other approaches, because sourcing partners access proprietary databases aggregating thousands of sources, call startups directly to verify references, and benchmark against specific criteria. GlassDollar's own sourcing team, for reference, runs to around 40 dedicated professionals doing exactly this.
Most mature programs use both: DIY to stay close to the market, professional sourcing for PoCs where the cost of getting it wrong is high.
Running DIY sourcing well follows four steps:
Briefing a sourcing partner well means handing over the full needs assessment and supporting materials, being explicit about must-haves versus nice-to-haves, stating compliance and technical requirements upfront, sharing budget and timeline, and being clear on decision criteria. A strong result comes back as five to eight recommended startups (not fifty), each mapped explicitly against the stated requirements, with at least one reference or case study, a recommended lead candidate with reasoning, and honestly flagged limitations. Dedicated software platforms like GlassDollar can streamline this process significantly: rather than manually building tracking tables and searching across a dozen scattered sources, these platforms centralize startup discovery, filtering, and matching into a single workflow.
A benchmark is a ranked comparison of startups against clear, defined criteria, used once requirements are well understood and a decision is imminent — "I need logistics software that integrates with SAP, tracks shipments in real time, and works at our supply chain's complexity" is a benchmark question. You're comparing a defined category against defined criteria, not looking at everything in the space.
A landscape is a broader, unranked map of the different ways a problem type can be solved, used when the problem is still loosely defined or multiple solution categories could apply — "our supply chain is inefficient, but we're not sure if we need software, a service, better visibility tools, or process change" is a landscape question. The output might show categories like demand planning software, optimization platforms, logistics automation, visibility tools, and consulting services side by side, with nothing ranked.
Many sourcing journeys move from landscape (explore broadly) to benchmark (narrow down once requirements emerge) to direct assessment (select, demo, test). See the full definitions in the glossary.
Selection moves the program from a researched shortlist to a chosen startup, defined scope, and a team ready to test it, not yet to a launch. It happens in a deliberate sequence: a sourcing presentation narrows the field, a startup briefing prepares each finalist to run a relevant demo, the demos themselves generate real evidence, and a decision meeting forces a choice.
The sourcing presentation narrows research into a shortlist of about three startups worth demoing; it's a dialogue, not a pitch for approval. A workable five-step structure:
The startup briefing closes the gap between a generic sales pitch and a demo that's actually useful, usually in just one 30–45 minute conversation. A four-step structure fixes the common failure mode of skipping this step:
Running the demo
The innovation manager's job in the room is to manage it, not to be the audience: watching whether the solution addresses the problem, whether the stakeholder is engaged, and whether the conversation stays on track, and stepping in if it drifts. Run all demos back-to-back in a single window if possible; comparison degrades quickly once demos are spread across days or weeks and momentum fades.
The strongest demos share a problem statement in the company's own language, a clear before-and-after, realistic (not generic) example data, one or two relevant references, and a focused ten-to-fifteen-minute walkthrough rather than a full product tour.
The decision meeting
Turns accumulated impressions into a locked-in choice. Without one, projects drift: stakeholders defer, weeks pass, and the preferred startup loses interest and moves on to other prospects. Schedule it before demos happen, and invite a minimal group, the pain point owner, their budget-holding manager, the innovation manager, and IT or procurement only if directly relevant.
A tight structure: summarize each startup in one paragraph without pricing yet; invite impressions starting with the pain point owner, then the budget holder, then the manager's own view, grounding any disagreement in specific evidence from the demos rather than abstract preference; confirm the choice out loud and in writing if consensus emerges (if it doesn't, identify precisely what missing information would resolve it and set a hard date to get it); and close by walking through concrete next steps: scope document, procurement handoff, kickoff, check-in cadence, and the eventual go/no-go point.
A delayed decision is almost always worse than an imperfect one.
PoC execution moves a chosen startup and defined scope through to a tested solution and an implementation decision, in three parts: scoping, procurement and kickoff, and monitoring through to the end-of-PoC decision.
Once a startup is chosen, the next job is defining exactly what will be tested, how, and by whom. This document protects both sides, prevents scope creep, and becomes the basis for the procurement request and success criteria. Proper scoping takes one to two weeks and is worth every hour: skipping it typically means discovering, three weeks in, that the startup interpreted the problem differently than expected.
The golden rule of scoping
Keep it as lean as possible while still validating the core functionality. A typical PoC runs four to eight weeks; a lean scope keeps it at the short end, while a bloated one pushes past twelve weeks and often collapses before finishing.
Avoid, unless essential
IT integration work (even simple integrations take weeks and compete with IT's other priorities), personal or sensitive data (which triggers legal, works council, and privacy review that can add a month or more — use anonymized or sample data instead), and high-dependency setups requiring three or more teams to act in sequence.
What's fine to keep in scope: simple SSO logins already supported by IT, sample or anonymized data, work the startup can do without depending on internal teams, and testing limited to a pilot group rather than the whole organization.
A complete scope document covers four things
- Clear responsibilities for each party (startup, business unit, and VCU), each with specific commitments and dates;
- success metrics with a defined what, how it's measured, target threshold, and timing (for example, "sales team reduces deal logging time from 40% of the week to 10%, measured by a time audit at the start and end of the PoC," or "forecasting accuracy improves from 60% to 80%, measured against actuals");
- a timeline of four to eight weeks with weekly milestones; and budget — the PoC fee (typically €5k–€30k), internal resource cost,
- and the indicative annual subscription cost if implementation follows.
Many corporates negotiate that the PoC fee is deducted from the first year's subscription if the PoC succeeds, which aligns incentives on both sides.
Once scope is set, a short Request for Proposal goes to the startup: problem statement, proposed scope, success metrics, timeline, and a request for both pricing figures and a resource plan, with about a week to respond. Once success metrics and indicative costs are in hand, build a simple business case: annual benefit if the PoC succeeds and gets implemented, weighed against the cost of full implementation. A worked example: if a sales team reduces manual entry time by 50%, that frees four hours a week per person; across thirty salespeople valued at €50 an hour, the annual benefit works out to 4 hours × 30 people × €50 × 50 weeks, or roughly €300k a year. Set against implementation cost (PoC fee, subscription, IT integration, ongoing support), that gives a net first-year benefit and a payback period.
This business case isn't meant to be perfect, it's meant to be credible, and worth updating as the PoC generates real data.
The message to procurement is that selection is already done. Their job is to process the chosen startup's offer into a contract, negotiate specific terms if needed, and get it signed, not to re-run competitive evaluation.
A smooth path includes:
- presenting a complete package (the startup's proposal, the scope document, the business case, and a short note on how Venture Clienting differs from standard procurement);
- asking for both PoC and indicative subscription pricing upfront, since without the second number the ROI picture is incomplete;
- offering non-monetary value in exchange for a lower PoC price (a case study, a reference call, structured product feedback, often worth a 10–20% discount, since startups tend to prefer this to a straight discount because it helps their business);
- negotiating strategically on cost deductibility, payment schedule, support SLAs, and data/IP terms, with a clear internal walk-away point; and moving fast once terms are agreed
Aim for 48 hours from agreement to signed purchase order, escalating politely but persistently if it stalls. The exact level of involvement depends on the company, as different procurement teams have different requirements for how they want to participate and what information they need.
The kickoff meeting is where the startup formally takes over execution. It should be startup-led: they're delivering the solution and have the biggest incentive to get it right, with the innovation manager supporting rather than presenting. A short pre-kickoff call with the startup two to three days ahead helps align on their plan, share context on internal culture and stakeholder concerns, and confirm shared understanding of success criteria.
The kickoff itself covers a short framing from the innovation manager on what the PoC is and isn't, followed by a startup-led walkthrough of scope, success metrics, timeline, roles, risks, and check-in cadence, opening up for questions and alignment, surfacing any scope disagreement immediately, and closing by confirming commitments and the first check-in date.
During execution, the VCU's role is to monitor progress, keep the startup and the business unit talking to each other, protect scope from creep, and keep the business case current, not to run the PoC day to day.
Regular thirty-minute check-ins every two weeks are non-negotiable, covering progress against milestones, corporate-team engagement, early success-metric data (collected from week three onward, not saved for the end), risks, and any scope drift. Issues should be handled the moment they surface: understand the real problem, brainstorm options with the startup, decide and confirm quickly, and move on without revisiting.
Before the formal decision meeting, three checks are worth running as verifications rather than discussions:
A small miss (75% vs. 80% adoption) often just reflects real-world complexity and may still support implementation; a large miss (40% vs. 50% time reduction) is a more serious signal that the solution isn't performing as hoped. If the updated business case still holds up, implementation is more clearly justified; if it's turned negative or marginal, the decision gets harder and deserves an honest look rather than momentum carrying it forward.
The decision meeting itself (pain point owner, budget holder, innovation manager, and IT or procurement if relevant) walks through scope completion, success metrics, the updated business case, and stakeholder impressions, and ends in one of three outcomes:
- implement (scope complete, metrics met, business case positive);
- implement with adjustments (metrics mostly met, but a phased or modified approach makes sense);
- or park the lead (metrics missed significantly, or the business case doesn't hold up).
A partial success isn't automatically a pass, it's a genuine decision point, and it deserves an honest answer rather than a default yes.
If a lead is parked, do it well: thank the startup, share specific feedback, acknowledge real strengths, and leave the door open if circumstances change. Document the outcome both for implementation planning and for program learning; this record becomes the VCU's own knowledge base over time.
A successful PoC proves a solution works in the test environment. Implementation is where it becomes part of daily operations and where the bulk of the program's business impact is actually realized, and it is reliably more complex than the PoC phase, typically taking six to twelve months rather than six to twelve weeks.
Three things change between PoC and implementation
IT shifts from a passive stakeholder to a primary one, since the solution now has to interface with real enterprise systems and handle real (not test) data, which triggers security review, compliance checks, and ongoing support requirements.
Process change moves from a small motivated pilot group to dozens or hundreds of users across departments, requiring training, workflow redesign, and active change management rather than a memo.
And contracting shifts from a time-limited PoC agreement to a full subscription or enterprise contract, pulling in procurement, legal, and finance in a way the PoC never did.
Four reasons implementation gets delayed, and how to accelerate it
A six-item implementation checklist
IT integration in more detail
IT's concerns are consistent and, once understood, predictable to prepare for: security (data storage, encryption, access controls, breach response; prepare with SOC 2/ISO 27001 documentation and a clear security policy), integration complexity (API stability, documentation, authentication approach), support and maintenance (defined SLAs and an incident process), scalability (load testing and transparency about limits), and vendor reliability (funding history, references, roadmap, team experience).
Startups that prepare for this scrutiny move through implementation two to three times faster than those that don't.
Three practical ways to get ahead of it:
- brief IT during PoC planning rather than after signing;
- assign a single IT contact point who attends the kickoff and closeout and stays engaged throughout;
- and if IT wasn't involved earlier, run a structured IT readiness workshop where the startup presents its security posture and integration plan directly.
Change management in more detail
A deployed solution nobody uses generates zero return, and implementation failures are more often organizational than technical, adoption plateauing at 30–40% instead of the 80%+ needed for real impact.
Five elements consistently separate implementations that stick from those that don't:
- hands-on training scheduled close to go-live, in small groups, with sessions recorded for later reference;
- clear process documentation showing old-versus-new workflows side by side, placed where users will actually find it;
- a steady drumbeat of communication from the decision through ninety days post-launch, increasing rather than fading at go-live;
- two to four internal champions per team, drawn from people already involved in the PoC, given visibility and a role in shaping the rollout;
- and visible executive sponsorship.
Adoption runs 20–30% higher when a senior leader visibly uses the tool themselves. Roll out in phases: a small, motivated group first (twenty to fifty people), then adjacent teams once the first phase is stable, then the wider organization once there's a proven playbook.
The clearest early warning signal is the ninety-day adoption metric: 70%+ of target users logged in at least once, 50%+ using it weekly, 30%+ using it multiple times a week.
Programs hitting these numbers by day ninety typically continue climbing toward 75–85% adoption; programs below 50% on any of them have stalled and need active intervention.
A landscape explores broadly when a problem is loosely defined; a benchmark compares a short list against defined criteria once requirements are clear.
No real or urgent problem, no meaningful business impact, no decision-making authority, overly rigid requirements, or no willingness to invest budget or time.
Typically four to eight weeks.
IT security and compliance checks, messier production data, and change management, which takes ninety-plus days before adoption solidifies.
