Guide
Your team is a design problem: a manager's guide to design thinking
How to lead a team with design thinking: empathize, define, ideate, prototype, and test, applied to the people you manage, with steps for each stage.
Your team is a design problem because it has users (your people), a goal (good work that people want to keep doing), and constraints (time, budget, personalities). Design thinking gives managers a simple loop for solving it: understand each person, name the real problem, try a few ideas, test them small, and keep what works. You don’t need a design degree. You need curiosity and the willingness to stop assuming everyone works like you.
Why treat a team like a design problem?
Because the way most of us learn to manage doesn’t work very well.
Most new managers get promoted for being good at the job, not for being good with people. Then they manage the only way they know: the way they’d want to be managed. Sometimes that works. Often it doesn’t, and nobody can say why.
Designers have a rule for this. You are not your user. What feels obvious to you isn’t obvious to the person on the other side of the screen. Good designers go find out what the user actually needs before they build anything.
Most managers never learn the team version: you are not your team. My co-founder Laura wrote about learning it the hard way in You are not your team: the mistake most new managers make. It’s the starting point for everything in this guide.
What design thinking changes
| The usual way | The design-thinking way |
|---|---|
| Assume people work like you | Find out how each person actually works |
| Treat a conflict as a personality problem | Treat it as a system problem you can redesign |
| Fix things with a big reorganization | Run small experiments and keep what works |
| Judge success by your own comfort | Judge it by how the team works and feels |
| Hire for the résumé | Hire for the person and the team they’re joining |
None of this is soft. Empathy isn’t a soft skill. It’s the method.
How I learned to treat my team like a design problem
I’ve spent nearly 20 years building products and teams, and my background is in design thinking. So when I was handed the people side of a digital marketing team at our previous company, I did the only thing I knew how to do. I treated it like a product.
Some context. Laura had been asked to rebuild that team with no management experience. She hired résumés, not people. Hires didn’t last, clients left, and everyone was stressed. The business was growing, but the way the team was being managed wasn’t working. Laura will tell you herself that she put me in charge because she was short-staffed, not out of brilliance.
Here’s what I did, in plain terms:
- I went through the team’s existing personality assessments and actually decoded them, so the results meant something to the people they described.
- I put everyone on one page, so I could see the whole team at once instead of one person at a time.
- I reframed opposing work styles as balance instead of friction.
- I defined everyone’s role, because nobody really knew who owned what.
- I redesigned how we hired, onboarded, and handed out work.
The same roles that had failed before started to work. The team stayed together, and they say they love their jobs. During 2025 and 2026, the firm didn’t lose a single client because of dissatisfaction with its service. When an operations consultant asked Laura how, she said: “Put Billy in charge.”
I want to be careful here. That happened at our previous company, before Woosah Teams existed. It’s our experience, not a product result. But it’s why we believe the method works, and why the rest of this guide is built on it.
Stage 1: Empathize. How do you actually get to know your team?
Empathy is where design starts, and it’s where most management skips straight past.
In product work, empathy means watching real users, asking open questions, and setting your own assumptions aside. With a team, it means learning how each person takes in information, makes decisions, collaborates, and handles stress. Not how you think they do. How they actually do.
What to look for
Pay attention to four things for every person on your team:
- How they take in information. Do they want the big picture first, or the details? Written or spoken? Ahead of time, or in the room?
- How they make decisions. Fast and on instinct, or slow and deliberate? Alone, or by talking it out?
- How they collaborate. Do they recharge by working with others, or by working alone? Do they like to be checked on, or left to it?
- How they handle stress. Do they get louder or quieter? Do they speed up or freeze? What does a bad week look like from the outside?
These are the same things a good work-style assessment helps you see. An assessment gives you a shared language fast. But it’s a starting point for conversation, not a verdict.
Manager actions for this stage
- Hold a “how do you work best?” one-on-one. Ask each person directly. Some good questions: “How do you like to get feedback?” “What does a great week look like for you?” “What should I do when you seem stressed?”
- Watch more than you ask. People don’t always know their own patterns. Notice who goes quiet in meetings, who replies at 11 p.m., who asks for the brief twice.
- Check your own defaults. Write down how you like to work, then circle every place you’ve been treating that as the team’s default. That list is your blind spot map.
A word on neurodivergence: some of your people experience work in ways that are very different from you, and they may not have told you, or may not know themselves. Empathy here means making room for different ways of working without asking anyone to explain or justify themselves.
Stage 2: Define. What is the real problem?
Once you understand your people, you can name the problem you’re actually solving. This is the stage most managers rush, and it’s the one that matters most.
The presenting problem is rarely the real one. “Jordan is difficult” is not a problem statement. It’s a frustration. A designer would ask: difficult for whom, when, and why?
Turn complaints into problem statements
A good problem statement names the people, the need, and the friction. Try this format:
[Person or group] needs [something] because [reason], but right now [what gets in the way].
Some examples:
- “Our planner needs decisions explained before she commits, because she’s accountable for the timeline, but right now I announce decisions in the meeting without context.”
- “The team needs to know who owns client follow-ups, because three people are doing it inconsistently, but right now nobody’s role says it’s theirs.”
Notice that none of these blame a personality. Every one of them points to something you can change. Almost every people problem is a management problem. That’s good news. It means the fix is usually in your hands.
Look for role confusion
In small companies, everybody wears several hats and nobody has defined them. That creates a lot of friction that looks like personality conflict but isn’t.
Clear roles are to a team what clear navigation is to a product. When people know where things live, they stop bumping into each other. If two people keep clashing, check whether they’re both responsible for the same thing before you decide they just don’t get along. More on this in our glossary entry on role clarity.
Manager actions for this stage
- Rewrite your top three frustrations as problem statements. Use the format above. If you can’t fill in the “because,” you don’t understand the problem yet. Go back to Stage 1.
- Map who owns what. List the recurring work on your team and write one owner next to each item. Gaps and overlaps will jump out.
- Look at the whole team, not just individuals. Put everyone’s work styles side by side. Where do styles cluster? Where do they contrast? What does nobody on the team naturally do? That’s how you start to see team dynamics instead of a list of individuals.
Stage 3: Ideate. How do you come up with better ways to work?
Ideation is where you generate options before you pick one. The rule is simple: go wide first, judge later.
Managers tend to jump to the first fix that comes to mind, usually the one that worked for them. Resist that. You’re designing for your team, not for yourself.
Reframe contrast as balance
This was the biggest shift for my team, and it’s the one I’d push every manager to try.
Take a manager who decides fast, on instinct, and a direct report who is deliberate and pragmatic. Left unseen, that’s friction. The manager thinks the report is slow. The report thinks the manager is reckless. Both are a little bit right, and both are frustrated.
Once you see it, it becomes a better decision-making system. One talks decisions through. The other nudges toward action. Together they make faster and better calls than either would alone.
I wrote a whole post about this: Opposite work styles: how to turn friction into balance. The short version is that most “personality clashes” are two useful strengths that haven’t been introduced properly.
Spot the pairings that already work
Ideation isn’t only about fixing what’s broken. Look for the pairs and trios on your team that already click, and figure out why. Maybe one person sees the big picture and the other loves the details. Maybe one thinks out loud and the other is a great listener. Once you know why a pairing works, you can lean into it on purpose instead of leaving it to chance.
Manager actions for this stage
- List at least five ideas for each problem statement. Include a few silly ones. They loosen up the good ones.
- Ask the team. People closest to the problem usually have the best ideas. Ask them in a way that fits how they work: some will speak up in a meeting, others will send their best idea in writing the next day.
- Pair contrast on purpose. For one upcoming project, pair two people whose styles balance each other, and tell them why you did it.
Stage 4: Prototype. How do you try a change without breaking the team?
In design, a prototype is a cheap, rough version of an idea that you can put in front of people. It’s meant to be thrown away if it doesn’t work.
With teams, a prototype is a small, time-boxed change. Not a reorganization. Not a new policy announced at the all-hands. A two-week experiment with a clear start and end.
What team prototypes look like
| Problem | Prototype |
|---|---|
| Decisions land badly with a deliberate teammate | Send a short written heads-up the day before big decisions, for two weeks |
| Nobody owns client follow-ups | Assign one owner for a month and see what changes |
| Meetings drain the quieter half of the team | Share agendas a day ahead and accept written input |
| New hires feel lost in week one | Add a one-page “how this team works” guide to onboarding |
| Feedback isn’t landing | Ask each person how they want feedback, and try their way for three one-on-ones |
Keep prototypes reversible
The point of a prototype is that it’s low-risk. “We’re going to try this for two weeks and then talk about whether it helped” is a much easier sell than “Here’s how it works now.” It also makes it safe for you to be wrong. You will be, sometimes. That’s the method working.
Prototype your hiring, too
Hiring is one of the biggest design decisions a manager makes, and usually the least designed. Hire people, not résumés. Change one thing in your interviews, like asking how the candidate works best with others, and see what you learn. We dig into this in Hire people, not résumés: what to look for beyond the interview.
Manager actions for this stage
- Pick one problem statement and one idea. Just one. Run it for two weeks.
- Announce it as an experiment. Say what you’re trying, why, and when you’ll review it.
- Define what “better” looks like before you start. Fewer missed handoffs? Less rework? A teammate who says they feel heard? Write it down.
Stage 5: Test. How do you know if it worked?
Testing closes the loop. You look at what happened, ask the people affected, and decide what to keep, change, or drop.
Most managers skip this step, then wonder why nothing sticks.
What to look at
You don’t need a dashboard. You need honest answers to a few questions:
- Did the friction go down? Fewer tense moments, fewer repeated questions, fewer things dropped between people.
- Did the work get better? Faster decisions, fewer surprises, cleaner handoffs.
- How do people feel? Ask them directly. Then ask again in a different format, because some people won’t tell you in a meeting what they’d tell you in a message.
Then loop back
Design thinking isn’t a straight line. A test often sends you back to Stage 1 or Stage 2 with a sharper view. That’s normal. Teams change, and you’ll run this loop for as long as you manage people.
Manager actions for this stage
- Hold a short retro at the end of every prototype. Three questions: What worked? What didn’t? What should we try next?
- Keep what works and make it official. If the written heads-up helped, it’s now just how you share decisions.
- Drop what didn’t work without drama. “We tried it, it didn’t help, here’s what we learned” builds more trust than pretending it worked.
- Update your notes on each person. You know them better now. Write it down.
What does this look like across a whole team?
Each stage is useful on its own. The real power shows up when you put them together and look at the whole team at once.
When I put everyone on one page, I stopped managing a list of individuals and started seeing a system. I could see where styles clustered, where they clashed, where nobody covered a gap, and which pairs worked well together. That changed how I assigned work, how I ran meetings, and how I hired the next person.
Laura took the same approach to the sales-driven side of the business. One employee leadership had wanted to let go was promoted to manager within a year. Her conclusion was the same as mine: the “bad employees” she’d been warned about on day one weren’t bad. They were being managed in a way that didn’t fit them.
This is what people-first management means to us. Not being nice. Not skipping the hard conversations. Designing the way your team works around the actual people on it, and adjusting as you learn.
It’s also the most reliable path to employee retention we know. People stay where they feel understood and where the work fits how they work.
A quick reference for each stage
| Stage | The question | Your first move |
|---|---|---|
| Empathize | How does each person actually work? | One-on-one: “How do you work best?” |
| Define | What is the real problem? | Rewrite one frustration as a problem statement |
| Ideate | What could we try? | List five ideas and ask the team for more |
| Prototype | What’s the smallest version we can test? | Run one two-week experiment |
| Test | Did it help? | Hold a short retro and decide what to keep |
Common mistakes to avoid
- Leaving yourself out. Your work style is part of the system, too. Understanding communication styles at work starts with your own.
- Treating an assessment like a label. A profile is a guide to how someone works best, not a box. “She’s an introvert, so she can’t present” is the opposite of empathy.
- Skipping straight to solutions. If you haven’t done Stage 1 and Stage 2, your fix is probably designed for you.
- Changing everything at once. If you change five things and the team improves, you won’t know which one helped.
- Never closing the loop. An experiment without a review is just a change.
Where Woosah Teams fits
When I did this by hand, it took a lot of time: decoding dense assessment reports, building the one-page view myself, and translating it all into plain advice for each person. Most managers don’t have that time, and they shouldn’t need a design background to do it.
That’s why we’re building Woosah Teams. It’s being built to give every person a short team personality assessment and a plain-language profile they’ll recognize, and to give managers a view of the whole team overlaid on one page: where styles cluster, where they contrast, and how to adjust for each person. You can see the idea in more detail on how it works and Woosah Teams for managers.
It’s the method in this guide, turned into a tool any manager can use. If you want to know more about why we care so much about it, read our story.
You don’t have to wait for the tool to start, though. Pick one person on your team this week and ask them how they work best. Then listen like a designer. That’s Stage 1, and it’s where everything gets better.
Frequently asked questions
What is design thinking for managers?
It's the habit of treating your team the way a designer treats a product: understand the people first, name the real problem, try a few small fixes, and keep what works. The users are your teammates, and the product is how the team works together.
Do I need design training to lead this way?
No. The method is mostly curiosity and patience. If you can listen well, write a problem down clearly, and try one change at a time, you can do this.
How long does it take to see a difference?
Small changes, like adjusting how you share information with one person, can land within a week or two. Bigger shifts, like redefining roles or changing how you hire, take longer and should be tested in pieces.
Isn't this just being nice to people?
No. Being nice is a mood. Design thinking is a method with steps, evidence, and follow-through, and it often leads to harder conversations, not softer ones.
Terms in this article
Go deeper on this guide
Hiring and onboarding
Hire people, not résumés: what to look for beyond the interview
A résumé shows what someone has done, not how they work. How to hire for the role and the team you have, then onboard people so they stay.
Work styles
Opposite work styles: how to turn friction into balance
Opposite work styles cause friction when nobody can see them. Once you name them, they balance each other. Here is how managers make that shift.
New managers
You are not your team: the mistake most new managers make
Most new managers assume their team works the way they do. Here is how to notice that habit and lead each person the way they actually work.
Written by
Billy Gozum
Billy Gozum is a co-founder of Woosah Teams and a product and people leader with nearly 20 years of experience building products and teams. As Director of Product Strategy leading digital marketing at a marketing and software firm, she treated her team like a design problem, and it worked. She holds a B.S. in Mathematics (Computer Science major) from the University of Santo Tomas, with certificates in design thinking (UVA), entrepreneurship (Cornell, Stanford), and leadership (HarvardX).