Separate operating work from a product claim
Current SEC filings make clear that commercial software companies report work beyond initial feature creation. Oracle describes cloud and software operations alongside consulting and customer-success services. SS&C describes software-enabled services and links changes in that business to customers, retention, and outsourced transactions.
Those disclosures establish neither a universal service model nor a reason to automate. They show that product operation includes many kinds of work. A filing cannot reveal which customer conversation, exception, or delivery judgment is repeatable for your service.
Treat “we do this manually every time” as a research prompt, not a product requirement.
Use a human-work register before writing a roadmap
For ten recent service actions, record five fields:
| Field | Question |
|---|---|
| Stable boundary | Can a third party identify the input, intended outcome, and excluded cases? |
| Consequence | What happens if the action is wrong, delayed, or performed for the wrong customer? |
| Transferability | Can another trained operator perform it from retained evidence? |
| Recovery | Who detects and corrects an error, and what evidence shows the correction? |
| Treatment | Keep human, document first, automate a bounded step, or stop the experiment? |
The accompanying evidence packet includes a human-work register with deliberately incomplete rows. It is a way to surface unknowns, not a score that turns judgment into a feature backlog.
Keep four kinds of work human until evidence changes
- Unbounded interpretation: where inputs are conversation, changing local conditions, or unstated preferences, record examples and disagreement first.
- High-consequence commitments: route price, legal, safety, or customer promises to an authorised human; automation must not extend authority.
- Rare but material exceptions: keep a visible exception queue when no one can state the recovery path.
- Work that has not transferred: write playbooks, examples, and escalation paths before calling a founder-only decision a product feature.
Automate bounded handoffs first
Candidates include collecting structured inputs, checking a known condition, creating a handoff, showing status, or reminding an accountable owner. Every candidate needs an authoritative input, permitted action, failure signal, and correction owner.
For example, a team may automate a request-status update while keeping the scope decision with an account lead. The interface should expose the request, owner, and exception; it must not imply that it made the decision.
Test the counterexample
A specialist may assess a few unusual cases where customers value the specialist's judgment. Inputs may be private, failures costly, and each case meaningfully different. Turning that work into generic software can add support, sales, security, and recovery obligations without making it repeatable.
The sound conclusion can be “keep this as a documented human service.” That is not a failure to productize; it follows the observed boundary.
Decision rule
Automate only a bounded step with repeatable inputs, a permitted output, a named correction owner, and retained examples. Keep judgment, authority, and unknown exceptions human until observed cases make the boundary inspectable.
This complements the feature-to-product gates: inexpensive code can test a workflow, but it does not prove every useful human action should become software.
What would change the conclusion?
Move a task toward automation when real cases show stable inputs and outcomes, another operator can execute it from evidence, error is observable, and the team can recover without the founder. Move it back to human review when new exceptions, consequences, or authority ambiguity appear.