Shopify Plus Project Roadmapping | Global

Shopify Plus planning series

Step 1: Run the 7-Sheet Discovery Workshop
Step 2: Turn discovery into a delivery roadmap. You are here.

A good discovery workshop creates alignment. It explains the business context, why the project exists, which outcomes matter, what could put delivery at risk and what a successful launch needs to include.

The next challenge is turning that shared understanding into a plan a delivery team can actually use.

This is where the roadmapping session begins. It takes the findings from the 7-Sheet Discovery Workshop and breaks them into features, stories, tasks, dependencies, estimates, workstreams and delivery phases. It is the point where the project moves from “why and what” to “how, when, who and how much.”

I have found this stage particularly valuable on Shopify Plus migrations. Large commerce projects rarely fail because the team forgot that a product page or checkout exists. Problems usually come from details that were not broken down early enough: product data rules, regional differences, integration ownership, B2B logic, content dependencies, SEO changes, testing responsibilities or app limitations.

A detailed roadmap makes those details visible before design and development commit the project to an approach.

The difference between discovery and roadmapping

Discovery and roadmapping are closely connected, but they are not the same exercise.

The 7-Sheet Workshop is a stakeholder alignment tool. It covers:

Business context
Project purpose and goals
Platform and delivery approach
Critical success factors
Risks
Definition of done
Open issues and the carpark

It helps the group agree what the project is trying to achieve and what must be protected.

Roadmapping is the delivery team’s working plan. It covers:

Features and customer journeys
Page templates and reusable components
User stories and technical tasks
Native, app-based and custom approaches
Effort by role and discipline
Dependencies and critical path
MVP, later phases and future ideas
Workstream timelines and handovers
Integration and migration planning
Testing, training and launch preparation

Put simply, discovery answers why, what and for whom. Roadmapping answers how, when, who and how much.

Skipping discovery can produce a detailed roadmap for the wrong project. Skipping roadmapping can produce good strategic notes with no reliable path into delivery. Both steps matter.

What needs to be ready before roadmapping

Roadmapping works best when the main discovery decisions are documented and the people in the room know what is still open.

Before starting, I look for:

An agreed project purpose
Prioritised goals and success measures
Initial MVP boundaries
A current platform and integration map
Known customer, operational and regional requirements
Critical success factors
A first risk register
A working definition of done
Named owners for open discovery questions
Access to existing analytics, content and system documentation

Not every question needs to be resolved. In fact, some roadmapping work exists to investigate an unknown. The important thing is to distinguish a confirmed requirement from an assumption, and to give unresolved decisions an owner and deadline.

If the team cannot explain the purpose or priorities, return to Step 1, the 7-Sheet Discovery Workshop before estimating features.

Who should take part

Roadmapping needs a more delivery-focused group than the main discovery session, while still keeping decision-makers close enough to resolve trade-offs.

The core group will normally include:

Product or project manager
Technical lead or solution architect
UX and information architecture
Design lead
Front-end and back-end development
SEO specialist
Data and analytics specialist
Content or copy lead
Quality assurance
DevOps or platform operations where relevant
E-commerce or trading lead

Specialists should join for the workstreams they own. Finance may be needed for payments and reconciliation. Operations may be needed for fulfilment and returns. Customer service may own account and contact journeys. Regional teams may need to approve market differences. ERP, OMS, PIM or 3PL owners must be involved when an integration is being estimated.

Stakeholders do not need to sit through every story estimate. They do need to approve priorities, scope choices and trade-offs at planned checkpoints.

Start by carrying the discovery decisions forward

The first part of roadmapping is not creating new feature ideas. It is reviewing the decisions already made.

Place the discovery outputs beside the roadmap and check:

Which goals does the roadmap need to support?
Which success factors affect architecture or acceptance?
Which risks require investigation or contingency?
Which definition-of-done items need stories or tasks?
Which open issues block estimation?
Which MVP boundaries have already been agreed?

This creates traceability. A feature should exist because it supports a customer journey, business outcome, operational requirement or delivery obligation. If no one can explain why a feature is needed, it should not quietly enter the estimate.

Step 1: Build the feature inventory

The feature inventory is the broadest view of what the project may need. It captures storefront, customer, content, operational, integration and delivery requirements before they are separated into detailed stories.

For a Shopify Plus project, I normally organise the inventory into areas such as:

Global storefront

Announcement and promotional messaging
Header and navigation
Search entry points
Country, language and currency selection
Footer and service links
Consent and preferences
Accessibility controls and shared states

Product discovery

