Seven people, 21 conversations: what a team taught me about shaping a product

How a cross-functional team of developers, art directors, marketing and UX shaped a product: where ideas come from, why coordination is hard, what helps.

Put seven people on a project and you don't get seven lines of communication. You get 21.

The maths is simple: every person can talk to every other person, so a team of n has n × (n − 1) / 2 possible conversations. Fred Brooks wrote it down in 1975, in The Mythical Man-Month, to explain why adding people to a late software project tends to make it later (Brooks's law). Three people share 3 conversations. Seven share 21. Every one of them can carry an idea, and every one of them can drop one.

For two years of my master's degree, I lived inside those 21 conversations. The project was Pawka, a mobile app that scans pet food and turns an unreadable ingredient list into a score out of 100. The team: three developers, two art directors, one marketing student, and me on UX research and UI design.

Here's the part I didn't expect. The single decision that made Pawka work didn't come from me.

The best idea wasn't mine

My side of the project was the users. The research behind Pawka covered 12 semi-structured interviews, three in-store observation sessions and a competitive benchmark. We knew our users spent an average of 4 minutes 20 seconds in the pet food aisle, and that 92% of them struggled to read a standard label.

What I didn't have was the business model. Then guest mode came from outside the UX seat: let people scan five products a day with no account at all, and only ask them to sign up when they want to save a favourite or see their history. A free tier first, Premium later.

On paper, it sounded like a marketing decision. In practice, it was the best UX decision in the app.

In the friction map of the user journey, "mandatory sign-up before the first scan" was the only problem rated 5 out of 5: asking for commitment before showing any value destroys conversion. In testing, one participant said it better than any chart: "I could explore without giving anything away. That's reassuring for someone like me who's suspicious of apps."

So the research and the business model pointed at the same door. I had the evidence of where it hurt. A teammate had the fix. Neither of us would have shipped it alone.

Why cross-functional teams have better ideas (when they work)

That's the promise of a cross-functional team, and there's solid research behind it.

In 2010, Anita Woolley and her colleagues gave groups of two to five people a wide range of tasks and found something like a collective intelligence factor: some groups were consistently good at everything. It wasn't explained by how smart the smartest member was. It was linked to how socially sensitive the members were, and to whether everyone got to talk, instead of one or two voices running the room.

Google found a similar pattern when it studied its own teams in Project Aristotle. Of the five dynamics that set effective teams apart, psychological safety came first: the shared belief that you can take a risk in front of your teammates without being punished for it. The idea goes back to Amy Edmondson's 1999 study of work teams, which linked psychological safety to how much teams actually learn.

Translated to a student project: the guest mode idea only reaches the table if the person who has it feels allowed to bring a business idea into a UX discussion. And it only survives if the UX person doesn't treat their research as territory.

Remote collaboration: the real enemy was the calendar

But I'd be lying if I said the hard part was ideas. The hard part was time.

Seven students means seven timetables: different courses, different deadlines, spread over two years. Getting everyone available at the same time was the hardest part of the whole project, and a lot of the coordination happened remotely.

Research on remote work describes exactly what that does to a team. When Microsoft moved its whole workforce home in 2020, a study of more than 61,000 employees found that collaboration became more siloed and more asynchronous: fewer links between groups, fewer live calls, more emails and messages. Information still moved, just more slowly, and less often across disciplines.

That's the danger for a mixed team. The developers end up talking to the developers, the art directors to the art directors, and the 21 conversations quietly shrink to three.

Therefore, the things that held Pawka together were the ones that could be read without anyone in the room.

A design system as a contract

We treated the design system as a contract between design and development. It followed Atomic Design: foundations, then atoms like buttons, badges and inputs with all their states documented, then molecules like the criteria card, then organisms like the full product sheet. A developer working at a different hour than me didn't need to message me to know what a disabled button looked like. The answer was already written down.

There's an old rule hiding here. In 1968, Melvin Conway observed that organisations design systems that mirror their own communication structure. If your team can only talk asynchronously, your product will be shaped by whatever you managed to write down. So write down the right things.

Feedback before pixels

Every wireframe went through two or three rounds of internal feedback before anything moved to high fidelity. At that stage the screens were deliberately ugly, just structure. That made them cheap to criticise. Nobody hesitates to say "this flow is confusing" about grey boxes, and an art director's comment on hierarchy costs nothing to apply before a single colour exists.

Personas as a referee

We ended up with seven profiles, including two anti-personas, and every design decision had to name which one it served. That sounds like process for its own sake. In a team where three disciplines disagree, it's the opposite: it moves the argument from "I think" to "Claire, standing in the aisle with two minutes to decide, needs this".

The result: what usability testing showed

The proof that the team worked is in the testing. 100% of participants still remembered the score and its colour after looking at a product sheet for five seconds. The app scored 80 on the System Usability Scale, rated "good". And the one task that struggled, finding how the score is calculated, only reached 50% direct success. The fix went straight onto the roadmap as the top priority: a "How is this scored?" button on every product sheet.

Teamwork tips for a product team starting out

• Count your conversations. With seven people, decide which of the 21 really need to happen live, and give every other exchange a written home.
• Let research referee, not seniority. A persona or a severity score ends arguments faster than a job title.
• Write each decision where the next person will look. If it only exists in a chat thread or someone's memory, for the person joining on Monday it didn't happen.
• Make it safe to bring ideas from outside your role. Our best UX decision came from outside UX.
• Protect one live slot a week. Do everything else asynchronously, but keep one moment where all the disciplines are in the same call at the same time, so the silos don't close.
• Credit ideas by name. People keep bringing ideas to teams where ideas are remembered.

Five free scans

You can read the full Pawka case study, from the 12 interviews to the testing results and the design system.

But if someone asks me what working in a team taught me, I'll point to the most ordinary screen in the app: five free scans, no account needed. It looks like a small UX detail. It's the one place where a business idea, a research finding and a sceptical user's sentence landed on exactly the same spot.

I didn't come up with it. I helped prove it was right. That's what a team is for.