From HR Operations to Product-Led Platforms: Dmytro Zykov on Building Enterprise Digital Products Inside the ANCOR Ecosystem

Intro: Most large companies do not become “digital” simply by automating what they already do. The larger shift comes when a recurring process gains clear ownership, a coherent domain model, analytics and a release rhythm that can survive organisational growth. Dmytro Zykov has served as CTO at ANCOR since 2014. In this interview, he discusses GetWork, Future Hub, the transformation of Experium and the corporate startup studio launched in 2022. The sequence matters: the EdTech work at Future Hub came before the Experium transformation, while his work on Wikium overlapped with both.

Interviewer: “Digital transformation” gets attached to almost any internal software project these days. What’s actually different about a real product versus automation with better branding?

Dmytro Zykov: Ownership, mostly, and what happens after launch. Automation takes a manual process and makes it faster — genuinely useful, but it stops there. A product has a domain model, defined user segments, someone accountable for it, a roadmap, and a release rhythm. It has to keep evolving, and it has to hold up under use cases nobody planned for at the start.

Recruitment is a clean example. A basic tool stores CVs, tracks vacancies, spits out a report. A platform connects the whole chain — intake, sourcing, parsing, the candidate database, search, matching, recruiter workflow, communication history, response handling, reporting — as one connected thing. Once those pieces talk to each other, the system stops merely supporting the process. It starts shaping how the organisation actually works.

That was the objective of the Experium transformation I worked on from 2022 to 2024: treat recruitment as a repeatable, data-generating process and develop the platform around it, rather than bolt features onto an internal system.

Interviewer: You make recruitment sound almost like a systems-engineering problem rather than an HR one.

Dmytro Zykov: It is, once you’re past a few hundred hires a year. Vacancies, candidates, clients, recruiters, stages, documents, communication events, sources, interviews, offers, SLA states, reporting requirements — all of it connected. Treat those as separate tables and separate screens and you get fragmented automation. Model them properly and you get a platform.

The hard part is letting data move through the system without turning into noise. A CV isn’t just a file sitting in storage — by the time it’s useful, it’s a parsed document, a skills profile, a source event, a potential match, a communication thread, and eventually an entry in the analytics feeding future hiring plans. Get the architecture wrong and the organisation gets slower every time it grows. Get it right and you scale recruitment without scaling the headcount coordinating it.

Interviewer: At the architecture level, then — what does Experium actually look like under the hood?

Dmytro Zykov: A product-led HR-tech platform built around recruitment operations, if I had to summarise it in one line. The domain objects are fairly clean: vacancy, candidate, resume document, recruiter action, funnel stage, communication event, client account, task state, SLA state, analytics snapshot. Around those, the product modules — resume ingestion and parsing, candidate search, matching, recruiter workflow, auto-response handling, reporting, integrations, and a predictive layer on top of task performance.

None of that is a feature list assembled after the fact. Resume parsing feeds search; search feeds matching; matching shapes recruiter prioritisation; recruiter actions generate the operational data that feeds analytics; analytics then informs planning. Once a platform is wired that tightly, it stops being automation and becomes something the business actually leans on to make decisions.

Interviewer: What did you personally own in that transformation, versus what the wider team drove?

Dmytro Zykov: At Experium, my formal remit covered changes to the technical structure, platform development and the introduction of AI and other technologies. In practice, that meant helping move delivery from a project model toward product ownership: defining core domains, the boundaries between modules and the shared foundations that should not be rebuilt team by team.

The delivery model changed alongside it. We moved away from a single request queue toward eleven product teams, each owning a domain with its own requirements and accountability — a genuinely disruptive change for an organisation used to project-style delivery, and one that took real internal negotiation to land.

We also introduced predictive components for task performance and prioritisation. I would describe those as decision support, not autonomous decision-making. The work had to be judged against release speed and commercial results as well as technical cleanliness.

Interviewer: Moving from a request queue to eleven autonomous teams sounds like exactly the kind of change that gets resisted internally. Was it?

Dmytro Zykov: It was. The first version of the change exposed why: we had given teams domain names and backlogs, but cross-domain work still entered through the old central request queue. Search and matching could own its roadmap on paper, yet anything touching candidate profiles, communications or analytics still waited for several approvals. We had changed the org chart without changing the decision path.

