Turning People Teams into Problem-Solving Teams

🗒 Summary

Luke and Chris joined us to make the case that the future of People teams isn't about better HR services. It's about treating work itself as a product, and organising around the problems that get in the way of customer/user progress.

📡 The Big Ideas

👉 Work is the product - not HR services The most important reframe in the session. Don't apply product thinking to make HR better. Apply it to understand and improve the experience of work itself, which is bigger than any one function. HR services are a means to an end, not the end.

👉 Great people teams are obsessed with problems, not solutions The default mode for people teams is to start with the solution - a programme, a process, a roadmap item. The product mindset inverts this. Start with the problem. Organise capability around finding and solving the right problems. Solutions only matter if they respond to something real.

👉 Work is a subscription product Employees are not passive recipients of HR services. They are users who choose, every day, whether to engage. If the product of work isn't valuable enough, they leave. That framing changes everything about how you think about your role.

👉 Every system is perfectly designed to get the results it gets If you want different outcomes from your people team, you need a different operating model. Trying to improve a broken HR system produces better broken HR. The shift is architectural, not incremental.

👉 Problems are opportunities, not failures HR culture tends to treat problems as things to hide or fix quickly. Product culture treats problems as the raw material for value creation. A problem is just a friction that's getting in the way of someone's progress. Finding it is the job.

⚡ The Framework: How to Find and Define Problems Worth Solving

Step 1: Understand your user Get specific about who you're thinking about. New employees? A specific role type? A particular office location? The narrower and higher fidelity the cohort, the better. When and where does this person experience the thing you're trying to understand?

Step 2: Understand the job to be done What is this person actually trying to achieve? Push past the surface. The classic example: McDonald's discovered people weren't buying milkshakes because of the flavour. They were buying them to fill time on a solo commute. The job to be done was something completely different from what the product team assumed.

Step 3: Map the friction What's getting in the way of that progress? What does the person do as a workaround, and why? What does that workaround cost them in time, stress, or quality? Look for desire lines - the unofficial paths people take because the official one is harder. Those are your richest signals.

Step 4: Understand the enterprise perspective Is there a business case for solving this? Does it align with company strategy and goals? You're looking for the intersection of user value and enterprise value. Both conditions need to be true.

Step 5: Write the problem statement Only once you've done the above. A good problem statement describes who is struggling, with what, under what conditions, and what the impact of that friction is. The iPhone example: "People struggling to stay connected and get things done while on the move, because existing tools are fragmented and difficult to use."

⚡ The User Problem Definition Canvas

A practical tool Chris shared for structuring discovery. For any problem you're exploring, map out:

• Who - which specific cohort of employees, in what context
• When and where - time, place, physical or virtual setting
• Job to be done - what are they actually trying to accomplish, and why
• Current experience - what happens today, what helps, what gets in the way
• Workarounds - what do they do instead, why does that work, where does it fall short
• Impact - what becomes harder, slower, riskier, more costly

This canvas is available to download from the Red Oak website and was shared in the session resources.

✅ What You Should Do: A Practical Step Plan

1. Stop starting with the solution Before your next programme, process, or initiative, ask: what problem is this actually solving? Who has that problem? How do we know? If you can't answer those questions clearly, go back to discovery before you build anything.

2. Go and sit next to someone The most powerful discovery method is observation. Spend a morning with your operations team, or your managers, or your newest joiners. Watch what they actually do. Ask why. The answers you get from shadowing are almost always different from what surveys and focus groups produce.

3. Use the User Problem Definition Canvas Take one problem you're currently trying to solve and work through the canvas. Who, when, where, job to be done, current friction, workarounds, impact. It takes an hour and will almost certainly change how you're framing the work.

4. Find the desire lines in your organisation Look for the workarounds people have built for themselves. Unofficial Slack channels, manual spreadsheets, processes people have quietly stopped following. Each one is a signal that the official path isn't working. Those are your best starting points for discovery.

5. Define your North Star metric What is the leading indicator of employee value in your specific company? Not engagement scores or programme completion rates. Something that, if it improved, you could make a credible hypothesis that work is genuinely getting better for people. Look up the North Star Metric Framework by Amplitude as a starting point.

