The whole product

Product-led growth gets you into one team. The whole product is what lets you spread through an enterprise.

July 22, 2026 12 min read

A product leader at a top-ten European telecom asked us a question that sounded simple:

"Can we recover what was decided six months ago, even if everyone involved has moved on?"

It is exactly the kind of question Brief is meant to answer.

The decision probably exists somewhere. Part of it may be in a roadmap, part in a ticket, part in a meeting transcript, and part in the memory of someone who has since joined another team.

Brief connects that scattered context so people and agents can understand what the company decided, why it decided it, and whether the decision is still current.

In a demo, that is the moment the product clicks.

Then the conversation moves toward deployment.

Can Brief retrieve context from our self-hosted GitLab?

Will it preserve the permissions attached to the original information?

Can it operate within our data-residency requirements?

Will an answer show its sources?

Can an engineer receive the context inside the tool where work is happening?

How will we know whether any of this reduced rework?

These can look like secondary enterprise requirements surrounding the interesting part of the product.

They are actually the rest of the original problem.

A decision that cannot reach the right person is not usable context. An answer without provenance cannot be trusted. Context that ignores permissions cannot be deployed. Information delivered after implementation cannot prevent the wrong thing from being built.

The customer did not ask for a system that could find old decisions in a demo.

They asked for organizational judgment that could survive time, team changes, and execution.

Geoffrey Moore gives us a useful way to name this gap in Crossing the Chasm.

The capability at the center is the generic product.

The customer needs the whole product.

Four versions of the product

Moore describes the product as a series of concentric layers.

The generic product is what the company ships. It is the capability named in the product description and demonstrated during the sales process.

The expected product is the minimum configuration the customer assumes will accompany that capability.

The augmented product adds the surrounding capabilities required to maximize the customer's chance of achieving the desired result.

The potential product contains the future extensions that could make the product useful in more situations.

The practical lesson is easy to miss.

Customers do not experience these as four separate products. They experience one outcome that either happens or does not.

For Brief, retrieving a decision is part of the generic product.

The customer's expected product includes access to the systems where decisions live, a way to tell current decisions from obsolete ones, and an answer that points back to its sources.

The augmented product may include enterprise permissions, governance, deployment controls, and a way to measure whether better context changed how work was executed.

The potential product extends that judgment across more teams, systems, and agents.

The layers should not be interpreted as an invitation to build everything.

They reveal the distance between what the vendor ships and what the customer must be able to accomplish.

For Brief, the capability is context retrieval.

The outcome is continuity of judgment.

The whole product is what carries one into the other.

Why the first team can mislead you

Moore's chasm separates early adopters, who will buy into a vision and help make it real, from pragmatists, who want to see a complete solution working for customers like them.

Inside an enterprise, that chasm can run through a single account.

The first team behaves like an early adopter. The next team behaves like a pragmatist.

Product-led growth is often described as a sequence of individual actions:

Sign up. Experience value. Invite a teammate. Upgrade.

That sequence works when one person can obtain the product's value independently.

Enterprise products operate inside an existing organization. Their value depends on information, workflows, permissions, and decisions owned by many people.

The first team can hide this complexity.

An enthusiastic product manager knows which roadmap is current. They recognize an outdated decision when it appears. They explain the product to every new user. They copy missing context into the system and tell engineers which answers can be trusted.

Their effort completes the product.

The team appears to be using a whole product because the champion is manually supplying the missing layers.

This is valuable during discovery. It becomes dangerous when interpreted as readiness to expand.

The next team may use different tools. It may not share the same vocabulary. Its manager may interpret the company strategy differently. Its engineers may not know which decisions are still binding.

The champion's private scaffolding disappears.

The first team can run on heroics. Enterprise expansion cannot.

Activation happens when context survives a handoff

A top-ten North American bank organizes engineering work across several tiers.

One group explores and de-risks an idea. Another industrializes it. A third may eventually operate the production system.

Each handoff compresses the original context.

The team receiving the work sees the selected approach. It may not see the alternatives that were rejected, the customer need that created the work, or the constraint that made one compromise acceptable.

A junior engineer sees a ticket.

A coding agent sees a prompt.

Neither automatically sees the product judgment behind them.

If Brief helps the first group record its rationale but the second group cannot receive and use that rationale, the company has created a better archive. It has not preserved intent.

The outcome occurs when the decision survives the handoff and changes what the receiving team does.

That gives enterprise software a more demanding definition of activation.

Activation is not simply the first successful search.

It is not the first generated answer.

It is the first time the right context reaches a person or agent early enough to prevent a wrong turn.

Once that outcome can be repeated across teams, the product can expand.

The integration is part of the promise

Another enterprise customer, a global data and analytics company, described a different version of the same problem.

Its product managers repeatedly recontextualize work for engineers, executives, and sales. The information already exists, but every audience needs a different path through it.

The company works across Microsoft Teams, SharePoint, Office 365, Jira, and Pendo.

A product that only understands Slack would miss the environment where this recontextualization happens.

The Teams or SharePoint connector is therefore more than an integration request. It determines whether the product can produce the promised outcome.

The same is true of self-hosted GitLab for the telecom. The decisions governing implementation may be attached to issues, merge requests, and repositories inside that system. A product without access to those sources can answer some questions, but it cannot reliably preserve the chain from decision to execution.

This does not make every connector equally important.

An integration belongs in the whole product when it performs at least one essential job:

