In the B2B growth work, the challenge is not only to collect data about users, but to understand how these data aggregate at account level. In the book Growth Engineering, growth is seen as a system that integrates product, data, code, experiments and operational responsibility. This perspective becomes concrete when it is recognized that often value arises at account level, even if events are generated by individual users.
Real problem
Measuring only individual users can hide the reality of the business. Three very active users belonging to the same account do not have the same value as three users scattered in three different accounts. In B2C you often look at the individual passenger, in B2B you must also consider the vehicle, group and destination.
Conceptual model
The point is not to add tools or dashboards, but to build a mechanism that makes the transition from signal to decision faster. A good growth system does not promise certainties, but reduces the cost of uncertainty. This also changes the way of writing code: a change is complete only when it can be observed, compared with a hypothesis and transformed into an operational choice.
Strict formalisation
A simple operating scheme helps to maintain clarity:
- user_id 2. account_id 3. workspace_id 4. role 5. invitations 6. shared activity 7. revenue or plan
The complexity comes later, with the increase of traffic, segments, channels and automations. If the base flow is not clear in a few steps, you are probably automating a process not yet understood.
Example or case study
We consider a collaboration tool. There may be a very active “champion,” but the account is at risk if no other member adopts the product. The real challenge is to connect each intervention to a learning: if the results improve, the team knows what to scale; if they do not improve, it knows what conviction to correct. So the system becomes more intelligent.
Metrical to watch
- account activation, seat expansion, multi-user adoption, champion dependence
These metrics must be part of a short scorecard, read regularly and associated with concrete decisions. If a metric does not lead to choices, it is probably a comfort metric.
Typical error to avoid
Confuse accounts and users in the same metric. This error seems productive because it generates activity and enthusiasm, but in reality tells a wrong story. Growth engineering measures value from the quality of the learning cycle, not from the number of actions carried out.
Checklist for the team
What kind of decision should be made more clearly?, What event or data source makes behavior observable?, What risk do we not want to make worse while optimising?, Who can really change the process after reading the result?
If at least one answer is vague, it is better to stop before implementing. The real speed is not to start immediately, but to avoid to redo the job for hypotheses, data or confused criteria.