Our first response was a weekly coordination meeting. Within a few cycles it had become another queue: everyone attended, but no one owned the final trade-off. We reversed that. Each domain got a named owner, clearer interface contracts and authority to prioritise its own backlog; only platform-wide conflicts went to the central group. Some stakeholders lost the ability to move a request by escalation, and teams gained accountability for outcomes rather than ticket volume. That was the part that took real negotiation.

Interviewer: Give me the practical difference between shipping a feature and building what you’d call platform capability.

Dmytro Zykov: A feature solves one visible problem in front of you. A capability creates leverage you can reuse for problems you have not hit yet. A new report is a feature. An event model that captures recruiter actions, funnel movement, communication delay and task outcomes is a capability: once it exists, reports, dashboards, forecasting models and operational alerts can all use the same foundation.

Same logic with resume processing. Upload-and-store is storage. Extract structured data, normalise it, connect it to candidate profiles, make it searchable — now it’s a capability. Companies that keep funding features without investing in capabilities end up with something that looks busy in a demo and doesn’t scale in production.

Interviewer: “Predictive analytics” gets thrown around loosely in enterprise pitches. What did it actually mean here, in concrete terms?

Dmytro Zykov: Fair — it’s often vague to the point of meaninglessness. The useful question was never “can we use AI,” it was “which operational decisions get better with a stronger signal.” In recruitment there’s no shortage of candidates for that: task performance, workload, response timing, candidate movement through the funnel, conversion between stages, recruiter capacity, likely bottlenecks before they hit.

I’d draw a hard line, though: this isn’t an autonomous decision-maker, and it shouldn’t try to be — that would be both technically fragile and organisationally the wrong call. Think of it as ranking, scoring, forecasting and prioritisation on top of historical operational data, feeding a human who’s still making the call.

Interviewer: How do you stop that predictive component from turning into a black box that recruiters just stop trusting?

Dmytro Zykov: Being explicit up front about what the system is and isn’t allowed to do. There’s a real difference between a model suggesting a priority and one making a consequential call, and in HR-tech I want the former every time — surfacing risk, ranking tasks, flagging bottlenecks, forecasting workload, but leaving the final read to the human operator, especially anywhere the outcome touches a person’s job prospects.

Traceability comes next: which data fed a given score, what triggered it, how fresh it is, whether a recruiter can actually see why something was prioritised. Different audiences need different depths of explanation — a recruiter needs a reason they can act on, a product manager needs to know if the signal’s actually improving the workflow, engineering needs logs and drift monitoring. Skip that structure and analytics turns into theatre — it can look sophisticated in a slide and still not earn anyone’s trust.

Interviewer: You worked on the Experium transformation from 2022 to 2024. What moved during that period?

Dmytro Zykov: During the 2022–2024 transformation, the release cycle fell from roughly six months to about one and a half months. Over the same period, annual revenue associated with the platform increased from about $1.2 to $1.8 million. Those figures show that the technical changes coincided with a material business change; they do not prove that architecture alone caused it.

The structural changes included a redesigned platform, predictive analytics for task forecasting and the eleven product teams. For me, the relevant result was the combination: the organisation could release product changes faster and operate them at larger scale.

Interviewer: Which of those changes do you think actually drove the numbers, versus just correlating with them?

Dmytro Zykov: Honestly, no single lever explains it — it’s the combination, and I’d be suspicious of anyone claiming otherwise. Faster releases need architectural modularity, clear ownership and fewer cross-team dependencies. Revenue growth needs product changes that touch real business workflows, not just cleaner code. Predictive analytics needs clean event data and a context where the output is actually useful. Product teams need domain boundaries and leadership willing to defend them when a stakeholder pushes back.

Pull one piece out and the rest weakens. You can stand up product teams on a monolithic architecture and watch them block each other constantly. You can build a forecasting model on inconsistent event data and watch nobody trust its output. Redesign the architecture without changing how the business actually uses the platform, and the impact caps out fast.

Interviewer: You came from cloud infrastructure before any of this. Does that background actually show up in how you approach product work now?

Dmytro Zykov: More than people expect. Before product-led platforms, I was in Linux servers, Kubernetes, Helm charts, Ansible, monitoring — infrastructure work that trains you to think in systems rather than screens. You stop seeing a product as user stories and start seeing reliability, deployment, dependencies, permissions, data flow, operational risk.

