Executive Thesis
Companies need internal structure.
They have:
- departments;
- divisions;
- product lines;
- internal classifications;
- technical terminology;
- catalogue systems;
- organisational responsibilities.
These structures help the company operate.
The problem begins when the same structure is assumed to be the natural way a customer understands the market.
It usually is not.
Customers arrive with:
- a problem;
- a use case;
- a product requirement;
- a compatibility question;
- an application;
- an outcome they want.
When a website simply reproduces the organisation’s internal logic, customers are forced to learn how the company thinks before they can find what they need.
That is unnecessary friction.
Internal logic feels obvious because the company lives inside it
A manufacturer may think naturally in catalogue families.
An IT integrator may think in technology vendors.
A professional-services company may think in departments.
A distributor may think in manufacturers and internal product groups.
Inside the organisation, that makes perfect sense.
Employees use these classifications every day.
A customer does not.
The customer may know only:
I have this problem.
or:
I need a component compatible with this vehicle.
or:
I need equipment for this particular application.
The website has to connect those two worlds.
The market creates its own taxonomy
Search behaviour exposes this particularly clearly.
People often search using terminology that does not match:
- product database names;
- catalogue articles;
- internal service names;
- organisational departments.
This is not a customer error.
It is market language.
If thousands of potential buyers describe a need differently from the company’s internal terminology, the commercial problem is not that customers need to learn the correct term.
The company needs an architecture that interprets the customer’s language and connects it to the correct solution.
A product can exist and still be almost impossible to discover
We encountered this in an automotive-related manufacturing project.
Products existed on the website.
Technically, they were published.
But many product pages were centred around catalogue article numbers.
Critical customer information was weak or missing:
- compatible vehicles;
- relevant models;
- applications;
- practical selection information.
From the manufacturer’s perspective, the catalogue was present.
From the customer’s perspective, the path to the correct product was incomplete.
This distinction matters.
Having a product page is not the same as having a page that captures product demand.
Website architecture should follow customer decisions
A more useful architecture begins by understanding the routes customers actually take.
Depending on the market, those routes may begin with:
Problem
“I need to solve X.”
Application
“I need this for Y.”
Compatibility
“What works with my equipment or vehicle?”
Category
“I know which class of product I need.”
Customer type
“I am a distributor / enterprise / public institution / homeowner.”
Desired outcome
“I need to reduce cost / increase capacity / comply with a requirement.”
Several paths can coexist.
A good architecture does not force the market into one internal hierarchy simply because that hierarchy is convenient for the database.
Search can become the architecture
In another automotive retail project, the problem was even more explicit.
A traditional homepage in the niche might prioritise:
- promotions;
- product categories;
- brand lists;
- catalogue navigation.
But the customer’s hardest task was not browsing.
It was identifying the correct part for a specific vehicle.
That led to a different architectural decision:
make complex product discovery the dominant homepage function.
The experience was designed around intelligent search, contextual recommendations and the ability to define vehicle configurations before searching for the required part.
The homepage therefore reflected:
the customer’s decision problem
rather than:
the retailer’s catalogue structure.
That is a fundamental difference.
The same principle applies outside ecommerce
This is not only a product-catalogue problem.
A service company can make the same mistake.
Suppose an IT integrator organises the website around:
- Infrastructure Department
- Cloud Department
- Security Department
- Development Department.
The customer may instead think:
- migrate our infrastructure;
- secure remote employees;
- automate a process;
- meet regulatory requirements;
- modernise a legacy system.
A professional-services company may organise around internal practice areas while the client thinks in business situations.
A manufacturer may organise around production categories while the buyer thinks in applications.
The mismatch changes by industry.
The underlying problem remains the same.
SEO cannot fully repair the wrong architecture
This is where SEO frequently becomes trapped.
A specialist can:
- optimise titles;
- add keywords;
- improve internal links;
- publish content;
- build links.
But if commercially distinct forms of demand have no appropriate destination, optimisation eventually reaches a structural limit.
Different intentions may have been forced onto one page.
Different products may exist only as internal catalogue records.
Different audiences may share a generic service page even though they make fundamentally different decisions.
At that point, the issue is no longer simply:
How do we optimise the page?
It becomes:
Should this be the page at all?
But more pages are not automatically better
The opposite mistake is creating a page for every keyword.
Demand architecture is not the same as keyword expansion.
A separate page deserves to exist when there is a meaningful distinction in:
- customer need;
- intent;
- proposition;
- information requirement;
- commercial path.
If two queries describe the same decision and need the same response, splitting them may create duplication rather than relevance.
The objective is not maximum page count.
It is minimum architecture required to represent meaningful market differences.
A simple architecture test
Look at a major section of your website and ask:
Could a new customer navigate this structure without knowing how our company is organised internally?
Then ask:
- Does the terminology match the market?
- Are major customer problems represented?
- Are important use cases represented?
- Can different customer types find their path?
- Can users identify compatibility or selection criteria?
- Does commercially meaningful search demand have a suitable destination?
- Does every major page have a defined role?
If the answer depends on the customer understanding your internal structure, the architecture deserves another look.
Why this matters
Websites are often treated as containers for company information.
Commercially, they are something else.
They are interfaces between:
market demand
and:
the company’s ability to satisfy it.
The stronger the interface, the less translation the customer has to perform.
That improves more than usability.
It affects:
- search relevance;
- category clarity;
- conversion;
- product discovery;
- positioning;
- acquisition efficiency.
Key principle
Customers should not need to learn your organisation before they can buy from it.
And:
The website should reflect the market, not the organisational chart.
Related Intelligence
Demand Map
Understand how customers structure problems, applications, segments and categories.
Growth Architecture Map
Connect those demand structures to offers, pages, acquisition, conversion and sales.
Positioning Map
Ensure that the architecture reinforces how the company intends to be understood and compared.