Entrepreneurship & Strategy

Due Diligence on Enterprise Customers: Five Maps

Share this article
LINEFacebook

Excerpt from 范冰’s 前線部署工程師 with Robin’s commentary; the original post did not name the author

Storage information

Bookmarks and reading positions are stored in this browser. Manage and back them up in My Reading.

Collected in Robin Shen’s Field Notes · Content type and attribution are shown above

English translation of the Chinese post originally published 2026-10-20. Translated 2026-11-05 with AI assistance. Historical figures and claims have not been updated or independently verified. 中文原文

Reading guide

Before writing the first line of code at an enterprise customer, map data, processes, organization, systems, and politics. Two weeks of diligence may look like pure cost but can prevent six months of work in the wrong direction. Robin argues that enterprise projects often fail because the team has not understood internal organization, responsibilities, and interests.

Key points

  • Map the customer’s situation before writing the first line of code.
  • Prepare five maps: data, processes, organization, systems, and politics.
  • Two weeks of diligence can prevent six months of misdirected investment.
  • Robin: understand the customer’s organization, responsibilities, and interests.
One clear path continues into the distance among several branching routes, suggesting choice and focus.
Entrepreneurship & strategyThematic illustration · AI generated

Full text — English translation

Due Diligence on Enterprise Customers—Five Maps Before writing the first line of business code on site, understand the customer’s situation systematically. A complete diligence checklist includes five maps. • Data map: sources, owners, quality, permissions, and overlooked dark data—veteran employees’ spreadsheets, reports circulated only by email, or paper archives. Ask not only what exists, but what people actually trust. In most organizations, official sources differ from those staff use; the latter deserve highest integration priority. • Process map: actual workflows observed through shadowing, not the documented version. Include unwritten steps, exceptions, and workarounds. Mark three points: the most time-consuming, the costliest errors, and the greatest concentration of conflict. These usually reveal valuable opportunities. • Organization map: who initiates, pays, uses, vetoes, and influences without a title. Failure often comes from misreading relationships, not technology: a champion is too junior, too senior to follow through, or key people are excluded. Identify knowledge hubs—staff everyone consults about difficult problems regardless of rank. They are important sources of requirements and early users for the later rollout. • Systems map: systems and interfaces, security and compliance boundaries, and change-management procedures. These determine architecture and timing. Some schedules fail from day one because nobody checked that client-system update approval takes six weeks. • Political map: the most sensitive and crucial. Ask three questions: whose established interests will change, whether a process to be automated is a department’s power base, and whose role loses value. Imagine a launch demonstration where one department applauds while another manager remains silent because that department maintains the process being automated. Employees’ reluctance to adopt tools is the leading roadblock. Usually the root is fear rather than laziness: replacement, invalidated abilities, or loss of meaning. Identify concerned stakeholders early and design new development paths rather than simply stripping away their value. Turn those who would be victims into the strongest supporters at renewal. Only after all five maps are complete are you ready to begin. Diligence generally takes one or two weeks with daily updates. It looks like pure cost, but two weeks can prevent six months of blind investment in the wrong direction. #Forward-deployed engineering (FDE) ---- Robin: ‘Most enterprise projects fail because the customer’s internal organization, responsibilities, and interests were not understood beforehand. Excellent technology does not automatically win everyone’s support.’

These articles are personal notes, book excerpts, and collected reprints. Figures and events reflect the time of the original publication, are not current information, and do not constitute investment advice.

Share this article
LINEFacebook

DISCUSSION

Reader comments

What did this article make you think about? Different perspectives and constructive criticism are welcome.

Comments are public immediately. Do not include personal contact details or external links. Automated checks block suspicious solicitation, prohibited transactions and spam; they can make mistakes.

0 / 2000

Comments load when you reach this section.

    Administrator sign-in

    My reading notes

    These notes stay in this browser and are not published. Writing a note also saves the article. Back up or move your notes in My Reading.

    Manage my bookmarks and notes →

    STAY CURIOUS

    Save a good question for your next visit.

    Save this article, or follow the Facebook page and RSS feed for additions. Historical articles retain their original publication dates.

    Browse All articlesSearch articles and full text →