The stated request rarely captures the whole problem
Consultants are usually invited because something is already stuck: a solution may have been selected, licenses purchased, and internal teams arguing for years about the underlying cause. Vorontsov recalls assignments where replacing a CRM concealed a mix of master data, reporting, and functions that did not belong in the system, while ambitious data plans ran ahead of basic marketing signal collection. Value starts with testing the initial hypothesis and stopping an investment that does not solve the business problem.
A technical report cannot do this alone. A consultant must understand the interests of business, IT, support, security, vendors, and executives; discover why earlier decisions stalled; and assemble a change that the organization can actually deliver. Sometimes it is better to reveal a problem gradually through corrected artifacts than to announce that the client has been doing everything wrong. Trust grows from domain-specific conversation and careful work with organizational dynamics.
AI accelerates familiar work but does not create expertise
Task decomposition, risk discovery, planning, notes, and a first draft can now take hours instead of several team-days. Fewer junior execution roles are needed, while the remaining specialists combine analysis, product work, design, and validation. Yet the acceleration appears only inside a familiar domain: an expert can recognize a strong option quickly, while a newcomer must still internalize knowledge, find experienced practitioners, and learn to distinguish a plausible answer from a correct one.
Delegating to an agent is unlike delegating to a trusted person. A model has neither reputation nor accountability, so the client still needs intent, acceptance criteria, and a verification method. Without them, faster generation becomes verification debt or an expensive correction after the wrong solution is implemented. Closed agent loops can maintain a known operating range, but they struggle with large changes beyond their designed conditions — exactly where a subject-matter expert remains essential.
Recommendations become prototypes and implementation
Once a polished document is no longer scarce, consultants must demonstrate the consequences of a decision. The episode examines a hotel-chain case: a proposed access model for franchisees can be turned into an interface prototype within hours, exposing administrative complexity, data-leak risks, and missing consent-management rules. This artifact does not decorate a predetermined answer. It helps the client reject a weak architecture or product hypothesis before committing significant money.
Consulting therefore converges with software delivery: prototyping happens during the consultation, and implementation continues the diagnosis. The unresolved issue is knowledge transfer. Documents are skimmed, while a compact team keeps critical context in the heads of a few people. Clients should decide who will own the system, interview the practitioners who will actually do the work, and negotiate staff transfer or extended support before the project starts; otherwise progress leaves with the external team.
What to take away
- 01Challenge both the proposed solution and the original problem statement: an official request may only legitimize a decision that has already been made.
- 02Use AI for drafts and decomposition, but keep problem framing, acceptance criteria, validation, and accountability with a domain expert.
- 03Replace promises and slide decks with fast prototypes that reveal the decision's consequences for data, processes, and people.
- 04Plan knowledge transfer before the project begins: instructions cannot replace a context holder who can continue implementation inside the company.