Kirill Dobrinov

Product Lead

B2B Product Management

  • Senior Product ManagerVK
  • Product ManagerYandex
  • Head of RnDAlfa-Bank
LinkedIn

Name, title and affiliations are given by the model’s author; avva has not verified them. Report this model

Solid coverage

Before your AI advises you on B2B product management, it reads the decisions Kirill actually made, the reasons where they recorded one, and where Kirill would push back.

Use this model for

  • MVP scope
  • Operating economics
  • Product roadmaps
  • Build or buy
  • Customer discovery
  • B2B workflows

Built from 58 approved decisions across AI chat history, issues & roadmaps, and documents. Updated October 14, 2026.

Connect to your AIWorks now, no account needed

Add this link to Claude, ChatGPT, or Cursor. Your AI then checks Kirill’s decisions before it answers you. The answer is still your AI’s.

https://avva.chat/mcp/b2b-product-management-kirill-dobrinov
Add Kirill’s model to your AI

On a phone? Email the link to yourself and add it on a computer.

What your AI sends is used for the answer and not stored. Kirill is not told.

Try it free
No account, up to 40 requests a day, per model. It returns a smaller part of the model: every stop rule and question, their approach and defaults, the criteria they put first, and five of their decisions.
Full access
Sign in, up to 1,000 requests a day, per model. It returns the complete published model, on a connection you can revoke from any device.

See Kirill’s model answer a question

One question Kirill answered, and the published decision it rests on. Your situation gets an answer of its own, written by your AI.

Example inside your AI app: a question Kirill chose, and the answer Kirill approved

You:

We are launching a product with individual entry and paid company capabilities. Should we require a subscription from the first use, or charge when customers expand into business use?

Checked Kirill’s Decision Model

Your AI:

Kirill Dobrinov’s proposed launch policy keeps basic individual entry free of subscriptions and charges for expansion: additional pages, analytics, and company capabilities. Set the paid boundary at that expansion.

Why. Charging at the entry point could kill traction and sharing.

What would change this. The customer is buying additional pages, analytics, or company capabilities; those are the paid side of the proposed launch policy.

Outside this model. The exact price, delivery costs, willingness to pay, and whether this launch policy has been validated commercially.

Copy an example prompt4 patterns with a gap to fill, once you are connected

  • Before you commit

    A full pass over a plan or a draft, with the changes it needs.

    Use Kirill Dobrinov's Decision Model on avva before we lock this in. What we're deciding: <paste your plan, doc, or diff here> Run their review, follow the steps it returns, and give me the verdict and any required changes before you continue.

  • Choosing between options

    A choice between two options, their stop rules checked first.

    Use Kirill Dobrinov's Decision Model on avva to compare these. Option A: <describe it> Option B: <describe it> Context: <what constrains the choice — operating economics> Check their stop rules first, then compare the options under their judgment, and tell me which one their model favors and why.

  • A quick gate

    A quick look for anything they would refuse outright.

    Run this past the stop rules in Kirill Dobrinov's Decision Model on avva before I send it. <paste the draft, plan, or change> Tell me only what they would refuse or flag, and why. If nothing trips, say so.

  • Before you have an approach

    The questions they ask before an approach gets locked in.

    I'm starting on MVP scope. Ask Kirill Dobrinov's Decision Model on avva what they would want settled first. Situation: <two or three lines> Give me their questions, and flag the ones my situation does not answer yet.

Patterns with a gap to fill. None is an answer Kirill gave. The one worked answer on this page is the one they approved themselves; anything else here would have been written by us, under their name.

Connect Kirill’s Decision Model to your AI

Three steps. The first works now, with no key or account; the last makes your AI check Kirill’s model without being asked.

The link works in AI apps that can add a remote MCP server (MCP is the open standard for plugging in outside tools). You set it up once.

  1. A connector is an address your AI reads from: one line, nothing to install.

    https://avva.chat/mcp/b2b-product-management-kirill-dobrinov
    1. Open Claude on the web or in the desktop app and go to Customize → Connectors.
    2. Press + next to Connectors and choose Add custom connector.
    3. Paste the address above and name it avva-b2b-product-management-kirill-dobrinov.
    4. When Claude asks to allow avva, say yes.

    Missing on a work account? Ask your admin to allow it. Claude Code and Cursor take a local config instead.

    The link is added on the web or in the desktop app. Email this line to myself

    The trial is enough to see how this expert reasons and whether their thinking fits your problem. Step 2 returns the rest.

    Check it worked. Send this in the chat once the link is added.

    Ask Kirill Dobrinov's Decision Model on avva what kinds of decision it covers, and summarize it for me in three lines.

