Refinery89 Product Manager Interview: Questions, Experience & Prep (2026)

Refinery89 is a publisher monetisation platform in the ad tech space. They help digital publishers, from independent blogs to large media houses, earn more from their ad inventory through programmatic advertising, header bidding wrappers, and audience analytics tools. A Product Manager here owns a slice of this stack and must be equally comfortable discussing publisher revenue goals with sales teams and talking through bid latency and data pipeline trade-offs with engineers.

As of knok jobradar data from July 2026, Refinery89 has 10 open Product Manager roles, suggesting active team growth. Candidates typically go through an application screen, a product case or take-home assignment, and one or more rounds of panel interviews with product and engineering leaders. Process details vary by role, so treat any published timelines as indicative.

Salary benchmarks from knok jobradar for PM roles in India:

Actual offers depend on the team, location, and your prior ad tech or publisher-side experience.

These questions reflect the topics Refinery89 product interviews typically cover, based on the company's focus on publisher monetisation and ad technology. Treat this list as a strong preparation guide, not a guaranteed question bank.

1. How would you prioritise features for a publisher-facing ad optimisation product when publisher needs and advertiser demands pull in different directions?
2. Walk us through how you would define and track success metrics for a header bidding solution.
3. Refinery89 works with publishers of many different sizes. How would you segment these customers and build a roadmap that serves all of them without spreading the team too thin?
4. Tell us about a time you used data to make a product decision that went against what your stakeholders expected.
5. How would you approach reducing latency in an ad serving pipeline while keeping fill rates healthy?
6. A publisher reports their eCPM has dropped noticeably after a recent product update. Walk through how you would investigate and respond.
7. How do you think about building privacy-first ad products as third-party cookies continue to phase out across major browsers?
8. Describe your experience working with engineering on real-time data processing or event-driven systems.
9. How would you design an experiment to validate a new ad format for publishers before rolling it out broadly?
10. What is your approach to competitive analysis in the ad tech space, and how do you translate that insight into roadmap decisions?
11. Tell us about a product you shipped that had a clear, measurable impact on revenue or engagement.
12. How would you onboard a new publisher onto a monetisation platform and reduce the time before they see value?

Q: How would you prioritise features when publisher needs and advertiser demands conflict?

*Situation:* At a previous role, we were building a video ad product where publishers wanted faster page load and advertisers wanted rich, high-impact formats. Both sides had a valid case and the tension was holding up the roadmap.

*Task:* I needed to decide which features to build first for the next quarter and justify the call to both the sales team and engineering.

*Action:* I ran a structured prioritisation exercise. I mapped each requested feature against two axes: revenue impact for the publisher and demand signal from the advertiser side, using bid density data we already had. I then held a joint review with the sales and engineering leads, presented the matrix, and proposed a phased approach. We first shipped a 'lazy-load' optimisation that improved publisher page speed without reducing ad quality. For the richer formats, I scoped a limited pilot with a small group of willing publishers to gather real performance data before any broad rollout.

*Result:* The lazy-load feature shipped in the next sprint. Publisher satisfaction scores, tracked in our quarterly NPS survey, moved up. The pilot for rich formats gave us the evidence to expand confidently in the following cycle. The framework also became the team's default prioritisation tool.

---

Q: Walk us through how you would define success metrics for a header bidding solution.

*Situation:* I joined a team mid-build on a header bidding wrapper product. There were no agreed metrics and different stakeholders had different ideas of what 'good' looked like.

*Task:* My first priority was to establish a shared definition of success before we launched the first publisher cohort.

*Action:* I ran a short discovery sprint with the engineering, data, and publisher success teams. We identified three layers of metrics: a primary metric (publisher eCPM lift compared to the previous setup), secondary metrics (auction timeout rate and page load impact), and guardrail metrics (advertiser win rate and fill rate, to make sure we were not improving publisher yield by degrading advertiser outcomes). I wrote a one-page metrics brief, got sign-off from the product director, and instrumented all three layers before go-live.

*Result:* At the first review, we had a clear story to tell. The primary metric showed a positive lift for the pilot cohort. More importantly, the guardrail metrics flagged one configuration that was quietly hurting fill rate, something we would have missed without them. The brief was later adopted for two other ad products in the team.

---

Q: Tell us about a product you shipped with clear revenue impact.

*Situation:* Our publisher analytics dashboard showed that a large segment of smaller publishers were churning within the first few weeks because they could not interpret their revenue data.

*Task:* I was asked to improve early-stage publisher retention without requiring significant additional engineering resources.

*Action:* I interviewed churned publishers directly and found the core issue: they did not understand why their eCPM was lower than expected, and there was no guidance in the product. I scoped a 'revenue health card', a lightweight in-product feature that surfaced the top reason for any eCPM gap and suggested a specific action. I partnered with the data team to define the logic, kept the engineering scope narrow, and ran a short beta with a small group of new publishers before the full rollout.

