A roadmap that admits what is unproven

Public roadmaps usually have two states: shipped and coming soon. Sometimes a third, “in progress”, which mostly means “coming soon, but we mean it”.

Jot’s roadmap has a state that most products would rather not show: written, with an explicit list of what is unproven. Code exists and has tests, but nobody has yet watched it work on a real Windows machine. This post is about why it is shown that way.

Why “written” is not “done”

Jot is built partly in environments that cannot run Windows. A lot of the code - the parser, the database, the sync logic - can be tested thoroughly anywhere. Some of it cannot: a native notification actually appearing, focus returning to the right window, the overlay being hidden from a Teams screen share, a Store licence check. Those only prove themselves on a real Windows PC, in front of a real person.

Calling those “done” because the tests pass would be the most natural thing in the world. It would also be untrue. Tests prove that code does what the tests check. They do not prove that Windows does what the code expects.

What the unproven list looks like

Each phase on the roadmap carries a plain-language note of what has not been walked on hardware. For example, the meeting minutes phase says the parser, storage and screens are tested, but nobody has yet hidden the overlay from a real Teams share or opened a reply in a real Outlook. The bring-your-own-key AI phase says no real API key has been used against it yet.

That text is written from the same verification checklist the project uses internally, and the checklist is the source of truth when the two disagree. When an item is walked on a real machine, it gets a date and a tick, and the roadmap updates.

Why show it publicly

Three reasons.

It sets expectations correctly. Someone deciding whether to rely on a feature deserves to know its real status. “Built but not yet verified” is useful information.

It keeps us honest. Writing “unproven” next to a feature is uncomfortable, and that discomfort is useful pressure to go and verify it.

It is how trust works for small tools. A one-person or small-team product cannot compete on brand. It can compete on being straight with people. The first hour on Windows post describes what happened when parts of the checklist were finally walked: the core loop held up, and a real bug turned up that no test could have caught.

The cost

It makes the product look less finished than a competitor that only says “shipped”. Some visitors will read “unproven” and leave. That is a real cost, and one worth paying: the people who stay know exactly what they are getting.

A pattern other projects could borrow

If you build software:

• Separate “implemented” from “verified in the real environment” in your own tracking.
• Make verification steps explicit, dated and checkable.
• Drive public status from that list, so the page cannot quietly get ahead of reality.

The UK Government Digital Service’s Service Standard has a similar spirit for public services: be open about what you are building and test it with real users in real conditions.

Jot is on the Microsoft Store, and the roadmap says exactly which parts are proven.

Jot is a quick-capture app for Windows: one hotkey, one line, back to what you were doing. What it is, or what is still unproven.