SLIM — Delivery & Feedback Plan

01Visual roadmap — timeline

Modules ship in batches every two weeks, each batch presented and trained on delivery day. The two weeks that follow are its feedback cycle — the labs use it, report as they go, and fixes are deployed continuously rather than held to the end. The next session reviews that batch and delivers the next one.

Modules, in 4 batches

Delivered and live

2 wk

Feedback cycle

Fortnightly sessions

Where we are today — Saturday 22 August. Batch 1 (Warehousing) shipped 5 Aug, ran a full two-week feedback cycle with fixes implemented as they arrived, and was reviewed on 19 Aug — closed. Batch 2 (Projects, Protocols, Notebook, Project journal & bulletin) shipped on that same 19 Aug session and is in its feedback cycle now, closing 2 Sep. Five of ten modules are live and one full cycle is complete.

August September October

3101724 317142128 51219

TODAY

Batches — deliver & train · two-week feedback cycle · rolling fixes

Company vacation 22–29 Sep · Poqet unavailable

VACATION

B1 · Warehousing ✓ cycle complete · reviewed 19 Aug

5 AUG

feedback

fixes

B2 · Projects · Protocols
Notebook · Project journal in feedback now · closes 2 Sep

→ delivered 19 Aug

feedback

fixes

B3 · Equipment · Tasks in build

→ deliver 2 Sep

feedback

fixes

B4 · Semantic search · Meetings
Material preparation in build · final batch

→ deliver 16 Sep

feedback — spans the vacation

fixes

Onboarding & acceptance dates to confirm — task 2

onboarding period → acceptance · TBC

Customer loop

Session 90 min · every 2nd Wednesday

Weekly sync Mon · 30 min · Daniel + Petrášek

every Monday from 10 Aug

resumes 5 Oct

Always-on channels in-app button · WhatsApp · email

continuous intake

Build Deliver & train Feedback week Fix week Session Vacation Dates to confirm

The last batch carries the most and is protected the least. B4 delivers three modules on 16 Sep — including Material preparation and its genetic-tree visualisation — and its feedback cycle then runs straight through the company vacation. It gets exactly one review, on 30 Sep, and no batch after it to absorb the overflow. Everything B4 surfaces lands in the onboarding period rather than in a normal fix cycle.

The vacation does not stop the labs. Poqet is away 22–29 Sep, but the three labs keep working and the in-app button keeps collecting. That week is feedback gathering with nobody on the other end — worth telling them explicitly, so silence is not read as neglect.

02Tasks

The shared action list across both parties. Filled in together and reviewed at every Monday sync — an item without an owner and a date is not a task.

#	Task	Owner	Party	Due	Status	Notes
1	Decision — review cadence. Can ÚEB test each shipped module, gather feedback and meet weekly, or is a two-week cycle more realistic?	Dr. Jan Petrášek	ÚEB	Wed 19 Aug	Closed	Answered: two weeks. The plan now runs on fortnightly batches with a two-week feedback cycle, which is what B1 actually ran and what B2 is running.
2	Confirm the onboarding period and acceptance date. What happens after the final feedback session on 30 Sep — how long is onboarding, what does ÚEB need from us during it, and when is formal acceptance?	Daniel + Dr. Petrášek	Both	Wed 2 Sep next session	Open	The only undated block left on the timeline. It also decides where B4's feedback goes — with no fix cycle after it, onboarding is the only window for those fixes. Needs a length, a scope, and an acceptance criterion.
3
4
5
6
7
8
9
10

Conventions: Party is Poqet, ÚEB or Both — every task belongs to exactly one, so nothing sits in the gap between us. Status is Open / In progress / Blocked / Closed. A blocked task names what it is waiting on and who owns that.

03Batches & modules

Ten modules in four batches. Each batch is delivered and trained on a Wednesday, runs a two-week feedback cycle, and is reviewed at the next session — which also delivers the following batch.

