Define the decision the pilot must support
This article proposes an editorial working method: before starting, define three possible outcomes. Expand deployment, run another bounded trial with specified changes, or stop pursuing this use case. This is not a customer, government or investor standard, and it does not describe results from a Jimhang Capital portfolio company.
If the only objective is positive feedback, there is no clear finish line. A better question is who will decide whether to deploy at a second location, and what evidence that person needs. The decision-maker may differ from the daily user or the contact who invited the demonstration. Identify the operator, site owner and budget decision-maker separately instead of treating them as a single customer.
Count support work alongside successful operation
The following worksheet is adaptable, not a universal acceptance threshold. Denominators, observation periods and operating conditions matter more than an isolated percentage.
| Question | Suggested evidence | Decision before the next site |
|---|---|---|
| Did the product complete its intended task? | Eligible tasks, completed tasks and reasons for non-completion | Change the product or narrow the use case |
| Did it require an engineer alongside it? | Remote support, on-site support and manual intervention hours | Identify work that needs to become a product feature |
| Can the customer maintain it routinely? | Owners of cleaning, charging, calibration and replacement tasks | Confirm training and maintenance handover |
| What does each additional site cost? | Installation, transport, consumables, spares and software integration | Check whether pricing covers delivery effort |
| Who can approve the next step? | Decision-maker, budget source and review date | Establish a specific follow-up decision |
A founder-operated demonstration and a deployment used independently by ordinary staff test different things. Do not remove support hours to improve the headline result. Those hours identify the engineering work still to be done.
Test repeatability with a hypothetical example
Consider an entirely fictional indoor delivery-device trial at one site over two weeks. The team records completion of the target route but discovers that an engineer resets a handover point every day. No real customer, private pitch deck or internal project data is used here.
The immediate question is not how many units to order. It is whether changing the handover point is a common operating condition or peculiar to this site. The team could document the reset procedure, hand it to the site owner and observe another controlled run. If research staff remain indispensable, record that limitation in the next scope and budget instead of claiming scalable delivery.
The second site need not change every variable at once. Keep a comparable route while changing the operators, then test a different environment. This helps distinguish product, workflow and setting issues rather than arguing over one mixed result.
Separate trial support from procurement and orders
Hong Kong has public mechanisms supporting technology trials. As checked on 10 October 2026, the ITC's official PSTS-TC page describes support for eligible technology companies conducting R&D in Hong Kong, involving samples, prototypes and public-sector trials. Existing HKSTP or Cyberport incubatees and graduate tenants are directed to another applicable category.
That is a resource to investigate, not confirmation of eligibility, funding or a purchase order for a particular project. Check the full requirements with the administering body. In your own operating records, distinguish trial support, trial completion, procurement approval, signed orders and cash received. An event photograph is not evidence of any of these milestones.
Give suppliers feedback they can act on
An observation such as unreliable device gives a Shenzhen engineering team little to investigate. Record hardware and software versions, operating conditions, reproduction steps, log location and the person responsible for confirming the issue. Before sharing personal or site-sensitive information, check necessity and access permissions, then disclose only what is needed.
Retest changes under comparable conditions and state which conclusions apply only to the current version. Supplier quotes, component changes and user feedback can be linked, but should not become one unversioned spreadsheet. Our component substitution and change-control guide covers engineering records; this article addresses sustained customer use and repeat deployment.
Discuss the next step with Jimhang Capital
Jimhang Capital, founded by Justin Zhan, publicly describes a role in connecting founders with Greater Bay Area hardware supply-chain resources. Teams working across Hong Kong and Shenzhen can discuss pilot scope, delivery effort and the resources needed for another stage. The scope of support is agreed individually; orders, investment and policy outcomes are not guaranteed.
An initial message to justin@jimscapital.cn can describe a non-confidential use case, completed and outstanding validation, and the next decision you want to discuss. Do not include unauthorised customer logs, personal information or contracts. A conversation grounded in verifiable work is more useful than declaring commercial success after a single trial.
Project-coordination analysis as of 10 October 2026, not procurement, legal or investment advice. Programme eligibility, site safety and contractual terms require review by the responsible parties and appropriate professionals.