A recruitment platform, an EdTech product and a cognitive training app look nothing alike at the interface. Underneath, they face the same core questions: how is data structured, how are services separated, how are releases managed, and how does the product evolve without breaking? Strong product architecture sits between business, engineering and operations. Left purely to business, it turns into a slide deck. Left purely to engineering, it may never move the company forward.

Interviewer: Future Hub predates the Experium transformation in your timeline. What did that experience contribute to your later platform work?

Dmytro Zykov: It showed me that productisation logic travels. HR-tech and EdTech are different markets, but both need profiles, journeys, behavioural events, progress or funnel tracking, analytics, access rights and, in B2B use, enterprise integration.

At Future Hub, I worked on analytics, hypothesis formation, testing, scaling, distribution and the product architecture, with micro-learning as a core product concept. The platform reached approximately $2 million in annual revenue. The important link to Experium is not that the products were the same; it is that both required a repeatable operating model around data, experimentation and ownership.

Interviewer: What is genuinely hard about turning expert-led learning into a scalable digital product?

Dmytro Zykov: That became clear in the first version. We had digitised the offline model too literally: full-length event recordings, organised mainly by speaker, with the expectation that the expert’s authority would carry the experience. The content was strong, but the early usage pattern was blunt: people sampled the opening and rarely continued to a second item. What worked in a room had become a catalogue.

We changed the unit of the product. A recording stopped being the finished asset and became source material for shorter learning sequences with a clear next step, progress tracking and a reason to return. For corporate clients, learner access also had to be separated from reporting and administration. That correction is when Future Hub started behaving like an EdTech product rather than an archive.

Interviewer: What had to work together for that correction to become a platform rather than another content redesign?

Dmytro Zykov: Content structure came first: courses, speakers, formats, metadata and rights had to be consistent enough to support search and curation. The product then needed a usable picture of the learner — interests, history, progress, subscription status and, in B2B, corporate affiliation — so that the next recommendation or learning path could respond to behaviour rather than a generic catalogue.

We tracked completion, early drop-off and cohort return behaviour alongside commercial measures. Company accounts, admin access and integration into a client’s own systems were designed with that data model, not added at the end. Subscriptions, corporate access and content packages then had something coherent to monetise. Built together, those elements form a product; built separately, they produce a content site that happens to take payments.

Interviewer: You’ve now described HR-tech, EdTech and cognitive products as sharing a “deeper challenge.” What is that, specifically?

Dmytro Zykov: That in all three, the platform is shaping behaviour, not just storing information — which raises the bar on responsibility considerably. HR-tech touches someone’s work opportunities. EdTech shapes learning paths and career development. Cognitive products can shape how someone understands their own mental state. Different domains, same underlying obligation: understand data quality, consent, and where overclaiming starts.

A platform can support a decision without pretending to make a perfect one. A learning product can personalise a path without implying clinical effect it hasn’t earned. The more a platform actually influences the people using it, the less optional governance becomes.

Interviewer: That’s close to an AI-governance conversation. How do you build that in without it becoming a bottleneck that slows product teams down?

Dmytro Zykov: The wrong way is bolting it on as a late-stage compliance review — that creates friction and resentment in roughly equal measure, and teams route around it the moment they can. The better way is designing it into the operating model from the start: if a platform uses predictive components, the team building it should already know what data feeds it, where it came from, who can see the output, and when a human has to step in — before any of that becomes a dependency baked into the roadmap.

Done that way, governance doesn’t slow anyone down — it removes a set of decisions teams would otherwise be re-litigating every sprint. In a mature organisation it isn’t a gate outside the roadmap. It’s a line item inside it.

Interviewer: What mistakes come up repeatedly when enterprises try to bring AI or predictive analytics in-house?

Dmytro Zykov: Starting with the model instead of the workflow tops the list — “what can we predict” instead of “what decision needs a better signal.” Weak data modelling follows close behind: build prediction on top of messy, inconsistent event data and the whole thing is unstable no matter how good the model architecture is.

Treating accuracy as the only success metric is another one — in an enterprise system, usefulness usually matters more than a clean benchmark number. Does the signal actually get acted on? And teams routinely under-invest in what happens after deployment. A model that performed well in testing can behave very differently once users start adapting their own behaviour around it, and most teams stop watching right when that starts mattering.