Module	Delivered	Reviewed	What ÚEB gets	Status
Batch 1 delivered Wed 5 Aug · reviewed Wed 19 Aug · cycle complete
Warehousing	Wed 5 Aug	Wed 19 Aug	Configurable inventory tables, 12 column types, per-warehouse schemas, global low-stock and expiry alerts. Feedback from the first cycle was implemented as it arrived.	Live
Batch 2 delivered Wed 19 Aug · review Wed 2 Sep · in feedback now
Projects Štěpán	Wed 19 Aug	Wed 2 Sep	Research initiatives with sub-projects and members, linked out to warehouse items and notebook entries.	In feedback
Protocols Pavel	Wed 19 Aug	Wed 2 Sep	Versioned step-based procedures — inputs, machines, outputs.	In feedback
Notebook Lab notes · Adam	Wed 19 Aug	Wed 2 Sep	Research timeline with rich-text editing, embedded lab objects, automatic version history.	In feedback
Project journal & bulletin Adam	Wed 19 Aug	Wed 2 Sep	Personal notebook entries roll up into a project journal; per-project bulletin board.	In feedback
Batch 3 deliver Wed 2 Sep · review Wed 16 Sep
Equipment Adam	Wed 2 Sep	Wed 16 Sep	Instrument register with service and inspection cards, files, and an availability/booking calendar.	In build
Tasks Pavel	Wed 2 Sep	Wed 16 Sep	Plans → buckets → tasks; Board, Grid, Charts and Schedule views; My Tasks; upcoming-task alerts.	In build
Batch 4 deliver Wed 16 Sep · review Wed 30 Sep · final batch
Semantic search Štěpán	Wed 16 Sep	Wed 30 Sep	Type a plant name, find it wherever it appears — projects, warehouses, protocols, material lineage, notebook.	In build
Meetings voice-to-text	Wed 16 Sep	Wed 30 Sep	Dictated meeting notes transcribed and propagated into the relevant projects.	In build
Material preparation Štěpán	Wed 16 Sep	Wed 30 Sep	Register of prepared plant material with its lineage — parent lines, crosses and resulting lines — rendered as a navigable genetic tree. Each node links to the specimens, protocols and projects that produced it.	In build
After delivery from 1 Oct · dates to confirm
Onboarding & acceptance	from 1 Oct	—	The labs move fully onto SLIM as their working system, supported by us; then formal acceptance and handover. This is also the only window left for anything Batch 4's review surfaces. Length, scope and acceptance date still to be agreed — task 2.	TBC

04Meetings & communication

Two standing meetings and one escape hatch. A 90-minute session every second Wednesday that delivers, trains and reviews; a 30-minute Monday sync every week; and ad-hoc calls whenever either side needs to consult something.

Meeting	Cadence	Length	Who	Purpose & output
Fortnightly session primary	Every 2nd Wednesday 5 & 19 Aug · 2, 16 & 30 Sep	90 min	Daniel, Jirka, module devs + all 3 labs	Delivery day, and does two jobs. Forward: the new batch is presented and ÚEB staff are trained on each module in it. Back: the previous batch is reviewed — our questions, then everything reported through the in-app button and what we did with it. Output: a trained team on the new batch, and a ranked friction list on the previous one.
Weekly progress sync	Every Monday from 10 Aug	30 min	Daniel + Dr. Petrášek	Kept weekly deliberately, so there is contact in the off-weeks between sessions. Standing agenda: shipped since last week · in flight · blockers needing ÚEB · task list reviewed. Output: updated decision log, and the running order for the next session.
Ad-hoc consultation	As needed either side calls it	15–60 min	Whoever is needed	When a question is blocking — a spec detail, a priority call, a design decision — it gets a short call rather than waiting for the next slot. Requested over WhatsApp, usually same or next day. Output: the decision, written into the task list.

Communication channels

A shared group for the working relationship: quick questions, "are you free for 15 minutes", heads-up that something is deploying, urgent blockers. Fast and informal — but anything that turns into a decision gets written into the task list, so the group never becomes the only record.

In-app feedback button

The primary route for anything about the product itself. A button in the app reports feedback and bugs directly, with screen context attached, at the moment of annoyance. Everything reported is reviewed out loud at the next session.

Email

For anything that needs to be findable months later: scope agreements, sign-offs, formal confirmations, anything commercial. Deliberately the slowest channel, and deliberately kept.

Ninety minutes for a whole batch is the constraint to watch. Batch 4 has three modules to demo and train, plus Batch 3 to review. Fixed split: 50 minutes deliver and train · 35 review · 5 to close. If training overruns it is the review that gets cut — and the review is the half that produces fixes. On 30 Sep there is nothing new to deliver, so the whole 90 minutes goes to reviewing Batch 4.

Exceptions. Company vacation 22–29 Sep: no sync on Mon 28 Sep (also a public holiday); the sync resumes Mon 5 Oct. No session falls inside the vacation — 16 Sep is before it and 30 Sep is after.

05Feedback collection framework

