Founder case study
HP: Use an early customer's request to test your product direction
HP's documented 200A-to-200B story, with a practical framework for deciding whether an early customer request belongs in your product.
An early customer can reveal a valuable use case, but can also pull a small team toward work that few others need. The question is not whether to listen. It is how to distinguish useful product learning from a commitment that changes the business you intended to build.
What HP's archives document
HP's official 1930s timeline records Bill Hewlett and Dave Packard beginning part-time work in a Palo Alto garage in 1938 with $538 in working capital, including cash and a used drill press. They formalized their partnership on January 1, 1939.
Their first product was the 200A audio oscillator. Disney reviewed it and requested modifications; the resulting model was the 200B, and Disney ordered eight. The Hewlett-Packard Company Archives explains that the modifications changed the frequency range. The distinction matters: the customer bought modified 200B units, not eight unchanged 200A units.
These company-maintained historical accounts establish a product and customer sequence. They do not tell us that accepting every request is a sound strategy, or that a famous customer's name proves demand in a broader market.
Our analysis: evaluate the reusable part
A request may contain several different things: a shared customer problem, a particular workflow, a preference and an expectation of ongoing support. Pull those apart before estimating the work. The reusable element may be smaller than the requested feature.
For a hypothetical scheduling tool, one customer might ask for an entirely custom dashboard. The underlying need could be to identify unconfirmed bookings each morning. A filter or export might address that task with less permanent complexity. That example is our planning illustration, not part of HP's history.
A customer-request decision sheet
Use this table before promising delivery. Record what you know and what you still need to ask.
| Decision field | What to write |
|---|---|
| Underlying outcome | [The customer task, without naming a proposed feature] |
| Observed problem | [A recent occasion when the task failed or required a workaround] |
| Reusable core | [The part another similar customer could also use] |
| Customer-specific portion | [Unique rules, data formats, integrations or presentation] |
| Evidence beyond one buyer | [Comparable requests, a second interview or a planned test] |
| Ongoing obligation | [Maintenance, training, compatibility and support work] |
| Decision | [Build, prototype, offer separately, postpone or decline, with a reason] |
Test before making a permanent commitment
- Restate the request as a problem. Ask the customer to walk through the last time it occurred. Confirm which part caused the difficulty.
- Show a small proposal. A sketch, sample output or limited prototype can reveal misunderstandings before a full implementation.
- Find a comparable situation. Check whether the same solution helps another intended customer. Similar wording does not always mean the same underlying need.
- Set the boundary. Explain what the solution includes, what remains manual and which future changes are outside the current scope.
- Review the result. Record task completion and support effort, then decide whether the request belongs in the standard product.
What a historical example cannot establish
HP's early capital amount is a historical detail, not a modern startup budget. A garage is a location, not a product strategy. Likewise, a single successful custom order cannot establish repeatability or the cost of serving future customers. Your decision needs evidence from the market and delivery model you actually face.
Sources and editorial note
Historical facts: HP's official 1930s timeline and HP Company Archives, “HP's First Products”. The decision sheet and interpretation are FounderType's editorial work. Unverified founder and Steve Jobs quotations have been omitted.