One of the products I’ve been working on for the past 18 months at Slice has just launched.

It’s the Slice Ordering Kiosk, a self-service ordering kiosk for independent pizza shops in the US. It gives customers another way to order and helps shops cope with those busy periods when everyone seems to arrive at once.

It’s also one of the first products I’ve worked on that I can physically point at and say, “I helped build that.” I’ve spent most of my career on software products, which can be surprisingly hard to explain to anyone outside the company. A kiosk is rather easier.

The more interesting part of the story, though, is what happened between the original idea and the product that’s now being installed in shops.

Starting with something that already worked

When I joined the Appliances team at Slice in April 2025, the kiosk already existed. Sort of.

A small team had built a proof of concept in a matter of weeks for Pizza Expo in Las Vegas, where Slice set up a coffee shop and visitors used the kiosk to place their orders.

As a proof of concept, it did exactly what it needed to do. It showed the idea worked and gave people something real to react to.

It also benefited from conditions that wouldn’t exist in a real shop. It only needed to work in one place, for a short period of time, with a deliberately simple menu. There was no payment flow, and Slice team members were on hand if anything went wrong.

My job was to turn that into something we could install repeatedly in independent pizza shops, without every installation becoming a bespoke engineering project.

That meant solving a much broader set of problems than the demo ever had to. The kiosk had to handle real restaurant menus, including all the ways it’s possible to customise a pizza. It needed to take payments, print tickets and stay reliably connected. The hardware had to survive a busy restaurant, and our installation teams needed to be able to assemble and configure it without difficulty.

We also had to think beyond installation day. Shop owners needed to know how to use and look after their kiosk, and our support teams needed to know how to help when something went wrong.

Much of the next 18 months was about removing, one by one, the assumptions that had made the original prototype possible.

Designing for independent shops

One of the more interesting constraints was that Slice serves independent pizzerias.

Large restaurant chains can design hardware around a relatively predictable environment. Their shops tend to follow common layouts, operating models and customer journeys.

Independent pizza shops are different. Some have a big lunchtime rush from a nearby school. Others get busy after a local game or later in the evening. Some have plenty of space; others have almost none. The mix of customers varies just as much.

That shaped both the physical and the digital design.

Physically, the kiosk had to stand up to normal life in a busy shop. People lean on it, brush past it and occasionally treat it with less care than we’d like. So it needed to be stable, hard to knock over and designed so that as much of the hardware as possible was protected from tampering.

The ordering experience had its own version of the same challenge. Someone might be in a hurry, carrying a child or ordering for a group. They might use touchscreens all day or hardly at all. And pizza brings its own complexity: sizes, toppings, extras and all sorts of combinations.

The challenge was to make that flexibility available without making the experience feel complicated. That meant being disciplined about what we added. There were plenty of ideas that could have made it into the product, but each one risked adding another step or another decision to what needed to remain a simple ordering flow.

Finding the right physical form

The stand turned out to be one of the harder parts of the project.

We looked at a lot of options. Many of the more affordable ones were really designed to hold information displays and didn’t have the stability or internal space we needed. Others were much closer to the right thing, but difficult to justify commercially.

Eventually I tried Amazon, mostly on a whim, and found a stand designed for restaurant use. It had room for our components, somewhere to mount a payment terminal and, importantly, looked substantial enough for the environment it would be used in.

We ordered a sample and tested it. It was close, but not quite right, so we contacted the manufacturer directly. That turned into a useful working relationship. Together we adapted the stand around our needs, reworking the internal layout, adding a custom tray for the printer and changing the finish.

The version in shops today is based on that original stand, but customised around the product we’ve built.

I like this part of the story because it’s a good example of how product work often happens in practice. We understood our constraints well enough to recognise something that was nearly right, then worked with the supplier to close the gap. And I rather like the fact that one of the most important parts of the product started with a speculative search on Amazon.

Getting into the details

My work on the kiosk moved around depending on what was blocking progress at the time. The Appliances team, ten people plus me, was working across several hardware products at once, so a big part of my job was keeping the kiosk moving forward while making sure the engineering team’s time went where it mattered most.

We broke the project down into three layers:

1. the physical hardware
2. the platform that powers the kiosk and controls that hardware
3. the consumer app that customers interact with when they order

I worked with our product designer on the ordering flow and with our engineers on getting it built. There was plenty of back and forth as we worked through what was desirable, what was technically sensible and what would keep the experience simple.

I also spent a lot of time sourcing and testing hardware: ordering samples, trying different displays and configurations, working with suppliers and making smaller calls about how the components fitted together. Not all of that needed an engineer, so where I could, I took it on myself and left them free to focus on the work only they could do.

Some of those decisions were very practical. A right-angled HDMI cable, for example, kept the cabling less exposed at the side of the display.

Others were about how the product behaves when things aren’t going perfectly. I pushed us to design the setup controls and hidden settings that installers and support teams would need. I also pushed us to think through the less obvious failure states, like a component not being connected, which are easy to ignore when you’re designing the happy path.

Hardware also has a habit of introducing dependencies you can’t solve by writing another ticket. Sometimes you need a different component, a revised physical design or simply to wait for something to arrive. It took longer than we’d initially expected, but around 18 months after I picked up the prototype, the kiosk launched publicly.