Two mechanisms, designed to feed each other: a button in the app that captures friction the moment it happens, and the fortnightly session that trains the labs on the new batch and then reviews the previous one. Fixes are deployed continuously across the two-week cycle, not held to the end of it.

1 · The in-app button — continuous capture

A button in the app reports feedback and bugs directly, without leaving the screen where the problem appeared.

Captures at the moment of annoyance — not recalled a fortnight later when the detail has gone.
Screen context is attached automatically, so we can see what they were looking at.
Reports land straight in the backlog as GitLab issues.
It matters more on a two-week cycle than a one-week one — there is twice as long for a detail to be forgotten before the session.

2 · The session — train forward, review back

Ninety minutes, run in the same fixed order every time:

Present the new batch — each module walked through live, what it does and why.
Train the staff on it — hands-on with their own data, so they leave able to use it rather than having watched someone else use it.
Our questions on the previous batch — a short, specific list: what we are unsure about, what we expect to be wrong.
The reported items — everything submitted through the button, read out with its disposition: fixed, scheduled, or declined with a reason.

The questions we bring

Asked about the batch under review — the one delivered a fortnight earlier — and kept consistent so the answers can be compared cycle to cycle.

Could you do the task without help?

Fully, with hints, or not at all. The single best predictor of whether a module survives real use.

Did it match how your lab actually works?

Separates “hard to use” from “built on the wrong model of our work” — two problems with very different fixes.

What did you have to work around?

Workarounds are the highest-value answer in the set. People rarely report them unprompted because they have already stopped noticing.

What is missing before this replaces your current method?

Names the adoption blocker directly, rather than inferring it from usage.

What would you remove or simplify?

The only question that makes the product smaller. Worth asking every time.

Would you use this next week for real work?

Yes / only if X / no. The honest adoption question, and the one that predicts acceptance.

Triage and commitments

Classification — every item gets exactly one

Bug — it does not do what it claims. Fixed inside the current cycle.
Usability — it works but obstructs. Sized and ranked; the top items land in the current or next cycle.
Scope change — new capability. Goes to Dr. Petrášek for a priority call against what it displaces.
Future — real, valuable, beyond this engagement. Logged visibly so it is not silently dropped.
Declined — with a written reason, read out at the next session.

Commitments we make

Everything acknowledged within 2 working days.
Everything classified and visible in the backlog within 1 week.
Blocking bugs fixed inside the current two-week cycle, not deferred to the next batch.
Fixes deployed as they are ready, continuously — the labs should see improvement mid-cycle, not only on session day.
Nothing declined silently — the reason is read out at the next session.

When the three labs disagree

Expect it — three labs with different specimens, different protocols and different habits will want incompatible things. The rule: Jirka rules on whether a request reflects real lab practice or one person's preference. Daniel sizes the cost. Dr. Petrášek decides. Where a genuine difference exists across labs, the first question is always whether configuration can absorb it — SLIM's per-warehouse schemas already prove that pattern works — before it becomes a fork in the product.

06The feedback loop

The engine underneath the timeline. It turns once a fortnight, and every turn ends with the labs hearing what happened to what they reported.

Why the read-back step is non-negotiable. The fastest way to kill a feedback programme is for someone to press the button twice and never hear what happened. Once a lab believes their reports disappear, they stop sending them — the button goes quiet, and the plan silently reverts to a big-bang delivery with extra meetings. Reading out the disposition of every item, including the declined ones, is what keeps the button in use.

07Risks

