Egor Chirkunov
egor@eqwise.ai

People are interested. Few of them buy.

You can bring the problem itself, not a spec for solving it. I work out what’s behind it, what can be tested, and what’s worth doing next.

Tell me about the problem

What these have in common is that there is usually no ready-made way to solve them yet. That part is my work too — from understanding the problem through to something that works.

You can arrive with a problem you can’t quite name yet.

01

There’s interest. Where it stops turning into sales isn’t clear.

What you leave withwhat to change in the offer, the messages, the pages, sales or the content; in what order; what to test before spending heavily, and what to leave alone for now.

People ask, they come by referral, they react to what you publish — and few of them buy.

The cause may be in the content. It may equally be in the audience, the offer, trust, the path to purchase, or nothing to do with communication at all.

I start by finding where the path to purchase actually breaks and what kind of check this needs. The work doesn’t end at the diagnosis: the cause that gets found is turned into specific changes.

02

The decision has to be made before you have data of your own.

What you leave witha decision map with priorities, risks and an order of implementation; where needed, the rules, specifications or prototypes a team can build on.

You’re launching a new product, a site, a new direction. There’s no data of your own yet, and dozens of decisions have to be made now.

When every option sounds reasonable, decisions turn into an argument about taste.

I gather the grounds where they already exist — in how buyers behave, in what competitors and adjacent categories do, in earlier launches and existing research — and turn them into a system you can decide inside, instead of arguing case by case.

03

The numbers show the result. They don’t explain the cause.

What you leave witha working set of measures or comparisons that shows where the result changes, plus the specific decisions or tests that follow from it.

Traffic grows and sales don’t. Scale goes up and the result barely moves. Some directions work noticeably better than others, and the usual numbers don’t say why.

Sometimes there is already enough data — one final number is the sum of several different causes.

If the existing measures aren’t enough, I build a way to see the problem first: separating things that have been mixed together, finding the comparison that matters, or creating a new layer of measurement. Only after that does it become clear what is worth changing.

04

To scale it, you first have to know what actually creates the quality.

What you leave withthe working logic written down, and a mechanism a team can use without permanent dependence on the person everything used to rest on.

The quality rests on a person: the expert does it all personally, the founder checks every important thing, or one employee knows why the process is the way it is.

Simply “automating” it is dangerous: you can remove the manual labor together with the thing the client or the business actually values.

So the source of the quality gets taken apart and written down first — rules, voice, criteria, exceptions, the order they are made in, calculations, context. Then I build the process or the tool that reproduces what matters without a person in the loop every time.

What you leave withwhat to change in the offer, the messages, the pages, sales or the content; in what order; what to test before spending heavily, and what to leave alone for now.

People ask, they come by referral, they react to what you publish — and few of them buy.

The cause may be in the content. It may equally be in the audience, the offer, trust, the path to purchase, or nothing to do with communication at all.

I start by finding where the path to purchase actually breaks and what kind of check this needs. The work doesn’t end at the diagnosis: the cause that gets found is turned into specific changes.

What you leave witha decision map with priorities, risks and an order of implementation; where needed, the rules, specifications or prototypes a team can build on.

You’re launching a new product, a site, a new direction. There’s no data of your own yet, and dozens of decisions have to be made now.

When every option sounds reasonable, decisions turn into an argument about taste.

I gather the grounds where they already exist — in how buyers behave, in what competitors and adjacent categories do, in earlier launches and existing research — and turn them into a system you can decide inside, instead of arguing case by case.

What you leave witha working set of measures or comparisons that shows where the result changes, plus the specific decisions or tests that follow from it.

Traffic grows and sales don’t. Scale goes up and the result barely moves. Some directions work noticeably better than others, and the usual numbers don’t say why.

Sometimes there is already enough data — one final number is the sum of several different causes.

If the existing measures aren’t enough, I build a way to see the problem first: separating things that have been mixed together, finding the comparison that matters, or creating a new layer of measurement. Only after that does it become clear what is worth changing.

What you leave withthe working logic written down, and a mechanism a team can use without permanent dependence on the person everything used to rest on.

The quality rests on a person: the expert does it all personally, the founder checks every important thing, or one employee knows why the process is the way it is.

Simply “automating” it is dangerous: you can remove the manual labor together with the thing the client or the business actually values.

So the source of the quality gets taken apart and written down first — rules, voice, criteria, exceptions, the order they are made in, calculations, context. Then I build the process or the tool that reproduces what matters without a person in the loop every time.

You don’t have to know in advance what you need.

For problems like these there’s often no process to follow. The first question is how to solve this one at all; where no approach exists, I build one for the task.

If it looks like you need social media,
I don’t start with a content calendar.
If you want to automate an expert’s work,
I don’t start with an AI agent.

What looks like the solution at the start is usually just a hypothesis about where the problem is.

Sometimes the way to solve it requires finding data that is missing. Sometimes it means inventing a new measurement, writing down expert knowledge, building a prototype, or building a tool. One task needs data; another needs rules, a prototype or a system. The method answers to the task, not the other way around.

