I bought a used Sprinter 2500 with 90,000 miles on it and turned it into a family adventure vehicle. I designed the layout, ran the electrical, built the furniture, and made about a hundred decisions I had to live with permanently. No do-overs once the bolt is in the wall.
It was one of the best product management education I've had since guiding fly fishing trips in Colorado.
There's something about building a physical thing for people you love, inside a space that doesn't forgive bad decisions, that surfaces every product principle in a way no sprint retro ever could. When you can't ship a patch, you learn to think differently.
You Can't Interview Your Users. You Live With Them.
I knew my users intimately. My partner, my son, two dogs (one of them a Bernese Mountain Dog who takes up roughly the square footage of a small couch), our gear, how we actually travel. I knew that mornings start slow and that someone always needs coffee before anyone's ready to talk about the day. I knew we'd need storage for hiking boots, fishing rods, ski gear, and whatever the Bernese decided to drag in from outside.
And I still got things wrong.
I built my son a dedicated bed, measured it carefully, planned the whole thing out. It didn't work. The dimensions weren't right for how he actually slept and moved in the space. That bed is now storage. I also built our main bed as a permanent feature, a fold-in-half design that I was sure we'd use constantly for overnight trips. Turns out we do far more day trips than overnights. The bed works great when we use it, but we over-indexed on a use case that wasn't our primary one.
The gap between what people say they need and what they actually use is real even when you know them as well as you know your own family. I'd asked the right questions. I'd observed how we traveled. But observation before the thing exists is different from observation after. You can't fully understand how someone will use a product until they're using it.
In product work, this is the trap of the pre-launch assumption. You can run all the discovery you want, build detailed personas, conduct fifty interviews. The moment the product hits real hands in real conditions, you learn something the research couldn't tell you. The best PMs I've worked with treat launch as the beginning of understanding, not the end of it.
Constraints Are a Gift
A Sprinter 2500 170 wheelbase gives you a fixed box to work with. You can't negotiate with the walls. You can't add another room. Every decision about what goes in is simultaneously a decision about what doesn't and with a Bernese Mountain Dog who needs floor space to sprawl, the non-negotiable footprint starts eating into your plans fast.
This forced a clarity that most product work never achieves.
When I was laying out the floor plan, I went through maybe fifteen iterations on paper before cutting a single piece of wood. Bed placement dictated storage access. Storage depth dictated walkway width. Counter length dictated where the electrical panel could go. Every choice cascaded. Every cubic inch carried weight.
In software, the constraint is rarely this tangible. You can always add another endpoint, another settings panel, another modal. The backlog grows because it's cheap to say yes and expensive to say no. But the cost isn't zero. Every feature adds cognitive load, maintenance burden, surface area for bugs. The space just isn't as visible as the inside of a van.
The van made me a better prioritizer because the consequences of over-building were immediate and physical. If I added a bigger water tank, I lost under-bed storage. If I built deeper cabinets, the sleeping surface narrowed. There was no version of "we'll figure out where to put it later." The space didn't allow ambiguity.
I think about this constantly in product planning now. Not "can we build this?" but "what does building this cost us in terms of everything else?" The answer is always something. The van just made it impossible to pretend otherwise.
Irreversibility Changes How You Think
Once you drill a hole in the floor of a van to bolt down a piece of furniture, that hole is there forever. You can move the furniture, sure. But the hole stays. Every structural decision leaves a scar.
This changed how I approached the entire build. I found myself naturally sorting decisions into two categories: the ones that could be undone and the ones that couldn't. Reversible decisions, I made fast. The color of a cushion cover. The type of latch on a cabinet. The mounting position of a light that was held on by magnets. These I could try, evaluate, and change without consequence.
Irreversible decisions, I slowed down. Where to route the main electrical conduit. Where to cut through the van's metal body for ventilation. The height of the fixed bed platform that would determine storage dimensions for the life of the build. I measured these three times, mocked them up with cardboard, sat with them for a day, and then committed.
Most product teams have this exactly backwards. They agonize over reversible decisions, running them through committees and approval chains that add weeks to things that could be changed tomorrow with a config update. Meanwhile, they rush the irreversible ones. Database schema that will be painful to migrate. API contracts that external partners will build against. Pricing models that set customer expectations. Architecture decisions that calcify into assumptions nobody questions.
Jeff Bezos wrote about this as Type 1 and Type 2 decisions, and he's right, but I didn't fully internalize it until I was staring at a hole I'd drilled in the wrong spot and realizing I'd be looking at that hole every time I opened the back doors for the next decade.
Categorize the decision before you decide how much process it needs. Move fast on the things you can undo. Move carefully on the things you can't. Simple rule, hard discipline.
Building for Delight, Not Just Function
Anyone can build a van with a bed and some storage. The internet is full of builds that check the functional boxes: a place to sleep, a place to cook, a place to sit. They work. They're fine.
The decisions that made ours feel like ours were the small ones.
The reading lights mounted at exactly the right height so you can read in bed without the light hitting your partner's face. The way the rear doors open to frame whatever you're parked in front of, because I designed the interior to look good from that angle, not just from inside. The specific placement of the USB ports, because I watched where we actually sat and reached before I committed to drilling.
None of these were on the original plan. They emerged from paying attention during the build and during early trips. They're the kind of decisions that nobody notices individually but everyone feels collectively. The van just works. Things are where you reach for them. Nothing snags. Nothing frustrates.
Delight isn't a feature you ship. It's the cumulative result of a hundred small decisions made with the user actually in mind. It's the loading state that doesn't make you anxious. The default setting that's already right for 90% of people. The error message that tells you what to do, not just what went wrong. These things don't show up on a roadmap. They show up in retention.
The van taught me to budget time for these decisions. Not as polish at the end, but as a practice throughout. If you only think about delight after the structure is built, you've already locked yourself out of the best opportunities to create it.
The 80% Problem
There came a point in the build when the van was functional but not finished. The electrical still had exposed wiring. The paint wasn't done. Insulation was mostly complete, mostly. But we had a trip to Colorado to visit family, and the van was usable if not polished.
We went.
And that trip broke the build open in ways another month in the garage never would have. We learned that if you sleep at a truck stop, you need serious window covers, not the ones I'd been planning to get around to, but actual blackout covers, because it's impossibly bright at 2am under those lights. We learned that fans are not a substitute for AC when you have a Bernese Mountain Dog who proceeds to rock the entire van all night, panting desperately to cool down. That was a long night for everyone.
Then, on the way back, the high-pressure fuel pump blew outside Buffalo, New York. We got towed. The van lived at a shop there for a month and a half while we rented a car and drove home. That wasn't a product lesson so much as a reminder that hardware has failure modes software people forget about. You can't roll back a fuel pump.
But even before the breakdown, the trip had already done its job. It forced me to confront the difference between "not done" and "not good enough." The exposed wiring didn't matter functionally. The missing window covers did. The incomplete paint was cosmetic. The lack of AC was a real problem for a real user (a 100-pound dog who voted with her whole body). The things that actually affected the experience, I could now prioritize with real data instead of guesses.
In product, shipping at 80% is standard advice. But "iterate" means something different when you're driving your family to Colorado and the thing you shipped is the vehicle. The stakes aren't abstract. If something important is broken, you feel it immediately. That urgency is clarifying. It strips away the perfectionism that masquerades as quality and focuses you on what the user, your family, actually needs to have a good experience.
Most products I've worked on could have shipped weeks earlier if the team had been honest about what was essential and what was anxiety disguised as polish.
The van sits in our driveway now. It's been to Colorado and back six times. Vermont's Northeast Kingdom. The White Mountains. The coast of Maine. Ultra marathons. Ski mountains for day trips. Sports events. It's carried us to more places than I could have imagined when I was sketching floor plans on graph paper.
There are still finishes I haven't completed. Trim pieces that never got installed. Details that exist only in my head. Functionally, it does exactly what we need it to do. It delights us constantly. I dream sometimes about tearing it down and rebuilding it with everything I've learned, but that's a fantasy, not a plan. The van is a part of our family now, imperfections and all.
That's exactly what a good product feels like. Not flawless. Not over-designed. Just honest about what it is, built with real attention to the people who use it, and shaped as much by what you learned after shipping as by what you planned before.
The best products, like the best vans, aren't the ones that try to be everything. They're the ones where every decision was made with someone specific in mind.