I Came Back From Maternity Leave Feeling Behind. Building Something Changed That.

This is the second post in our Moms in Tech guest blogger series, written by Moms in Tech member Cherie LaFlamme. We are thrilled to bring more diverse voices to our blog, and to highlight the incredible work our members do each day. To learn more about our guest authors, head to their bios at the end of each post, or click here to read our previous guest post. Happy reading!

---

When I came back from maternity leave early last year, I expected the first few weeks to feel like a reorientation to my company. There were roadmaps to review, decisions to get up to speed on, and a few thousand Slack messages to skim (aka mark as read). I figured I'd feel wobbly for a few weeks and normal by week three or four.

What I didn't expect was to feel like I had missed an entire chapter of learning that is vital to my own career trajectory.

AI wasn't new to me. Like many others in early 2025, it was already part of how I worked, helping me draft requirements, pressure-test analysis, and tighten my external communications. But somewhere in those months it stopped being one more tool and became the baseline everyone was already working from. Conversations that used to be about prioritization now included agents, MCP servers, and prototypes built without a single engineer. On LinkedIn, I would see founders shipping products over a weekend. Job descriptions for roles I was more than qualified for started listing "experience building with AI."

For the first time in my career, I felt behind.

If you've ever come back from leave, you know that feeling of being out of the loop isn’t really about technology at all. It’s wondering whether everyone else kept growing while you were focused on something else, doing something that mattered more.

My instinct was to read my way out of it. I subscribed to the newsletters peers recommended, listened to AI podcasts on my drives to the grocery store, and watched tutorials after my baby went to sleep for the night. For a while that felt like progress and I was learning…conceptually anyways. But every episode pointed me toward another tool, and every tool came with a founder who had a very good explanation of why theirs was the one that mattered, and none of it added up to anything I could actually do. A month of that, and all I had was a list of browser tabs and apps I'd opened once.

I could have told you precisely how I used AI in my day to day. At that time, though, I couldn't yet tell you how I'd use it to build something that didn't exist yet. That was the real gap, and no amount of reading was closing it.

The question that changed my approach

One afternoon I asked myself something I'd normally ask a candidate: if I were interviewing for a product role next month, what story would I want to tell?

The answer obviously wasn't "I read everything published about AI this year." It was, "I found a problem worth solving, built something, put it in front of people, and learned from what happened."

That answer has nothing to do with AI. It’s the job I’ve been doing my entire career, and that piece hadn’t changed while I was gone. What had changed was how much of it one person could now do on her own, in a weekend, without a team behind her.

So I stopped trying to “learn AI” by listening to yet another podcast and picked one small thing to build. Start with a problem that's already in your life

The worst question to start with is "what could I build with AI?" The better one is "what have I complained about three times this month?" We spend our careers solving other people's problems and forget that we're customers too, with a whole backlog of friction we've learned to live with.

Here are three examples from my own head, all small enough to finish in a weekend:

• The 5:30 problem. I don't need more saved Instagram recipes, I need something that looks at what's actually in my fridge and tells me what to make. Type "chicken, half a bag of spinach, rice, toddler who won't eat anything spicy, thirty minutes" and get a few curated options.
• The birthday you find out about on Thursday. The party is Saturday and you're going to spend twenty minutes on Amazon at 11pm choosing a bad gift. Build a place to keep what you already know about the kids in your life, what they're into, what you gave them last time, and have it turn that into two gift ideas whenever you type a name.
• The re-entry brief. Coming back from leave means reconstructing three months of context from Slack scroll and guesswork. Point something at your team's roadmap, the recent announcements, and your old notes, then ask what changed and what to ask in your first one-on-one.

None of these has to become a business. It only has to solve one real problem for one real person, and you're allowed to be that person.

Keep it smaller than feels right, then ship it early

What I actually built

My first instinct was to build something ambitious, which is the product manager in me. That instinct is an asset when you're leading a team and a liability when you're learning, because big projects are terrible teachers. They take too long to give you feedback, and feedback is the entire point. My rule became simple: if I couldn't picture finishing it in a few days, it was too big. I had to focus on keeping the build smaller than I’d typically imagine, shipping it early, and iterating from there.

My first build came out of a habit I couldn't break. Every time I had a new idea, I started the same way: write down what I was assuming, work out who it was actually for, sketch the workflow, name what could go wrong, cut it to something testable. None of that is hard and I've done it hundreds of times, but it was enough friction that ideas sat in my notes app for weeks (where most of them eventually died, RIP ideas).

So I built the thing I wanted someone to hand me. It helps you on the path to building:

• Friday you pick a small, real problem.
• Saturday you use AI to scope it down to something you can actually finish.
• Sunday you build it and put it in front of one person.

Along the way it asks the questions I'd ask anyone else: what are you assuming here that you haven't checked, who has this problem badly enough to change what they're doing today, what's the smallest version you could show someone this week. You come out the other side with a physical record of what you built, why you built it that way, and what happened when someone used it. "I've been using AI" is a sentence anyone can say in an interview. A document that walks through a problem you found, the calls you made, and what a real person did with it is evidence. Whatever you build this weekend, write yours up into a deliverable. That page is your AI portfolio, and contrary to what you might think, not a lot of people have one yet.

What actually changed

I'm a product builder now, which is not a sentence I would have written before I went on leave. Problems that used to end up in a note somewhere end up as something I can use, and that only happened because I stopped simply reading about the work and started just doing it. Watching other people build isn’t the same as building. It all started to feel real when I finally started making things myself.

The part I didn't see coming is what it changed about the work itself. I've spent a long career building things that mattered to customers, which is what I love to do.

But everything I build has to earn its place. It needs a customer, a business case, a quarter it fits into, and a team with room to take it on. For the first time, I have the tools to build something myself, without a developer, simply because I want it to exist. That’s pretty empowering!

Your homework

Give yourself thirty minutes and write down every time this week you've said some version of:

• "There has to be a better way to do this."
• "I do this every single week."
• "I wish someone would just build..."
• "I always forget to..."

That list is your backlog: pick the smallest thing on it, sign up for an account on Lovable, Replit, or Cursor, build something small enough that you can get done by Sunday, and show it to a person who will tell you the truth about it (it’s not so scary; in fact, your friends and family will probably be very impressed!). Then start on the next one.

I say this to people all the time and I believe it more now than when I started saying it: if you can define a problem, you can write a prompt, and if you can write a prompt, you can build a product. Defining the problem clearly is still the hard part, and it happens to be the part many of us were trained for. The rest of it gets simpler and more accessible to more and more people every month.

About the author

Cherie LaFlamme is VP of Product at Green Check, where she leads product strategy for a fintech platform serving highly regulated industries like cannabis and gaming. She's also the author of Greetings from Tucson and mom to a toddler. She writes about building with AI, returning to work after leave, and doing product well. Find her on LinkedIn.