Can we skip discovery and start building?

You can, and the failure mode is consistent. The real objective of the site gets misread. The technical team works without knowing which business priorities matter. Architecture and design decisions get made with nothing underneath them. What arrives instead is a run of unplanned, unbudgeted scope changes. The most common version starts with a quiet assumption that the new site is the old site with better paint, which is precisely the assumption discovery exists to test.

How long does it take, and what do you need from us?

Reserve one to two weeks in your team's calendar. Discovery does not work as a background task, because every part of it depends on your people being reachable. We need three things: Access to your content, marketing and technology leads. Access to the current site, or to whatever requirements documentation exists. A kickoff framed around clear objectives rather than a general introduction. The quality of the kickoff sets a ceiling on the quality of everything after it.

What is in the discovery document?

Four things: A map of your content as it exists today and as we propose it should be. An inventory of functionalities. Technical recommendations. The risks we detected. We work sitemaps in Octopus.do, user and content flows in Miro, and deliver the written material in Notion or Google Docs. The document then goes into a joint review where the minimum viable backlog is defined and approved, and that approval is what unlocks the next stage.

Could you not just send us a questionnaire?

We could, and it would be faster. It also risks arriving incomplete, or filtered through one person's view of a project that involves five departments. There are four ways to gather this and each trades something: Workshops and interviews give the most depth and cost the most of your time. A form is quick, but incomplete or subjective. An audit of your current site starts from something real, and can quietly reinforce practices that should not survive the rebuild. Access to your internal data, Analytics or Hotjar, is the most objective input available, and only works if you already have it running. We combine them rather than pick one, and we weight them according to what your organization can actually give us.

What do you look at in the site we already have?

The site itself, its analytics, the tools connected to it, and the content architecture underneath. Then we map the content types you run: blog, reports, webinars, cases, products, teams, along with the user types, their access levels and how each one moves through the platform. That mapping is the input for two later workstreams: content architecture, where content types, fields and taxonomies are implemented, and content migration, where the surviving library is moved into them without losing relationships or SEO equity.

What happens after discovery?

You approve a minimum viable backlog, and the project moves into design, or into design system definition if that is what your platform needs next. The deliverables are built to be reused there. A content map, a functionality inventory and a set of technical recommendations are inputs to the proposal and the design stage, not documents that get filed once the workshop ends. If you decide not to continue with us, the same is true.

Discovery Phase

Enterprise WordPress project planning that ends in a backlog you approved

The expensive scope change is the one nobody planned or budgeted for. Discovery finds it while it is still a question, before it becomes a change request against a signed timeline.

Home
Capabilities
Discovery Phase

What we investigate

Four investigations, run before anything is designed

Projects that start without these tend to inherit the old site with new paint. The assumption that the new platform is the previous one rebuilt is the single most expensive thing a WordPress project can carry into its first sprint.

Functional survey

What the site actually has to do: blocks, filters, search, permissions. And which user flows have to be accounted for, established as requirements rather than inferred later from a design file.

Content analysis

What content exists today, what stays, what gets migrated, and which content types do not exist yet but will be needed. Not everything should move, and settling that here is cheaper than settling it mid-import.

Initial information architecture

Menus, sections, URLs and the relationships between content types, plus navigation hierarchies and the main labels. Structure gets argued about on paper, where changing it costs an afternoon.

Preliminary technical definition

Hosting, security, APIs, marketing tools and integrations, together with the requirements that constrain all of them: performance, user roles, language and long-term maintenance.

How discovery runs

Six steps, ending in a decision rather than a presentation

Each step produces the input the next one needs. Plan on one to two weeks of your team’s calendar, because the parts that matter depend on your people being available.

1

Kickoff

Teams meet, and the objectives and strategic expectations for the site go on the table. A kickoff with vague objectives produces a discovery with vague findings.

2

Interviews and survey

Internal roles on your side, current content versus future content, and the specific problems with the site you run today. We ask what does not work now before anyone designs something new.

3

Digital ecosystem audit

The current site, its analytics, the tools connected to it and the content architecture underneath, reviewed as one system instead of as a list of complaints.

4

Mapping content, users and flows

Blog, reports, webinars, cases, products, teams. Then the user types, their access levels, and how each of them actually moves through the site.

5

Discovery document delivered

A map of current and proposed content, an inventory of functionalities, technical recommendations and the risks we found. In writing, so it can be disagreed with.

6

Validation with you

A joint review that defines the minimum viable backlog and approves the move into design, or into design system definition. Discovery closes with a decision.

What we learned running these

Three habits that decide whether discovery was worth it

The process is not the hard part. These three are.

Include the non-technical roles

Content, communication and legal shape more of an enterprise site than any requirements document admits. Leaving them out of discovery means meeting their constraints later, during QA, when the structure is already built.

Separate mandatory from wishlist

Not every requested feature is a requirement, and not every priority carries the same weight. We document that difference explicitly, because a backlog where everything is critical is not a backlog.

Do not assume everything migrates

Understanding what does not work today comes before designing anything new. A content audit almost always finds material that should not survive the move, and deciding that early shortens the migration.

What enterprise teams ask before committing to discovery

The questions that come up on every scoping call.

Related insights

Reading for the scoping stage

How enterprise teams evaluate a CMS and plan the transformation around it.

May 21, 2025

WordPress

Book a discovery workshop

Bring content, marketing and technology. We will work through goals, content and technical constraints, and tell you what a build against them actually involves.

Book a discovery workshop Talk through your project