Technical PASS is not Product PASS

A prototype can answer the question it was built to answer and still tell you almost nothing about whether the product should exist.

Exam Workbench reached that point quickly.

The first product idea was too narrow

The project started from a real problem: teachers spend time formatting exam papers, and complex Word / WPS documents are tedious to assemble.

That pain is real. It is also already served by mature products. Existing tools cover exam formatting, large question banks, drag-and-drop assembly, multiple paper sizes, and scanned-paper workflows.

So the decision changed.

Instead of asking “can we make exam formatting better?”, the product question became:

Can teachers start from the DOCX, PDF, image, and scanned material they already own, progressively select what they need, assemble a new paper, and keep a high-fidelity editable output — without first migrating everything into another question bank?

That is a different hypothesis. It also creates two different kinds of uncertainty.

Technical uncertainty

First, we needed to know whether a browser-first workflow could preserve enough document fidelity to be credible.

The first bounded vertical slice used two real DOCX files. The browser opened both locally, content was selected across sources, the draft was reordered, an A3 two-column page profile was applied, and the result was exported as an editable DOCX.

That file was then reopened in WPS and used to produce a PDF.

A second slice tested something document prototypes often hide: embedded images and package relationships. Ordinary inline images were remapped across DOCX packages and verified in WPS. Structures that were not yet safe — including floating anchors and OLE objects — remained unsupported instead of being silently flattened or corrupted.

Those results matter.

They reduce technical uncertainty.

What they do not prove

They do not prove that teachers want the workflow.

They do not prove that starting from existing materials creates a meaningful enough advantage over current tools.

They do not prove willingness to pay.

They do not prove repeat use.

A working prototype makes it easy to blur these boundaries because the most visible evidence is now positive: the file opens, the draft assembles, the DOCX exports, WPS reopens it.

But none of those events contains a buying decision.

Two separate scoreboards

The project therefore keeps two scoreboards separate.

Technical feasibility asks whether the workflow can work safely enough to test.

Current evidence says a bounded multi-source DOCX path can.

Commercial validation asks whether real teachers bring their own materials, recognize a clear advantage, pay, and come back.

Those gates are still open.

That means Exploring is not a placeholder status. It is the truthful product state.

Why this matters beyond this project

For a small product team, technical progress is especially dangerous as a proxy metric because building is often the thing the team is best at.

A difficult implementation can feel like evidence that the opportunity is important. A successful demo can feel like evidence that the product is wanted.

Neither inference is automatic.

A more useful rule is:

Use engineering to remove technical uncertainty. Use users, money, and repeated behavior to remove commercial uncertainty. Do not let one scoreboard impersonate the other.

The next valuable Exam Workbench result is therefore not another DOCX feature by itself.

It is evidence from real teacher work that changes the commercial decision.