When I first heard about Claude Code, I assumed it wasn’t for me.
The name alone put up a wall. I’m not an engineer. I don’t have a technical background. I’ve spent years as a product manager navigating that particular flavor of imposter syndrome where you’re surrounded by people who can build things, and you’re the one writing the docs about what they should build. Using something called Claude Code felt like showing up to the wrong party.
It took me a while to get over that framing. I’m glad I did.
At Wealthsimple, I work on the ledger: the system behind the records of money and assets moving through the platform. Technically dense, low glamour, and high stakes. Understanding how something works often means piecing together documentation, code, and conversations with people who hold different parts of the context.
Over the past few weeks, I’ve been using Claude Code to get closer to that work. Three experiments have been useful enough to become part of how I do my job.
Giving people something to react to
Earlier this month, I ran a user testing session for a tool my team was building. Partway through, users flagged interface issues and inconsistencies we hadn’t caught earlier. They were immediately apparent once someone had something interactive to try, but easy to miss in a document.
That session pushed me to build a better prototyping process.
I started using Claude Code to create clickable prototypes informed by our existing interface patterns, with mock data shaped like the information the real product would display. Users could move through a familiar-looking screen and react to specific fields, choices, and interactions.
That gave us a more concrete conversation to have before committing engineering time.
I’ve spent plenty of time knowing roughly what I wanted to test and waiting until someone else could build enough of it to find out. Being able to make an early version myself shortened that wait. It also made me work through details I might otherwise have left vague in a requirements document.
I still need engineers’ judgment about what belongs in production. But I can bring them something more useful to discuss.
Making scattered knowledge easier to find
One of the most complex areas I work in is trade corrections. Understanding a workflow can require reading code, finding the right documentation, and asking someone who remembers why a decision was made.
That context takes time to assemble, especially when you’re new to the domain.
I built a custom skill, a reusable set of instructions, that helps Claude investigate questions about those workflows. It searches relevant documentation and code, then returns a structured explanation with references I can check.
Building it required substantial work on my end first. I had to validate data patterns, cross-reference documentation against code, and distinguish findings I trusted from assumptions that still needed checking.
That was a useful part of the process. Writing instructions for something else to follow exposed where my own understanding was incomplete.
I also started keeping a record of validated findings across sessions. Otherwise, I’d find myself reconstructing context I had already worked hard to understand.
The result gives me a faster starting point for investigating a question. I still have to read the references, check the explanation, and recognize when something doesn’t add up. The more I understand the domain, the better I am at doing that.
Spending less time assembling updates
Some recurring parts of my job involve gathering information from several places and turning it into something another person can quickly understand.
My weekly update is one of them. The raw material lives across project tickets, Slack conversations, documents, and code changes. Before I can write anything useful, I have to reconstruct what happened.
I built a skill that gathers that material and drafts an update for my review.
I did something similar for my daily standup. It pulls together recent activity, asks me about the subjective pieces it can’t infer, and compiles a draft.
I still decide what matters, what needs context, and what I’m comfortable sharing. Starting with the information assembled leaves me more attention for those decisions.
What I haven’t figured out yet
User research synthesis is one area where I’m still dissatisfied. I’ve tried using Claude to find patterns across interview notes and feedback, but the outputs feel thin compared with what I get from doing the work manually. I suspect there’s more I could do with the instructions and context I provide. I haven’t solved it yet.
I’m also learning when to stop.
Some long research sessions help me make connections I wouldn’t have made otherwise. In others, I start treating the length of the session as evidence that I’m being thorough. Sometimes I should have stopped an hour earlier and done the hard thinking myself. It’s difficult to tell the difference in the moment.
Then there’s the work that still needs a direct human conversation: a stakeholder who needs to feel heard, a team dynamic that needs attention, or a disagreement about what we should prioritize. Those situations ask something different of me.
Every artifact I use from Claude Code goes through my review. I’m responsible for the update I send, the prototype I put in front of users, and the explanation I bring to an engineer.
I started out wondering whether a tool with “Code” in its name had anything to offer me. Now I have a more useful question to ask: where am I waiting on an artifact I could make well enough to move the conversation forward?
A clickable prototype has been one answer. A draft update has been another. Both have given me a way to learn by doing, even while I’m still figuring things out.