Collections and category structure
Search and predictive search
Filters and sorting
Merchandising rules
Product recommendations
Product finders or guided selling
Recently viewed and saved items

Product detail

Product information and media
Variant selection
Availability and delivery messages
Subscriptions or purchase options
Bundles and related products
Reviews and user-generated content
Samples, swatches or consultation journeys
Store or stockist availability

Conversion

Cart behaviour
Discounts and promotions
Gift cards and gifting
Shipping estimates
Checkout content and validation
Payment methods and buy now, pay later
Post-purchase communication
Returns and exchanges

Customer accounts

Registration and login
Order history
Address management
Saved products
Subscription management
Loyalty and referrals
Customer service handover
Privacy and data requests

B2B and wholesale

Company profiles and locations
Buyer roles and permissions
Catalogues and price lists
Quantity rules and volume pricing
Payment terms and invoicing
Purchase orders
Sales representative involvement
ERP and finance handover

Content and brand

Landing pages
Editorial content
Campaign pages
FAQs and support content
Store or location pages
Market-specific content
Reusable sections and content models
Digital asset and translation workflows

Integrations and operations

ERP, OMS, PIM and WMS
Third-party logistics and fulfilment
CRM and lifecycle marketing
Search, reviews, loyalty and subscriptions
Customer service and returns
Tax, duties, fraud and payments
Analytics, consent and reporting
Data migration and reconciliation

Delivery and readiness

Environments and access
SEO migration
Analytics implementation
Content migration
Quality assurance
User acceptance testing
Training and documentation
Launch, rollback and post-launch support

The inventory should be complete enough to reveal the project shape, but it does not need a perfect solution attached to every line. Detailed decomposition comes next.

Step 2: Break features into stories and tasks

A feature name is rarely detailed enough to estimate.

“Product filters” sounds small until the team asks which data defines the filters, who maintains it, whether values change by market, how filters behave on mobile, which combinations need indexation controls and what happens when product data is incomplete.

Each feature should be broken into:

Stories: customer-facing or user-facing outcomes
Tasks: technical, operational or delivery work required to make the story possible
Acceptance criteria: the conditions that show the story is complete
Dependencies: other decisions, systems or stories that must happen first
Unknowns: questions that need investigation before the estimate can be trusted

Example: product filtering

A story may be:

As a customer, I can filter a collection by the attributes that matter to my purchase so I can find suitable products quickly.

Tasks may include:

Confirm filter attributes and merchandising rules
Define the metafield structure
Clean and populate product data
Configure Shopify Search & Discovery or another tool
Design desktop and mobile filter behaviour
Build active-filter states and empty results
Define SEO rules for parameter combinations
Add analytics events
Test catalogue size, accessibility and performance
Document the ongoing product-data process

The story is no longer just a front-end component. It is a connected piece of product data, UX, technology, SEO, analytics and operations.

Step 3: Classify the implementation approach

For each story, record the likely approach:

Native Shopify capability
Theme or configuration work
Shopify app
Custom app or middleware
Integration with an existing system
New business process
Requirement that should be changed or removed
Investigation needed before a decision

This classification helps the team compare build effort with licence cost, operational overhead, data risk and long-term support.

An app is not automatically simpler than custom work. It may introduce theme code, customer-data access, recurring cost, API limits or market restrictions. Custom development is not automatically better either. It creates ownership, testing and maintenance responsibilities.

The roadmap should show the trade-off, not hide it.

Step 4: Estimate effort at story level

Once the story, tasks and approach are understood, estimate the effort required from each discipline.

Depending on the project, roles may include:

Content
Strategy
SEO
Data and analytics
UX
Information architecture
Design
Copywriting
Technical lead
Back-end development
Front-end development
DevOps
Quality assurance
Development QA
Project management

The purpose of role-based estimation is not to create false precision. It is to show where the work sits and prevent invisible disciplines from being forgotten.

A product page story may require only a few development hours but substantial product-data, UX, content, design, SEO and testing work. A data migration may need little visual design but significant technical analysis, rehearsal, reconciliation and project coordination.

Story estimates roll up into feature, epic, workstream and phase totals. This gives the project manager a first view of cost, capacity and timeline.

Use ranges when uncertainty is real

If an integration has not been documented or an app has not been tested, use a range or a time-boxed investigation rather than pretending the estimate is fixed.

Record the assumption beside the estimate. For example:

Estimate assumes the ERP exposes the required customer and order endpoints
Estimate excludes historic order migration beyond the agreed period
Estimate assumes one shared product model across markets
Estimate requires checkout validation to be supported by extensibility

