Кирилл Лагно

• AI adoption

  Demonstrated

  Kirill acts as a de facto adoption driver in his organization: he pushes AI across departments beyond his own, builds enablement tooling for colleagues (the training bots), and applies a financial-justification gate before scaling anything. That's more than most peers at his level. What's missing is the systematic layer: no evidence of guardrails, shared standards, adoption measurement, or managing second-order costs (skill atrophy, review load) — adoption currently spreads through his personal energy rather than through a designed operating model.

• AI evaluation

  Demonstrated

  This skill was not meaningfully demonstrated. Proxy signals exist: he wants AI decision logic transparent and explainable before trusting it as a buyer, he architected separate bots to avoid quality drift, and he tracks token economics. But no evaluation habits surfaced — no test sets, no output quality checks, no calibrated view of where AI output is reliable versus where it must be verified. Given how central evaluation is to AI-first work, this should be treated as an open gap rather than a weakness confirmed — it simply wasn't in evidence either way.

• AI-first product management

  Partial

  Kirill shows real, lived AI practice unusual for his seniority: he has embedded AI into his daily PM/project work (risk analytics built on an internal case base, automated requirements-quality checks, knowledge-base automation from Jira) and applies a clear "applicable, not just burning tokens" filter, backed by payback calculations. What's not yet visible is the product-management layer on top of the practice: measured before/after deltas, explicit trust-vs-verify boundaries, and a deliberately redesigned workflow he can defend. Today he applies AI well; operating AI-first as a system is the next step.

• AI workflows

  Partial

  The strongest concrete evidence of the session: he designs and ships actual AI workflows, not just prompts — including custom "personality" bots that train specialists through a Feynman-method loop (no direct answers, the learner must explain back), and separate knowledge-base-scoped bots per use case to prevent quality drift. This is real workflow design with intent behind the architecture. Gaps: no quality-evaluation loop around these workflows, and no evidence yet of measuring whether they deliver the intended outcome.

• Product Discovery

  Gap

  This was the session's defining gap. In both case exercises Kirill jumped to solutions and distribution before establishing users, segments, or problems; the pattern recurred three times and had to be named explicitly. His research instincts default to self-as-user testing and asking customers what they want to be built — rather than problem interviews, segmentation, and job-level framing. He cites JTBD but didn't apply it unprompted. Positive signals exist (skepticism of his own opinion as verdict, validating mock-ups before build), and by session end he spontaneously produced a correct jobs-based analysis — the capacity is emerging, but discovery is not yet his default operating mode. Concrete next steps were given: Mom Test, JTBD practice, discovery-first case reps.

GTM case (AI interview agent, no clients yet): asked for a week-one plan, Kirill went straight to execution — internal metrics, B2B sales channels, conferences, freemium pricing, a three-tier product split — without first asking who the target users are, what segment the business is betting on, or what problem the product solves. Solution and distribution before discovery. The recurring pattern: the jump-to-solution reflex appeared three separate times (GTM case, user-research question, dashboard case) and had to be explicitly named twice before he adjusted. His self-correction after being called on it was immediate and non-defensive both times — a strong coachability signal. User-research question: asked how he would approach understanding user pains, his plan was to go through the product himself as a test user, then run usability/A-B checks — a CJM/UX pass on an existing solution, not problem discovery. It took a reframe to move him toward talking to real users. Stakeholder-request case (partner asks for a funnel dashboard): his first instinct was correct — "define what business goal this serves" — but within the same answer he began assuming what the business wants ("they'll care more about how many reach the end"). When caught mid-assumption, he acknowledged it and restructured: brief the partner on goals, poll other partners, check dev cost, validate mock-ups before build. A solid delivery loop, though framed as requirements confirmation rather than de-risking a hypothesis. Business-side research: his approach was to ask companies what they want and what to build — the classic solution-interview trap — plus tag search on LinkedIn/TenChat. No problem-first interviewing, no segmentation before outreach. JTBD claim vs. practice: he said he uses Jobs To Be Done, but no answer during the cases showed job-level framing unprompted. Notably, at the end of the session he spontaneously analyzed a real product (skills-verification platform) in correct jobs terms — evidence the concept is landing but is not yet his default lens. AI practice (positive): unprompted, he described concrete systems he built — risk analytics on an internal case base, requirements-quality checks, Jira knowledge-base automation, and Feynman-method training bots with deliberately separated knowledge bases to prevent quality drift. Grounded, specific, architecturally reasoned — not tool name-dropping. Commercial instinct (positive): repeatedly and unprompted brought financial framing — payback on AI initiatives, token-cost economics of the product, "does it pay off" as a gate — plus compliance awareness (data storage, recording consent, 152-FZ) raised on his own initiative.

1. 1

   Rewire the reflex: problem before solution. Read The Mom Test (Rob Fitzpatrick) and start applying its rules in every customer conversation — ask about facts and past behavior, never "would you use this?". Pair it with Ivan Zamesin's materials on JTBD/AJTBD (the strongest practical treatment of the framework, in Russian): learn to state the core job and the big job behind any product before discussing its features. Target habit: when handed any task, first write down whose problem is this and what job are they hiring a solution for — only then touch the solution.

2. 2

   Get discovery reps on a real, tiny product. Pick one narrow segment with a visible pain and launch something minimal — a Chrome extension, or even a fake-door landing page with a signup button. Do the full loop yourself: find where the segment talks (Reddit/communities), mine their complaints, analyze competitors through their landing pages and reviews (what audience they target, what jobs they claim to close), write your landing in the users' own language, and watch conversion. The goal isn't revenue — it's training the customer-centric muscle end to end.

3. 3

   Learn to talk about results, not output. Watch Jeff Patton on Output → Outcome → Impact and start applying it to your current work: for every initiative, articulate not just what was shipped, but what changed for the user and what it did for the business. This mental model alone separates project-managers-with-a-product-title from product managers.

4. 4

   Build the numbers layer: unit economics. Study Ilya Krasinsky's talks on unit economics (YouTube) — it's the bridge between user-acquisition metrics and product revenue, and the base language for any monetization discussion. Alongside it, skim the basics of prioritization (RICE, MoSCoW) and funnel metrics (AARRR) — you don't need to memorize frameworks, you need to understand what question each one answers.

5. 5

   Reposition your profile around your real strengths. Your execution muscle, financial framing, and hands-on AI practice (workflow bots, automation) are genuine differentiators for a junior PM — make them visible. On LinkedIn, align your profile keywords with regular posts on the same themes (the algorithm rewards profile-post coherence and it drives inbound recruiter flow). Frame yourself as "PM who ships AI workflows with measured payback," not as a generalist junior.