What we have seen is this: “discovery” is sometimes a polite name for several meetings the supplier intended to hold anyway. A useful ecommerce discovery phase changes the quality of the decision. It proves which problem deserves investment, exposes constraints and leaves the buyer with assets another competent team could understand.
Explore StoreBuilt ecommerce strategy and consulting.
Table of contents
- Keyword decision
- Start with uncertainty
- Bring evidence, not opinions
- Design the workshop sequence
- Demand useful deliverables
- Decide whether to proceed
- StoreBuilt point of view
Keyword decision
Primary keyword: ecommerce discovery phase. Secondary intents include Shopify discovery, ecommerce project planning UK and Shopify project scope. Intent is mid-to-lower-funnel project research. Competitor agency pages frequently invite a discovery call but rarely explain what the buyer should receive. StoreBuilt can earn trust by making the phase testable and buyer-owned, supporting strategy and delivery services without targeting the homepage’s broad agency terms.
Start with uncertainty
Discovery effort should follow uncertainty multiplied by consequence. A new promotional section inside a known theme needs less investigation than a replatform involving subscriptions, B2B pricing, ERP data and international markets.
List the decisions the project cannot safely make yet:
| Unknown | Decision it blocks | Evidence needed |
|---|---|---|
| Customer problem | Which journeys deserve investment? | Research, analytics and support themes |
| Commercial value | What outcome justifies cost? | Margin, conversion and operating baseline |
| Process ownership | What should the platform automate? | Current workflow and exception review |
| Data readiness | Can products and customers move? | Samples, quality profile and mapping |
| Technical constraint | Configure, integrate or build? | Theme, app and system audit |
| Delivery risk | What can launch safely? | Dependencies, capacity and acceptance plan |
Write a discovery charter with questions, participants, time box, deliverables and decision date. Avoid promising a preferred solution in the charter. If the answer has already been sold, the work is validation theatre rather than discovery.
Bring evidence, not opinions
Collect evidence before workshops so expensive group time is used for decisions. Useful inputs include analytics trends, search terms, customer-service contacts, return reasons, failed payments, manual work logs, current system diagrams, app bills, release incidents, product data samples and stakeholder goals.
Segment claims by confidence:
- Observed: supported by current data or direct research.
- Assumed: plausible but not yet tested.
- Constraint: fixed for legal, contractual or operational reasons.
- Preference: valuable but negotiable.
- Decision: agreed with an owner and date.
An anonymous UK brand entered discovery asking for a headless rebuild because content publishing felt slow. Evidence showed the bottleneck was approval and duplicated product data, not page rendering. The team improved governance and theme components instead of introducing a new frontend platform. Discovery created value by cancelling unnecessary architecture.
Interview the people who execute awkward work: support agents, merchandisers, warehouse leads and finance operators. Senior stakeholders know goals; operators know exceptions. Both are required for a Shopify project that survives launch week.
Design the workshop sequence
Do not begin with a feature wish list. Move from outcomes to journeys, operations, data and technology.
- Goals and guardrails: commercial outcome, non-negotiables, budget and timing.
- Customer journeys: priority tasks, friction, accessibility and market differences.
- Operations: fulfilment, returns, service, trading and finance exceptions.
- Content and data: catalogue model, ownership, migration and quality.
- Technology: Shopify capability, apps, custom work, integrations and security.
- Prioritisation: value, risk, dependency and evidence strength.
- Delivery planning: releases, acceptance, training, cutover and support.
Use pre-reads and decision logs. A workshop should not spend its first hour discovering that two departments use “customer account” to mean different things. Record disagreements and assign evidence-gathering actions rather than forcing premature consensus.
Use a Shopify audit to seed project discovery with evidence.
Demand useful deliverables
A beautiful deck is not enough. The outputs must allow estimation, governance and handover.
| Deliverable | What good looks like |
|---|---|
| Outcome model | Baseline, target, guardrail and measurement owner |
| Prioritised journeys | Users, trigger, need, friction and success |
| Requirements | Clear, testable and linked to business value |
| System/data map | Authority, movement, integration and retention |
| Decision log | Choice, alternatives, evidence, owner and date |
| Risk register | Probability, impact, mitigation and owner |
| Delivery options | Scope, trade-offs, dependencies and estimate range |
| Acceptance plan | Business scenarios and release gates |
Require explicit exclusions. The strongest scope statement makes it easy to see what will not be solved in the first release. Include assumptions that move cost: record volumes, number of markets, languages, customer groups, integrations, templates and migrated history.
The buyer should receive editable files, not only a locked presentation. Confirm intellectual-property and reuse terms. If discovery recommends pausing, choosing a standard app or using another specialist, the outputs should still be useful.
Decide whether to proceed
Close discovery with a decision, not automatic momentum. Options can include proceed as scoped, run a technical proof, fix data first, split delivery, change platform choice, or stop.
Score readiness across value, evidence, operational ownership, data, technology, capacity and acceptance. Any red area needs an owner and treatment before the corresponding build begins. Do not hide risk inside a contingency percentage if a short proof can resolve it.
Compare the delivery estimate with the outcome model. If success cannot be measured or the expected value does not support lifetime cost, reduce scope. Keep a thin first release coherent: it should complete an end-to-end journey, not scatter half-features across the site.
Ask StoreBuilt to plan an ecommerce discovery phase.
StoreBuilt point of view
We believe discovery succeeds when the organisation is more able to say no. Its job is not to create excitement for a large build; it is to replace expensive ambiguity with evidence, owned decisions and the smallest credible path to value.