Interviewer: How would you actually measure whether an internal productisation effort worked, rather than just declaring victory?

Dmytro Zykov: Across a few dimensions at once, not just feature delivery. Release cycle time and deployment frequency tell you if speed is real and sustainable. Adoption tells you whether anyone’s actually using the thing. Workflow metrics tell you whether the underlying business process actually improved, and revenue or retention tells you whether any of that mattered commercially.

For Experium specifically, the release-cycle and revenue numbers are the headline, but I’d also weight recruiter productivity, funnel velocity and response time — the operational texture underneath the topline figures. For something like Future Hub, activation, completion and corporate adoption tell the more honest story.

Interviewer: The corporate startup studio began operating in 2022. How does that connect to everything we have discussed?

Dmytro Zykov: It sits between corporate strategy and venture-style product development. Its role was to identify promising projects and integrate them into the wider ecosystem rather than leave them as isolated pilots. We brought six projects into cooperation — Experium, GetWork, Podbor, PLANKA, Sales for Management and HRFile — with roughly $10 million in associated investment. The portfolio combined existing products with newer projects. GetWork, for example, had already been developed and launched between 2016 and 2018; the studio later brought it into the wider portfolio and integration model.

The evaluation question is different from a standalone startup, though. It’s not just “can this exist” — it’s whether it fits the ecosystem, whether it can scale through corporate channels, and whether the business model survives past the pilot phase once the initial enthusiasm wears off. That needs both entrepreneurial instinct and enterprise judgment at the same time, which is a harder combination to find than either alone.

Interviewer: You led GetWork from idea to market between 2016 and 2018. What did that add to how you think about platform development?

Dmytro Zykov: Another version of turning a workflow into a platform, this time freelance cooperation between companies — task setting and performance monitoring through a personal account, which meant building around roles, permissions, performance tracking and the financial model simultaneously rather than in sequence.

My remit covered market and competitor analysis, technical specifications, financial modelling, the MVP, testing and launch. The experience reinforced the same design lesson: a recurring process with multiple roles, data flows and transactions can become a product only when the architecture and business model are designed together.

Interviewer: Your work on Wikium began in late 2018 and overlapped with ANCOR, Future Hub and later Experium. Does it connect to the recruitment and EdTech story, or is it a separate chapter?

Dmytro Zykov: It connects through the same lens, even though the domain looks completely different on the surface. Wikium was a cognitive training platform with millions of users — user profiling, exercise selection, engagement mechanics, personalisation, retention, B2B sales, scientific input into the methodology. Recruitment and cognitive training don’t share a market, but they share the same underlying questions: how does someone enter the system, how is their profile understood, how does the platform decide the next action, how do you measure whether any of it’s working.

Wikium grew to more than seven million users. My work there included scientific research, B2B sales and neural-network-based selection of training courses. Congru.me (Max Mentality), which I founded and led from 2020 to 2021, was a separate cognitive service using neural-network logic and an AI chatbot. I would not fold either product too tightly into the Experium story, but they show the same interest in platforms where data, personalisation and user behaviour have to work together.

Interviewer: After everything we’ve covered — recruitment, EdTech, cognitive training — what does “product architecture” actually mean to you, stripped of the jargon?

Dmytro Zykov: The structure that lets a product grow without losing coherence, basically. The domain model, module boundaries, data flows, integration points, analytics, user roles, release model, governance — and the commercial logic sitting underneath all of it, which capabilities create value and which metrics actually matter.

A product without architecture becomes a pile of features. Architecture without product thinking becomes an elegant system solving the wrong problem. The job is holding both at once, and in enterprise environments specifically, every new stakeholder or integration adds pressure fast enough that skipping this isn’t really an option.

Interviewer: Last question — how should a large company decide whether an internal process is actually worth turning into a platform, versus just automating it and moving on?

Dmytro Zykov: I would start with frequency and leverage. A process becomes a serious platform candidate when it recurs often, involves several roles and permissions, produces data that can improve later decisions, and has a credible link to revenue, margin or retention. Reuse matters as well: if the capability can serve another team, client or adjacent product, the economics change.

Recruitment, corporate learning and freelance coordination met that test for different reasons. Where those conditions are absent, automation may be the more disciplined choice. A company should not build a platform simply because the process is important; it should do so when continued product ownership can create compounding value.