6. Stop measuring outputs, start measuring outcomes How many programmes you ran, how many tickets you closed, how many people attended - these are activity measures. They tell you what you did, not whether it mattered. Shift your reporting toward outcomes: what changed for people, and what did that change mean for the business?

7. Build cross-functional problem-solving teams The solutions to work problems rarely sit entirely within the people function. You'll need IT, legal, policy, operations. Organise around problems, not functions, and bring the right people in to solve them together.

8. Start with visible leadership commitment Breaking down silos and shifting to a problem-solving model requires someone senior to own the change visibly. If that commitment isn't there, your first job is internal influence. Build the case upwards before trying to shift the system sideways.

💬 Q&A Highlights

How do you break down internal silos and get teams to share goals? (Luke) There's no shortcut here. The root cause of silos is usually territory protection and status games, and those take time to unwind. The single most important lever is visible leadership commitment - a senior person who owns the change and talks about why it matters. Without that, you're likely spending months just getting to zero before you can start making progress.

Does this shift change what people teams should be measured on? (Chris, Luke) Yes, completely. The goal is to move away from volume metrics - programmes delivered, tickets closed, services rendered - and toward leading indicators of employee value. What those are is specific to your company and your people. There is no universal answer. A useful framework to explore is the North Star Metric approach from Amplitude. The question to ask: if this metric improved, could we make a credible hypothesis that the experience of work is genuinely better?

How do you define outcomes in a way that's meaningful to the business? (Luke) One practical approach: identify a small number of durable, multi-year problem spaces where your team will focus. In each space, define a metric that represents the experience improving. For example, in the employment basics space, one company is tracking the proportion of employee needs met well. That metric then ladders up to a broader North Star. It requires some engineering and rigour, but it gives you something real to measure and move over time.

My challenge is to sell to senior leadership to "go fast to go slow". What's the best selling point in your opinion, Chris, to be allowed to start trialing this approach? (Chris) Make the learning curve explicit. If we want a team to develop a genuinely different capability, we cannot reasonably expect it to operate at full proficiency from the first day.

Imagine putting eight physically able people who have never rowed before into a racing boat. Nobody would expect them to become a coordinated, competitive crew simply because someone told them to go faster. We would expect coaching, practice and a period of adjustment before seeing even basic proficiency. Shouting “go faster” wouldn’t create the capability they hadn’t yet developed. Their initial pace wouldn’t tell us what they could eventually achieve.

The military has a saying: 'Slow is smooth and smooth is fast'. It means careful and intentional focus on practicing good form first eventually leads to speed once a group has 'felt' what happens when they establish the basic mechanics of a new movement.

The same applies to changing how a People team works (or any team for that matter). Learning unfamiliar practices and becoming confident using them together takes time and attention. That period of change and adaptation needs to be accounted for, rather than added invisibly on top of everyone’s existing commitments.

But “trust us, we’ll be faster eventually” isn’t a sufficient proposition. Connect the investment to something stakeholders care about - whatever that means for your context - perhaps that is better decisions, less wasted effort, fewer repeated problems or more reliable outcomes. Explain what will change initially, which commitments you will protect, what you will deprioritise and when you will review progress together.

You might start the conversation like this:

“We want to improve our ability to solve [this kind of problem]. To develop that capability, we’ll need some supported practice, and initially that may mean delivering less while we learn. Let’s agree where we can make room for that, what progress should look like and when we’ll review whether the investment is paying off.”

The aim is to make the adjustment period a shared, deliberate investment, with realistic expectations and visible progress, rather than a slowdown stakeholders discover after the fact.

There is also a question of professional confidence. We need to be prepared to say: “If we want this new capability, we have to make room to develop it.” We cannot promise a different way of working while automatically accepting that every existing commitment and expectation must remain untouched. Our role is to recommend what is needed, explain the trade-offs and negotiate a workable agreement. Stakeholders may challenge that recommendation, and we should be ready to discuss it, but we shouldn’t negotiate away the learning time before the conversation has even started.