prodc
Product management as code: personas, flows, and features traced to evidence, so a product's state is read from the repo instead of chased in meetings.
prodc treats product thinking the way requirements-as-code tools (Doorstop, StrictDoc) treat requirements — plain text, in git, with IDs that link to each other — but for the artifacts a product person actually works with: Persona → Flow → Feature → Assumption, each tied to evidence. Two rules give it teeth:
- No evidence link = flagged as opinion. Every "why" must trace to a user signal (feedback, ticket, interview), or it is marked unsupported.
- Status comes from the repo, not from a standup. "Flow UF-004: 3 of 5 scenarios passing", "Feature F-012: blocked, assumption A-003 has no data" — the report answers "where are we" and "what's blocking" without a meeting.
The lineage is Toulmin's argument model (claim + grounds + warrant): a feature is a claim, its evidence is the grounds, its assumptions are the warrant. The same shape safety engineering uses for a "safety case", pointed at product decisions.
What it's for
prodc does not replace the human conversation with a client — it is scaffolding around it. Going in, the board already shows what is still unknown for that client: needs with no evidence (opinions) and needs with no proof (HOLEs), so the meeting is spent closing real gaps instead of re-deriving them. Coming out, what was learned is captured as evidence on the need, so the next decision is planned from the repo rather than from memory. The board answers "where are we" and "what's blocking" between meetings, without a standup.
Prior art
prodc draws on, and tries to credit, several existing lines of work:
- Continuous discovery / opportunity framing — Teresa Torres (opportunity = need; the interview > artifact > internal evidence ladder; "solutions in disguise").
- The argument/assurance model — Toulmin (claim · grounds · warrant) and the safety-case / GSN tradition it informs.
- Spec-driven development — product/requirements modelled as plain JSON/YAML in git (the ThoughtWorks / Fowler SDD writing).
- Structured requirements — EARS (Easy Approach to Requirements Syntax), the NASA requirement-writing guidance, and the SysML lineage.
- Requirements-as-code tooling — Doorstop and StrictDoc (plain-text, git-tracked, linked IDs), which prodc follows in form but points at product artifacts rather than "shall" statements.
Status: v0.3, on PyPI (
pip install prodc). The model (Need · Source · Proof), the proof and source adapters, and the status / show / diff / portfolio commands are in; seedocs/issues/for what's still open.
Install
uv sync # dependencies
make install-hooks
make check # lint + typecheck + test
Why not just Doorstop / StrictDoc?
Those track "the system shall…" requirements for auditors in regulated industries. prodc tracks personas, flows and features for product decisions, and derives live status from the project's own tests. It reads a repo it is pointed at — including existing Gherkin/BDD and whatever ID scheme already lives there — rather than asking you to re-author everything in a new grammar.
Layout
src/prodc/— the package (typed;py.typed).docs/issues/— follow-ups, as a plain-markdown issue register.Makefile—format/lint/typecheck/test/check/build/docs.AGENTS.md— build/test/style/gotchas for coding agents.
1 maintainer
Metadata
1 maintainer
Release files for prodc 0.3.14
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| prodc-0.3.14.tar.gz | 29.9 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| prodc-0.3.14-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 56.3 kB
Release files / prodc-0.3.14.tar.gz
| Download URL | prodc-0.3.14.tar.gz |
|---|---|
| Size | 29.9 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
1fb012dd89f85b1cdb3f42be9b98eba6951450b77096953cc2aaa148da705a90
|
|
BLAKE2b-256 checksum How to use checksums |
c7b2b2bb5e97a82258056cc37ee733addc72eb4b375ef615b1785d1545605026
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
uv/0.11.19 {"installer":{"name":"uv","version":"0.11.19","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Debian GNU/Linux","version":"12","id":"bookworm","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}
|
Release files / prodc-0.3.14-py3-none-any.whl
| Download URL | prodc-0.3.14-py3-none-any.whl |
|---|---|
| Size | 26.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
64341b8734f823a82c04d93c7f56bde7734c2d1ada44c6ace409254413271230
|
|
BLAKE2b-256 checksum How to use checksums |
6bc0f4a7c9311fa49d8cda402da834a381151d1bef2a2e53719821fe0f1bb9a0
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
uv/0.11.19 {"installer":{"name":"uv","version":"0.11.19","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Debian GNU/Linux","version":"12","id":"bookworm","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}
|
