Field note · 2026
The Product Works. Is the Company Around It Ready?
A practical diagnostic for the moment when a growing product can no longer rely on memory, informal ownership and undocumented handoffs.
- Reading time
- 3 minutes
- Published through
- LinkedIn and Astana Hub
- Topic
- Systems and Implementation
- Series
- The system around the product
About this edition. This English site edition combines the international LinkedIn article with the original Russian Astana Hub note. It preserves the shared argument and removes channel-specific repetition.
A product can keep working long after the system around it has stopped being legible.
At first, the whole operating history fits inside a small team. A founder remembers who built the prototype. The CTO knows which services sit inside the stack. A contract can be found in an old email. A new AI tool can be approved in one conversation.
Then an external question arrives. A customer asks how data moves. An investor asks who owns the core assets. A public-sector buyer asks for named responsibility and working controls. The product still runs, but the answer has to be reconstructed from people, folders and assumptions.
That is the point of this diagnostic: not to make a young company look like a large one, but to find where growth now depends on memory.
Start with the event that will test the company
Governance becomes useful when it is attached to a real decision. The right starting point is rarely a complete policy library. It is the next event that will ask the company to explain itself.
- A due diligence request asks how the product was created and which rights support it.
- An enterprise customer asks where its data is stored, who can access it and which vendors receive it.
- A new market changes the privacy, contracting or deployment conditions.
- An AI feature moves from an individual experiment into a customer or operational workflow.
The event gives the work a boundary. It also separates a useful minimum from documentation produced only because a template exists.
Draw the boundary wider than the interface
The visible product is only one layer. Around it sit people, agreements, third-party code, cloud services, datasets, support practices, access decisions and informal workarounds.
A reliable first map asks five questions:
- What is the product made of?
- Who created or supplied each material element?
- What data enters, moves through and leaves the service?
- Which decisions depend on a named person rather than a repeatable mechanism?
- What evidence remains after the conversation ends?
The objective is not to eliminate every unknown. It is to make the unknowns visible before someone outside the company gives them a deadline.
Test what remains after the conversation
Ask two people from different sides of the same process to explain it. If the answers diverge, the difference is useful evidence.
Then look for the operating trace: an owner, a record, a trigger for review and a route for exceptions. A process that works only while one person is available is not yet a company capability.
The product may be ready for the next customer before the company is ready for the customer's questions.
Readiness is not a claim that every control is complete. It is the ability to show the current state, identify the real gaps and name what happens next.
A one-hour first pass
Choose one upcoming event and one product flow. Put the following on a single page:
- the product elements and critical third parties involved;
- the people and agreements behind them;
- the data route and material copies;
- the decision owner and reviewer;
- the evidence that already exists;
- the questions that are still unknown;
- the event that will force the next update.
If the page can be assembled only from one person's memory, that is the first finding. If several sources tell different stories, that is the second. Both are more valuable than a polished policy that describes an organisation no one can recognise.