# Founder writing: optional fictional exercise

Original invented teaching material. The founder, conversation and first-person draft are fictional; the source recording uses synthetic voices.

## Inspect the source before selecting a thesis.

Original fictional teaching conversation. This is new material written for these guides, not an actual interview or a rewritten Rishwajeet essay. An invented software founder observes a print operator calling for confirmation after receiving a green tick. The full [source transcript ](https://machinehouse.media/resources/podcast-trailer/source-transcript.txt) and [synthetic recording ](https://machinehouse.media/resources/podcast-trailer/conversation-source.wav) are available.

### The source-to-argument turn

Observation, D02: two PDFs are called final, someone says “looks good,” and the operator still makes a phone call.

Interpretation, D04: the click is visible but release authority is unclear.

Boundary, D06: if one person owns the decisions, keep the process simple.

Evidence limit, D12: the proposed change is a small pilot; it has not established an operational improvement.

Notice what is absent: measured savings, market-wide prevalence and proof that the same repair suits every customer. Those gaps should narrow the writing, not become invitations to add confident language.

## Three arguments the same source could support.

| Possible thesis | Reader and supporting material | Limit

| Approval software must represent authority. | A product designer deciding what an approval action means. D02–D06 distinguish a click from a release decision. | Some jobs have one person responsible for every decision. Do not prescribe a committee.

| Version control belongs inside approval. | A producer managing files. D08 connects the approved version to the release owner and reopens a decision when the file changes. | The source does not compare tools or prove that a particular interface is best.

| Workarounds can expose missing product understanding. | A founder interviewing customers. D14 reinterprets the phone call they wanted to remove. | Not every workaround is useful. Investigate its job before deciding whether to preserve it.

For this piece, choose the third argument. It contains a change of mind and travels beyond approval software without claiming every workaround is wise. Reject “Removing approval calls makes every print shop faster”: neither the experience nor the pilot evidence supports it. The stronger-sounding claim would make the piece less trustworthy.

## A finished passage in the fictional founder’s voice.

### Illustrative first-person draft

The phone call was the part I wanted to remove.

An operator had a proof on screen and a machine ready to run. Someone had replied “looks good.” From the software’s point of view, the job looked approved. From his point of view, it was still unclear whether that person could authorise printing this version.

I had treated the call as friction. It was actually carrying a decision our interface had failed to name.

That changed the question I wanted the product to ask. A comment, a correction and permission to release a job can happen beside the same file. They do not necessarily mean the same thing, or belong to the same person. A brighter green tick would have made the ambiguity easier to see. It would not have resolved it.

The next version named the proof and the person who could release it. That was a small pilot, not proof that we had made the operation faster. We still needed to observe a rush job, a late change and an absent approver.

I would now ask who can say yes, and yes to what, before deciding which button belongs on the screen.

The opening starts with the founder’s mistaken interpretation. The scene lets the reader see why it was plausible. The middle changes the meaning of the call, and the ending offers a question the reader can use. The pilot qualification stays inside the argument because it changes what can honestly be concluded.