How I work

Principles

A product has to solve a real problem for a person or a business and bring measurable value. Everything else — process, technology, design — serves that.

I own the product end to end: economics, team, quality and timing. So decisions are made on data, not opinions, and every decision gets a measurable success criterion.

Complex things get done in small steps. A big goal is split into testable hypotheses, each confirmed or closed within weeks, not quarters.

Research and customer development

Every product starts with conversations with the people who will use it. I run problem interviews myself and teach the team to do the same: open questions about past experience, no pitching of a solution, verbatim quotes recorded.

For one segment, 8–12 interviews are usually enough to see recurring patterns. Then comes quantitative validation: surveys, behaviour analysis in current products, support and review data.

The output of research is not a report but a list of problems scored by frequency and pain, a segmentation of users, and an explicit "we will not do this" list that saves months of engineering.

• Scripted problem interviews, 8–12 per segment
• Quantitative validation: surveys, analytics, support tickets
• Problem map scored by frequency and pain
• A list of things we will not build

From needs to stories and jobs

I describe needs through Jobs to be Done: what job a person hires the product to do, in what situation, and what outcome they expect. It keeps the team from chasing competitor features and shows the alternatives people use today.

For engineering, jobs become user stories with a clear "who, what, why" and acceptance criteria. For complex system scenarios, such as roaming of charging sessions between operators, I write use cases: actors, preconditions, main and alternative flows, failure paths.

That gives every task traceability: from an interview quote to a backlog line to a test.

Customer journey maps

I build a journey map as a working tool, not a slide. For each step: what the person does, what they see, how they feel, which data and systems are involved, where they get lost or leave.

The map rests on interview and analytics data, not on team assumptions. The most painful points become backlog priorities. For "Ya — Atom" this is how the market's core problem was found: a driver kept five apps from different operators, and a single entry into a charging session became the foundation of the product.

For B2B and clinical scenarios I draw a separate map for each role: administrator, specialist, participant. One product, different journeys.

Discovery

Discovery is a continuous process, not a phase before development. Every week the team tests several hypotheses: prototypes, interviews, A/B tests, data analysis. A hypothesis is phrased so it can be disproved, with a metric and a deadline.

Solutions pass four checks: do people need it, can they use it, can we build it, and does it work as a business. If any answer is "no", the hypothesis is closed before money is spent on it.

The product manager, the designer and the lead engineer do discovery together. The engineer is there to see technical constraints and opportunities the product manager cannot.

Delivery

Delivery is built around short cycles and continuous deployment. Small increments ship to production often, behind feature flags, with monitoring and a rollback that takes minutes. A quarterly release is a risk, not a celebration.

The mandatory minimum: code review, automated tests on critical paths, a staging environment with production-like data, and a production readiness checklist. At Neurocode we add monitoring with alerts, because devices run on people 24/7.

Process metrics I watch: lead time from idea to production, release frequency, rollback rate, time to recover from an incident. They are more honest than completed story points.

Where strong solutions come from

A mediocre product appears when the team copies the market and burns down the backlog. A strong one appears when the team understands the problem deeper than competitors and is ready to drop the obvious answers.

I look for places where users tolerate friction because "everyone does it this way". Plug&Charge at Atom came from a simple question: why should a driver press anything to start charging if the car and the station can negotiate on their own. That question grew into a patent and a key product feature.

At Neurocode the point was transparency: instead of a "black box" with a state score, we showed the metric formulas and the raw signal. That made the platform interesting to business and science, not only to gadget enthusiasts.

Three things are needed: team time for research without an immediate result, the right to be wrong, and a habit of testing bold ideas cheaply before investing for real.

Design approach

Design starts not with screens but with the product language: what entities are called, what states objects have, what the user should understand without a manual. This vocabulary is fixed before mockups and used in the interface, the code and the documentation.

Then the design system: tokens, components, spacing and typography rules. A system done well once saves weeks on every new screen and keeps the product coherent when several teams work on it.

Mockups are tested on people before development: hallway tests, Figma prototypes, task timing. A beautiful interface where the user cannot find the button is not done.

Platform architecture

