The Hardest Product Decision: When to Build for Teams

A founder's public story of building ExecReps.ai

The email that changed everything arrived one Tuesday morning. It was from a VP of Learning & Development at a company I can’t quite name. She’d been using ExecReps on her own for three weeks. She found us through Product Coalition, and her message was four sentences:

“My entire leadership team needs this. Can I buy ten seats? Also, I need to see their scores. Is that possible?”

I remember reading it twice. Then I closed my laptop. I walked out the door and headed along the Tagus River here in Lisbon, because I knew what those four sentences meant.

They meant the hardest product decision I’d ever have to make was no longer theoretical.

It was time to build for teams.

The Graveyard of Products That Went Team Too Early

If you’ve been in product long enough, you’ve seen this movie play out. A product works beautifully for individuals. Users love it. Then someone says the magic words: “We need to go multi-seat.” And often, the product dies. It doesn’t happen overnight. It dies slowly. The dashboard gets cluttered with admin panels. Onboarding asks seventeen questions about org structure before you can even do anything useful. The individual user, the one who loved your product, suddenly feels like they’re using enterprise software.

The Kano Model explains why this often kills products. The individual experience, the thing that created genuine excitement, is what Kano would call the ‘attractive quality’. Team features, though, are ‘must-be’ qualities: admin panels, permissions, billing. They don’t generate delight. They just prevent dissatisfaction. If those ‘must-be’ features degrade the ‘attractive quality’, you’ve traded the very reason people cared for infrastructure nobody loves.

With ExecReps, the stakes felt even higher. This is a product where people practice speaking. Out loud, vulnerably, sometimes badly. That requires psychological safety that most team software never even considers.

The First Attempt: v0.6 and the Flat List

Back in October 2025, we shipped v0.6. These were our first team accounts. It was basic. A team owner could invite members via email, see aggregate analytics, and manage billing through Stripe.

It worked. Just barely. But within weeks, the feedback exposed every assumption we’d made.

“Can my team members see each other’s scores?” We hadn’t decided.

“We have regional sub-teams. Can I create groups within the team?” No.

“I want to add thirty people at once.” You’ll need to type thirty email addresses, one at a time.

“I manage two teams: product and design. Can I be in both?” Also no.

Every one of those questions was a canary in the coal mine. In Don Norman’s language, we had a massive conceptual model mismatch. We’d built a mental model of ‘team’ that meant ‘flat list of people under one admin’. Our users’ mental model was messy, overlapping, hierarchical, and fluid. Because that’s how organizations operate. The Gulf of Execution, the gap between what users wanted to do and what our interface let them do, was enormous.

The Privacy Problem Nobody Mentions

What makes ExecReps different, what makes the team pivot entirely different from adding team features to a design tool or a project tracker, is this:

When someone practices a high-stakes conversation, maybe a board presentation or a salary negotiation, they’re being vulnerable. They’re getting feedback that says their pace is too fast, they use “um” forty-seven times, their confidence score is 520 out of 1000. That data is intimate. Now imagine their manager can see all of it.

Kahneman and Tversky’s loss aversion research is painfully relevant here. The fear of losing something, like privacy or psychological safety, is roughly twice as powerful as the motivation to gain something, like a better score or team recognition. If a team member even suspects their boss can see a bad session, the fear of exposure outweighs any motivation to practice. They’ll stop using the product. Or worse, they’ll only practice things they’re already good at.

The VP of L&D who emailed me? She needs to see her team’s progress. That’s the entire value proposition for an enterprise buyer. She’s spending budget. She needs ROI.

But the individual needs to feel safe enough to be bad at something.

Our solution:

Aggregation is the answer.

Managers see trends, not transcripts. They see that someone’s EPS has improved 15% over the last month, not that they bombed a specific practice session on Tuesday. They see engagement patterns, who’s practicing regularly, but not the content of what anyone practiced. The individual owns their detailed data. The team sees the trajectory.

Deci and Ryan’s Self-Determination Theory says people need autonomy, competence, and relatedness to stay intrinsically motivated. Full transparency to managers kills autonomy. Our aggregation model preserves it. The member controls what they practice and when, and their boss sees only the trajectory of growth, not the vulnerable process behind it.

It’s the difference between a fitness tracker that tells your boss you worked out three times this week, versus one that shows them the video of you wheezing on the treadmill. I wonder if there’s an equivalent in other domains, like a coding practice tool. Would a manager want to see every syntax error, or just the overall improvement in code quality?

v2.1: Making Teams Find Themselves

By March 2026, we were ready for the real team rebuild. The first thing we tackled was the most fundamental question: How do teams form in the first place?

In most enterprise tools, team creation is top-down. An admin buys seats, manually invites people, and assigns them to groups. From a BJ Fogg B=MAP perspective, it’s an ability disaster. Every email address the admin has to type is friction. We saw this firsthand: admins who bought ten seats would invite three people, get distracted, and never finish.

