PacSun · eCommerce
Operating PacSun’s 2020 Site-Merchandising Roadmap
How I brought a cross-initiative PacSun eCommerce portfolio into one view—making priorities comparable, keeping operating states visible, and carrying the work into leadership and the broader business.
- Owned
- Manager, Site Merchandising — PacSun; managed and maintained the cross-initiative roadmap for leadership and broader-business communication
- Boundary
- This supports portfolio-level ownership, not sole authorship, approval, or execution of every underlying initiative.
2020 roadmap · with late-2019 date-entered context
Operating sequence
One view for unlike work
As Manager, Site Merchandising at PacSun, I managed a 2020 eCommerce portfolio whose work did not arrive in one shape or move on one clock. Site experience, app, copy, personalization, testing and optimization, site merchandising, Drop Ship, and content and operations each involved different specialists, platforms, and business conditions.
I needed one operating view that kept those lanes visible together instead of letting them disappear into separate conversations. The roadmap gave me that view. A customer-facing experience change could sit beside operational work, and a large platform-dependent request could remain visible beside a smaller merchandising change.
The point was not to make unlike work identical. It was to see the portfolio as a whole while preserving the differences that mattered to each initiative.
Give priority a common language
Once the work was visible together, its relative priority needed a common language. I connected a task, where possible, to a key KPI or customer and business need, then considered effort and impact alongside it. Vendor or dependency shorthand and date-entered context kept relevant operating conditions in the same view.
The measures changed with the work. Conversion rate, add-to-cart rate, and bounce reduction were the core KPIs I typically used when prioritizing. Other rows named recommendation click-through, product-detail and product-listing views, average order value, revenue per user, or units per transaction. Not every task carried every field, and no one metric explained the portfolio.
Effort and impact estimates made comparison more disciplined; they did not make it automatic. A helper labeled ROI in some functional views simply subtracted effort from impact. It was not financial ROI, a weighted scoring model, or a required ranking rule.
That combination made the reasoning inspectable. A request could be discussed through the condition it addressed, the work it appeared to require, the impact it might have, and the vendor, dependency, or timing context that traveled with it. The fields informed judgment; they did not replace it.
Turn priority into operating state
Priority then needed an operating expression. The roadmap placed work into four recurring states: Launching, On-Going, Ending Soon, and Upcoming. The same grammar could locate work from different lanes without turning those lanes into one undifferentiated list.
Those labels made the portfolio’s current shape visible without collapsing it into a binary backlog. They did not establish exact transitions: Launching does not prove shipped, Ending Soon does not prove completed, and Upcoming does not prove that an item later launched.
Taken together, the recurring structure suggests a practical loop: identify an initiative; connect it, where possible, to a KPI or customer and business need; estimate effort and impact; surface vendor, dependency, or date context; and give the work a current operating state. That sequence is an inference from the surviving roadmap structure, not a source-stated standard operating procedure.
Priority therefore became more than a statement of desire. It had a visible place in the current field of attention.
Keep the unfinished work visible
Unresolved work remained in the same view as priority and state. Vendor and platform shorthand flagged external or technical boundaries, date-entered context anchored when some work entered the portfolio, and local notes retained operational follow-up. This did not form a complete dependency graph or assign every dependency to an owner. It kept the conditions around the work from disappearing.
The two surviving workbooks preserve the same relationship: **SAME SYSTEM — different versions/stages**. They share the operating grammar and much of the same work, while some states and local items differ. The sources do not establish which came first, whether one was a fork or export of the other, or whether either was more authoritative.
That unresolved relationship does not prove direction or any exact item’s movement. It does preserve a system in which dependencies, notes, timing, and open work could remain visible without being falsely converted into completion.
Carry the portfolio to the business
“I used the roadmap to present priorities into leadership and the broader business.” For that conversation, the operating view brought together what the site-merchandising and eCommerce portfolio contained, why particular work mattered, what effort and impact context surrounded it, and where it currently sat.
The roadmap organized that conversation; it did not authorize the work. The sources preserve no named audience or meeting cadence. Its communication value was simpler: a broader group could inspect what was being considered, what need it served, what conditions surrounded it, and what state it held.
My ownership was at that portfolio level. I managed and maintained the roadmap, prioritized within it, and brought its priorities into the business. The underlying initiative, specialist, operational, technical, and vendor work remained collaborative; managing the view did not make me the executor or decision-maker for every lane.
The durable responsibility was not spreadsheet maintenance. It was maintaining one truthful view of unlike work, making priority reasoning inspectable, keeping unfinished work visible, and carrying the portfolio into the broader business conversation.