Not legal, medical, financial, or other professional advice. Terms of Use

About this model

Every rule below rests on decisions Kirill approved. Open any of these to check the grounding yourself.

How this model is groundedWhat it holds, and what Kirill weighs first

This model holds 58 decisions, 19 forces, 12 criteria, and 12 stop rules.

What Kirill weighs first

The next useful action must survive the scope decisionMUST WEIGH
The offer must be economically viable for its intended customer and the teamMUST WEIGH
A product roadmap communicates added value; delivery still needs an ownerMUST WEIGH

The expert set this order. 3 of 12 criteria are shown, the ones the model puts first. The other 9 reach your AI too, along with what each one looks for, the stop rules, and what changes Kirill’s answer.

Kirill’s usual answer changes under 2 named conditions. Those conditions and the 12 stop rules reach your AI with the rest.

See examples of approved decisions5 of 58, written from Kirill’s approved decisions

The first 5 in the record, in published order. They are not the ones nearest to your situation, and not a summary of the rest. Your AI does not copy a decision it reads here: it checks what decided that case against your own facts. With a key or signed in, your AI receives all 58, ordered against your situation.

  1. What decided itThe money, implementation work, and operating workload the team can carry · Customers’ ability to start using and spread the product

    Situation: A small team is building an MVP B2B SaaS for smaller companies. It is choosing calculation infrastructure that will affect the price its customers can afford.

    Decision: Reject the expensive infrastructure stack. Make the product affordable to more companies; large firms already have substantial IT departments.

    Why: The economics would not work, and I want as many companies as possible to be able to afford the product.

  2. What decided itEnough clarity to understand the behavior, task, or next action · The purpose and boundary of the current product work

    Situation: A small team develops an open B2B tool. The CTO wants CI, public images, and deployment tooling in the product roadmap used by sales and other business functions.

    Decision: Keep engineering delivery items in a separate engineering roadmap where useful. Break them down and put them in the backlog; they still have to be delivered.

    Why: Putting everything in the product roadmap makes it complicated and unreadable and defeats its purpose. Its purpose is to communicate added value and coordinate with other departments. The platform work is still essential: without a workable installation process, the product cannot be deployed.

  3. What decided itA working next step that produces customer value · The money, implementation work, and operating workload the team can carry

    Situation: An open B2B tool needs a product roadmap. An assistant recommends excluding a public knowledge base that would replace first-line support and treating it as operational readiness.

    Decision: Treat the knowledge base as a product feature and include it in the product roadmap.

    Why: Without it, the support requests land on us. It has customer value and affects the user experience.

  4. What decided itRoom for change and variation

    Situation: Exploratory B2B product development is being contracted through task tables with hours. Tasks change through research and hypothesis testing, and the parties need a reporting structure.

    Decision: Use review periods organized around analysis, hypothesis testing, piloting, and active development instead of hourly task tables.

    Why: Things change almost every day, there are hundreds of tasks, and this is not custom development against a fixed order.

  5. What decided itEnough clarity to understand the behavior, task, or next action

    Situation: One organization can buy in some transactions and sell in others. A B2B product is considering a combined workspace for the two roles.

    Decision: Keep buyer and seller workspaces separate. Switching is easy; combining them would confuse people.

    Why: Combining them is strange and people will not understand it. Switching between workspaces is easy.

