About the role

This is ContactVerse's first product management hire, and it matters more than the title suggests. We have Product Engineering and Product Design, but nobody has owned what to build and why. Requirements live in workbooks maintained by the founder, and the backlog is ordered by whoever asked most recently. You would own the requirement itself: what gets built, for whom, how we know it worked, and, most importantly, what we decline to build and why.

What you will do

• Own the requirement. What is built, for which customer, and how success will be measured. Written so an engineer can build from it without a meeting.
• Own the backlog and its order. Across Core and the industry verticals, with the reasoning visible rather than held in your head.
• Own the change process. A changed requirement is a change request referencing the original; a genuinely new one is a new requirement. The two are not the same and the history matters.
• Own packaging and entitlements. What each plan includes, with sales and finance, in a business where the marginal cost of a feature is real.
• Bring customer evidence in. From support, from lost deals, from usage. Opinion is not evidence and the loudest internal voice is not a customer.
• Say no, with a reason. The single most valuable thing this role does.
• Work with Design and Engineering as a trio. Not as a relay. You own what and why; they own how and whether.
• Define the release narrative. What changed, who benefits, and what we tell customers.
• Put the requirements estate on a proper footing. It currently lives in spreadsheets. Moving it is part of the job, carefully, without losing the reconciliation that makes it useful.

Your first year

First 90 days. A backlog that is ordered and explicable, and requirements engineers can build from without a meeting.

By six months. Plan entitlements and packaging agreed with sales and finance. Customer evidence feeding the roadmap.

By twelve months. A product function that decides what not to build, with reasons.

What you will bring

• Eight years or more in product management for B2B software, including a product sold to small and mid-sized businesses.
• Has written requirements that engineers built from without needing a meeting to interpret them.
• Has killed a feature that someone senior wanted, and can explain how.
• Comfortable with technical depth: APIs, data models and the constraints they impose.
• Has owned packaging and plan entitlements, not only features.
• Works from evidence (usage, support, lost deals) rather than from opinion.
• Has been the first or only product manager somewhere.
• Writes clearly and briefly.

Nice to have

• AI or agent products, where the output is probabilistic and the specification is harder.
• Contact-centre, communications or workflow automation.
• Experience of a platform serving multiple industry verticals.
• Has migrated a requirements estate from spreadsheets into a tracker without losing history.
• Experience of self-serve products where onboarding is the product.

What you will work with

Requirements currently live in two workbooks (Core and Tour & Travel) with change request tabs, a staffing schedule that mirrors them, and a documentation site generated from the requirement and reconciled against the code.

What this role is not

Not a project manager and not a requirements scribe. If you cannot say no to a feature, this is not the role.

How we work

The team works to a UK-aligned pattern, with the main working overlap in the evening IST. These hours are indicative and may change as the business changes; any change would be discussed rather than imposed. Development happens on company-provided remote machines. Everything is remote and nobody is in an office.

We are a small company and we write things down. Decisions are recorded, corrections are made to the source rather than to the output, and status is expected to be honest even when it is unwelcome.

Compensation and what we offer

• A long-term incentive, discussed at offer stage for senior appointments.
• Fully remote working, with company-provided equipment where the role requires it.
• A role with unusual scope for its level, because the organisation is being built rather than joined.
• Direct access to the founders. There are no layers between this role and the people making the decisions.

How we will assess you

We assess against three or four weighted signals agreed before we read a single CV, rather than against years of experience or a list of tools. Expect four stages:

• Introductory conversation with our People team. About 30 minutes, covering the role, your background and what you are looking for. This first conversation may be with an AI assistant; you will be told at the time and may ask to speak to a person instead.
• Conversation with the hiring manager. About 60 minutes, going deep on what you have done and how you think.
• A working session on a real ContactVerse problem. About 90 minutes. Not a whiteboard exercise and not a take-home test you do unpaid in your evenings.
• Final conversation with the founders. Covering fit, expectations and how we would work together.

We aim to complete the process within three weeks and to give you a decision, with reasons, within three working days of the final stage.

Equal opportunity

ContactVerse is an equal opportunity employer. We welcome applications regardless of age, disability, gender identity or expression, marital or civil partnership status, pregnancy or maternity, race, religion or belief, sex or sexual orientation. We select against the published signals for the role and nothing else. If you need an adjustment at any stage of the process, tell us and we will make it. It will not count against you.

Research consistently shows that some candidates apply only when they meet every criterion. If this role interests you and you meet most of what is listed, please apply.

How to apply

Write to career@contactverse.ai quoting reference POS-012, with your CV and a short note (a few paragraphs is plenty) on the part of this role you would most want to get your hands on, and why.