You bring the problem. I work out what it takes to solve this one — what to understand or test, what to change or build — and carry the work through to a result you can use.

If the task is already well defined and you just need someone to execute a finished spec, a specialist will probably be simpler and cheaper.

You end with something you can act on.

A one-time task

A decision

What to do. In what order. Why this option beats the alternatives. What it rests on. Where the risk remains. What to watch to know whether it worked.

A task that keeps coming back

A working mechanism

If the same question or the same work returns, the way of solving it becomes a mechanism you can use without working it out from scratch each time.

First comes a way to solve this particular task. After that, the form of the result depends on whether it happens once or keeps coming back.

A decision

  1. Decision map
  2. Launch plan
  3. Change priorities
  4. Specification
  5. Prototype
  6. Test plan

The form depends on the task.

A working mechanism

  1. Radar
  2. Self-updating database
  3. Dashboard
  4. Production pipeline
  5. Process
  6. A tool for the team

Built for the specific task.

Talk about which form you need

In each of these, the first thing to invent was how to solve it at all.

The end forms differ: a product system, a decision map, a market radar, a priority model. What they share is that no ready-made method existed that could simply be executed.

PIPELINE

How to increase volume when the quality rests on something hard to describe

The source of the quality had to be described first. Only then could it be scaled.

Source

expert model

  • voice and tone
  • rules and constraints
  • product logic
  • client map or reading

System

personalized reading pipeline

1context
2generation
3parsing
4layout
5review
shared context · configuration · templates

Output

finished personal document

  • text shaped around client data
  • one coherent reading
  • typographic PDF
  • saved client history
shared contextevery section is produced as one coherent reading
layout follows textthe design adapts to length without changing the content
configuration over codeproducts, sections, rules, and templates are set separately
products
9 types of personalized product
pipeline
calculation → generation → normalization → typographic layout
result
a finished personal PDF product
handover
a non-technical operator can run the system

One specialist’s personal work took several hours per piece, and it was valued for exactly that: an individual voice, the logic of interpretation, precise calculations, and the sense that the result was made for one particular person.

So the task was never “add AI.” What had to happen first was writing down what had existed as a person’s craft: the rules, the voice, the psychological logic, the calculations and the criteria for quality.

After that I built a system that brought together the calculations, the generation, the checking, the typographic PDF layout and the operator’s interface.

FIELD

How to make a hundred decisions before the first day of sales

There was no data of their own yet — so the first thing to build was a way to decide without it.

1 AUDITS AND OBSERVATIONS

FIELD
jewelry houses · DTC · fashion · automotive
FOCUS
trust · choice · purchase · aftercare

Observation map

supportneutralrisk point

The test is not “beautiful or ugly,” but whether the experience helps people choose, builds trust, answers doubts, and supports the purchase.

2 PATTERNS AND FINDINGS

SUPPORTS
moves that can be carried across
GAPS
opportunities the market leaves unused

Key categories

  • Buyer and motivationgift · self-purchase · uncertainty
  • Product and offerprice · materials · personalization
  • Path to purchasesearch · comparison · service · trust
  • Market and contextcountry · channels · cultural codes
  • Hypotheses and risksgaps · assumptions · limits

3 RANKED RECOMMENDATIONS

PRIORITY
start with decisions that remove the main risk
SEQUENCE
launch → test → grow

Implementation plan

  1. 1
    TRUSTtransparency · reviews · service
  2. 2
    CHOICEscenarios · prices · gifts
  3. 3
    ECOSYSTEMone framework · distinct sub-brands
  4. 4
    GROWTHmetrics · tests · personalization
marketmap of competitive moves
buyermotives and barriers
systemrules and patterns
launchsequence of decisions
field
39 brands and adjacent categories
questions
105 strategic questions
academic base
59 academic sources
result
127 prioritized decisions with evidence, risks and phases of implementation

A new ecosystem of six brands had no history of its own buyers’ behavior, and the key product and UX decisions were needed before development.

I assembled the grounds from competitive audits, academic sources, buyers’ own words and the national context, then turned them into a single system of decisions — with priorities, risks, rules and prototypes.

The research became not a report about the market but a working architecture to design and launch the product from.

TRACE

How to choose new locations when the competitors’ market is barely visible from outside

A way to see the market at all had to be invented first. Then that way became a working system.

1 PUBLIC STATUSES

A station exposes a simple public status. The system turns it into an observable layer of the market.

AVAILABILITY

how many devices are available now

MOVEMENT

rental, return, and changes in availability

CONDITION

whether a station is active and its capacity changes

CONTEXT

city, location, category, and opening hours

2 METRIC RECONSTRUCTION

From a single status to market movement

AvailabilityRhythmDensityGaps

The comparison tracks not only station count, but how availability, activity, and coverage change from city to city.

3 PLACEMENT DECISION

  1. low availability in an area of steady demand
  2. an active market with insufficient coverage
  3. a transit location with a long wait
  4. high footfall but weak capacity
  5. a seasonal area suitable for a controlled test