We built domain-based team discovery instead. When you sign up with your work email, say sarah@acmecorp.com, we check if there’s already a team associated with the acmecorp.com domain. If there is, you see it. You can request to join. An admin approves. No invitation needed.

This sounds simple. It was not simple. Domain matching has a hundred edge cases: personal Gmail addresses, multiple company domains, embedded consultants. The perfectionist in me wanted every edge case solved before shipping. The product manager in me knew domain matching would cover 80% of signups.

We saw immediate change. An L&D manager would sign up, invite three people, and within a week we’d see twelve more from the same domain requesting to join. Any product team familiar with Cialdini’s social proof research would recognize what was happening. “Your teammates are already here” did the selling for us.

We also built multi-team membership with a sidebar switcher. The real world isn’t a neat org chart. People belong to functional teams, project groups, and leadership cohorts. Forcing single-team membership tells your users you don’t understand how they work. Nielsen’s “Match Between System and Real World” heuristic is clear: the system should reflect how people organize, not force them into the system’s preferred structure.

v2.3: When “Enterprise” Stops Being a Dirty Word

Two weeks later, we shipped v2.3. This was enterprise team management. Flat team lists work for ten people. They break at fifty. They’re laughable at five hundred. We built nested team hierarchies with unlimited depth.

‘Unlimited depth’ scared me a bit. Every product instinct says to constrain. The moment you say “maximum three levels of nesting,” someone’s org chart has four. And you’ve lost the deal.

Bulk onboarding was the other critical piece. That VP of L&D didn’t want to type thirty email addresses. She wanted to paste from a spreadsheet. So we built multi-email paste (smart parsing for commas, semicolons, newlines) and CSV import for larger teams.

This is pure BJ Fogg Ability Chain work. Fogg identifies six friction factors: time, money, physical effort, mental effort, social deviance, and non-routine. Typing thirty emails one-by-one fails on three of six. CSV import collapses the entire action into a single file upload. We didn’t increase the admin’s motivation to onboard their team. We made the behavior so easy that their existing motivation was enough.

Nobody writes blog posts about CSV import. It’s the difference between a product that can be used by teams and one that teams adopt.

The Security Audit That Changed Everything

During the v2.1 build, we ran a security audit. This is standard practice when you’re building team features. You’re now handling data relationships between users, and that’s often where vulnerabilities hide.

The audit found an XSS vulnerability. Someone could inject malicious code through a team name or display name, and it would execute in other users’ browsers. In an individual product, the blast radius is limited. In a team product, one compromised input affects every team member who views that page.

We fixed it immediately. It changed how I thought about the entire architecture. We implemented timing-safe token comparisons for join requests and hardened every data input that crossed team boundaries.

The team pivot reveals hidden technical debt. If you’re making this pivot, audit everything. Assume every user input displayed to another user is an attack vector.

The Product Lesson: Individual Magic Is Your Moat

If you’re a founder or PM standing at the edge of the individual-to-team pivot, I’d tell you this:

The individual experience is not a stepping stone to the team product. It IS the team product.

Nir Eyal’s Hook Model makes this concrete. The hook loop: trigger, action, variable reward, investment, lives entirely at the individual level. The trigger is a morning prompt to practice. The action is completing a workout. The variable reward is the AI feedback that surprises you with a specific insight. The investment is the data that accumulates in your profile, making the next session more personalized. Every piece of that loop belongs to the individual user. The team layer doesn’t create a new hook. It amplifies the existing one by adding social proof (“your teammates practiced today”) and Daniel Pink’s relatedness dimension (“you’re growing together”).

Every feature we built for teams is worthless if the individual hook isn’t working. A manager can buy fifty seats. If the individual user doesn’t feel safe, doesn’t see improvement, doesn’t find each practice session genuinely valuable? Usage drops to zero within a month and the contract doesn’t renew.

The team layer should be a window into individual value, not a replacement for it.

I’ve seen products get this backwards. They build the admin panel first, the reporting first, because that’s what the buyer asks for. In Norman’s terms, they collapse the Gulf of Evaluation for the buyer at the expense of widening the Gulf of Execution for the user. The admin gets beautiful dashboards. The user gets a worse product.

Don’t let the buyer’s requirements cannibalize the user’s experience.

Where We Are Now

We’re eight months past that first “can I buy ten seats?” email. We’ve gone from a flat member list to nested enterprise hierarchies, domain discovery, multi-team membership, bulk onboarding, and engagement analytics that give managers what they need without exposing what they shouldn’t see.

When an individual user opens ExecReps and starts practicing, it still feels like the same product. Intimate. Safe. Focused on them.

I’m not sure if we’ve gotten it perfectly right. Every week I talk to a team admin who wants more visibility and a team member who wants more privacy. I think that tension is the point. The moment you resolve it fully in either direction, you’ve built something that serves half your users at the expense of the other.

The best team products hold that tension. They don’t resolve it. They design around it.