There were also more conventional product trade-offs.

Early shop testing showed that some customers wanted to order on the kiosk but pay in cash, so we added a pay-at-counter option.

The bigger debate was about the printer. I argued pretty strongly against including one. Every extra piece of hardware adds cost, complexity and another potential point of failure, and I thought we could design the experience around digital receipts or collection at the counter instead.

Others made the case for keeping it, and in the end the argument came down to speed. We could deliver a kiosk with a printer sooner than we could design and deliver a good experience without one. Framed as “launch now with a printer, or later without one,” it became an easy call, and the kiosk launched with a printer.

A kiosk in my living room

At one point an engineer came to my house and the two of us assembled a complete demo unit in my living room.

It stayed there for several weeks while I tested the hardware, the setup and assembly process and the ordering experience.

It also meant my children had their very own pizza-ordering kiosk. They thought it was brilliant.

My seven-year-old quickly discovered two things. First, there wasn’t much stopping them from adding an extraordinary number of items to an order. At one point they built a basket worth more than $20,000. Second, the name field on the order was free text. “Mr Bum” and various other names soon started appearing on printed tickets.

It was funny, but also useful. People rarely use products exactly as you expect them to, and children are particularly good at finding the boundaries without any concern for what the designer intended.

We haven’t changed the product because of it. One seven-year-old testing a demo, with no money at stake, isn’t enough evidence to justify a design change.

I’m sure the odd college student or late-night customer will find the same joke funny, and there’s something quite playful about that being possible. We don’t want anyone to be offended, but we also don’t want to start policing something that doesn’t yet need policing. It’s a software change if we ever need one, so it’s an easy decision to revisit, and we’ll be watching for it as more real customers use the kiosks.

Preparing everything around the product

As launch got closer, more of my attention shifted to everything that needed to exist around the kiosk for it to work as a product.

I worked with our procurement, installation and distribution teams on the assembly and setup process, documenting what I’d learned from building and testing units myself.

I wrote the first versions of the guidance shop owners use to operate and look after their kiosk, and the internal material that prepares our support teams for when something goes wrong.

I coordinated with other product teams whose systems needed to work alongside the kiosk. I also worked with our go-to-market team on the launch, defining the kinds of shops the kiosk was most likely to suit and helping identify initial customers who matched that profile.

One evening, shortly before the first production installation, I was on a video call with a colleague in Los Angeles, talking them through a dry-run assembly.

It wasn’t quite the product management work I’d imagined myself doing earlier in my career. But it was exactly what needed doing to make sure the product could leave our hands and still work.

The first production install

The first production installation happened overnight, UK time.

I woke up to messages from the team confirming it had gone well. After months of work, our first production kiosk was in a real pizza shop and ready to take orders.

It was exciting, though less dramatic than it might sound. We’d already installed earlier prototypes in shops and spent weeks testing a production-candidate unit, so by that point we were confident the installation would work.

Much of the work had been about reducing uncertainty around what would happen when a unit arrived in a shop. An uneventful first install was the best sign that the work had paid off.

What we don’t know yet

It would be easy to treat launch as the end of the story, but launching doesn’t mean we’re done.

We built the kiosk because we believe that, in the right shops, self-service ordering can help during busy periods. It makes it easier to capture more orders without relying entirely on counter staff, and frees those staff to focus on preparing orders and providing the best service they can.

We’re only now reaching the point where we can test that belief. There aren’t yet enough production kiosks in shops to draw meaningful conclusions about usage or impact, and I won’t pretend otherwise.

The launch proves we can deliver the product. It doesn’t yet prove the product delivers value.

The more interesting questions come next:

• Are we right about which shops benefit most from it?
• How do customers actually use it?
• Where does it get in the way?
• What changes would make it more useful?
• And, most importantly, does it create enough value to justify its place in the shop?

What I’ve taken from the experience

I’ve spent most of my career building software products, so working on the kiosk, and the other hardware products we’re building, has been a useful change of perspective.

Many of the habits are the same. You still need to understand the problem, make uncertain ideas tangible, put things in front of people and learn from what happens. But the feedback loops are slower, and early decisions can be much harder and more expensive to undo.

That has made me more conscious of how much of product work is really about judgement. It means knowing which decisions need more evidence and which are reversible, where to simplify, and where it’s worth getting into the detail yourself.

I’ve also enjoyed how broad the work has been. It has spanned product design, engineering, hardware suppliers, logistics, installation, support and go-to-market, alongside plenty of practical problems nobody anticipated at the start.

That breadth suits the way I like to work. The part I find most interesting is the space between an idea and a working product, when lots of things still aren’t clear and the job is to help a team work through them one by one.

The kiosk is now in shops and taking real orders, and that’s a huge milestone for the team. A lot of credit goes to the engineers and designer I’ve been lucky enough to work with, and to everyone across Slice who helped with the hardware, installation, support and launch. It took a lot of people, plenty of problem-solving and more than a few hardware deliveries to my front door.

Now we get to find out what difference it makes for the shops using it, and how to make that difference bigger.