An estimate without its assumptions is difficult to manage later.

Step 5: Prioritise MVP, Phase 2 and future work

Roadmapping makes scope trade-offs visible. Every feature should be placed into a delivery phase rather than left in one large backlog.

MVP

The minimum set of capabilities required to launch safely and achieve the agreed project purpose.

MVP should include operational readiness, SEO, analytics, accessibility, testing and training. Those are not optional extras simply because customers do not see them as features.

Phase 2

Valuable improvements that can follow launch without preventing the first release from succeeding. These may include richer personalisation, additional account tools, advanced merchandising or process automation.

Phase 3 and future

Ideas that need more evidence, depend on later business changes or are not justified by the current goals.

From our experience: use the line to create alignment

When we run these roadmapping sessions, one of the most important outcomes is alignment between the client and agency on what belongs in MVP, what moves into Phase 2 and what is held for Phase 3. This gives both teams the same expectations before design and development begin.

We make that decision visual. MVP features sit above a clear scope line. Phase 2, Phase 3 and nice-to-have ideas sit below it. The items below the line are not forgotten. They remain visible and can move into scope when priorities, evidence, budget or capacity change. This is much clearer than hiding deferred ideas in a separate document or leaving everything in one undifferentiated backlog.

The format works particularly well for larger teams because everyone can contribute, question assumptions and see the effect of each trade-off. Running the session in person usually creates the strongest conversation, but the same method works online with shared boards in Miro or FigJam. The important part is that the board stays open, collaborative and easy for every participant to understand.

Before the session ends, confirm the features above and below the line, the reason for each decision, any assumptions attached to it and who has authority to approve a later scope change. That shared visual record becomes a practical reference for the client, agency and delivery team.

A practical prioritisation test

For each feature, consider:

Customer value
Business value
Operational necessity
Legal or compliance need
Dependency on other work
Delivery risk
Evidence available
Cost and capacity
Whether a safe workaround exists

MVP is not the smallest possible website. It is the smallest release that can achieve the agreed purpose safely and be operated by the business.

Step 6: Map dependencies and the critical path

Features cannot be sequenced by priority alone.

Product filtering may depend on the product data model. Product page design may depend on confirmed variant structures. Checkout work may depend on payment and shipping decisions. SEO redirect mapping may depend on the final information architecture. Content entry may depend on approved templates and translations.

The roadmap should show:

Story-to-story dependencies
External vendor dependencies
Decision deadlines
Data and content readiness
Environment and access dependencies
Work that can run in parallel
Work that controls the launch date

This is where a feature list becomes a project roadmap.

The critical path should be visible to stakeholders. If an ERP interface or product model controls several downstream workstreams, that decision deserves more attention than a small visual enhancement even if it is less exciting to discuss.

Step 7: Organise the work into parallel workstreams

Large Shopify Plus projects rarely move through one simple sequence. Several workstreams run at the same time and meet at planned handovers.

Typical workstreams include:

Experience design

Information architecture, user journeys, wireframes, design system, templates and component states.

Content and migration

Content inventory, ownership, writing, photography, translation, entry, product data and migration rehearsals.

Storefront development

Theme architecture, components, customer interactions, performance and accessibility.

Integrations and data

System interfaces, middleware, migration scripts, error handling, monitoring and reconciliation.

SEO

URL architecture, redirects, canonicals, hreflang, structured data, internal linking and launch monitoring through Google Search Console.

Data and analytics

Measurement plan, consent, Google Analytics, tag management, reporting and validation.

Testing and readiness

Functional QA, cross-browser and device testing, integration testing, UAT, training, documentation and support preparation.

Deployment and post-launch

Data freeze, final migration, cutover, rollback planning, monitoring, incident ownership and the first optimisation backlog.

Each workstream needs milestones, inputs, outputs, owners and handovers. The roadmap should show how they meet, not just how they progress separately.

Integration and technical planning

Integration names are not enough for accurate roadmapping. “Connect Cin7” or “connect the ERP” does not explain what the integration needs to do.

For each integration, map:

Business process supported
System of record
Data entities and fields
Direction of travel
Real-time, event-based or batch pattern
Expected frequency and volume
Authentication and access
Error handling and retry behaviour
Monitoring and alerting
Reconciliation process
Manual fallback
Support owner

This should create a first integration architecture and expose gaps that need separate technical discovery.

If the team cannot confirm the interface, create an investigation story. Do not hide unknown integration work inside a general development estimate.

Shopify Plus constraints that need story-level decisions

Shopify Plus provides a strong commerce foundation, but every requirement still needs to be assessed against the platform.

