PIWOW

Home

About

PIWOW

Home

About

PIWOW

Work

About


CATEGORY:

Enterprise Software

YEAR:

2012-2019

ROLE:

UI, UX, User Research, Product Management, Marketing Design, Branding Design

WORK THROUGH THE YEARS:

First pass (2012)

Coming back, this time on purpose (2016)

Redesigning the core DAM

Rethinking Collections

The other hats

A bigger bet: PIM

What I took with me

Image Relay was a small but mighty Vermont SaaS company — a digital asset management platform used by 400+ companies worldwide. I started there in 2012 as a freelancer and came back four years later as their first full-time designer. Over the next two-and-a-half years I owned the entire design function: product, research, marketing site, and a fair bit of strategy.

This is what I got up to.
Woman Side Pose
Setting up a way to work


I'd just come from IBM, where I'd spent a year working on bringing design thinking into the enterprise. When I rejoined Image Relay full-time in 2016, I wanted to bring some of that with me. Less "what should we build next," more "what's the actual problem we're solving."


But before I could change how we made decisions on individual features, I needed to change how we made decisions, period. The team was small, scrappy, and good at shipping. What it didn't have was a shared way of figuring out what to ship and why. So that's where I started.


The process


The first deck I put together wasn't about a feature. It was about us. I pulled the canonical design thinking frameworks together in one place (Stanford d.school, IDEO, IBM) and proposed a slimmed-down version for Image Relay: four phases, Understand, Explore, Make, Reflect.


The point wasn't process for process's sake. It was to give a four-person product team a shared vocabulary for moving from "we think we should build X" to "we know why we're building X, what we're learning from it, and how we'll know if it worked." Each phase had a defined output. Understand produced a clear problem statement and user research. Explore produced multiple solution directions, sketched and pressure-tested. Make produced a scoped MVP. Reflect was where we measured against success metrics and decided what to do next.


Alongside the framework I introduced a project structure: a strategic roadmap split into Near, Mid, and Long term (Cupcake, Birthday Cake, Wedding Cake), themes that grouped related problems together, and a project brief template that every three-month chunk of work had to fill out before it got built.


Redesigning the core DAM


The next big swing was a full redesign of the DAM itself — the heart of the product. This one came with proper user research, multiple rounds of iteration with existing customers, and a rollout plan I'm still proud of.


Rather than flip a switch, we soft-launched to a handful of specific clients first so we could learn in deployment and keep iterating. When we opened it up more broadly, we shipped walkthrough videos I produced and built in a toggle so users could move between the old and new systems on their own timeline. The full rollout took about six months from soft launch to everyone-on-the-new-thing.


We weren't tracking metrics in a rigorous way, but the customer service team became a useful proxy — the new system kept coming up in support conversations as something people genuinely liked. Our customer base grew through that period and attrition stayed very low.

Redesigning the core DAM


The next big swing was a full redesign of the DAM itself — the heart of the product. This one came with proper user research, multiple rounds of iteration with existing customers, and a rollout plan I'm still proud of.


Rather than flip a switch, we soft-launched to a handful of specific clients first so we could learn in deployment and keep iterating. When we opened it up more broadly, we shipped walkthrough videos I produced and built in a toggle so users could move between the old and new systems on their own timeline. The full rollout took about six months from soft launch to everyone-on-the-new-thing.


We weren't tracking metrics in a rigorous way, but the customer service team became a useful proxy — the new system kept coming up in support conversations as something people genuinely liked. Our customer base grew through that period and attrition stayed very low.

Setting up a way to work


I'd just come from IBM, where I'd spent a year working on bringing design thinking into the enterprise. When I rejoined Image Relay full-time in 2016, I wanted to bring some of that with me. Less "what should we build next," more "what's the actual problem we're solving."


But before I could change how we made decisions on individual features, I needed to change how we made decisions, period. The team was small, scrappy, and good at shipping. What it didn't have was a shared way of figuring out what to ship and why. So that's where I started.


The process


The first deck I put together wasn't about a feature. It was about us. I pulled the canonical design thinking frameworks together in one place (Stanford d.school, IDEO, IBM) and proposed a slimmed-down version for Image Relay: four phases, Understand, Explore, Make, Reflect.


The point wasn't process for process's sake. It was to give a four-person product team a shared vocabulary for moving from "we think we should build X" to "we know why we're building X, what we're learning from it, and how we'll know if it worked." Each phase had a defined output. Understand produced a clear problem statement and user research. Explore produced multiple solution directions, sketched and pressure-tested. Make produced a scoped MVP. Reflect was where we measured against success metrics and decided what to do next.