*Result:* Early retention for the beta cohort improved noticeably. The publisher success team reported fewer support tickets related to eCPM confusion. The feature was rolled out to all new publishers in the following quarter.

Use STAR for behavioural questions. Situation and Task together should be brief. Spend the majority of your answer on Action, covering the specific steps you took, the trade-offs you weighed, and the people you involved, then close with a measurable Result. If you cannot share a specific number, describe the directional outcome clearly.

Use a structured breakdown for product design questions. Candidates report that Refinery89 interviewers respond well to answers that start with the user or customer, move to the problem, then to solution options, and close with how you would measure success. Avoid jumping to features before you have established who you are solving for.

For metrics questions, use a layered approach. Lead with your primary success metric, add one or two secondary metrics that give more detail, and include at least one guardrail metric that tells you if you are causing unintended harm elsewhere in the system. This is especially important in ad tech, where optimising one metric (say, eCPM) can easily degrade another (like page load time or fill rate).

For prioritisation questions, show your reasoning explicitly. Whether you use a simple impact-versus-effort grid, a RICE score, or a custom framework, the interviewer wants to see that your prioritisation is anchored to business goals and customer evidence, not personal preference or the loudest stakeholder in the room.

Refinery89 operates in a technical, data-heavy space. Interviewers typically look for a few specific signals:

Comfort with ad tech concepts. You do not need to have built a header bidding wrapper yourself, but you should be able to talk fluently about programmatic advertising, eCPM, fill rate, bid density, and how publisher revenue is affected by changes in each. Brush up on these terms before your first round.

Data-driven decision making. Candidates report that interviewers push back on purely qualitative reasoning quite quickly. Come prepared with examples where you used data to define a problem, choose between options, or validate a hypothesis. If your example involves a small sample, acknowledge that directly rather than overstating the result.

Publisher empathy. The end customer here is a publisher trying to earn more from their content. Interviewers want to see that you can think from the publisher's perspective, not just from the platform's.

Clear communication across disciplines. PMs at ad tech companies spend a lot of time translating between engineering constraints and commercial goals. Show that you can make technical trade-offs legible to non-technical stakeholders, and vice versa.

Ownership and follow-through. Interviewers typically probe for what happened after you shipped something. Avoid stopping your story at launch. Talk about what you measured, what you learned, and what you would do differently.

Step 1: Learn the product. Spend time on Refinery89's public website, case studies, and any published blog content. Understand what types of publishers they serve and what their core product does differently from competing header bidding or monetisation platforms. Note down two or three things that seem like genuine product bets you could discuss in an interview.

Step 2: Refresh your ad tech vocabulary. If you have not worked in the space before, invest time learning the basics: header bidding, Prebid.js (the open-source wrapper standard), eCPM versus CPM, fill rate, demand partners, and how the programmatic auction works. AdMonsters and the Prebid.org documentation are useful public starting points.

Step 3: Build your story bank. Map your past experience to the question types listed above. For each story, know the situation in one sentence, your specific actions in a few clear points, and one concrete or directional result. Having five to six strong stories ready lets you adapt to unexpected questions without losing structure.

Step 4: Practise the product case. Candidates report that Refinery89 interviews typically include a product design or strategy case, often in take-home format. Practise working through a brief end-to-end: user, problem, solution options, metrics, and trade-offs. Time yourself so your written answer is focused and does not run long.

Step 5: Prepare smart questions. Interviewers typically respond well to candidates who ask about the team's current challenges, roadmap priorities, or how success is measured for the PM role. Avoid questions whose answers are already on the company website.

Knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR for you. It is a practical way to stay on top of all of Refinery89's open positions while you focus your energy on deep prep.

Skipping ad tech fundamentals. Many PM candidates apply to ad tech companies with a strong general product background but no fluency in programmatic advertising. Interviewers at companies like Refinery89 spot this quickly, and it is hard to recover from in a single round. Even a focused study session before your first interview makes a visible difference.

Treating 'publisher' as an abstract user. Ad tech PMs sometimes speak about publishers as a broad category rather than as real businesses with specific pressures. A small independent news site and a large lifestyle publisher have very different revenue pressures, team sizes, and technical capabilities. Bring that specificity to your answers.

Stopping your story at launch. A very common pattern is to describe a product you built and end the story at 'we shipped it'. Interviewers want to know what happened after. What did the metrics show? What did you learn? What would you do differently?

Vague prioritisation answers. Saying 'I weighed impact versus effort' without describing how you gathered evidence for impact, or how you handled stakeholder disagreement, leaves the answer feeling thin. Be specific about the process and the people involved.

Over-indexing on features, under-indexing on outcomes. In product design questions especially, candidates often jump straight to listing features. Lead with the outcome you are trying to achieve and the user problem you are solving. Features are a means, not the answer.

Not acknowledging data limits. In a data-heavy company, claiming a result based on a small sample without noting the limitation can hurt your credibility. It is better to say 'our sample was small, so we treated this as directional' than to over-claim.