Recognizing the product thinking you already do

Product, at its simplest, is the department that figures out what to build and why – and makes sure that decision works for the user and the business. But "product" is a much bigger tent than product managers.

It encompasses product operations, product marketing, product analytics, and product communications, and many more roles. Sometimes you're doing product work, and nobody's put the word "product" anywhere near your title.

Five years ago I was singing "Defying Gravity" in a poodle skirt at Ellen's Stardust Diner in Times Square, balancing a tray of burgers over my head.

Today, I'm the Director of Product Operations at Solovis, a B2B fintech SaaS company. I build the tooling, processes, and systems that let our product org actually move.

Nobody would guess those two sentences belong to the same person. That's kind of the point.

I didn't come in through code or an MBA. I walked into my first interview with travel writing clips, university syllabi, and stories about performing on stage. No case studies. No wireframes. Just years of doing the actual work under a different name.

Because here's what nobody tells you: if you were designing for different audiences, translating complex ideas, and adjusting in real time based on feedback (as a musician, a teacher, a waitress, whatever), you were already doing product thinking. You just didn't have the vocabulary for it yet.

Here are the five patterns I see over and over. Chances are you're already running at least three of them.

1. Prioritization under constraints

We prioritize constantly, in every part of our lives. It's the most basic form of product thinking there is: you have limited time, money, or people, so you'd better know exactly what actually moves the needle right now.

During my master's research in the Netherlands, I worked with refugee women, expat women, and local Dutch women, using vocal improvisation to build communication across all three groups. I had almost no funding, very little time, and I was working with people who had lived through real trauma.

Something had to give. I prioritized translating the consent forms – establishing legal and ethical clarity before anything else happened – over almost everything, including documentation. Building trust with these women mattered more than a great reel of footage for my thesis.

So the photos are thin. The video, thinner. The audio? Solid. Beautiful documentation would have made my presentation look better. It would not have gotten these women to trust me enough to open their mouths and sing.

That's the whole job, really. Product managers do it with roadmaps, deciding what ships this quarter and what quietly disappears from the list. Product ops does it by choosing which tools and processes are actually worth a team's time.

2. Segmentation and personalization

Different audiences need different things from you. Full stop.

At Ellen's Stardust Diner, I belted "Defying Gravity" for the tourists – big, loud, showstopping – and the tip bucket confirmed I was right, every single time.

Try that same number at a jazz club, and you'll clear the room. That crowd wants their wine and a low flame, not a Broadway climax in their ear. Same singer, same voice, completely different read on the room – and the difference decided whether people tipped me or told me to keep it down.

That's segmentation. Product managers build personas for exactly this reason: an enterprise customer and a five-person startup don’t want the same feature, at the same price, explained the same way. Product marketing writes different copy for different buyers on purpose. And you're doing a version of this every time you explain the same project differently to your engineer and your VP in back-to-back meetings.

3. Building systems for enablement

Enablement means building something once so people can succeed without you standing over their shoulder.

Between teaching voice at Purdue, a private music school, and my own studio, I had way too many students to write custom exercises for every single one, every single week. That math didn't work.

So I stopped trying to be the bottleneck. I recorded vocal exercises students could run at home. I built peer feedback structures with specific criteria, so students could evaluate each other without me in the room.

Lessons got better, not worse. Students showed up having already done the foundational work, so we spent our actual time together on the advanced stuff. I went from being the ceiling on how fast anyone could improve to being the thing that got out of the way.

Product teams do this constantly – product requirement docs (PRDs) exist so a team has a clear framework without a PM narrating every decision live. Product ops builds playbooks and self-serve tools so the rest of the business doesn't need to book time with us just to move. If you've ever written a one-page FAQ so you'd stop answering the same Slack message for the fortieth time, you've built for enablement.

4. Contextual translation

Translation means telling the same true thing in a different language depending on who's listening.

Ask me what I do for a living, and you'll get two completely different answers. To someone in tech: I'm a force multiplier for product teams – I build the systems and cadences that turn strategy into clear priorities, and I connect the dots between engineering, go-to-market, and customers.

Say that to my family, and you'll get a very polite, very blank stare.

So for them, I use the apps-on-your-phone version: there's a team of people deciding what those apps do next, and my job is making their jobs easier – making sure the builders, the marketers, and the salespeople are actually talking to each other, so what ships solves a real problem instead of a made-up one.

Product managers translate all day, every day: engineering complexity going up to execs, business goals coming back down to engineers. Product marketing turns a spec sheet into a reason someone would actually buy the thing. If you've ever explained the same decision three different ways in the same afternoon, you already know how to do this.

5. Rapid iteration based on signals

Iteration means testing something, watching what actually happens, and changing course based on that, not on what you assumed would happen.

During the shift to virtual lessons, I had a student who could not land a belt (that big, brassy vocal sound) no matter what I tried. Different breath work, different exercises. Nothing landed.

So I stopped adjusting the technique and started watching her. She was holding back, tentative, even when she was doing everything correctly. Eventually I learned why: a previous teacher had told her flatly that her voice was wrong, and she'd hurt herself once already trying to force a belt on her own.

The problem was never technique. It was trust. So I threw out the plan, and we spent weeks on emotional work instead – rebuilding her confidence, showing her what a healthy belt actually feels like in her body – before we chased the sound at all.

That's iteration: test, watch the real signal instead of the one you expected, diagnose what's actually broken, change course.

Tech is living this at warp speed right now – AI has taken product cycles that used to run 24 months and compressed them into weeks. Teams that can't read the real signal and adjust fast end up holding a roadmap nobody needs anymore.

Formalizing what you already know

Write these five patterns down against your own life. Not in the abstract; document the actual stories, actual stakes, and actual outcomes. Those are the stories that belong on your resume and in your interviews, not "results-driven professional with strong communication skills."

You're already doing this work. The only thing left is saying so, out loud, in the language the room understands.

Looking for more career advice from those who've been there, done that? Join our Slack community of 15k+ product professionals and share network with product leaders around the world.

Join the community