Checkout extensibility

Legacy checkout scripts and customisations may need to move to Shopify Functions, UI extensions, Checkout Blocks or a changed business process.

Roadmap the checkout requirement as a customer and operational outcome. Then validate whether the proposed approach can support the required market, payment and account states.

Shopify B2B

Company profiles, locations, catalogues, price lists, buyer permissions, payment terms and purchase orders affect customer experience, data and ERP processes. The Shopify B2B and wholesale guide explains the main decisions in more detail.

Markets and expansion stores

International architecture changes domains, content, catalogue, payments, tax, fulfilment, governance and SEO. Decide the model before estimating duplicated or market-specific work. See the guide to Shopify Markets versus expansion stores.

Metafields and metaobjects

Content and product attributes need a governed data model. Filters, product finders, comparison, content sections and integrations may all depend on the same field structure.

Roadmap data modelling before downstream templates and migration. If bulk data needs to be moved or rehearsed, tools such as Matrixify may form part of the migration approach.

Apps and platform performance

Every app should be assessed for capability, market support, customer-data access, performance, accessibility, maintenance and total cost. App selection should include a proof of concept where the requirement or integration is important.

API and webhook limits

Integration patterns need to account for Shopify API limits, event delivery, retries, reconciliation and failure states. The happy path is only one part of the story.

Operational automation

Shopify Flow can support tagging, notifications, review queues and other workflows, but the business rule, owner and exception path still need to be defined.

Content, SEO and analytics are roadmap work

These disciplines should not sit outside the feature estimate.

Content

Every template needs a purpose, content owner, source, approval process and migration rule. New product finders or comparison journeys may require data that does not exist today. Translation and legal review may control the timeline.

SEO

SEO and GEO stories should cover URL structure, redirect mapping, canonicals, hreflang, metadata, headings, structured data, XML sitemaps, internal links, performance and post-launch monitoring.

SEO requirements should be linked to the relevant templates and features. For example, product filtering needs indexation rules, market architecture needs hreflang and a migration needs redirect acceptance criteria.

Analytics

Measurement stories should begin with decisions the business needs to make. Define events, parameters, consent, data layers, dashboards and validation for priority journeys.

If an MVP feature cannot be measured or operated, its definition of done is incomplete.

Plan testing, UAT and training at story level

Testing effort grows with the number of markets, devices, customer states, integrations and purchasing paths.

The roadmap should cover:

Functional testing
Accessibility testing
Cross-browser and device testing
Performance testing
Payment and checkout testing
Integration and failure testing
Data migration reconciliation
SEO pre-launch checks
Analytics validation
User acceptance testing
Regression testing
Launch rehearsal

Assign UAT scenarios to business owners. The delivery team can test whether a feature behaves as specified, but operational teams need to confirm that it supports the real process.

Training and handover also need stories, estimates and acceptance criteria. Documentation, role setup and support procedures should be ready before launch, not written after the project team has moved on.

Keep a live risk, dependency and decision log

The roadmapping session will surface new risks and decisions. Add them to the project record immediately.

Examples include:

Checkout extensibility may not support a required validation
ERP sync timing is still to be confirmed
A product builder requires separate technical scoping
Filters depend on a new metafield structure
Reviews depend on final app selection
Local teams have not approved the shared catalogue model
Historical orders exceed the agreed migration volume
Product photography will not be ready for content entry

Each item needs an owner, next action, due date and effect on the estimate or critical path.

Do not remove an unknown from the roadmap simply because it cannot be estimated yet. Represent it as investigation work and show which decisions depend on it.

What the roadmapping session should produce

A finished roadmap should give the organisation more than one large estimate.

Key outputs include:

Feature inventory

Features grouped by customer journey, template, business process and integration area.

Story-level estimate

Effort by role, total effort, assumptions and confidence for each story.

Phased product roadmap

MVP, Phase 2 and future features with clear reasons for each decision.

Project roadmap

Workstreams, milestones, dependencies, handovers and critical path.

Integration architecture

Systems, data ownership, interfaces, sync patterns, monitoring and open technical questions.

Risk and dependency log

Known blockers, uncertainties, mitigations, owners and decision dates.

Role and capacity plan

Which disciplines are needed, when they are needed and where internal or vendor availability affects the schedule.

Decision log

Approved trade-offs, rejected approaches, assumptions and items that still require stakeholder sign-off.

These outputs become the basis for a statement of work, budget, delivery timeline and mobilisation plan.

A practical roadmapping session structure

For a large migration, roadmapping is usually a short programme rather than one very long meeting.

