Record the baseline.
The PM confirms the links from source excerpt to assumption, acceptance criterion, and task. The agreed scope is saved as a baseline version.
APPROVED SCOPE / SOURCE LINK EVIDENCE REVIEW FOR PRODUCT TEAMS · IN DEVELOPMENT
See which requirements
new evidence challenges.
For 1–5-person B2B SaaS product teams using Linear or Jira. Review new customer evidence against agreed acceptance criteria and work already in progress.
IN DEVELOPMENT · EARLY ACCESS
20–200employees at B2B SaaS companies
1–5people in the product team
Linear or Jira
Customer support + recorded calls
NOVI EDGE FZCO
STARTUP PROGRAMME MEMBERSHIPS
Google for StartupsCloud Program · Member
NVIDIAInception · Member
01 / AFTER ENGINEERING HANDOFF
Keep the reason
beside the requirement.
A feature is already in development when another customer call challenges the assumption behind it. The PM has to find the agreed requirement, locate the affected work, and decide whether to reopen the scope.
We’re building Threadline around that review. Each approved requirement would keep a link to its evidence and delivery tasks, so a proposed change can be checked against the original decision.
02 / INSIDE THREADLINE
Evidence, decisions,
and the work they inform.
Four concept screens with sample data
explore how evidence could stay linked to scope.
[ 01 ]
Keep the source.
Store the original excerpt, its date, and the customer context beside the assumption it supports.
[ 02 ]
Record the decision.
Confirm which acceptance criteria depend on that assumption and which tasks implement them.
[ 03 ]
Review the change.
Compare new evidence with the agreed baseline. Approve a change brief before revising the handoff.
03 / THE FIRST WORKFLOW TO TEST
A customer call can
challenge a decision
already in the sprint.
For the first pilot, we plan to focus on B2B SaaS onboarding. Suppose the team agreed to require a teammate invitation before the first brief. A later interview reveals that the user must show value internally before inviting colleagues.
Threadline would flag the assumption about when to invite teammates, the blocking acceptance criterion, and the linked task. The PM would see both excerpts and proposed edits, then decide whether the evidence applies to this customer segment.
Illustrative scenario. The workflow is in development and has not been validated with customer teams.
See the proposed review flow
04 / HOW THE WORK MOVES
From new evidence
to a reviewed change.
Planned for evidence that arrives
while a feature is already in development.
Check the context.
Compare a new excerpt with the baseline. Check the persona, customer segment, and situation before proposing a conflict.
NEW SOURCE / POSSIBLE CONFLICTTrace the possible impact.
Show linked criteria and tasks that may need review, with the original evidence and proposed edits. Flag missing links for the PM to check.
CRITERIA / TASKS / PROPOSED DIFFApprove the next version.
The PM accepts, rejects, or requests more evidence. An approved change becomes a new baseline and a copyable brief; external tasks stay unchanged.
HUMAN REVIEW / VERSIONED HANDOFF
Threadline is developed by Novi Edge FZCO. The initial product concept focuses on reviewing new customer evidence against requirements already in development.
contact@threadline.com05 / QUESTIONS
Before you
join us.
Where the product stands,
and what to expect.
Who is Threadline for?
Our initial customer focus is product teams of 1–5 at B2B SaaS companies with 20–200 employees, where customer evidence is spread across support conversations, call recordings, and delivery tools.
What are you building?
A workspace for reviewing new customer evidence against requirements already agreed with engineering. The proposed review connects a source excerpt to an approved assumption, its acceptance criteria, and the linked tasks in progress.
How is the concept different from a spec generator?
The focus is a decision after handoff: does a new interview or support conversation challenge a requirement already in the sprint? We plan to compare it with a versioned, PM-approved baseline and prepare a change brief for specific linked criteria and tasks. This is a product hypothesis to test with teams, not a claim that competing tools cannot do it.
How would a review work?
The PM first confirms the links between evidence, assumptions, criteria, and tasks. When new evidence arrives, Threadline would propose possible conflicts and check the customer persona and context. The PM could approve a change, reject it, or ask for more evidence. Unlinked work would remain outside the review; no task would change automatically.
Which integrations are available?
No production integrations are available yet. The first pilot is planned around uploaded interview transcripts and read-only Linear access, with a change brief the PM can copy. Jira, Intercom, Zendesk, and Gong are candidates for later validation.
Can I use it today?
Threadline is in development. The four product screens illustrate the proposed workspace using sample data; they are not evidence of a deployed product or live customer results.
What happens when I request early access?
We save your email and a record of your request, so we can contact you about early access. The privacy notice explains the operator, purpose, retention criteria, and how to withdraw. Signing up does not connect any of your tools.
06 / EARLY ACCESS
Request an early-access
invitation.
We’re developing evidence review for small B2B SaaS product teams, starting with onboarding decisions already in delivery.
IN DEVELOPMENTB2B SAAS · 20–200 EMPLOYEES