A platform differs from a product in that other products, including third-party ones, must be built on it. So I lay out the architecture with explicit domain boundaries, stable API contracts and separate circuits for different clients: B2C, B2B, partners, clinics.

Principles I hold to: a single source of truth for every entity, events instead of direct calls where resilience matters, backward-compatible APIs, observability from day one. Where standards exist, such as OCPI for charging roaming, I prefer them to proprietary protocols.

Architecture decisions are recorded in short notes: context, options, choice and consequences. A year later this is the only way to understand why the system looks the way it does.

From business to technical requirements

The business states the goal and the constraints: how much, by when, with what economics. My job is to translate that into requirements an engineer can estimate and build without losing the meaning.

The path: business goal, then user scenarios, then functional requirements with acceptance criteria, then non-functional ones: load, security, availability, data retention. For every requirement it is clear which goal it grew from.

Processes that involve several roles and systems I describe in BPMN: roles in lanes, events, gateways, integration points. Such a diagram reads equally well for business and engineers, and object states and APIs follow from it directly.

• Business goal and constraints
• User scenarios and use cases
• Functional requirements with acceptance criteria
• Non-functional requirements
• BPMN for cross-role and cross-system processes

AI in a product director's work

Since 2025 AI has been part of every stage of my product work: from parsing interviews to shipping to staging. Not experiments for fashion's sake, but specific places where days used to go and now hours do.

Analytics. Interview transcripts, support tickets, app-store reviews and behaviour logs flow into one store, and once a week a model builds a digest: recurring problems, frequency, quotes, shifts against the previous week. The product manager no longer reads three hundred tickets by hand; they read one page and spot-check. Product metrics are requested in plain language: "retention by cohort for the quarter, split by channel" becomes SQL and a chart in a minute instead of a two-day task for an analyst.

Discovery. At the start of a hypothesis the model gathers context: what users said on the topic, what competitors do, which constraints are already fixed in the architecture. After interviews, draft JTBD, user stories and acceptance criteria are generated from the transcript and edited by a person rather than written from scratch. A prototype for a hallway test is built in Figma and in code within hours. As a result the team tests more hypotheses per week, and the cost of checking one idea fell several times over.

Time to market. Engineering runs in agent-assisted mode: Claude Code gets a task with repository context, writes code, runs tests and deploys to staging; Codex and GPT models provide a second opinion and an independent review. Typical tasks — screens, integrations, migrations, infrastructure — reach staging the same day. The cycle from a described task to a verifiable result shrank from days to hours, and the site you are reading was built and shipped this way in one working day.

Testing. The agent writes automated tests for critical paths together with the feature, runs scenarios in a browser, takes screenshots in the required sizes and themes, reads incident logs and proposes a cause. Manual regression testing that took a day before a release became a minutes-long run plus a human spot-check.

Rules. A person sets the task, defines the boundaries, reads the result and is accountable for it. Every change goes through review, production is deployed only through git and the pipeline, the agent has no access to production data or money, and decisions on architecture, security and priorities stay with people. The model's conclusions from data are always checked against the sources before they reach a decision.

What else helps a product manager: quick competitive reviews and teardowns of other products from screenshots, drafts of specifications, decks and partner letters, translation and localisation, image generation and Figma AI tools for visual options, meeting preparation from past minutes, summaries of long threads and documents. One rule throughout: AI does the draft and the routine, a person makes the decision.

• Weekly digest of interviews, tickets and reviews instead of manual reading
• Product metrics on request in plain language
• JTBD, user stories and acceptance criteria drafted from the transcript
• A test prototype in hours, in Figma and in code
• Task to staging in hours instead of days (Claude Code, Codex, GPT)
• Automated tests, browser runs and incident analysis by the agent
• Review, git pipeline, no access to production data

Team and mentoring

I build teams around the task, not the org chart: the product manager, the designer and the engineers work together from the first interview to the release. I hire people who ask questions and can say "this will not work".

I grow product and engineering leads inside teams through regular decision reviews: what was known, what the options were, why this one was chosen. It is faster than any course.

Separately, I mentor product managers and technical leaders outside my companies and lecture in educational programmes. If you need help with a product, a strategy or a team, write to me.