How Kirill takes up a decision12 steps in order, approved by Kirill

  1. Step 1Identify the useful action for each side of the workflow, then trace the proposed scope to the action it enables. Use that path to decide which supporting work belongs in the product.

    When: Choosing scope, an entry flow, or the explanation of a product’s value.

    Backed by 9 decisions

  2. Step 2Evaluate the economics of serving a customer through the complete workflow. Account for variable infrastructure and vendor usage, human work needed to fulfill the promise, support, and recurring integration work. Separate one-time onboarding and implementation costs from recurring service costs and fixed product investment. Check the economics for the segment and usage pattern being proposed.

    When: Evaluating an offer, segment, price, or costly capability.

    Stated by them and confirmed; no decision on record shows it

  3. Step 3Check implementation effort and operating costs against what the intended customer and the team can afford before expanding the offer.

    When: A release has limited resources or the target offer depends on keeping costs accessible.

    Backed by 7 decisions

  4. Step 4Make the commercial promise match the cost driver. When service costs vary sharply with usage or customer complexity, make the pricing boundary, allowance, or service scope explicit. Choose a billable unit the buyer understands and can forecast, while checking how it relates to delivery expense. Estimate heavy legitimate usage before committing to unlimited use.

    When: Setting pricing, allowances, or service scope.

    Stated by them and confirmed; no decision on record shows it

  5. Step 5Compare obtainable contract value with sales effort, time to collect payment, implementation work, and recurring support. Identify who pays for a pilot or custom request, what is being committed, and which costs can realistically be recovered.

    When: Choosing a segment, sales motion, pilot, or customer commitment.

    Stated by them and confirmed; no decision on record shows it

  6. Step 6Assess whether a requested integration or customization can serve the intended segment again. Make ownership, maintenance burden, and commercial terms explicit. Evaluate the effect on the core offer before accepting work that consumes roadmap capacity.

    When: Considering customer-specific product work.

    Stated by them and confirmed; no decision on record shows it

  7. Step 7Name what free use is expected to produce: distribution, qualified demand, successful activation, or a route into paid organizational use. Keep its cost and scope bounded. Review whether users reach the next step before widening the free promise.

    When: Defining or expanding a free offer.

    Stated by them and confirmed; no decision on record shows it

  8. Step 8Test willingness to pay with a concrete buyer, outcome, price, scope, and purchase or renewal decision. Distinguish positive feedback, usage, pilot interest, and a commitment to pay. Use the cheapest credible test of the assumption blocking the commercial decision and specify what would justify the next commitment.

    When: Deciding whether demand can support a paid offer.

    Stated by them and confirmed; no decision on record shows it

  9. Step 9Separate observed customer behavior from estimates and favorable assumptions. Examine lower conversion, slower sales, heavier usage, and more support. Use a bounded pilot or staged commitment when unresolved assumptions determine the decision; define what will be learned and which next decision that learning enables.

    When: Committing resources under unresolved commercial assumptions.

    Stated by them and confirmed; no decision on record shows it

  10. Step 10Define the customer-facing plan and engineering delivery ownership together; establish who will complete the required work as priorities are agreed.

    When: Planning product and engineering work together.

    Backed by 3 decisions

  11. Step 11Make the current commitment and its blocking dependencies explicit before accommodating future capabilities.

    When: Work is being accepted or sequenced under changing requirements.

    Backed by 5 decisions

  12. Step 12Check the intended meaning of a claim or product state before treating it as evidence for a decision.

    When: A recommendation relies on a numeric claim, observed behavior, or a displayed state.

    Backed by 6 decisions

Technical methodologyHow the 21 decisions that say what won and what lost are read
  1. 58decisions Kirill approved, from AI chat history, issues & roadmaps, and documents
  2. 19forces those decisions turned on, the pressures Kirill decides under
  3. 27contests read off 21 decisions: every force that settled a case is set against every force that lost there, so a case naming two of each counts four times
  4. No order yetthey separate no two forces yet, so your AI weighs a collision itself

Nobody ranks these forces by hand. Where any order between them comes from is on For AI agents.

How Kirill decides, in summaryWho they are, and a summary written from the decisions they approved

14+ years in product development

Use this model for B2B product decisions about scope, operating economics, adoption, and delivery. It connects customer outcomes to an offer the business can sustain, with explicit commitments and dependable product behavior.

The summary covers what the model holds. Kirill knows more than is in it.

What’s trustworthy hereWhat is checked, and what is only stated
  • Identity: Name, title and affiliations are given by the model’s author; avva has not verified them. Judge by the record on this page and by what your AI receives.
  • Scope: B2B Product Management (MVP scope, Operating economics, Product roadmaps, Build or buy, Customer discovery, B2B workflows, Adoption and monetization)
  • Coverage: A solid set of decisions behind it, with patterns that repeat across them.
  • Privacy: Their cases and rules, written in English from decisions they approved. Their own AI takes out client and employer names, and they check every case; source quotes never publish.
  • Whose answer it is: avva runs no AI of its own. Your AI reads this model and answers you, and it names where the model had nothing to say.
  • Limits: Informational tooling for your AI, not professional advice. avva is provided as-is.

Privacy Center · Terms

Know someone whose decisions you would want your AI to have? Send them to Studio. Publishing is free during beta.