← The journal
Design 2026.11.10 · 6 MIN

The System Is the Work: Design the Operation First

I trained as a product designer, then led ecommerce at big retailers. The costliest lesson: design the operation before the product, or the promise breaks.

A product page promising delivery by Thursday sits on top of the operation underneath it: inventory, warehouse, carrier, support, returns, and payments, where the promise can break in the handoffs.

I spent the first part of my career making screens better.

I trained as a product designer. I finished my design degree in Guntur in 2000, then studied at the Royal College of Art in London. I did UX work at Nike, Microsoft, and Ogilvy. Later I led ecommerce at Chico's, JCPenney, and Art Van, and I was Chief Digital Officer at Conn's.

Somewhere along that road, I learned the lesson that changed how I build. The screen is the smallest part of the work. The system is the work.

Key takeaways

  • Every product is a promise. An operation has to deliver it. Design the operation first.
  • Most launches fail in the handoffs: between teams, between systems, between the screen and the store.
  • My method has five steps: the promise, the path, the people, the numbers, and only then the product.
  • Design skills work on organizations too. Point them inside the company.

What does "the system is the work" mean?

It means the real product is everything behind the screen: people, incentives, data, and handoffs. A beautiful interface on a broken operation is a broken product.

I first heard a version of this at Nike. I was presenting commerce platform work I was proud of. A senior leader asked me about incentives, about who inside Nike was motivated to make it work. I had no answer. I tell that story in the moment I stopped thinking like a designer.

That essay is about the moment the light turned on. This one is about what I do now, because of it.

Why should you design the operation before the product?

Because the product makes a promise, and the operation pays for it. If you design the promise first, you find out too late that nobody can keep it.

I watched this happen more than once.

At Microsoft, teams building features next to each other found out six months in that their work did not fit together. The code worked. The experience did not. No one had drawn the full journey.

At JCPenney, the digital team launched a buy online, pick up in store feature that stores could not execute. Marketing celebrated. Operations struggled. The customer suffered. Store associates did not know how to process online returns. The training had not been updated. The systems did not talk to each other. It worked only when we fixed the operations before we marketed the promise.

At Chico's, omnichannel only worked when store incentives lined up with how customers really shopped online. Until then, the people in the store had good reasons not to help.

None of these were design failures in the usual sense. The screens were fine. The system under the screens was not designed at all.

How do I design the operation first?

I use five steps, in order. The promise, the path, the people, the numbers, and then the product.

1. Write the promise in one sentence. What exactly are we telling the customer? "Order by 2 PM, pick up today." "Free returns for 30 days." "Talk to a real person in under a minute." If you cannot write it in one sentence, you cannot keep it.

2. Draw the path. Every step the promise needs, from the customer's click to the final handoff. Every system it touches. Every place where work moves from one team to another. Handoffs are where promises die, so I mark each one.

3. Name the people. For every step, one owner. For every decision, one decider. Then I ask the Nike question: is this person paid and measured in a way that makes them want this to work? If not, fix the incentive before you build anything.

4. Pick the numbers. Which few numbers tell us, every week, whether the promise is being kept? Not vanity numbers. Promise numbers. Orders ready on time. Returns processed in a day. Calls answered in a minute.

5. Then design the product. Now the screen has something solid to stand on. And honestly, the screen gets easier. You know what is true, so you can say it simply.

This is krama, right order. Each step needs the one before it. When I skipped ahead in my early years, it was because I could see step five clearly and wanted to start there. The steps in between were not technical. They were about people. They were the real work.

Why do good products fail in the handoffs?

Because each team optimizes its own part, and nobody owns the space between parts. The customer lives in that space.

A marketing team measured on traffic will push a promise hard. A warehouse measured on cost per order will protect its process. A store measured on store sales will not love online orders. Every team is doing its job well. The customer still has a bad day.

I wrote about this in when alignment is the real bottleneck. Alignment is not a soft skill. It is a structure you design, the same way you design a screen.

How can designers become better operators?

Keep your design tools. Point them inward. Empathy, journey maps, and prototypes work on a company just as well as on a customer.

A designer interviews users. An operator should interview the store associate, the warehouse lead, the customer service agent. They know where the promise breaks. They have usually known for months.

A designer draws a customer journey. An operator should draw the employee journey behind it. Who touches the order? What do they see on their screen? What happens when something goes wrong at 9 PM on a Saturday?

A designer prototypes a screen. An operator should prototype a process. Run the new promise in one store, one region, one product line. Watch it break in a small way before it breaks in a big way.

My design training did not go to waste when I moved into operations. It became more useful. I just aimed it at a bigger surface.

What does this look like with AI today?

The same rule applies, maybe more. AI makes it very easy to build the screen fast. It does nothing to fix a broken operation behind it.

I see teams use AI to ship a feature in a week that the business cannot support for a month. The speed is real. The promise is still empty. I wrote about the risk of building fast without judgment in the vibe coding trap.

So when I start anything new, I still start with a blank page and one sentence: what are we promising? Then I draw the path. The tools have changed a lot since 2000. The order has not.

There is a word I keep close: seva, service. A product is a form of service to a customer. Service is not a screen. Service is a whole chain of people doing their part well. Design the chain, and the screen will follow.

FAQ

What does "the system is the work" mean? It means the real product is the whole operation behind the screen, including people, incentives, data, and handoffs. A great interface fails if the system behind it cannot keep the promise.

Why should you design the operation before the product? Because every product makes a promise that an operation has to deliver. If you design the promise first, you often find later that stores, warehouses, or teams cannot execute it.

What is operating model design? Operating model design is deciding who does each step, who decides what, which numbers you watch, and how work moves between teams, before you build the customer-facing product.

How can designers become better operators? Point the same design tools, such as empathy, journey maps, and prototypes, at the people and processes inside the company, not only at the customer screen.

One question for you

Think about the last promise your company made to customers. Who owns the space between the teams that have to keep it?

Satya Sivunigunta
Advisory

Work with me

An operator's honest read for founders, owners, and CEOs. One sharp session, a full diagnosis, or a fractional seat.

See the three ways to work
Keep reading

The Best Marketers Now Build Systems. So Should Every Leader.

Next essay