Session 1: Feature inventory

Review discovery outcomes
Map customer and operational journeys
Capture storefront, content and integration features
Identify known dependencies and unknowns

Session 2: Story decomposition and technical approach

Break priority features into stories and tasks
Classify native, app, custom and investigation work
Map data, platform and integration dependencies
Draft acceptance criteria

Session 3: Estimation and phasing

Estimate effort by role
Review assumptions and confidence
Prioritise MVP, Phase 2 and future work
Identify critical path and capacity constraints

Session 4: Roadmap approval

Review product and project roadmaps
Confirm trade-offs
Approve MVP boundaries
Assign open decisions
Agree the next planning and design outputs

The exact format depends on project size. A smaller store may need two focused sessions. A global migration with B2B, several integrations and independent markets will require specialist follow-ups.

How to manage price without pretending every detail is known

Roadmapping should improve commercial confidence, but it cannot remove every unknown.

Separate work into:

Well-understood stories with a stable estimate
Stories estimated within an agreed range
Time-boxed investigation work
External costs such as apps, licences and vendors
Client-owned work such as content, data preparation or UAT
Contingency tied to named risks

This is more useful than one fixed number with hidden assumptions.

When an investigation changes the scope, update the roadmap and decision log. The roadmap is a controlled working document, not a promise that nothing will ever change.

What happens after roadmapping

Once the roadmap is approved, the project can move into detailed planning and execution with a much stronger foundation.

Typical next steps include:

Finalise the statement of work and delivery team.
Confirm the solution and integration architecture.
Develop the information architecture and URL model.
Create low-fidelity wireframes for priority journeys.
Define the content model and migration plan.
Complete SEO and analytics requirements.
Produce the visual design and component system.
Begin development and integration work.
Rehearse data migration and testing.
Prepare UAT, training, cutover and post-launch support.

The roadmap remains active throughout these stages. Design may expose a new dependency. Integration testing may change an estimate. Content work may reveal missing product data. Those changes should be recorded and managed against the agreed goals and MVP.

Common roadmapping mistakes

Estimating from feature names

Break the feature into customer behaviour, technical tasks, data, content, SEO, analytics and acceptance before assigning effort.

Treating every idea as MVP

Use the project purpose, success factors and dependencies to make trade-offs. A later phase is often the responsible choice.

Hiding uncertainty inside development estimates

Create investigation stories and record assumptions. Unknown work does not become safer because it is given a precise number.

Forgetting client-owned work

Content, product data, legal approval, translations, access and UAT can control the launch date. Show them on the roadmap with owners.

Choosing apps without operational review

Confirm capability, data use, market support, maintenance, performance and cost before treating an app as the solution.

Sequencing by department rather than dependency

Workstreams can run in parallel, but handovers and critical decisions must be explicit.

Leaving testing and training until the end

Estimate them with the features and plan readiness milestones before launch.

Disconnecting the roadmap from discovery

Every significant feature and trade-off should connect back to a goal, journey, risk or definition-of-done requirement.

Roadmapping checklist

Before approving the roadmap, confirm:

Discovery outcomes are reflected in the feature plan
Every MVP feature supports an agreed purpose or requirement
Features are decomposed enough to estimate
Native, app, custom and investigation approaches are identified
Role-based effort is visible
Assumptions are recorded beside estimates
MVP, Phase 2 and future work are separated
Dependencies and critical path are mapped
Integrations include data ownership and failure handling
Content and product-data work have owners
SEO and analytics are included in the relevant stories
Testing, UAT, training and launch are estimated
Risks and unknowns have owners and next actions
Workstreams have milestones and handovers
Stakeholders have approved the main trade-offs
The roadmap can support a statement of work and capacity plan

If several of these points are missing, detailed design is likely to begin with avoidable uncertainty.

Final thoughts

Roadmapping is where the project becomes real.

The 7-Sheet Workshop creates a shared view of the business, goals, risks and success. The roadmapping session turns that view into stories, estimates, phases, responsibilities and a critical path.

Across complex commerce projects, this step has helped me expose platform constraints earlier, price work more honestly and keep delivery teams and stakeholders aligned on what is being built first and why.

The roadmap will continue to change as the team learns. That is expected. What matters is that change happens against an agreed purpose, with the effect on scope, timing and risk made visible.

If you are starting this process, begin with Step 1, the 7-Sheet Discovery Workshop. When that alignment is in place, New Site Agency can help turn it into a detailed Shopify Plus delivery roadmap covering customer experience, architecture, integrations, SEO, analytics, testing and launch.