Running Enterprise PoCs Small and Fast, on Top of Existing Assets

Netsujo Inc. · Published June 22, 2026 · Updated July 11, 2026

Large companies and manufacturers often want to run technology proofs of concept (PoC) as fast as startups do, but they carry structural constraints startups don't: multiple approval layers, dependence on stable legacy systems, scope creep, and long procurement lead times. This article sets out how to design a PoC that stays small and fast despite those constraints. The core design points are narrowing hypotheses to one to three, fixing the scope of integration with existing systems before implementation starts, shipping a working demo every week, and agreeing exit (go/no-go) criteria before the PoC begins. It also covers issues specific to enterprise PoCs — phased budget approval, steering committees, and internal resistance — and how to choose an external partner. The piece argues for an implementation-led partner who works from concept through to a first working build, rather than splitting strategy and delivery across two separate vendors.

Why enterprise new-business development is slow

Large companies struggle with the speed of new-business PoCs not for lack of capability, but for structural reasons: the organization, processes, and systems built to keep an existing business running reliably are often at odds with fast experimentation.

• Multiple decision layers — business unit, IT department, legal, and executive approval all sit in sequence rather than in parallel, so waiting for sign-off alone can take weeks.
• Dependence on existing systems and a 'don't touch it' constraint — core systems and databases are designed for years of stable operation, and connecting anything new to them tends to get split off as a separate project.
• Scope creep and perfectionism — requests from the field, additional executive instructions, and competitive feature additions pile up during planning, pulling scope away from the core hypothesis until budget and time run out before anything works.
• Procurement lead time — even once an external partner is chosen, contracting, security review, and environment setup can add weeks, during which market conditions can shift.

Designing a PoC that stays small and fast

• Narrow the hypotheses to 1–3 — write down what this PoC needs to prove in order to move forward, and start with the highest-priority hypothesis. More hypotheses mean more time, more cost, and a harder question of which result to believe; deciding to test only the riskiest hypothesis in the first 2–4 weeks is what creates speed.
• Fix the scope of existing-system integration first — confirm at the design stage which data can be pulled from which existing system, at what granularity, and through which API. Leaving this for later causes rework once implementation discovers the expected data isn't available; involving the existing system's owners from the design stage is essential.
• Show something working every week — if more than two weeks pass with nothing visible, stakeholder interest fades and requests pile up. Keeping a demoable state every week, with feedback folded into the next cycle, is the single biggest factor in keeping a PoC small and fast.
• Agree Go/No-Go exit criteria in advance — agree before starting on a criterion such as 'if this KPI falls below this value, the PoC stops.' Without one, a disappointing result tends to produce 'let's continue a bit longer' rather than a decision, and sunk cost grows. It also helps build a culture that treats stopping as early learning rather than failure.

Issues specific to enterprise PoCs

• Integration realities — connecting to core ERP or production-management systems starts with confirming API scope, authentication method, and data format. Deciding upfront whether to use mock data or read-only access to real data shapes the design of every later phase; judging what can proceed without IT department involvement is part of an implementation partner's job.
• Phased budget and approval flow — trying to get an entire PoC budget approved in one lump sum raises both the amount and the approval bar. Splitting the request into 'Phase 1: technical validation (a few weeks, small scope)' and 'Phase 2: user validation (additional budget)' lowers the initial decision cost, and clear Go/No-Go criteria give later budget-addition decisions a documented basis.
• Steering committee and interim reporting — one organizational reason PoCs fail is that executives, business owners, and the development team disagree on what counts as success. A monthly or biweekly steering committee that shares hypotheses, KPIs, progress, and issues in the same format is a safety valve that surfaces misalignment early.
• Internal resistance — new-business PoCs can change how existing departments work, so pushback can come from three directions at once: front-line staff, IT security review, and a cautious legal department. Showing small results early, rather than arguing on logic alone, is usually more effective at getting concrete risks and concrete benefits onto the table for discussion.

Choosing an external partner

Netsujo is a Kyoto-based implementation-led business development ("BizDev") firm that stays involved from concept structuring through to implementation in Web3, AI, and other emerging-technology areas. In a PoC context, we take on projects from the stage of "we have a hypothesis but no one who can judge whether it is technically feasible" or "the design is done but there is no one who can build the first working version." We have no delivered manufacturing-sector case studies as of this writing, but we do work on PoC design across industries in the context of integrating with a client's existing systems.

How to run a PoC: 5 steps and typical costs（日本語）

5 reasons PoCs don't turn into a business, and how to avoid them（日本語）

What is implementation-led business development?（日本語）