Productboard + Koji: Turn AI Interview Insights Into Roadmap Evidence Automatically

The 60-second answer

Koji has no native Productboard app and emits no outbound webhooks, so the link is one you build: poll the Koji read endpoint for interviews that come back completed with an analysis attached, then create a Productboard note through its API for each grounded quote. Productboard's own model is built for exactly this - a note is raw customer input, and you link notes to features to justify them. Koji supplies the notes; Productboard does the linking.

The prize is not automation for its own sake. It is that every feature on your roadmap ends up with real sentences from real customers attached to it, instead of a remembered anecdote from a sales call six weeks ago.

Why this pairing works

Productboard says it is trusted by 6000+ leading product teams, and the reason teams adopt it is almost always the same complaint: feature requests arrive from everywhere, and nobody can reconstruct why anything was prioritised. Productboard solves the storage and linking problem well. What it cannot do is generate the evidence - it can only hold what you feed it, and most teams feed it summaries typed from memory.

That is the gap Koji fills. An AI-moderated interview produces the thing Productboard is designed to store: a verbatim customer sentence, attached to a theme, with the follow-up question already asked.

What maps cleanly

The Koji analysis payload lines up with Productboard's data model better than most sources:

• A quote from extractedData.quotes becomes the body of a note. It is verbatim, in the participant's original language.
• Theme tags become Productboard tags, so notes cluster without manual triage.
• The respondent object supplies the company or segment the note should be attributed to.
• The quality score gives you a filter, so weak conversations never reach the board.
• A link back to the transcript gives anyone reading the note a way to see the full context.

What does not map

• Cross-interview themes. Koji clusters themes when the study report is generated, not per interview. Productboard has its own clustering. Pick one as the source of truth; running both produces two different counts of the same thing.
• Prioritisation scores. Koji does not compute a Productboard priority. Nor should it - that is a judgement call your team makes with commercial context Koji does not have.
• Events. There is no trigger, no event stream and no outbound webhook. Polling is the mechanism.

Setup: Koji to Productboard in four steps

Step 1 - Get a Productboard API token

Create a token in Productboard under your workspace integrations settings. Notes are created through Productboard's public API; the token scopes what your integration may write. Store it as a secret alongside your Koji key.

Step 2 - Poll Koji for completed interviews

Call GET /api/v1/interviews/{id} with an API key in the Authorization: Bearer header. The key needs the interview:read permission, the endpoint requires an Interviews plan or higher, and every response carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset. Read those headers and back off rather than finding your ceiling with a burst of 429s.

Treat an interview as ready when status is completed and analysis is populated. Before that point the transcript exists but the themes and quality score do not.

Step 3 - Create one note per quote, not per interview

This is the step teams get wrong, so it is worth being blunt about it. An interview is not an insight. A single 20-minute conversation might contain four distinct observations about three different parts of the product. Pushed as one note, it is unlinkable - you cannot attach the same note to three features and have any of those links mean anything.

Iterate extractedData.quotes and themeTags, and create a note per grounded item. Each note gets the verbatim quote as its body, the theme tag as a Productboard tag, and the transcript URL as its source link.

Step 4 - Let a human do the feature linking

Resist auto-linking notes to features by keyword match. Productboard's value is that a link between a note and a feature is a deliberate claim that this customer input justifies this work. Keyword matching produces links nobody believes, and once the team stops believing the links it stops using the tool. Push the notes automatically; link them in the weekly triage.

How Koji handles this

• Quotes are grounded, so a note cannot contain something nobody said. Every extracted item carries a verbatim slice of a real respondent message, copied character for character in the participant's original language. Items whose supporting quote cannot be matched back against the transcript are dropped server-side rather than displayed. A note pushed from Koji is defensible in a roadmap review.
• The follow-up already happened. A form captures the reporting is slow. Koji's AI asks which report, how often, and what the person does instead - so the note you file names a cause, not a symptom.
• All six structured question types return machine-readable values alongside the conversation: open_ended, scale, single_choice, multiple_choice, ranking and yes_no. A ranking question tells you which of five candidate features a customer would pick first; the transcript tells you why. Both travel into Productboard together.
• Quality scoring filters the board for you. Each interview carries a 1-5 score with a breakdown across relevance, depth and coverage, so low-signal conversations never become notes.
• Voice and text interviews produce the same payload, so one integration covers both.

Common mistakes

Sending summaries instead of quotes

A summary is your words. A quote is the customer's. Only one of those survives the meeting where someone asks did a customer actually say that? Push extractedData.quotes, and keep the summary for the study report.

Creating one note per interview

Covered above, and it is the single most common failure. Notes should be one observation each.

Pushing every interview regardless of score

A board full of thin notes is worse than a smaller board, because it destroys trust in the ones that matter. Filter on a quality score of 3 or above at minimum.

Letting the integration become the only reader

Automation moves the evidence; it does not read it. Someone still has to open the transcripts for the studies that matter. The integration buys back the transcription and filing time so that reading actually happens.

Governance

Notes carry customer names, company names and unedited opinions into a tool that often has a wide internal audience. Decide before you switch the integration on whether notes should be attributed or pseudonymous, and make that match what you told participants during recruitment. The respondent object gives you an external_id as well as a display name, so attributing by account rather than by person is straightforward.

Frequently asked questions

Does Koji have a native Productboard integration?

No. There is no Koji app in Productboard and no outbound webhook from Koji. The integration is one you build or configure: poll the Koji read endpoint, then create notes through Productboard's API, either from your own backend or from a no-code tool such as Zapier, Make or n8n.

Should a note be one interview or one quote?

One quote. An interview usually contains several distinct observations, and a single combined note cannot be meaningfully linked to more than one feature. Iterate the quotes and theme tags in the analysis payload and create a note for each grounded item.

How do I stop weak interviews cluttering the board?

Filter on the quality score. Every completed Koji interview carries an overall score from 1 to 5 plus a breakdown across relevance, depth and coverage. Most teams push only scores of 3 and above, which is the same threshold Koji itself bills at.

Can Koji decide which feature a note supports?

No, and it should not. Koji supplies grounded evidence and theme tags; deciding that a piece of evidence justifies a particular roadmap item is a judgement that needs commercial context Koji does not have. Automate the note creation, keep the feature linking human.

What plan do I need for the API route?

An Interviews plan or higher. The read endpoint also requires an API key carrying the interview:read permission. If you only want to share findings rather than sync them, publishing the study report and linking to it needs neither.

How is this better than pasting notes from a survey tool?

A survey gives you a rating and a sentence fragment with no follow-up. Koji asks the next question automatically, returns the answer grounded in a verbatim quote, and attaches a theme tag and a quality score - so the note arrives already triaged rather than needing a human to read and classify it first.

Related Resources

• Structured Questions Guide - the six question types and what each returns
• Headless API Overview - the endpoints this integration polls
• Research-Driven Roadmap Prioritization - deciding what the evidence justifies
• The Roadmap Evidence Audit - tracing every roadmap claim back to a source
• Feature Request Management - handling inbound requests at scale
• Understanding Quality Scores - what the 1-5 score measures
• Jira Research Integration - the same pattern for delivery tickets