Test the market signal first. Then decide on placement and spending.

OPENthe visible layer of data
TRACEchange over time, not a static snapshot
PLACEfrom signal to the next test
coverage
over 60,000 stations across several competitors in several countries
refresh
every 30 minutes
method
public statuses → reconstructed measures
result
an interactive dashboard for placement decisions
time to launch
28 days

The operator could see its own network but could not compare it with competitors on the same measures.

No ready source for that comparison existed. I found an open signal the market’s movement could be reconstructed from, and built a system that regularly turned public station statuses into comparable measures.

What came out of it was a continuously updating picture of the market and an interactive tool for placement decisions.

NETWORK

How to turn thousands of conversations into decisions rather than one more stream of data

Collecting was only the way in. The value came from the system that turned noise into the next action.

DECISION MAP: FROM SIGNAL TO ACTIONEach circle is a pattern that recurs in audience conversations. Size shows signal strength; position shows proximity to a practical decision.
closer to a decision↑ high↓ lowsignal → durable opportunity
growth pointsstable contextweak routescircle size = signal strength
sources
9 platforms
volume
around 40,000 discussions a month
structure
24 meta-themes · over 200 sub-themes · movement over time
result
priorities for product, language, communication and content

The product needed to know what different parts of the audience cared about, in what words they said it, and which topics were growing or fading.

Reading the platforms by hand didn’t scale, and a plain feed of matching posts only added to the noise.

I built a chain that selected the relevant conversations, extracted the signals that repeated, gathered them into stable themes, and turned those into priorities for the product and for communication.

Answers got cheaper. Decisions did not.

A plausible answer takes a minute. The harder part is knowing which question actually matters here, what it takes to solve it, and what to change or build once you know.

  1. What needs to change

    The starting point is the business situation, not a method: what is happening now, and what result or decision is actually needed.

  2. How this could be solved at all

    I settle on an approach for this particular task. Where no ready one exists, I assemble it: research, a new system of measurement, writing down expertise, a prototype, a tool — separately or together.

  3. What has to be learned or written down

    I gather the missing signals and data, or turn tacit human knowledge into rules you can already work with.

  4. What survives checking

    I compare versions, sources, decisions and trade-offs. Plausible does not become true by sounding good.

  5. Which decision gets made

    I set down what to do, in what order, why this option is stronger than the ones beside it, and what risk remains.

  6. What working form it turns into

    A decision shouldn’t stay text. Depending on the task that can be a specification, a prototype, a decision map, a process, a dashboard, a production pipeline or another tool.

  7. Handover and checking

    The result stays with you and has to work without a permanent dependence on me. The test is agreed before the work starts, not fitted to it afterwards.

AI inside the work: it speeds up search, collection, labeling, processing, prototyping and production where that is warranted. The choice of method, sources and alternatives, the final decisions, and responsibility for the result are not delegated to a model.

Where the limits are

01 / Few traces

A confident answer where the data doesn’t support one.

Sometimes the honest result is not a decision but a precise plan of what still needs to be learned and where it can be checked.

02 / One good-sounding version

A hypothesis does not become proof by sounding good.

Confirmed, likely and unknown stay separate layers.

03 / Business results

I don’t promise growth, sales or payback that depend on more than my work.

I am accountable for the quality of the grounds, the recommendation, the mechanism I build, and a check you can understand.

04 / The cost of being wrong

Not every question is worth its own project.

If being wrong is cheaper than working it out, the rational move is sometimes a small test and a look at the result.

One person holds the whole problem

My name is Egor Chirkunov. For eleven years I ran my own production company; the clients included Xerox, Microsoft, Beeline and Rostelecom, and they came back with new work for years.

I build systems for hard creative and analytical work. Among them: organizing the work of a narrative team of around 50 people, competitor tracking from public sources, and research systems and tools that turn complicated manual work into a process that can be repeated.

Directing

I read an audience, gather scattered parts into a whole, and carry the result through to action.

Psychology

I read motives, barriers, language, and how people decide.

Research discipline

I test plausible versions against the alternatives and don’t hide where the evidence stops.

Engineering

I turn the way of solving it into a working tool, process or system.

These aren’t four services. They’re the reasons one hard problem doesn’t have to be cut up between several contractors.

Two or three sentences is enough to start.

  • “People ask, but they rarely buy.”
  • “We launch in three months and we’re arguing about almost everything.”
  • “The numbers look fine, but the business doesn’t feel it.”
  • “The whole process rests on one person.”

How the work starts

  1. You write two or three sentences about what’s going on.
  2. In one conversation we check whether there’s a useful problem here for me.
  3. Before anything starts, we set out exactly what you get, the limits of the work, the timeline and the cost.
  4. Then you decide whether to go ahead.

There’s no need to prepare a brief, a study or a body of data in advance. You don’t have to choose a method, run research or write a spec. I’ll tell you whether I see a problem here I can be useful on.

egor@eqwise.ai