Risk	Likelihood	Impact	Mitigation
Batch 4 has no safety net 3 modules on 16 Sep, one review, then onboarding	High	High	Every earlier batch had a following cycle to absorb its overflow. B4 does not — whatever the 30 Sep review surfaces goes into the onboarding period or nowhere. Settle task 2 before 16 Sep so there is a named window with agreed capacity, rather than discovering on 30 Sep that there is nowhere to put the findings.
Genetic-tree visualisation is unscoped Material preparation ships 16 Sep in B4	High	High	Tree rendering, lineage depth and crossing semantics are all still unknown, and this is now the last module built with the least room to correct it. Get Jirka and one lab to sketch a real pedigree on paper at or before the 2 Sep session — a wrong model here cannot be repaired in a fix week, because there is no fix week after it.
B4's feedback cycle runs through the vacation Poqet away 22–29 Sep	High	Medium	The labs keep using three brand-new modules for a week with nobody answering. Tell them explicitly that the button still works and reports will be picked up on 30 Sep — silence read as neglect is what stops people reporting. Expect the 30 Sep review to be the heaviest of the engagement and plan the full 90 minutes for it.
Onboarding and acceptance are undated	High	Medium	The only block on the timeline without dates, and it now carries B4's fixes as well as onboarding. This is task 2 and it is due at the 2 Sep session.
Fix debt accumulates across cycles 5 modules live, only 1 cycle closed	Medium	High	B2 put four modules into feedback at once, and B3 and B4 arrive before that debt is necessarily cleared. Track items closed versus raised per cycle at the Monday sync; if it stays below 1.0 for two cycles running, the answer is to cut scope in the next batch, not to work harder.
Training three modules in one session 50 minutes for all of B4	Medium	Medium	Roughly 15 minutes per module is enough to demonstrate, not to train. For B4, consider a written guide per module so the session covers the shape and the guide covers the detail — and check at the 30 Sep review whether people can actually use all three, not just the one they liked.
The in-app button goes quiet	Medium	High	On a fortnightly cycle the button is the only continuous input; between sessions there is nothing else. Track submissions per lab per week; a lab reporting nothing is either not using the product or has stopped believing reports go anywhere — both need a conversation, not a reminder.
Three labs pull in different directions	Medium	Medium	Configuration before customisation. Escalation path used consistently. Divergent requirements are logged as such, not averaged into a compromise nobody wants.
Labs do not adopt in real work feedback given from demos rather than daily use	Medium	High	Deliver-immediately and train-immediately exist for this reason. Question 6 measures it directly. With acceptance following straight after onboarding, a lab that has not genuinely adopted by 30 Sep is the clearest predictor of a contested handover.

08Team & responsibilities

Who	Role	Accountable for
Dr. Jan Petrášek	Client project lead (ÚEB)	Priority calls across the three labs; final arbitration when lab requests conflict; sign-off at each batch review; securing lab attendance at the fortnightly session, including for training.
3 ÚEB labs + crew	Pilot users	Using each batch with real data; reporting friction through the in-app button as it happens; attending the session for training on the new batch and review of the previous one.
Daniel Pondělíček	Poqet PM / product	Plan, scope and schedule; feedback intake and triage; running the Monday sync and the fortnightly session, including the training walkthrough; the single decision log and the task list.
Jirka	Domain specialist	Translating lab language into buildable specification; judging whether a request is real lab practice or one person's habit; validating protocols, specimens and material lineage against how the labs actually operate.
Štěpán · Pavel · Adam	Development team	Build, test, deploy. One primary owner per module so feedback has a named destination. Fixes are shipped continuously through the cycle, not batched to its end.

The one role we should name explicitly: with three labs feeding one backlog, conflicting requests are certain — lab A wants a field lab B considers noise. Daniel triages, Jirka rules on domain validity, and Dr. Petrášek is the tie-breaker. Without that escalation path agreed up front, the backlog stalls on unresolvable disagreements.

09Approach & principles

SLIM is being built for people whose real work it has to survive contact with. A lab-operations system that is specified once and delivered at the end is a system that arrives wrong. So this plan is organised around deliver → observe → correct, repeated every fortnight.

Deliver on a fixed beat

A batch ships every second Wednesday and is trained the same morning. Warehousing went live 5 Aug; the tenth and last module lands 16 Sep.

Feedback is a deliverable

Collecting it is scheduled and owned like any build task — a two-week cycle on the timeline after every batch, and a button in the product, not a hope that time will be found.

Fix while the cycle runs

Fixes ship as they are ready rather than waiting for the next session. The labs should see the product improve mid-cycle — that is what keeps them reporting.

This is not theoretical — the loop has now run twice. The original Warehousing feedback pass (issues #26–#31, #33, #35, #36) shipped via merged MRs !18–!25 before this plan existed. Batch 1 then ran the same cycle formally: delivered 5 Aug, feedback gathered and implemented across the fortnight, reviewed and closed 19 Aug. Batch 2 is running it now.

SLIM — delivery
& feedback plan

The plan

01Visual roadmap — timeline

02Tasks

The detail behind the plan

03Batches & modules

04Meetings & communication

Communication channels

WhatsApp

In-app feedback button

Email

05Feedback collection framework

1 · The in-app button — continuous capture

2 · The session — train forward, review back

The questions we bring

Triage and commitments

Classification — every item gets exactly one

Commitments we make

When the three labs disagree

06The feedback loop

07Risks

08Team & responsibilities

09Approach & principles

Deliver on a fixed beat

Feedback is a deliverable

Fix while the cycle runs