Alongside the framework I introduced a project structure: a strategic roadmap split into Near, Mid, and Long term (Cupcake, Birthday Cake, Wedding Cake), themes that grouped related problems together, and a project brief template that every three-month chunk of work had to fill out before it got built.


The roadmap workshop


With the framework in place, I ran a full-day workshop with the team to figure out what we were actually working toward. We worked through Hopes and Fears, mapped the six experiences inside the product, ran empathy mapping, and walked away with three user types we'd carry through everything after: the Governor, the Producer, and the Consumer. From there we turned needs statements into a Now and Later timeline, and the timeline into our first real roadmap, bucketed into three themes: Governance and Sharing, Triggers and Notifications, and Collaboration.

Setting up a way to work


I'd just come from IBM, where I'd spent a year working on bringing design thinking into the enterprise. When I rejoined Image Relay full-time in 2016, I wanted to bring some of that with me. Less "what should we build next," more "what's the actual problem we're solving."


But before I could change how we made decisions on individual features, I needed to change how we made decisions, period. The team was small, scrappy, and good at shipping. What it didn't have was a shared way of figuring out what to ship and why. So that's where I started.


The process


The first deck I put together wasn't about a feature. It was about us. I pulled the canonical design thinking frameworks together in one place (Stanford d.school, IDEO, IBM) and proposed a slimmed-down version for Image Relay: four phases, Understand, Explore, Make, Reflect.


The point wasn't process for process's sake. It was to give a four-person product team a shared vocabulary for moving from "we think we should build X" to "we know why we're building X, what we're learning from it, and how we'll know if it worked." Each phase had a defined output. Understand produced a clear problem statement and user research. Explore produced multiple solution directions, sketched and pressure-tested. Make produced a scoped MVP. Reflect was where we measured against success metrics and decided what to do next.


Alongside the framework I introduced a project structure: a strategic roadmap split into Near, Mid, and Long term (Cupcake, Birthday Cake, Wedding Cake), themes that grouped related problems together, and a project brief template that every three-month chunk of work had to fill out before it got built.


The roadmap workshop


With the framework in place, I ran a full-day workshop with the team to figure out what we were actually working toward. We worked through Hopes and Fears, mapped the six experiences inside the product, ran empathy mapping, and walked away with three user types we'd carry through everything after: the Governor, the Producer, and the Consumer. From there we turned needs statements into a Now and Later timeline, and the timeline into our first real roadmap, bucketed into three themes: Governance and Sharing, Triggers and Notifications, and Collaboration.

Setting up a way to work


I'd just come from IBM, where I'd spent a year working on bringing design thinking into the enterprise. When I rejoined Image Relay full-time in 2016, I wanted to bring some of that with me. Less "what should we build next," more "what's the actual problem we're solving."


But before I could change how we made decisions on individual features, I needed to change how we made decisions, period. The team was small, scrappy, and good at shipping. What it didn't have was a shared way of figuring out what to ship and why. So that's where I started.


The process


The first deck I put together wasn't about a feature. It was about us. I pulled the canonical design thinking frameworks together in one place (Stanford d.school, IDEO, IBM) and proposed a slimmed-down version for Image Relay: four phases, Understand, Explore, Make, Reflect.


The point wasn't process for process's sake. It was to give a four-person product team a shared vocabulary for moving from "we think we should build X" to "we know why we're building X, what we're learning from it, and how we'll know if it worked." Each phase had a defined output. Understand produced a clear problem statement and user research. Explore produced multiple solution directions, sketched and pressure-tested. Make produced a scoped MVP. Reflect was where we measured against success metrics and decided what to do next.


Alongside the framework I introduced a project structure: a strategic roadmap split into Near, Mid, and Long term (Cupcake, Birthday Cake, Wedding Cake), themes that grouped related problems together, and a project brief template that every three-month chunk of work had to fill out before it got built.


The roadmap workshop


With the framework in place, I ran a full-day workshop with the team to figure out what we were actually working toward. We worked through Hopes and Fears, mapped the six experiences inside the product, ran empathy mapping, and walked away with three user types we'd carry through everything after: the Governor, the Producer, and the Consumer. From there we turned needs statements into a Now and Later timeline, and the timeline into our first real roadmap, bucketed into three themes: Governance and Sharing, Triggers and Notifications, and Collaboration.

Lil' Sugar

Tagline

Lil' Sugar

Tagline

Project Carbon

Tagline

Project Carbon

Tagline

©MatthewPerryGerardPiwowarski

©Matthew

Perry

Gerard

Piwowarski

©MatthewPerryGerardPiwowarski