The blank page problem
At Xceptor, we use Productboard to capture product insight from across the business: customer requests, internal feedback, pain points surfaced during delivery. The tool itself is straightforward. The problem was what went into it.
A note from someone who knew Productboard well looked nothing like a note from someone who didn't. Some were rich and specific, with named customers and clear context. Others were two sentences and a vague title. Product managers ended up chasing people for detail, guessing at half-formed requests, or skipping the ones too thin to act on.
The friction wasn't Productboard. It was the blank page. Writing a genuinely useful product note means covering what's being requested, who it affects and why, what pain it causes today, what a good outcome looks like and whether a workaround exists. Most people submitting feedback don't think in that structure. They have a request, a feeling about it, and they want to log it and move on.
Asking people to self-structure their feedback before submission creates exactly two outcomes: they don't submit at all, or they submit something too thin to be useful. Both leave product with less to work with, not more.
The gap sat between how people think about a problem and how product teams need it written down. Never the tool itself.
What a product manager does with a rough description, in person, is ask the right questions, infer context from what they know about the business, and turn it into a clear brief. That's the behaviour I wanted an agent to replicate: not transcription, interpretation.
What I built
The agent is an internal web app, gated behind Xceptor SSO so only employees can reach it. A user picks a note type (Product Request or Feedback), enters their name and email, and describes what's on their mind in plain language through a chat interface.
The model takes that raw input and produces a structured note: title, use case, pain points, benefits, workaround, expected timeframe. The user reviews it in a side panel, edits anything they want, selects their tribe tag and company, and submits directly to Productboard. The note arrives with consistent structure, proper attribution and a link back to whoever submitted it.
Building it, session by session
The frontend lives in Figma Make, a React-based tool deployed via Figma Sites. The backend is using Cloudflare Worker for proxy server and custom API services. Most sessions during my breaks at a time: I'd write a short handoff note at the end of one, carry the context into the next, and keep moving. The whole build took a few weeks, working solo alongside various other strategic initiatives .
This is an AI tool, built with AI tooling, to improve the feedback that shapes AI-adjacent product decisions. Not an accident. Building this way kept the loop tight enough that testing "what if the system prompt did X" and seeing it live felt good: the shortest distance from idea to working software I'd experienced.
Frontend in Figma Make · Backend on Cloudflare Workers · No database only localStorage
Key decisions
Interpretation over transcription
The system prompt is written to push the model to interpret and sharpen what's typed in, not just reformat it. It writes in product management language, infers context from what it knows from user's input and attached files, flags the assumptions it makes and asks at most one or two clarifying questions, only when it genuinely can't produce a useful note without them.
Two separate flows, not one generic template
Product Requests and Feedback have different shapes. Feedback doesn't need a "what's being requested" section, but it does need sentiment and frequency signals that a feature request doesn't. Splitting them upfront, rather than handling both in one flexible template, made the output noticeably better in both directions.
Nothing sensitive touches the client
The Productboard API token and every other credential live behind a Cloudflare Worker that sits between the browser and any upstream API. No secrets in the bundle and a single place to add caching and observability later without touching the frontend.
File attachments, extracted client-side
Users can attach PDFs, Word documents or text files to a message. Content is extracted in the browser and passed to the model as context. Files can also be uploaded to Cloudflare R2 and embedded as links in the submitted note.
What I didn't expect
Thinking time became a UX problem. The model reasons silently before it streams, so users sometimes stared at nothing for ten to twenty seconds. Streaming wasn't broken. The wait felt endless. Rotating status messages during the silent phase, plus a lower reasoning-effort cap, fixed it.
Productboard's API has its own learning curve. Migrating from v1 to v2, forced by a deprecation deadline, surfaced a few things the documentation doesn't spell out clearly, particularly around how notes get linked to companies. Get the request shape wrong and you get a silent failure: querying the workspace's own schema directly beat trusting the generic docs example.
Identity is hard without a database. I wanted submitter attribution without building auth from scratch. SSO gates access to the app but doesn't expose identity to the React app itself. I got Microsoft SSO via MSAL.js partly working, the dropped it because it didn't support Figma Sites. Fallback: name and email in localStorage, pre-filled on return visits.
Prompt injection is a real risk, even here. People found they could nudge the agent off-topic (I did too!): away from feedback, into questions it had no business answering. Nothing malicious, but not what a single-purpose tool should do. The fix was an explicit scope restriction at the top of both prompts: refuse anything outside product feedback, redirect immediately, don't engage.
What people are saying
Three people, unprompted, said some version of the same thing: it removed the guesswork. One said it structured their feedback into something readable without them having to think about structure at all. Another said it was more intuitive than expected. A third just said: it does the job.
The goal was for people who'd struggled with Productboard before to actually use this, alongside the people who were already comfortable with it. Both groups are using it.
Where it is now, and what's next
The app is live and in daily use. Notes submitted through the agent are consistently better structured than notes submitted directly, and the product team has more signal to work with as a result. A few things are still on the roadmap: AI-suggested tags and tribes, plus a "my submissions" view so people can track what they've sent in.
The more significant next step came directly from the PMs using it. Once submission was solved, the obvious next question was what happens to all that feedback afterwards. PMs wanted visibility into their own data: feature pipeline, feedback volume, initiative progress, OKR status, without navigating Productboard's full interface to find it. And they wanted to be able to ask questions about it directly.
That's the direction for the next version: a personalised PM dashboard inside the same app. It would pull each PM's owned features, linked notes, releases and OKRs from the Productboard API, with an AI chat layer on top so they can query their own data in plain language. Which of my features has the most unprocessed feedback? What's at risk in my Q3 release?
Tech stack, briefly, for anyone who wants specifics: React frontend via Figma Make, hosted on Figma Sites. Azure OpenAI (for the AI reasoning model) powers the agent itself. All API calls proxy through a Cloudflare Worker, with file storage in Cloudflare R2. Productboard's v2 API handles note submission and company lookup. No database. Auth is Figma Sites SSO for access, localStorage for identity persistence.