• It contains authoritative context.
• It is where the customer makes decisions.
• It is where people or agents act on those decisions.
• It carries permissions the product must preserve.
• It provides evidence that the desired outcome occurred.

This is a better test than counting feature requests.

A connector requested by one customer may complete the product for an entire market. A connector requested by ten customers may add convenience without changing whether they succeed.

The question is not how many customers asked.

The question is whether the product's promise remains incomplete without it.

The next team is the real activation event

Enterprise product-led growth does not eliminate sales, security reviews, or procurement.

It changes what gives those functions leverage.

A champion who merely likes the product has an opinion.

A champion whose team avoided rework, recovered a critical decision, or helped an agent implement the right behavior has evidence.

That evidence makes the next conversation easier.

The product-led loop inside an enterprise looks like this:

1. One team uses Brief during real product and engineering work.
2. The relevant decisions reach people and agents inside their workflows.
3. The team can point to work that moved faster or avoided a wrong turn.
4. The champion uses that result to earn trust from an adjacent team.
5. The product reproduces the outcome without requiring the champion to reconstruct it manually.

One Brief account expanded from 10 seats to 56.

The important event was not the purchase of 46 additional seats. It was the product becoming useful beyond the original group.

Seat expansion recorded the result. Repeatability caused it.

This is the enterprise version of product-led growth. The product gives the internal champion something concrete to carry across the organization.

Sales helps the evidence travel. The product creates the evidence.

Build the smallest complete promise

The whole-product model can easily become an excuse for roadmap sprawl.

A team hears that enterprise customers need integrations, governance, analytics, onboarding, regional hosting, and support. It begins constructing a generic enterprise checklist.

The result is usually a wide product with no clear promise at its center.

The better approach is to choose a narrow beachhead and make one outcome complete.

For Brief, the beachhead might be one product and engineering pod using coding agents on active work.

The desired outcome could be reducing implementation mistakes caused by missing or outdated product decisions.

That promise immediately establishes what the minimum whole product needs:

• Access to the authoritative sources used by that pod.
• A way to distinguish current decisions from superseded ones.
• Provenance so an engineer can inspect the underlying evidence.
• Existing access controls applied to retrieved context.
• Delivery inside the coding agent's workflow.
• A runnable way to check whether implementation followed the relevant decisions.

Each element follows directly from the outcome.

A new connector belongs when the pod's authoritative context lives behind it. An executive dashboard belongs when it is necessary to prove the result and earn the next deployment. A feature that does not help the pod achieve or demonstrate the outcome can wait.

This also creates a useful product discipline.

Do not ask, "What would make us look enterprise-ready?"

Ask, "What is preventing this customer from completing the job they already chose us to do?"

The first question produces a checklist.

The second produces a whole product.

Coding agents make the gap wider

The distinction between capability and outcome becomes more important as companies adopt coding agents.

An agent can generate a working implementation from an incomplete prompt. That is precisely what makes missing context dangerous.

The code may compile. The tests may pass. The implementation may still violate a customer commitment, repeat a rejected approach, or optimize for a metric the company no longer prioritizes.

More capable agents increase the amount of work a team can produce before discovering that the work was pointed in the wrong direction.

The required product is therefore larger than a search box for company knowledge.

Context must be current, relevant, permitted, sourced, and available at the moment of action. It must survive when people change teams. It must be expressed in a form an agent can use without forcing every engineer to become a product historian.

That is the standard Brief has to meet.

Brief's role is to make organizational judgment reusable at execution time. Connectors, permissions, decision history, provenance, and agent delivery all follow from that role.

They are not a separate enterprise story surrounding the product.

They are how the product keeps its original promise.

What this does and does not claim

The whole-product model does not mean startups should build every integration or satisfy every large customer.

It means the company should understand the complete outcome promised to a deliberately chosen customer.

Some gaps can be filled manually while learning. Early adopters are valuable because they reveal those gaps.

The important thing is to notice who keeps filling them.

If a founder, champion, or solutions engineer repeatedly performs the same missing work, that work may belong in the product.

If the work changes completely for every customer and does not strengthen the central outcome, it may belong in services. It may also be evidence that the market is too broad.

The model also does not require an organization-wide launch.

One team is enough to begin.

That team should be narrow enough to support closely and important enough to produce credible evidence. Expansion follows when the product can reproduce the outcome for the next team without reproducing all the manual effort.

The generic product can answer:

"What did we decide six months ago?"

The whole product ensures that the answer is current, permitted, sourced, delivered inside the workflow, and capable of changing what gets built.

The first team proves the answer is useful.

The next team proves the product is whole.

Frequently asked questions

What is a whole product? The whole product is the complete set of capabilities and surrounding conditions a customer needs to achieve the promised outcome. It includes the core capability as well as any necessary integrations, controls, services, and evidence.

How does the whole product relate to product-led growth? The core product creates initial pull. The whole product makes its value repeatable across teams. In enterprise PLG, that repeatability turns one successful deployment into account expansion.

Does enterprise product-led growth still require sales? Usually. Sales helps navigate procurement, security, executive alignment, and expansion. The motion remains product-led when demonstrated product value creates the conviction required to adopt it elsewhere.

How should a startup decide what belongs in its whole product? Choose a narrow customer and one promised outcome. Identify what prevents that customer from achieving the outcome in its actual environment. Build the smallest set of missing pieces that closes that gap.

Are enterprise integrations part of the product? They are when the promised outcome depends on them. If authoritative context lives in GitLab, Jira, Teams, or SharePoint, reaching those systems may be essential to the product rather than an optional addition.