Product operations

How we run product covers what a PM is here: a builder, not a coordinator. This page is the operating layer: the three vectors product owns, what each one produces, and how a feature moves from an idea to a documented, tested, shipped thing. We grade it every week with the product health score.

Product owns three vectors:

1. Product - building a differentiated AI product. Specs, mocks, the AI quality bar, and the proof of what makes us different.
2. QA - the quality bar. Scenarios that trace to requirements, run as tests and as manual passes, so nothing ships unverified.
3. Customer - communication. Docs, academy, customer research, and the in-product voice during incidents and support.

The roles

Three owners move a feature, and the handoffs are explicit so no one waits by accident. The full flow is in how we work.

• Product owner (PO). Owns the what and the why. Writes the requirements, the UAT scenarios, and the mockup gap. Never writes the code, the endpoints, or the selectors.
• Engineering owner (EO). Owns the how. Writes the service design, the API contract, the production code, and the automated tests.
• Test owner (TO). Owns the manual end-to-end pass on staging against real infrastructure, and records the result.

A feature runs in order: requirements and scenarios first, then the mockup, then the build, then the tests, then sign-off, then the customer docs. Requirements land and are reviewed before any mockup is prompted; the spec is one change, the mockup is the next.

Vector 1: a differentiated AI product

Product decides what gets built and proves why it is different. It produces three things before engineering writes a line, plus the quality bar that holds after.

• Specs. Every product area has a spec: a requirement table with stable IDs and the UAT scenarios that will test it, written so an engineer can build from it without a back-and-forth. The specs are the source of truth for what the product is supposed to do, and code is never shipped ahead of them.
• Mocks. New UI is prototyped in Lovable before engineering picks anything up. A mockup gap analysis maps every requirement to a mock and classifies the coverage as ready, partial, missing, or deferred, so the build starts against a real target, not a description.
• The AI quality bar. Every AI feature ships with a rubric and is scored on relevance, accuracy, format, and helpfulness. Product writes and iterates the prompts, evaluates the output, and catches degradation first. An AI feature with no quality bar is not done.
• Differentiation. Product supplies the honest technical comparison that proves the product is different: what each competitor is genuinely good at, where it is weak, and who should pick it over us. We concede a rival's strengths rather than pretend they do not exist, because an operator can smell a rigged comparison.

Vector 2: a real QA bar

Quality is not a stage at the end; it is a scenario written at the start and run to the finish.

• Scenarios trace to requirements. The PO writes UAT scenarios whose every case names the exact requirement IDs it covers, so coverage is provable, not asserted. The EO adds the technical steps and writes the test code.
• Automated, then manual. The regression scenarios are automated by engineering and run on every change. The remaining end-to-end scenarios are run by the test owner on staging against real infrastructure, on a cadence: the changed area every week, a full sweep every quarter.
• The review walks backward. A pull request review resolves the feature's requirements, mockup, and scenarios first and stops if there are none, rather than reviewing a diff with nothing behind it. It is the executor of the whole QA pipeline.
• Escaped defects are the signal. A production bug that a scenario should have caught, or drift between a shipped feature and its spec, is what the QA vector is measured on, not test count.

Vector 3: customer communication

The product is only as good as what the customer can understand, learn, and hear from us.

• Docs. Every shipped feature is documented, as a step of the feature process, not an afterthought. Docs are written from a tracked plan against a stated source of truth, held to a high bar before they ship, and they document only what is public: a method or event that appears in a public API contract or an SDK reference, never reverse-engineered internal code.
• Academy. A structured video curriculum teaches the product course by course and lesson by lesson. The scripts are written and checked against the live product; filming is the next phase. The curriculum is honest about which lessons are filmed and which are still scripted.
• Customer research. An evidence-backed ICP and a voice-of-customer practice keep product pointed at a real buyer, not a guessed one. Research is held to honesty tiers: a verified fact, a one-hop quote, and a hypothesis are labeled as what they are until customer interviews settle them.
• In-product voice. During a critical incident, product is in the war room from minute zero and owns the status-page updates and the stakeholder communication. Product also handles the escalated support tickets that the AI-first support layer cannot resolve.

The acquisition loop

Owning the surfaces means owning the path to paid on them, not just the build. We are a signup ecommerce product, so growth sits in product, and Product & Growth runs the direct channels that feed it: PLG distribution, the creator and UGC program, and the paid media on that UGC. For every feature that can stand on its own, product runs a self-contained loop: a landing page, a signup or paywall, and the activation that follows, fed by paid media Product & Growth buys on creator UGC. Marketing runs the long game off-surface, the content, partnerships, social, and founder brand that make every loop cheaper, and hands the visitor a surface.

One PM carries each loop end to end, including the number it moves: activated free workspaces and the self-serve revenue behind them. Media buying is optimized against cost per activated workspace across every loop; the PM owns conversion and revenue inside one. The creator program supplies the UGC the ads run on. The whole channel-to-paid loop is Product & Growth's and does not leave it; it is graded by the product and growth health score.

How it is graded

The product health score reads these three vectors every week: whether the product is differentiated and specced, whether QA is real, and whether the customer can follow along. A standard we do not meet yet shows up as a low score, not a quiet omission.

Want to work at Intempt? Check out our open positions.