Product Strategy
Absensia: Research to Rebuild
Validating the market case for rebuilding, not just rebranding.
The Situation
Absensia had been running for a while by the time I joined JMC IT Consultant's R&D team as a mid-level system analyst, already subscribed to by a base of client companies, each with its own HR policies layered on top of the same platform.
Reworking it wasn't a one-off request, it was part of a recurring cycle at JMC: periodically stepping back from an existing product to check whether it still matched where the market had moved.
This round of that cycle landed on Absensia, and the mandate was broader than a visual refresh. It meant validating what the HR software market actually needed now, not what Absensia already had, and evaluating whether the technical infrastructure underneath it could support where the product needed to go next. Whatever came out of that would have to hold up against a product already running live subscriptions, not a blank slate.
How I Untangled It
The market side of this ran on more than one source at once: industry reports and competitor product research to see what an HR platform was expected to do now, alongside conversations with Absensia's existing clients to hear what they'd actually asked for or worked around.
Reading about the market and using it through a client's eyes turned out to surface different things, and both mattered.
Infrastructure evaluation ran in parallel, done in stages rather than all at once: reviewing the technical architecture Absensia already had, then bringing developers into the conversation to hear where the current setup actually strained under real usage, not just where it looked fragile on paper.
I ran the research side largely on my own before bringing it forward, presenting findings and a proposed direction to my manager for approval first. Once that direction was set, developers came in for a different kind of conversation: effort, technical constraints, and environment, translating a proposed direction into what it would actually take to build.
The two tracks ended up reinforcing each other rather than pulling in different directions. What the market research said the product needed lined up with what the infrastructure review said the current architecture could realistically support, which made the case for moving forward easier to make than it might have been if the two had disagreed.
All of it fed into four concrete outputs: a competitor matrix, a feature roadmap, a PRD, and UI/UX design, the blueprint the next phase would be built from.
Key Decisions / Trade-offs
Not every feature the market research surfaced could be built at once, so the roadmap had to be sequenced.
The principle behind that sequencing was straightforward but not automatic: start with whatever combined low build effort with high urgency of use, rather than chasing the most impressive feature first or building in the order features happened to be discovered.
The infrastructure question had a harder trade-off underneath it. Extending the existing architecture would have been faster to ship, but the evaluation had already shown that architecture was what limited how far the roadmap could realistically go. Rebuilding cost more time upfront, but it was the option that didn't just delay the same ceiling to a later date. That was the recommendation that went forward.
None of this meant repositioning Absensia toward a different market. The target stayed the same, mid-to-large companies, the case for the upgrade was that the same audience would get meaningfully more value out of the platform, not that the platform needed a new audience to justify rebuilding it.
How I Kept Everyone Aligned
Manager approval ran through formal presentations, not casual updates, and it wasn't a single rubber stamp: some rounds came back with revisions to how far a given feature was allowed to reach, which meant returning to the research and adjusting scope rather than defending the original version.
Developers came in through scheduled meetings once a direction had approval, focused on effort and technical feasibility rather than re-litigating the roadmap itself. The four outputs from this phase, the competitor matrix, feature roadmap, PRD, and UI/UX design, went to different audiences depending on what each one was for: management and business development read the market-facing side, developers worked from the PRD. The UI/UX design was mine as well, a first pass meant to communicate direction, which the design team would later refine for technical implementation.
Research itself pulled in one more voice beyond the usual product stakeholders: an HR consultant, brought in to make sure the feature decisions were grounded in how HR actually works, not just in what competitor products displayed on the surface. Business development wasn't part of this phase directly, their alignment comes later, in the rollout that follows the build.
Outcome
This phase of Absensia's rework closed with all four outputs, the competitor matrix, feature roadmap, PRD, and UI/UX direction, fully approved by management, including the harder recommendation: rebuilding the architecture rather than extending it.
That approval was the real test of the research, a strategic call that costs more time upfront only holds up if the analysis behind it does too.
The project is now queued to move into build. I'm still at JMC as this happens, and the version of Absensia that ships next will be built on the direction this research set, not just a coat of new branding on the same product.