1. HR has to go through an “ego death” to evolve

Jessica didn’t sugarcoat it — moving to a People Ops as a Product model requires letting go of traditional HR identity.

For years, HR has been structured around compliance, administration, and process ownership. And in many organizations, power has quietly come from being the “keeper of the keys” — the one who knows the policies, owns the process, and controls the workflow.

But that model doesn’t scale in today’s environment.

“You almost have to go through a bit of an ego death… The way that we’ve been doing things for the past five or ten years just isn’t working anymore.”

To operate as builders instead of responders, we have to release the idea that running the process equals creating value. The shift is from owning tasks to owning outcomes. From protecting compliance to driving impact.

And yes — that can be uncomfortable.​

2. Stop being the glue bottle. Start building the machine.

One of the most practical takeaways: most People teams are drowning in “human operations.”

They’re running onboarding. Processing paperwork. Managing the performance cycle. Fielding Slack messages. Chasing signatures. Keeping everything barely on the rails.

The result? No time to improve anything.

Jessica’s advice is simple but bold: fix your own internal operating system first — even if things get temporarily messy.

“We have to just have six months of being really bad at keeping this stuff on the rails… because we’re restructuring how we work.”

That might mean:

• Automating manual workflows
• Building manager self-serve systems
• Introducing ticketing instead of ad hoc Slack requests
• Accepting short-term friction to create long-term leverage

You can’t build a product if you’re manually pumping the gears all day.

3. The power of solving the real problem (not the loudest one)

Jessica shared a story about a company struggling with “feedback culture.” Employees said feedback wasn’t working. Tension was rising. Managers were frustrated.

The traditional response? Buy a new feedback tool.

Instead, her team ran user research and discovered the real issue: people were giving feedback in pull requests using question marks, thumbs down emojis, and vague comments.

That small behavior was poisoning the experience.

So instead of buying software, they built a lightweight Chrome plugin that prompted engineers to give structured, useful feedback in real time.

“We didn’t spend money on a new tool. We found the root cause, built something small, and zapped it.”

That’s product thinking.

Start with the problem. Run research. Ask “why” five times. Ship the smallest possible intervention. Measure impact.

Don’t solve what’s easy to buy. Solve what’s actually broken.

4. Not everyone wants to be “transformed” by work

This was one of the most thought-provoking parts of the conversation.

Jessica challenged the assumption that everyone wants their job to be their purpose.

“Some people really happily want to go to their job, have a good time, get paid well, and be transformed by their life outside of work.”

For years, companies have over-indexed on purpose-driven messaging. But when layoffs hit, when AI reshapes roles, when economic reality shifts — that narrative collapses.

If the real job-to-be-done for employees is:

• Stability
• Fairness
• Good pay
• Flexibility
• Opportunity

Then People teams should design around that — not around aspirational transformation.

When we misdiagnose what employees actually value, trust erodes. And once trust breaks, it’s hard to rebuild.

5. Lightweight user research beats heavyweight surveys

You don’t need a massive engagement survey to start operating like a product team.

Jessica shared two simple practices:

I. Structured 1:1 research conversations.​
She runs recurring conversations with employees using the same four questions to surface themes over time.

One of them?

“If Talentful went bankrupt in two years, what would you say was the beginning of the end?”

That question surfaces strategic insight — not surface-level complaints.

II. Message testing before major communications.​
Before sending a big policy update, she pulls five random employees into a quick huddle, has them read the draft, and asks what they understood.

It’s scrappy. It’s fast. It’s incredibly effective.

Product teams don’t guess. They test.

People teams shouldn’t either.

6. Yes — this works even if you’re a team of one

One of the biggest myths is that People Ops as a Product requires a big team, engineers, and complex squad structures.

It doesn’t.

“People as a product is a philosophy as much as it is an operating method.”

If you’re a team of one, you can still:

• Frame problems clearly
• Write hypotheses before launching initiatives
• Ship in sprints
• Share a roadmap
• Prioritize based on business impact

The shift is mental before it’s structural.

And in many ways, it’s easier to change direction when it’s just you.

‍