Dual PM and PO on an analytics SaaS
What the dual PM and PO seat on Veroxos meant, and how real-time KPIs cut manual reporting by 60%.
From December 2021 to December 2025 I was a senior technical project manager and product owner at TEO International / StableLogic, delivering remotely from Islamabad into UK and European programmes. One of those programmes was Veroxos, an analytics SaaS. I held both seats: project manager and product owner. Manual reporting on that product dropped by 60 percent.
This note is about what that dual seat actually was, and what it was not. It was not two job titles on a slide. It was one person accountable for the roadmap and for the release, on a product whose value was the reporting people were still doing by hand.
The wider picture of that employment — CSCS, Veroxos, and Firstcom Universe — is on the enterprise delivery page. Veroxos is the one I want to unpack, because the dual role is the part recruiters and product managers usually misread.
What I was accountable for
As product owner I owned the roadmap, the feature choices, and the real-time KPIs the product was supposed to put in front of people. As project manager I owned scope, sequence, risk, and whether a release actually landed. Splitting those across two people is normal, and often right, on a large programme. On Veroxos the useful move was to keep them in one seat so a KPI decision could not drift away from the delivery plan that had to produce it.
The practical effect was fewer translation layers. A stakeholder asking for another report was talking to the person who also had to say what slipped if that report jumped the queue. On Veroxos the product's job and the project's job were the same job: replace hand-built reporting with figures people could trust during the week.
The 60 percent figure is the outcome I will stand behind: 60 percent less manual reporting. I will not dress it up with a measurement method I am not putting in this note, and I will not apply that percentage to any other product. It belongs to Veroxos.
Why reporting was the product problem
Analytics SaaS fails in a specific way. The dashboards exist, and people still export to spreadsheets because the dashboard does not match the question they are asked on Monday. Manual reporting is not a training issue when it is the only way to answer the real question. It is a product gap, and it is also a delivery gap, because every extra extract becomes a recurring task for an analyst who should have been doing something else.
The work, then, was not "add more charts". It was to decide which questions deserved a real-time KPI, which requests were one-off and should stay one-off, and which manual packs existed only because nobody had put the source and the definition in one place. Roadmap conversations were about those choices. Feature work followed the choices. The release plan existed to get the chosen KPIs into use, not to ship a catalogue.
That is also why the dual seat mattered. A product owner who never sits in the release conversation will keep accepting report requests. A project manager who never owns the KPI definition will treat every request as scope and try to deliver all of it. Either pattern preserves the manual pack. Holding both meant I could say no to a report and still be the person who owed a date.
What I carried across the other two programmes
Veroxos did not sit alone. On CSCS, a UK construction compliance programme, performance was 35 percent faster, support queries fell by 25 percent, and more than £1.5 million was delivered on time. On Firstcom Universe, a unified communications programme, efficiency improved by about 25 percent, budgets ran up to $1.8 million, and the cross-functional teams were 30 people or more. Those are separate outcomes. I mention them because they were the same years and the same kind of accountability: a senior TPM who also had to make product calls, with Agile, Jira, and Power BI as the working tools rather than as a methodology poster.
CSCS was compliance scope and operational performance. Firstcom was coordination across a large team and a real budget. Veroxos was the decision to treat reporting as the product, not as a service desk. The thread is an outcome a sponsor can recognise.
The same instinct, on a product I built myself
Years of watching manual reporting survive a tool made me intolerant of it in my own builds. Circles Finance exists because billing windows, resource leave, and budget tracking were living in spreadsheets, and the spreadsheets drifted. I took the product owner and builder role: requirements, workflows, and a GenAI-assisted implementation with Claude Code, React, and MySQL. Timesheets, invoicing, and the budget ledger sit in one workspace so a billing cycle stays consistent. Login on that app may show Systems Ltd branding where it is used at work. The portfolio page is about the product decisions I owned, not about turning an internal convenience into a commercial story.
I am not claiming the Veroxos 60 percent for Circles Finance. I am saying the design lesson transferred. If the job is to retire a spreadsheet, the first release has to cover the cycle the spreadsheet was covering. A partial tool plus the old spreadsheet is a more expensive status quo.
TaskCue is the lighter version of the same judgment. Teams wanted shared tasks and reminders without a heavy project tool. The correct scope was capture and follow-through, not a smaller copy of Jira. Dual PM and PO work trains that reflex: every feature you add is a feature you now have to release, support, and explain. On a client SaaS that cost shows up in the team. On a personal build it shows up in whether you will still operate the thing next month.
How I would staff the dual seat again
I would only combine the seats when the product outcome and the delivery outcome are the same sentence. On Veroxos that sentence was real-time KPIs in place of manual reporting. The person in the seat also has to be able to say no and still own the date. A dual role that only collects requests is just a busier project manager. On a regulated programme I would not use this shape to skip a compliance or engineering review. CSCS did not get looser because Veroxos was lean.
What I tell other PMs
If you are asked to "be both", write down the single outcome you will be measured on, and write down the decisions you will stop running through a second person. Then protect the release. A roadmap that does not change what people do on Monday is a backlog. A release that ships the old manual process beside the new KPI has not finished.
The numbers I will repeat are the ones on the record: 60 percent less manual reporting on Veroxos; the CSCS and Firstcom results beside it; and, separately, the live finance workspace at finance.samikhanapps.com. The rest of the work is on samikhanapps.com. I compare notes with other PMs and builders on LinkedIn.