Help one real workflow reach completion
The obstacle between an early customer and a useful product may be a failed data import, an unfamiliar setting or uncertainty about who handles a breakdown. Another brochure will not necessarily resolve it. Working alongside the customer lets a founder see where the task actually stops.
Paul Graham's essay on work that does not scale emphasizes recruiting early users directly and learning through unusually attentive service. The operating worksheet below is Jimhang's original application. The example is hypothetical, not a portfolio company case.
Source：Do Things that Don't Scale
Choose a setting that produces complete feedback
Imagine an inspection tool for factory equipment. Instead of requesting a factory-wide rollout, agree on one equipment area, one inspection task and one shift. Help install the tool, train the operator and observe the handover. This makes it possible to distinguish a product problem from a convenient demonstration environment.
A laboratory contact or an alumni business may provide the first opportunity. Their willingness to host the team does not establish a repeatable market. Record how the introduction happened, whether payment was involved and who requested continued use. The next customer without a personal connection should have a comparable baseline.
Keep an effort ledger
Separate configuration, customer learning, defect repair and customer-specific requests. Manual tasks do not all deserve immediate automation, and customer requests do not all belong in the standard product. Review the ledger after a working week, when the details are still available.
| Manual work | Record | Next decision |
|---|---|---|
| Setup and import | Minutes and points of friction | Improve repeated onboarding obstacles |
| Training | Questions asked repeatedly | Separate unclear instructions from design problems |
| Fault handling | Conditions, impact and recovery effort | Prioritize failures of the core task |
| Customization | Whether other users share the need | Agree scope before adding it to the product |
Make service commitments concrete
Human assistance can be part of an early product, provided the trial customer understands which steps remain manual, when support is available and what happens when the trial ends. Promise a level of service the team can sustain. For work spanning Hong Kong and the Pearl River Delta, record transport and travel as well as time spent operating the software.
After each visit, compare what mattered most to the customer with what consumed most of the team's time. Overlap may point to a valuable improvement. Heavy effort on something the customer barely notices calls for a different discussion. The ledger should change priorities rather than merely document activity.
Watch what gets easier for the next customer
Can another similar customer complete the same task with less assistance? Compare time to first completion, support effort, failure causes and later independent use. If progress stalls, first check whether the contexts differ. Do not quietly remove difficult customers to make the chart improve.
A useful early-customer discussion with Jimhang Capital can show this progression alongside the benefits delivered. It helps distinguish a repeatable product opportunity from work that continually depends on a particular founder. The next investment may belong in product design, sales or delivery; the effort record helps the team choose.
Leave with a concrete work product
- Agree on one initial setting with an observable workflow.
- Record support effort and failure causes by task.
- Explain manual steps, support hours and trial-end arrangements.
- Compare how much help later customers need.