I'm a software engineer who spends work hours thinking about products, users, and how to make things that matter. After hours, I work with my hands—wood, leather, garden soil. This is where those worlds meet. Sometimes a hobby teaches me something about my day job. Sometimes my product instincts change how I approach a craft. The lines cross more often than you'd expect. And this series of posts will be about that bi-directional influence.
Some time ago, I had an idea: what if I sold a kit for making a leather wallet—not the full process, but just the final step?
I had already done the hard parts. I had measured, cut, punched holes, installed the push buttons, and glued the zipper. What remained was the stitching. The buyer would receive a nearly-complete wallet, two needles, some thread, and one skill to learn. One weekend, one satisfying project, one personal leather wallet.
The person who bought it told me it was a lovely weekend project. For them, the experience was about creating something without frustration. For me, it was about recognizing where the real barrier was—and removing everything except the one thing that makes the craft feel like craft.
What I didn't expect was how much this little experiment would influence how I think about my day job.
The same is true in software engineering. When a new engineer joins a team, the actual coding is rarely the bottleneck. The barrier is the setup, the domain knowledge, the unwritten rules, the context that lives in someone's head. By the time they write their first meaningful line of code, they've often already felt lost, slow, and unsure of themselves.
I've seen what happens when someone's first contribution is a small, successful one—fixing a bug, shipping a minor improvement. And I've seen what happens when their first task is unclear and goes nowhere. The first one builds momentum. The second one builds doubt.
The wallet kit taught me this in a different material: prep the hard parts, hand over the meaningful part, and let the learner feel competent early.
This is the same tension in product scoping.
When I've worked on launching a new product feature, we spent time in early research before writing a line of code. We looked at existing solutions, built small prototypes, and tested our assumptions. The goal wasn't to ship everything at once. It was to ship the minimum thing that would make a user feel: "Yes, this solves a real problem I have."
We cut features. Not because they weren't valuable, but because they weren't the first valuable thing. The wallet kit works because stitching is the first valuable thing—it's the moment where the pieces become a product. Everything before that is preparation. Everything after that is improvement.
In product, I've learned to ask the same question the wallet kit answers: what is the one action, the one moment of value, that this product delivers? Build toward that. Cut the rest for later.
When I scope a product feature now, I think about the wallet kit. Not literally, but structurally: What am I asking the user to do before they reach value? Can I remove some of it? Am I handing them a pile of pieces and tools, or am I handing them a nearly-complete experience with one meaningful step to own?
When I design any other hobby project now, I think about user research. Who is this for? What do they already know? What will frustrate them, and is that frustration necessary—or is it just there because that's how I learned?
Neither side owns the lesson. They feed each other.
But I've noticed—in engineering, in product, and in craft—that small wins are where bigger things begin. The new engineer who ships a fix on day three comes back on day five wanting something harder. The user who tries a feature and saves time asks what else it can do. The person who stitches a wallet starts looking at leather and wondering about more.
You don't get people to bigger commitments by making the first step harder. You get there by making the first step possible—and letting the satisfaction do the rest.
That's what the kit was really about. Not leather. Not wallets. Just the idea that lowering the barrier to a first win is one of the most generous things you can do—for a teammate, a user, or a stranger who wants to make something with their hands.
I had already done the hard parts. I had measured, cut, punched holes, installed the push buttons, and glued the zipper. What remained was the stitching. The buyer would receive a nearly-complete wallet, two needles, some thread, and one skill to learn. One weekend, one satisfying project, one personal leather wallet.
The person who bought it told me it was a lovely weekend project. For them, the experience was about creating something without frustration. For me, it was about recognizing where the real barrier was—and removing everything except the one thing that makes the craft feel like craft.
What I didn't expect was how much this little experiment would influence how I think about my day job.
Where the barrier actually lives
When I started learning leathercraft myself, I ruined materials. Not because stitching is hard—it isn't, once you try it—but because getting to the stitching required a wall of tools, precise cuts, and mistakes that were expensive to make. The entry cost wasn't the skill. It was everything around the skill.The same is true in software engineering. When a new engineer joins a team, the actual coding is rarely the bottleneck. The barrier is the setup, the domain knowledge, the unwritten rules, the context that lives in someone's head. By the time they write their first meaningful line of code, they've often already felt lost, slow, and unsure of themselves.
I've seen what happens when someone's first contribution is a small, successful one—fixing a bug, shipping a minor improvement. And I've seen what happens when their first task is unclear and goes nowhere. The first one builds momentum. The second one builds doubt.
The wallet kit taught me this in a different material: prep the hard parts, hand over the meaningful part, and let the learner feel competent early.
What product scoping and leather prepping have in common
There's a moment in leathercraft where you decide how far to prepare and where to stop. Cut too little and the user struggles. Prepare too much and you've removed the craft entirely—there's nothing left for them to own.This is the same tension in product scoping.
When I've worked on launching a new product feature, we spent time in early research before writing a line of code. We looked at existing solutions, built small prototypes, and tested our assumptions. The goal wasn't to ship everything at once. It was to ship the minimum thing that would make a user feel: "Yes, this solves a real problem I have."
We cut features. Not because they weren't valuable, but because they weren't the first valuable thing. The wallet kit works because stitching is the first valuable thing—it's the moment where the pieces become a product. Everything before that is preparation. Everything after that is improvement.
In product, I've learned to ask the same question the wallet kit answers: what is the one action, the one moment of value, that this product delivers? Build toward that. Cut the rest for later.
The feedback loop I didn't plan for
Here's what surprised me: the product thinking I use at work started flowing back into my hobbies, and vice versa.When I scope a product feature now, I think about the wallet kit. Not literally, but structurally: What am I asking the user to do before they reach value? Can I remove some of it? Am I handing them a pile of pieces and tools, or am I handing them a nearly-complete experience with one meaningful step to own?
When I design any other hobby project now, I think about user research. Who is this for? What do they already know? What will frustrate them, and is that frustration necessary—or is it just there because that's how I learned?
Neither side owns the lesson. They feed each other.
Small wins, bigger bets
The person who bought that kit wasn't trying to become a leatherworker. They wanted a weekend project that felt good. A small win.But I've noticed—in engineering, in product, and in craft—that small wins are where bigger things begin. The new engineer who ships a fix on day three comes back on day five wanting something harder. The user who tries a feature and saves time asks what else it can do. The person who stitches a wallet starts looking at leather and wondering about more.
You don't get people to bigger commitments by making the first step harder. You get there by making the first step possible—and letting the satisfaction do the rest.
That's what the kit was really about. Not leather. Not wallets. Just the idea that lowering the barrier to a first win is one of the most generous things you can do—for a teammate, a user, or a stranger who wants to make something with their hands.
