“Jay, can I see your security architecture?”

She didn’t ask, “do you have SOC 2?” She didn’t ask “are you GDPR compliant?” She wanted to see the architecture. The actual policies. The scanning pipeline. How data flows and who can touch it.

I pasted a link into the chat: execreps.ai/security.

Thirty seconds of silence stretched.

Then: “Okay. This is more than I expected.”

That page is why I’m writing this post. Building security as a first-class product feature, not a compliance afterthought, has been one of the highest-ROI investments I’ve made. I even built it when I was a team of one.

Don Norman would recognize what happened on that call. The buyer had a ‘Gulf of Evaluation’. She needed to answer, “Can I trust this vendor with my company’s data?” Most startups force buyers to dig through questionnaires and schedule follow-ups to close that gap. A public security page closes it in thirty seconds.

The First RLS Policy (October 2025)

Back in October 2025, I shipped v0.5 of ExecReps. The product was barely functional. People could record themselves practicing a presentation, get AI feedback, track their scores. Maybe two dozen active users.

That release included Row Level Security across six database tables.

If you’re not a backend engineer, Row Level Security means the database itself enforces who can see what. It isn’t application logic saying ‘don’t show User A’s recordings to User B.’ It’s the database saying ‘this row does not exist for you.’ Even if someone bypasses the API, even if there’s a bug in the code, the database won’t hand over data that doesn’t belong to you.

Overkill for two dozen users? Absolutely.

The thing I understood, after fifteen years of product work, was this: security debt compounds faster than any other form of technical debt. Kahneman and Tversky’s research on loss aversion explains why. Losses are felt roughly twice as intensely as equivalent gains. You can refactor a messy UI. You can optimize a slow query. You cannot un-leak data. A breach isn’t a setback you recover from. It’s a loss your users feel viscerally. That asymmetry makes early security investment disproportionately valuable.

Six tables. Every query filtered by the authenticated user’s ID. A day and a half of work that’s paid for itself a hundred times over.

The Recursion Bug That Almost Ruined Everything

You might expect this part to be smooth. It wasn’t.

When I started building team functionality, managers seeing team data, admins needing org-wide visibility, the original RLS policies became a problem. The naive approach was policies that check team membership by joining against the teams table. Which had its own RLS policies. Which tried to check membership. Which queried the teams table again.

Infinite recursion. In the database layer.

Supabase doesn’t give you a helpful error for this. The query just… dies. I spent an evening staring at Postgres logs, convinced I’d broken my approach.

The fix was security definer functions that bypass RLS for specific trusted operations, restructured team membership verification, and extreme deliberation about which policies reference which tables. Sounds simple in a blog post. Had me questioning my life choices at midnight on a Thursday.

The critical part, though, was this: I found the bug during development, not in production. Nielsen’s Error Prevention heuristic (H5) says the best error message is no error message. The best data breach is one that’s structurally impossible. Because the RLS foundation already existed, I was forced to solve multi-tenant complexity before real enterprise data was at stake. If I’d waited, if I thought ‘we’ll add security later when we have enterprise customers,’ I’d have been retrofitting access control while actual company data flowed through the system.

That is exactly how breaches happen.

Building the Wall Higher (v2.4)

v2.4 is ‘Enterprise Security Hardening’. It’s the release that transformed our security story from ‘solid foundation’ to ‘genuinely enterprise-grade.’

Product teams who use the Kano Model know the categories: must-be, performance, and delighter. For enterprise buyers, security is firmly must-be. Absence kills a deal instantly, but presence alone doesn’t win one. What wins is when the implementation exceeds expectations. When a must-be quality is delivered at a delighter level, buyers notice.

On every pull request, we now run these checks:

Semgrep. This is Static Application Security Testing, scanning for vulnerability patterns like SQL injection, XSS, insecure auth patterns, and hardcoded secrets. Every PR, every time.

Gitleaks. This scans for accidentally committed secrets: API keys, tokens, passwords. Because sooner or later someone (or some AI, I’ll come back to this) pastes a token in a config file.

Dependency auditing. Every npm package is checked against known vulnerability databases. A critical CVE? The build fails.

Content-Security-Policy headers. These tell the browser exactly which domains can execute scripts, load images, or open connections. Most startups don’t implement this until past Series B.

Aikido DAST integration. This is Dynamic Application Security Testing, monitoring the running application. It probes endpoints, tests real-world attack vectors, and reports continuously.

The /security page itself ties it together. A public, human-readable overview of everything above. Not a compliance PDF. A web page that an IT buyer can read, share with their team, and use to make a procurement decision. Norman’s Gulf of Evaluation and Gulf of Execution, closed simultaneously. Buyers can evaluate without scheduling a call, and act by forwarding the URL to their CISO, without needing us in the room.

The AI Engineer Problem

Something I haven’t seen discussed much is this: what happens when one of your engineers is an AI?

I use Devin, an AI software engineer, for significant portions of development. Devin is remarkably capable. Clean code, follows patterns well, handles complex refactoring. Devin doesn’t have security intuition, though. It doesn’t think ‘this input should be sanitized.’ It won’t instinctively avoid hardcoding a token in a test file.

BJ Fogg’s B=MAP model describes the AI security problem perfectly. Devin has high ability to write code and zero motivation around security, no concept of consequence. There’s no built-in ‘prompt’ for ‘check for vulnerabilities before you commit.’ The SAST pipeline becomes that prompt. Devin opens a PR, scanners run, a vulnerability is found. The build fails. Period.

It’s not about trusting or not trusting the AI. Human engineers ship vulnerable code too. Security automation doesn’t care about intent. It enforces rules. Like guardrails on a mountain road. They aren’t there because you’re a bad driver. They’re there because the cliff doesn’t care how good you are.

Not sure where the industry lands on this in a year or two. I had a podcast guest recently who was convinced AI-written code would be more secure than human-written code within 18 months. Maybe. The scanning pipeline doesn’t care either way.

Feature Flags as a Security Mechanism

One surprise from v2.4: feature flags became a security tool.

We built an admin UI for feature flags, turning features on or off for specific users, teams, or globally. The obvious use is gradual rollouts.

Feature flags also give you a kill switch. Vulnerability in a feature? Disable it in seconds. No emergency hotfix, no midnight deployment. Toggle it off.

Norman would call this a strong affordance. The toggle looks like instant control because it is instant control. For a solo founder without a 24/7 on-call rotation, mean time to mitigation drops from ‘however long it takes to write, test, and deploy a fix’ to ‘however long it takes to click a button.’

Enterprise buyers get this immediately. “Any feature can be instantly disabled without a deployment” translates to “if something goes wrong, it gets fixed immediately.” That’s not just a product feature. That’s a purchasing decision.

Security as Moat

I think many startups miss the mark on this: they treat enterprise security as compliance theater.

The scramble for SOC 2 before the first enterprise deal. The ‘we take security seriously’ banner on a website with Access-Control-Allow-Origin: * in production. The security questionnaire answered by Googling in real-time.

Cialdini’s research on Authority explains why this fails. Authority isn’t claimed, it’s demonstrated. Telling a buyer ‘we take security seriously’ is a claim. Showing them automated scanning pipelines and row-level data isolation is a demonstration. The buyer’s brain processes those inputs completely differently.

Security is a competitive moat. Not because your competitors can’t build it, but because they won’t. It’s unglamorous. It doesn’t move metrics VCs ask about. Nobody tweets about CSP headers.

Enterprise buyers, the ones writing the big checks, care a lot. The gap between ‘we’ll get to security eventually’ and ‘here’s our security architecture, publicly documented’ is enormous in their eyes.

I’m a solo founder competing against funded teams. I shouldn’t be winning security conversations. But when the review happens, I’m not scrambling. I’m sending a link.

What This Costs

The SAST pipeline runs in GitHub Actions. A few hours to configure, almost no ongoing cost. Aikido has a generous startup tier. CSP headers: half a day. RLS policies: three to four days across iterations. The /security page: an afternoon.

All in? Maybe two weeks of engineering time over five months.

This is loss aversion math in your favor. Enterprise buyers overweight security risk. Two weeks of your work neutralizes months of their perceived risk. Compare that to losing a deal over a question you can’t answer, or spending three months rushing SOC 2 because a prospect demanded it. I wonder if this kind of upfront investment is often undervalued by founders focused solely on new feature velocity.

The Deeper Connection

I think about why I care this much about security for a communication practice tool. ExecReps isn’t handling financial data or medical records. We hold voice recordings of people practicing presentations, pitch rehearsals, feedback conversations.

That’s exactly why it matters.

Someone records themselves practicing a difficult conversation. Asking their boss for a raise, rehearsing for a board presentation, delivering bad news. That’s vulnerable. That’s someone exposing the gap between where they are and where they want to be.

Deci and Ryan’s Self-Determination Theory identifies three needs for intrinsic motivation: autonomy, competence, and relatedness. The prerequisite, though, is psychological safety. You can’t pursue competence if you’re afraid of being exposed. The practice loop that makes ExecReps work, record, get feedback, improve, repeat, only functions when users trust the container.

Executive presence should not be a privilege. The willingness to practice it, though, requires trust. Trust requires infrastructure, not just promises.

A Question for Builders

If you’re building a product right now, especially if you’re thinking ‘we’ll handle security later,’ ask yourself:

What would it mean for your customers if their data leaked tomorrow? Not legally. What would it mean for them?

The answer tells you when to invest. For many of us, it probably should have been yesterday.

The good news: ‘yesterday’ is closer than you think. A few days of intentional work now can be worth months of panic later.

Security isn’t just a phase of your product development. It’s a core feature. It’s probably worth building like one.

“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.

Then I hit delete.

That single action, hitting delete, was one of the best product decisions I’ve made on ExecReps. Maybe it’s also the most contrarian thing I’ll write in this entire series.

The Seduction of the Easy Answer

Nobody talks about this in product right now. LLMs have become the new ‘just throw it in a database.’ Every feature. Every recommendation. Every personalisation decision. The default instinct in 2026 is to ask a model. I get it, I’ve done it too. ExecReps uses GPT–4 for assessment, and it’s brilliant there.

But recommendations are a different beast.

When we started planning personalisation, that moment a user logs in and sees curated practice scenarios instead of a generic wall of content, the temptation was overwhelming. Embed the user’s profile. Embed the content. Cosine similarity. Done. Ship it. Put ‘AI-powered recommendations’ on the marketing site.

Except I kept hitting one problem I recognized from Don Norman’s work. I couldn’t explain why the model would recommend what it recommends. Norman calls this the Gulf of Evaluation, the gap between what the system did and why it did it. I wonder if this is the biggest long-term trust issue with LLMs. When your user can’t bridge that gulf, you’ve built a black box. They’ll eventually stop trusting it.

The Explainability Problem Nobody’s Solving

In EdTech, and executive coaching is EdTech even if we don’t always dress it that way, recommendations aren’t like movie suggestions. If Netflix recommends a mediocre rom-com, nobody gets hurt. You scroll on.

If ExecReps recommends the wrong practice scenario to someone preparing for a board presentation next Tuesday, and they spend their limited practice time on a scenario that doesn’t stretch the right muscles? That’s someone’s career development time wasted. I was talking to a product leader last week, and he mentioned how frustrating it is when ‘AI’ gives him generic suggestions. He just wants to know why. So when they ask ‘why did the platform have me practice this?’, ‘well, the embedding similarity was high’ isn’t an answer.

Any product team that’s applied Nielsen’s Heuristics knows this tension. His sixth heuristic, Recognition over Recall, says users should never have to guess why the system made a decision. They should see the reasoning. With an LLM, the honest answer was we couldn’t show it. With math, we could.

Nir Eyal’s Hook Model shaped our thinking too. The Hook cycles through Trigger → Action → Variable Reward → Investment. In a coaching context, the variable reward needs to feel earned and understood, not random. If users can’t connect the recommendation to their own growth, the reward loop breaks. The thing I keep coming back to is this. We needed variability in the content surface, yes, but not opacity in the logic underneath.

Five Factors, Zero Magic

So we built what I now think of as the honest recommendation engine. Five scoring factors. Each weighted. Each grounded in learning science. And each, I’d later realize, maps to established behavioral frameworks that any product team would recognize:

1. Content Relevance. Does this scenario match what you need to practice? A structured mapping between your stated goals, your role, your industry, and the content metadata we’ve tagged on every scenario.

2. Difficulty Match. Straight from Vygotsky’s Zone of Proximal Development, which anyone who’s studied Csikszentmihalyi’s Flow theory will recognize. Optimal challenge sits just beyond current ability. Daniel Pink calls this the Mastery component of his Drive framework, the intrinsic pull toward getting better at something that matters. The engine doesn’t just serve content. It serves the right difficulty to keep users in that Flow channel.

3. Skill Gaps. Where are you weakest relative to where you need to be? If your scores show strong Command but shaky Eloquence, the system pushes you toward scenarios demanding clarity and articulation. The Kano Model would call this ‘must-be’ quality. Users expect a coaching platform to know where they need work. Not a delighter. Table stakes.

4. Recency. When did you last practice a particular skill area? Spaced repetition works. Kahneman and Tversky’s research on memory availability tells us the same thing from a different angle. Recently practiced skills feel more accessible than they are, creating an illusion of competence the system needs to counteract.

5. Diversity. This one’s mine, not from any textbook. I kept noticing in user testing that people got stuck in loops, practicing presentations over and over because that’s what felt comfortable. From a Hook Model perspective, this is where variable reward design becomes critical. Eyal is explicit: predictable rewards lose power. The diversity factor nudges you into unfamiliar territory. Difficult conversations, upward feedback, client escalations. The things you avoid are often the things you need most.

Each factor produces a normalized score. The weighted combination gives us a final ranking. No black box. Every recommendation traces back to defensible reasoning. ‘We recommended this because you haven’t practiced delivery skills in 12 days, this scenario is one level above your last difficulty rating, and it targets the dimension where your gap is widest.’

Norman would call that bridging the Gulf of Evaluation. Nielsen would call it Visibility of System Status. I just call it treating adults like adults.

141 Skills Walk Into a Bar

Let me be honest about a mistake here. It’s one that any PM who’s read Norman’s work on conceptual models should have seen coming.

When we first built skill tracking, I let users self-report their target skills. Free text. ‘What skills do you want to develop?’ Very user-friendly. Very product-manager-who-reads-too-many-UX-books, me included.

We ended up with 141 unique skills in the database. Think ‘Executive presence.’ Then ‘Executive communication.’ Then ‘Presence in meetings.’ Then ‘Being more present in executive meetings.’ Four users, four entries, functionally the same thing.

The recommendation engine couldn’t work on top of that. In Norman’s terms, we had a catastrophic conceptual model mismatch. Every user had built a different mental model of what they were working on, and the system had no shared language to operate from. You can’t do gap analysis when the gap dimensions are fuzzy, overlapping, and user-generated.

So we did something painful. We threw all 141 away and started from psychometric research. Validated communication competency frameworks. Published, peer-reviewed dimensions of what ‘communication skill’ means when you measure it rigorously.

We landed on eight dimensions. Eight.

That collapse, 141 to 8, was one of the hardest product decisions I’ve made. In Self-Determination Theory terms (Deci & Ryan), it felt like violating the Autonomy principle. It felt like telling users ‘we know better than you what you’re working on.’ The psychometric evidence was overwhelming though. When you let people self-categorize communication skills, they create endless synonyms and miss critical dimensions entirely. Almost nobody listed ‘consistency’ as a target, for example. I’m not sure if this is a universal human trait or specific to communication skills, but it’s a pattern I’ve seen often. Consistency, maintaining quality under pressure, across contexts, is one of the strongest predictors of communication effectiveness in the literature.

User-generated taxonomies feel democratic. Validated taxonomies work. The Kano Model has a concept for this. Users will say they want freeform input, but their satisfaction doesn’t improve from getting it. What improves satisfaction is getting recommendations that work.

Solving Cold Start Without Asking Boring Questions

The classic cold start problem. New user, no data, and you need good recommendations immediately. Most platforms solve this with a questionnaire. ‘Rate your interest in these 15 topics.’

BJ Fogg’s B=MAP model told us that was wrong. Behavior equals Motivation plus Ability plus Prompt. A new user arriving from their manager’s email has moderate motivation at best. A fifteen-question onboarding form tanks their Ability. Too much time, too much mental effort, too much friction. Fogg is clear: when motivation is low, make the action trivially easy. A questionnaire is the opposite of easy.

We built two things instead.

First: industry/role/seniority profiles. Before any user tells us anything personal, we know statistical priors. A VP of Engineering at a Series B startup has different communication challenges than a Marketing Director at a Fortune 500. We built baseline profiles from research. What skills matter at each seniority level, what scenarios each role encounters, what difficulty level fits each experience bracket.

Second, and this is the one I’m proudest of, the Challenge Picker and Confidence Slider.

Instead of asking ‘what do you want to improve?’ we show three real scenarios and let users pick which feels most relevant. Steve Krug would call this ‘Don’t Make Me Think.’ Recognition, not recall. Show options, let them point.

Then, before their first practice: a Confidence Slider. ‘How confident do you feel about this scenario?’ Zero to ten. Two seconds.

That slider is pure signal. It’s where Kahneman and Tversky’s work on cognitive bias becomes directly useful in product design. Someone who rates themselves 8/10 confidence and delivers a 550 EPS score has a calibration problem, what Kahneman calls overconfidence bias. Someone who rates 3/10 and delivers the same 550 is underestimating themselves. The recommendation engine treats them completely differently, and it should. The gap between self-assessment and performance is one of the richest signals any coaching product can capture.

All of this runs without a single API call to any language model. Zero tokens. Zero latency. Zero risk of prompt injection or model drift affecting what learning path someone follows.

The Quiet Confidence of Boring Technology

I’m not anti-AI. ExecReps runs on AI, yes. Our assessment engine is genuinely powerful and would have been impossible three years ago. AI was the wrong tool for recommendations though, because the recommendation problem was well-defined enough to solve with math.

Here’s my rough heuristic, for what it’s worth:

Use AI when: the input is unstructured, the output needs to be generative, and you can’t write rules for what ‘good’ looks like. Assessment of free-form speech? That’s AI.

Use algorithms when: the input is structured, the output is a ranking, and you can define ‘good’ with research. Matching users to content? That’s math.

Use neither when: the problem is a UX problem disguised as a technical one.

There’s a confidence that comes from building something you can fully explain. When a user asks ‘why did you recommend this?’ and you can say ‘because your skill gap in Eloquence is 23% wider than your gap in Command, you haven’t practiced client-facing scenarios in 9 days, and this sits one difficulty tier above your last successful attempt’, that’s a different conversation than ‘our AI thought you’d like it.’

In executive coaching, where people are developing skills that affect their careers, their livelihoods, their sense of professional identity, they deserve the transparent answer. Someone making decisions about their own development should understand the reasoning behind the recommendations shaping that development.

Executive presence should not be a privilege. Neither should understanding why your learning platform steers you in a particular direction.

It’s not the flashiest thing we’ve built, I know. ‘Startup uses math instead of AI’ isn’t exactly clickbait. Still, when I look at our recommendation accuracy, users completing recommended scenarios at a significantly higher rate than self-selected ones, I think about that moment with the GPT–4 prompt written and ready to ship.

I’d delete that prompt again every time.

I had one of those mornings recently. You know the kind. Staring at a screen, coffee going cold, and the data just… mocks you. Not the company, not the product, but the dashboard itself made me want to quit.

We’d spent weeks building acoustic voice analysis into ExecReps. Pace, filler words, clarity, confidence. Now, users could see everything.

Their content scores, broken out across structure, persuasion, and relevance. Their delivery scores, measured across four vocal dimensions we called Command, Eloquence, Engagement, and Consistency. Eight archetype classifications. Historical data on every dimension. Charts for days.

It was, objectively, impressive engineering. It was also terrible product design.

I knew this because I watched myself use it. I’d finish a practice session, get my results, and then spend two minutes trying to figure out whether I’d gotten better. Was my Eloquence going up, but my Command going down? Did the content improvement offset the delivery dip? Was a 620 in Engagement good? Compared to what?

This is the bit I keep getting stuck on with some of the data visualization trends. We collect so much, but what do we dowith it?

Don Norman calls this the Gulf of Evaluation: the gap between what a system shows you and your ability to figure out what it means. Our dashboard had created a canyon-sized gulf. Tons of data, zero answers. If I, the person who built this thing, couldn’t quickly answer ‘am I improving?’, no user stood a chance.

The Data Trap

Engineers and PMs love data. Users love answers.

I’ve learned that the hard way, multiple times, across multiple companies.

There’s a seductive logic to giving users more information. More data means more transparency, more trust, more engagement. It’s a clean little story that falls apart the moment a real human opens your app.

Barry Schwartz’s Paradox of Choice shows more options create more anxiety, not more satisfaction. Nielsen’s eighth usability heuristic, aesthetic and minimalist design, exists because every extra element on screen competes for cognitive bandwidth. Show someone eight metrics and you haven’t given them eight insights. You’ve given them decision paralysis wearing a dashboard costume.

The mistake isn’t in collecting the data. It’s in thinking the data is the product.

What Fitbit Already Figured Out

The breakthrough came from a conversation I had with a friend who’d just gotten a Garmin watch. She was showing me her stats: heart rate variability, VO2 max, sleep stages, body battery. I asked her what her resting heart rate was.

She had no idea.

What she did know was that her ‘body battery’ was at 73 that morning, which was higher than last week. Her training status said ‘Productive’. That’s all she needed.

In the Kano Model, Garmin’s raw biometric data is table-stakes quality: expected but not exciting. The ‘body battery’ synthesis is the delighter. Same sensors, but the experience shifts from ‘here’s your data’ to ‘here’s your answer’.

Fitbit figured this out years ago. It wasn’t ‘here are your steps, your distance, your calories, your active minutes’. It was: you hit your goal today. You’re on a streak. You’re improving. The raw data lives behind a tap for the nerds who want it. The product is the answer.

We needed our own version of that. I wonder if this lesson applies to every ‘pro’ tool. Do finance professionals want every row of a spreadsheet, or just the insights from it? I’m not sure.

Building the Executive Performance Score

So in late November, we built what we call the Executive Performance Score. The EPS.

One number. 400 to 1,000 scale. It tells you how effective you are as a communicator. Full stop.

Under the hood, EPS combines two systems we’d already built. Think of it like this:

Content quality. Our GPT–4 analysis layer evaluates what you say. Structure, clarity, persuasion, relevance, depth of thinking. This is the stuff traditional coaching often focuses on.

Delivery quality. Our acoustic analysis layer evaluates how you say it. Command, Eloquence, Engagement, and Consistency. This is the stuff that usually requires a live coach or, more often, never gets measured at all.

In Norman’s terms, we were creating a new conceptual model. Instead of ‘I have eight separate scores I need to track’, the mental model becomes ‘I have one number that goes up when I get better’. One number. Two systems. A graspable picture.

The 60/40 Fight

This is where it got contentious. If EPS combines content and delivery, what’s the weighting?

My instinct was 50/50. Clean. Fair. Democratic.

But content and delivery don’t matter equally. Pretending they do is the kind of elegant-sounding product decision that makes your product worse.

We went back and forth on this for longer than I’d like to admit. The arguments for 50/50 were aesthetic. The arguments against were practical.

First, content has a higher ceiling of differentiation. Two people can deliver a message with nearly identical vocal quality but wildly different levels of insight and persuasion. Academic communication research suggests content predicts audience perception of competence more strongly than delivery alone.

Second, we’re building for professional contexts. In a board meeting, a pitch, a difficult conversation, what you say carries more weight than how you say it.

Third, and this is the one that settled it, a 50/50 split created a perverse incentive. Kahneman and Tversky’s work on framing effects applies directly. How you frame a metric changes what people optimize for. A 50/50 split would tell users with strong voices but weak content that they were ‘good’ when they were just pleasant-sounding. That’s not what we’re building. We’re not a voice beautification tool.

So we went 60/40. Content gets 60%, delivery gets 40%.

It’s not a perfect split. It does create the right incentive structure: if you want a high EPS, you need to think well and communicate substantively. A beautiful voice won’t carry you past 700.

The product lesson is that ‘weights are product decisions, not math decisions’. Every composite metric encodes values. Spotify’s Discover Weekly weights novelty against familiarity. Google’s search algorithm weights freshness against authority. The weights aren’t neutral, they’re your product’s opinion about what matters. Own that opinion explicitly, or you’ll end up with a metric that doesn’t drive the behavior you want.

The 400–1,000 Scale (And Why Not 1–100)

Small decision, but it mattered more than expected: the scale.

Early versions used 1 to 100. It felt intuitive. Everyone understands percentages. It created two problems though.

First, nobody wants to be a 43. This is Kahneman and Tversky’s anchoring bias in action. Decades of school grades have anchored everyone to read anything below 70 as ‘bad’. A score of 52 out of 100 is above the mathematical median, but it feels like failure. The anchor is stronger than any disclaimer you put next to it.

Loss aversion tells you why this kills a self-improvement product. If users feel they’re ‘failing’ on their first session, the emotional cost of continuing outweighs the potential gain. They don’t come back. You’ve lost them to a technically accurate but emotionally devastating number.

We borrowed the 400–1,000 scale from standardized testing (SAT, GRE, GMAT). It’s population-normalized, so a 600 means you’re at the median, not ‘failing’. A 580 doesn’t trigger the same shame response as a 58.

Same underlying data, different emotional frame. That’s product design. I wonder if there’s a limit to how much you can ‘gamify’ negative feedback. Or if all products should just avoid grading entirely.

The Backfill Decision

This is the part I’m most proud of. It was almost the part we didn’t do.

When we launched EPS, every user had existing data. Practice sessions from weeks or months of using the platform. They didn’t have EPS, because EPS didn’t exist when they did those sessions.

The easy path: EPS starts now. Old sessions get old scoring. New sessions get EPS. A clean cutover.

But that meant users would open the dashboard and see… nothing. No trend line. No trajectory. Just a single data point. The whole promise of ‘am I getting better?’ requires comparison over time. One data point isn’t a trajectory. It’s a dot.

So we went back and calculated EPS for every historical submission in the system. Every practice session, every scenario, every user. We applied the same 60/40 weighting, the same population normalization, the same scale. When users opened the new EPS dashboard for the first time, they didn’t see a blank slate. They saw their entire journey.

This matters more than it sounds like it should. Multiple well-established frameworks explain why.

Teresa Amabile’s progress principle research at Harvard shows that the single strongest driver of motivation at work is the sense of making progress on meaningful work. Not recognition, not incentives. Progress. Deci and Ryan’s Self-Determination Theory identifies competence, the feeling that you’re getting better, as one of three fundamental human needs. Daniel Pink’s mastery research in Drive makes the same case. The trajectory line directly feeds the deepest drivers of human motivation.

From a behavioral design perspective, Nir Eyal’s Hook Model would call the backfill data ‘stored value’, the Investment phase of the habit loop. Users who see their history have something invested in the system. That investment loads the next trigger: ‘I wonder if my next session will push me past 700.’ Without the backfill, zero stored value. With it, they start already hooked.

When users opened ExecReps and saw a line going up, even slightly, something clicked. I could see it in the engagement data. Session frequency increased. Users who’d been doing one practice a week started doing two or three. They weren’t responding to a new feature. They were responding to evidence that they were getting better.

BJ Fogg’s B=MAP model explains the mechanism: Behavior = Motivation × Ability × Prompt. The backfill didn’t change ability or the prompt. It changed motivation. Seeing a rising trajectory makes the next session feel not just possible, but inevitable.

The engineering cost was maybe two days. The impact on retention was disproportionate. If you’re building any kind of self-improvement product, I’d argue the backfill is the feature. Not the score itself. The score is just a number. The trajectory is the product.

Measure What Matters, Show What Motivates

We ended up with a design philosophy we still use: ‘measure what matters, show what motivates.’

We still collect all the granular data. Every acoustic dimension, every content sub-score, every archetype shift. That data lives one tap away. Progressive disclosure in Nielsen’s terms. Or what Dan Saffer’s microinteraction patterns might call a ‘long tap to reveal’ secondary layer. Some users dig into it and love it.

The product surface, the thing you see first, is one number, one trend line, and one answer: you’re getting better.

This philosophy cuts against every instinct a data-driven PM has. We want to show our work. We want credit for the engineering. All of that is ego, not product sense.

The best products are like the best coaches. They take in a huge amount of information, synthesize it, and tell you the one thing you need to hear right now. That’s what EPS became. Not just a metric, a design principle. Every feature we’ve built since, I ask: are we showing what motivates, or are we showing what we measured?

The Uncomfortable Truth About Metrics

I’ll end with something that still makes me slightly uncomfortable.

EPS is an opinion. It’s our opinion about what makes effective communication, encoded as math. The 60/40 split is a product decision. The population normalization is a modeling choice. The scale is a psychological design. None of it is ‘objective’ in the way users might assume when they see a number with decimal precision.

Every metric in every product is like this. Your credit score is an opinion. Your Uber rating is an opinion. Useful approximations dressed up as measurements.

I think founders and PMs have an obligation to be honest about this. Cialdini’s research on commitment and consistency shows that once people anchor their identity to a number (‘I’m a 720’), they’ll work to stay consistent with that identity. That’s powerful. The behavior your metric incentivizes should be the behavior you want. Get the weights wrong, and you build a precise system that makes users worse at the thing they’re trying to improve.

We spent more time on the values behind EPS than on the engineering. I think that’s exactly right.

It reminds me of a conversation I had with one of our Product Coalition podcast guests, Marty Cagan, who often talks about how product strategy is value decisions. Metrics are just a manifestation of those values.

Because that’s the point. Not the number. Not the dashboard. It’s the person on the other side of the screen, trying to close the gap between where they are and where they want to be. They’re trusting us to tell them whether it’s working.

If this idea resonates with you, and you’re curious about how a tool like ExecReps could help your team communicate with greater impact, you can learn more about it on our website. It’s been a fascinating journey building it in public, and I’m genuinely excited about what we’re helping people achieve.

“Should we add streaks?” Our designer sent it.

I typed “yes” immediately.

Then I deleted it.

Then I typed a longer answer. Deleted that too.

I stared at the cursor for a solid minute. Behind those six words was one of the most consequential product decisions we’d make. Not technically. Streaks are trivial to build. Philosophically, though, it was huge. Because the answer would define whether ExecReps helps people build a practice, or just guilt-trips them into opening an app.

Very different things, those two.

The Duolingo Problem

Let me back up a little. We’d just shipped v2.5, our personalized experience release. We had role-based navigation. Smart empty states. Progressive disclosure that showed people only what they needed. Don Norman would call that reducing the “Gulf of Execution,” narrowing the gap between intent and interface.

But we had a retention problem. People who practiced three times stuck around. The challenge was getting people to practice three times in the first place. Our activation curve looked like a cliff with a plateau. You either fell off in the first week or stayed for months.

When we ran our engagement features through Nir Eyal’s Hook Model, we scored about 4 out of 10. We had a decent trigger (email invite) and a reasonable action (do a workout). Our Variable Reward was flat, though, and our Investment phase was nonexistent. Users completed a workout and… nothing loaded the next trigger. No real reason to come back tomorrow. Any product team using the Hook Model would recognize that open-ended loop as the problem.

So, the conversation turned to engagement mechanics. And someone said “streaks.”

If you’ve ever uninstalled Duolingo, you know why that word made me pause. Duolingo’s streak system is a masterclass in behavioral design. And, I think, an object lesson in crossing the line from helpful to hostile. The sad owl. The passive-aggressive notifications. The sheer guilt of it all. That thing where you feel worse about breaking a streak than you ever felt good about maintaining one.

I’ve talked to people who kept their Duolingo streak alive for 300 days without learning a single new word. The metric had completely decoupled from the outcome. In Kano Model terms, what should be a ‘delighter’ – a sense of momentum – had degraded into a ‘must-be’ obligation that only generated dissatisfaction when broken.

That isn’t retention. That’s a hostage situation. A podcast guest told me something similar about fitness apps a few months back. The moment the streak becomes the point, you’ve lost the plot on what the product was supposed to do.

BJ Fogg Changed My Mind

I almost killed the streaks idea entirely. Then I re-read BJ Fogg’s Tiny Habits, and his B=MAP model reframed everything.

Fogg’s framework is pretty standard product science now. Behavior = Motivation × Ability × Prompt, all converging at the same moment. Miss any one, nothing happens. The mistake most products make is trying to increase motivation. More notifications, more badges, more guilt. Fogg argues you should instead decrease the effort required. Make the behavior so easy that even low motivation is enough.

That distinction changed everything. The question wasn’t “how do we motivate people to practice?” It was “how do we make practicing the path of least resistance?”

We spent two weeks mapping the behavioral science before writing a single line of code.

BJ Fogg’s B=MAP. Design for the low-motivation moment. Not eager Monday morning, but exhausted Thursday afternoon. If the streak system only works when people are fired up, it’s not a system. It’s a fair-weather friend.

Kahneman & Tversky’s Prospect Theory. People feel losses roughly twice as intensely as equivalent gains. The engine behind every streak system ever built. We’d use loss aversion, but carefully, with an escape valve.

Nir Eyal’s Hook Model. Trigger → Action → Variable Reward → Investment. Our 4/10 audit exposed the missing Investment phase. Our morning nudge system needed to close that loop.

Deci & Ryan’s Self-Determination Theory. Intrinsic motivation requires autonomy, competence, and relatedness. Daniel Pink popularized this as Drive’s AMP framework: Autonomy, Mastery, Purpose. This became our ethical guardrail. Any engagement system that undermines autonomy will eventually backfire.

What We Built (And What We Didn’t)

Streaks, But With an Exit Ramp

Yes, we built streaks. But with one critical difference. We designed the break as carefully as the streak itself.

When you practice, your streak increments. You see a small visual celebration. Dan Saffer calls this a ‘signature moment’ in his microinteractions framework. Not confetti cannons, just enough feedback to trigger Fogg’s “celebration” mechanism. The key is immediacy. Celebration fires within 200ms of completion. Delayed celebration doesn’t wire the habit. Hit milestones (7 days, 30 days, 100 days) and the feedback gets richer. It’s a progressive loop where the microinteraction evolves as your behavior matures.

The part I’m quite proud of? Streak freezes. Miss a day, spend a ‘freeze credit’ to keep your streak alive. You earn these by practicing consistently. It’s Kahneman’s loss aversion working for you instead of against you. You’re spending a resource you banked through good behavior. Cialdini’s Commitment & Consistency principle is baked in. The freeze credits are earned through past commitment, making the current streak feel like something you’ve invested in, not something imposed on you.

If your streak does break? We don’t show a sad owl. We show your best streak as a personal record. “Your best: 23 days. Let’s start a new one.” The streak dies quietly. No funeral. No guilt. Just a clean slate.

Someone on the team argued a broken streak should feel like something. They thought mild pain of loss is what makes streaks work. They weren’t wrong about the psychology. But they were wrong about the ethics. Our users are professionals trying to get better at communication. If they miss a day because their kid got sick, the last thing they need is an app eroding their confidence. That’s a direct violation of SDT’s autonomy principle. Once autonomy is undermined, Deci & Ryan’s research shows intrinsic motivation doesn’t just dip. It collapses.

Morning Nudges, Timed to the B=MAP Window

Our nudge system sends a morning email, not a push notification. That’s deliberate. It’s timed based on engagement patterns. Content varies. It could be a prompt related to something you’re working on, a micro-insight from your last session, or simply “Your 3-minute warm-up is ready.”

The timing isn’t random. We anchored nudges to what Fogg calls ‘anchor moments’. That’s the Tiny Habits recipe: “After I [existing behavior], I will [new behavior].” Most professionals have a cortisol spike in their first waking hour. Alert, but not yet consumed by chaos. That’s when B=MAP converges. Motivation is fresh, ability is high, and the email is the prompt.

The variable reward, straight from Eyal’s Hook Model, comes from the content. You don’t know what the nudge will contain. It might surface a skill gap you hadn’t considered, or a scenario relevant to a meeting that afternoon. Variable rewards of the “hunt” type create curiosity. Curiosity beats obligation every time.

Every nudge has a one-click opt-out. Not buried in settings. Right there in the email. Nielsen’s Heuristic #3, “User control and freedom,” in practice. The moment a nudge feels like spam, trust is gone permanently.

Re-engagement, An Invitation Not an Intervention

For users who go quiet: one email after two weeks. “Here’s something new since you’ve been away. No pressure.” One email. Not a drip campaign. If they don’t come back, we leave them alone. That’s Pink’s Autonomy principle in action. And it matters more than juicing a metric.

The “What We Don’t Build” List

Every product team has a roadmap. Very few have a formal anti-roadmap. We started one during v2.6 planning, and it’s become one of our most valuable documents.

No leaderboards. Communication skills aren’t a competition. Ranking people against each other undermines what Deci & Ryan call ‘relatedness’. That’s the sense you’re part of a supportive group, not fighting for position.

No public scores. Your EPS, streak, practice frequency. All private by default. Nielsen’s Heuristic #7: flexibility and efficiency of use means users control their own data.

No shaming mechanics. No “you’re falling behind” messaging. We learned from our social proof analysis that showing “3 of 15 members practiced today” is negative social proof. Cialdini warns that framing the minority as the example normalizes inaction. We use absolute counts instead. “3 team members practiced today.” No denominator, no implied judgment.

No engagement theater. No features that increase time-in-app without increasing value-to-user. Norman calls this a conceptual model violation. When the product’s goals diverge from the user’s, the relationship erodes.

The Product Lesson: Easiest Beats Loudest

This is an insight I keep coming back to. It applies to virtually every product with a retention challenge.

The best retention features don’t motivate people to do hard things. They make the right thing the easy thing.

The B=MAP alternative to amplifying motivation: make the behavior so frictionless that even a bad day’s motivation is sufficient.

• Shorter sessions, not longer ones. A three-minute warm-up is better than a thirty-minute workout you skip. That’s Fogg’s “Starter Step.” An entry point so small it feels absurd to say no.

• Fewer choices, not more. Progressive disclosure means one clear next step, not twenty options. Norman calls this ‘constraints’. Limiting action possibilities to guide behavior without instructions.

• Gentler nudges, not louder ones. A calm morning email beats five push notifications. Saffer’s microinteraction principle: triggers should match the emotional context, not overwhelm it.

• Graceful failure, not punishment. A quiet streak reset beats a guilt-trip notification.

Our early v2.6 data is encouraging. Streak cohort users practice about 40% more frequently. More importantly, session quality metrics haven’t dropped. People aren’t checking a box to keep a number alive. They’re doing the work. Not sure yet whether that holds over six months, but it’s the right signal.

That’s the difference between a habit and an obligation.

The Uncomfortable Truth About Behavioral Design

Building this system forced me to confront something uncomfortable. Every behavioral design technique is morally neutral. Kahneman & Tversky’s loss aversion can build a healthy practice or trap someone in a toxic loop. Eyal’s variable rewards can spark curiosity or create compulsive checking. Cialdini’s social proof can inspire action or manufacture peer pressure. The framework doesn’t care about your intentions.

I wonder if that’s the biggest design challenge we face today. Not building the features, but building the ethics around them.

We optimized for practice quality, not app opens. For skill growth, not session count. We built explicit escape valves, too. Freeze credits, quiet resets, one-click opt-outs. Because these tools were powerful enough to do real harm if deployed carelessly. I’m not sure we got every detail right, but the intent was right.

That three-week internal argument about streaks – the one that started with six words in Slack – was the most valuable product discussion we’ve had. The most important product decisions aren’t about what you build. They’re about why you build it. And what happens when it works exactly as designed.

If you’re building engagement systems, write your own “what we don’t build” list before you write a single user story. You might be surprised how much clarity it provides. It sure did for us, and it’s why we built ExecReps the way we did.

And if you ever find yourself designing a sad owl, stop. Close your laptop. Go for a walk. You’ve lost the plot.

The user, a senior PM at a mid-size SaaS company, had scored well on our platform. Her content was structured, her arguments logical, her delivery measured. By every objective metric we’d built, she was a strong communicator.

Her feedback, though, said: “I guess I’m just not a natural speaker. My scores are fine but I still don’t feel like I know what I’m doing.”

Fine scores. No identity.

That’s when I realized we’d built a measuring stick when people wanted a mirror. The thing I kept coming back to was this idea of identity.

The Score Trap

Let me rewind. By November 2025, ExecReps had acoustic voice analysis working. V1.0 shipped with AssemblyAI-powered analysis of pace, filler words, clarity, confidence.

Users would record a practice response to a scenario like ‘Your CEO just asked you to explain why the roadmap is slipping, go,’ and we’d break down both content quality and vocal delivery.

The scores were… fine. People used them. People improved. Something, though, was missing.

I’m not sure if it was the numbers themselves, or just how we were presenting them. I wonder if it’s just human nature to want more than a number.

I kept hearing the same questions: “What’s a good score?” “Am I normal?” “How do I compare?”

These aren’t questions about improvement. These are questions about identity. People weren’t asking “How do I get better?” They were asking “Who am I as a communicator?”

Anyone who’s read Deci and Ryan’s Self-Determination Theory would recognize the pattern. Scores satisfy competence (one of three basic psychological needs) but completely miss relatedness and autonomy.

A number tells you where you rank. It doesn’t tell you where you belong.

I’d spent fifteen years building products and somehow missed one of the most documented insights in motivation research. People don’t optimize for numbers. They optimize for a sense of self.

This reminds me of a conversation I had with a founder recently, talking about how a lot of fitness apps fail because they focus on calories burned, not on the feeling of being an ‘athlete.’ It’s the same thing.

The Research Rabbit Hole

Once I saw the problem, I couldn’t unsee it. So I did what any product person does when they sense an insight. I went deep into the research.

I started with the usual suspects. Big Five (OCEAN) is scientifically validated, but measures who you are, not how you communicate. DISC is closer, but too static. Myers-Briggs has too much pseudoscience baggage. Sixteen types is a nightmare for product design.

None of these were designed for voice. They were built for survey responses and check boxes.

We had actual recordings of people speaking under pressure, with measurable acoustic properties. So we built our own.

Four dimensions emerged:

Command. How much authority and conviction comes through. Not volume. Certainty. Vocal steadiness, declarative phrasing, pacing that says ‘I know what I’m talking about.’

Eloquence. The precision of expression. Vocabulary range, sentence structure, the ability to find exactly the right word instead of four approximate ones.

Engagement. How much you pull people in. Vocal variety, storytelling instincts, tonal warmth. The difference between reading a report and making someone lean forward.

Consistency. How stable your communication is across contexts. Some people are brilliant in a 1:1 and fall apart in front of a group. This dimension measures the gap.

We called it the Voice Performance Score, VPS. We scaled it 400 to 1000, like the SATs.

That familiar-scale choice comes straight from Nielsen’s Recognition over Recall heuristic. If your scoring system requires a user manual, you’ve already lost. The SAT scale gave people an instant mental model. No learning curve.

The VPS wasn’t the breakthrough, however. The archetypes were.

Eight Ways to Speak

What I saw at a company in education (as well as at “MyersBriggs”, “Working Genius” etc ), was this: when you give someone a category to belong to, they engage differently with your product.

At FYG we profiled students into career pathways. The moment a student could say ‘I’m a Builder’ or ‘I’m an Advocate,’ their engagement doubled. Not because the content changed. Because their relationship with the content changed.

If you know the Kano Model, this is the difference between a ‘must-be’ feature and a ‘delighter.’ Scores are must-be. You expect them in an analysis tool. Archetypes are a delighter.

Nobody asked for them. Once people had them, though, they became the reason people came back. Kano’s insight is that delighters create disproportionate satisfaction precisely because they’re unexpected.

So we mapped the four VPS dimensions into eight communication archetypes:

The Analyst. Clarity is their superpower. Blind spot: clarity without engagement can feel cold.

The Commander. Walks into a room and people listen. Not loud, but certain. Blind spot: steamrolling without realizing it.

The Diplomat. Reads the room better than anyone. Builds consensus. Blind spot: prioritizing harmony over directness.

The Maverick. Brilliant in bursts. The off-the-cuff comment everyone remembers. Blind spot: inconsistency.

The Mentor. Natural teachers who make complex things simple. Blind spot: over-explaining when the room just needs a decision.

The Practitioner. Reliable, trusted, steady. Won’t dazzle you, but will never let you down. Blind spot: disappearing in Commander-dominated rooms.

The Storyteller. Turns data into narrative, problems into quests. Blind spot: not every moment needs a story.

The Visionary. The full package when they’re on. Paints futures people run toward. Blind spot: so compelling nobody challenges them.

Choosing eight was a deliberate product decision. Four would have been too broad. People wouldn’t see themselves. Sixteen too granular. Too many edge cases where users fall between types.

This is what Don Norman calls building the right conceptual model: if the model is too simple, people distrust it. If it’s too complex, they can’t hold it in their heads. Eight sits in the cognitive sweet spot. I still wonder if there’s a ‘perfect’ number, but eight just felt right, you know?

We debated whether archetypes should be fixed or fluid. Fixed archetypes are easier to build product around. Fluid archetypes are more scientifically honest. Your style does shift based on context.

We chose a middle path. Your archetype is your dominant style based on your body of work. We surface how your dimensional scores shift across scenarios.

So you might be a Diplomat overall, but skew Commander during board presentation practice. That nuance maps to Daniel Pink’s Autonomy principle from Drive. It gives users freedom to explore their communication range rather than boxing them in. The dominant archetype gives you identity. The dimensional shifts give you agency.

The LinkedIn Moment

We shipped archetypes on November 16th. Within the first week, something happened that I did not expect.

People started sharing their archetype on LinkedIn. Not their score. Not their improvement percentage. Their archetype.

“Just found out I’m a Storyteller on ExecReps. Honestly tracks 😂”

“Apparently I’m a Commander. My team is not surprised.”

“Diplomat here. Which explains why I spend half my life translating between engineering and sales.”

The product insight that hit me then, and that I hope lands for you too, is this: people share identity, not metrics.

Nobody posts their credit score on LinkedIn. Nobody shares their Duolingo XP. They’ll share their Hogwarts house, their Enneagram number, and now, their communication archetype.

Through the lens of Nir Eyal’s Hook Model, we’d accidentally built a complete engagement loop: someone sees an archetype post on LinkedIn (external trigger). Curiosity drives them to try ExecReps (action). They discover their archetype, any of eight possibilities (variable reward, the ‘Hunt’ type). They share it publicly, loading the next trigger for their network while creating a public identity commitment (investment).

We hadn’t designed this loop. Every piece was there, though. I wonder if we could have planned it, or if some of the best product moments just emerge like this, almost by accident.

And what made it powerful rather than gimmicky: the archetypes were grounded in real behavioral data. This wasn’t a quiz telling you what you already knew. It was acoustic analysis of how you speak under pressure.

Cialdini’s Authority principle explains why it stuck: the archetype carries weight because the source is rigorous. A personality quiz calling you creative is forgettable. A voice analysis confirming it is not.

The Diplomat Problem

The title of this post is about Diplomats, and I want to get specific.

When archetype results started rolling in, something interesting emerged. Diplomats were disproportionately likely to have previously described themselves as “bad communicators” in their onboarding surveys.

Read that again. The people most skilled at reading rooms, building consensus, and managing complex interpersonal dynamics… thought they were bad at communication.

Why? Because in most professional environments, ‘good communicator’ is coded as ‘Commander.’ Be decisive, be loud, be certain.

If your natural style is diplomatic. If you listen before speaking, build bridges instead of podiums, choose precision over volume, you’ve been told your whole career to “speak up more.”

Kahneman and Tversky’s work on framing effects explains this precisely. The professional world framed ‘communication skill’ around a single archetype, and Diplomats measure the gap between their style and the dominant one. They interpret that gap as deficiency. It’s a framing problem masquerading as a skill problem.

This hit close to home. I still remember being told my Cockney accent, my natural speaking voice, disqualified me from a design job early in my career. The implicit message then was ‘the way you communicate doesn’t belong here.’ It wasn’t about the content of what I said, but the sound of it. It was about identity, about belonging.

That’s the same message every Diplomat gets in a Commander-dominated culture. Every Mentor told they’re ‘too soft.’ Every Analyst told they’re ‘too in the weeds.’

The archetypes reframed what ‘good communication’ even means. There isn’t one model. There are at least eight.

Personas As Product

This is the product lesson I keep thinking about, because I believe it’s underappreciated:

Personas aren’t just a marketing tool. They can be the product itself.

What if the persona isn’t something you build about the user, it’s something you build for them?

Spotify Wrapped understood this. ‘I’m a top 1% listener of Japanese city pop’ is more powerful than any feature Spotify has ever shipped.

When we built archetypes into ExecReps, three things changed, and they map to frameworks any product team would recognize.

Retention jumped. Self-Determination Theory explains why: an identity satisfies all three psychological needs at once, competence (‘I’m a strong Diplomat’), autonomy (‘I choose to develop my style’), relatedness (‘I belong to the Diplomat tribe’). That’s Pink’s Mastery drive, visible progress along a path you’ve claimed as your own.

The product got easier to build. Archetypes gave us a design language. ‘You’re becoming a more commanding Diplomat’ is infinitely more motivating than ‘Your Command score increased by 40 points.’ Norman’s conceptual model principle: when the mental model is rich and intuitive, every communication taps into it.

Word of mouth ignited. BJ Fogg’s B=MAP model explains the mechanics: Motivation was sky-high (identity validation), Ability was trivial (screenshot and post), and the Prompt was the archetype reveal itself. All three maxed at the moment of discovery. We’d accidentally engineered sharing behavior at the exact point where Fogg’s equation was maximally favorable.

Two weeks later we shipped v1.3, the Executive Performance Score. Technically more sophisticated. Content weighted at 60%, delivery at 40%. Population-normalized. Objectively better.

Nobody shared their EPS on LinkedIn. They shared their archetype.

What I’d Tell Myself

If I could go back to early November 2025, deep in acoustic analysis, obsessing over signal processing, I’d tell myself: the most important feature you’re about to ship isn’t the most complex one. It’s the one that helps someone say ‘Oh, that’s who I am.’

Because the biggest barrier isn’t skill. It’s self-knowledge. Most people aren’t bad communicators. They’re communicating in environments that reward a style that isn’t theirs, and they’ve internalized that mismatch as a personal failing.

You’re not a bad communicator. You might just be a Diplomat in a room full of Commanders.

Once you know that, once you see it, you stop trying to be something you’re not, and start figuring out how to be the best version of what you already are.

This idea, this reframing, is at the core of what we’re trying to build with ExecReps. It’s about helping people find their voice, not just change it. I’m still learning how to articulate this, but it feels important.

She was a product director from a Series B startup. Smart as hell. Her answer to our practice prompt, a mock board presentation on quarterly growth, was structurally flawless. Perfect, even. Clear thesis, supporting data points, strong close.

Our AI gave her a stellar score.

Then I played the audio.

She said “um” twenty-three times in ninety seconds. Her pace swung between racing through numbers at 210 words per minute and grinding to a near-halt when she hit anything she wasn’t sure about. Stretches where her voice got so quiet it almost disappeared.

None of that showed up in our assessment. For the first four months of building ExecReps, our AI couldn’t hear anyone. It could only read.

I keep coming back to that moment when someone asks about finding product-market fit. The thing that makes your product ‘real’ isn’t always the thing you build first. Sometimes it’s the thing you were accidentally ignoring.

The Text-Only Era

Let me back up. When we launched v0.1 in July 2025, the core loop was simple: you record yourself speaking, we transcribe it, GPT–4 evaluates the transcript, you get feedback. Record, Transcribe, Assess, Improve.

If you’ve read Nir Eyal’s Hook Model, you’ll recognise that structure. External trigger (the prompt), action (record yourself), variable reward (personalised AI feedback), investment (your practice history building over time). It worked.

GPT–4 is good at analysing structure, directness, and evidence. Users were coming back daily, practising pitch decks, preparing for all-hands, rehearsing difficult conversations. BJ Fogg’s B=MAP model would have given us decent marks: motivation was there (real presentations coming up), ability was easy (speak for two minutes, get instant feedback), and the prompt was the product itself.

I almost fell into a trap here. The product was working. Users were engaged. Growth was happening. Every instinct in my PM brain said ‘don’t touch it. Optimise what’s working.’

But something gnawed at me. We were building a communication coaching tool that only analysed what people said, not how they said it. We were a voice product that was functionally deaf.

This reminds me of a conversation I had with a guest on the Product Coalition podcast a while back, talking about the gap between perceived and actual performance. In Don Norman’s terms, we’d created a massive Gulf of Evaluation. Users would record themselves, get text-based feedback, and think “great, I’m improving.” They had no way to evaluate their actual delivery. That’s the part that mattered most for their career. The system was hiding their most critical signal from them.

The Origin Story Collision

I need to tell you why this bothered me more than it probably should have.

Years ago, I graduated from university in London with a design degree. Portfolio polished, creative director at a prestigious agency loved my work. Then the call came: “Jay, I have to be honest with you. Your work is great. Your attitude is great. But we can’t employ people who talk like you.”

My working-class Cockney accent. That was it.

Not what I said. How I sounded.

I was building a product whose entire origin story was about the injustice of being judged by your delivery, and the product itself could only judge content. The irony was not lost on me.

Every time I reviewed a user submission and saw a clean transcript score next to audio that told a completely different story. Rushed pace, vocal fry, filler words stacking up. I felt the gap widen. Kahneman calls this WYSIATI: ‘What You See Is All There Is.’ Our users were suffering from it. They’d look at their text-based score, see nothing flagged about delivery, and conclude their delivery was fine. The investor who later told us “I thought I sounded the same the whole way through”? That’s WYSIATI in action. If the system doesn’t show you a problem, your brain concludes no problem exists.

Going Acoustic

In September 2025, I started researching acoustic analysis providers. Building it ourselves lasted about a week. Training acoustic models from scratch is a rabbit hole that has swallowed entire startups. Build vs. buy was an easy call.

AssemblyAI became our answer: pace detection, filler word identification, pause analysis, and raw data we’d need for confidence and clarity metrics.

The hard part wasn’t the API calls. It was deciding what to do with the data. AssemblyAI gives you a firehose. Every millisecond of audio has extractable features. Which ones matter most? I’m still not sure we’ve found the perfect answer here, but we’re getting closer.

Nielsen’s heuristic of “recognition rather than recall” shaped our thinking here. We didn’t want to dump a wall of acoustic data on users. We needed to surface metrics they’d immediately recognise as relevant. Pace variation they could hear in their own head, filler words they’d felt themselves say. The data had to match their fuzzy memory of the recording, then sharpen it.

The 80/20 Decision

This is the product decision I think about most from that period. I still wrestle with it sometimes.

We now had two signals: content quality and delivery quality. My first instinct was 50/50. That’s what every public speaking book tells you. Mehrabian’s “7–38–55 rule” even suggests delivery matters ‘more’.

Mehrabian’s research is about emotional communication, not professional presentations. When a product director presents quarterly numbers, the content matters more than her pacing. If the analysis is wrong, no amount of vocal confidence saves it.

We went with 80% content, 20% delivery. It felt conservative. Part of me wanted to weight delivery higher because that was our differentiator.

A product team that’s worked with the Kano Model would recognise the trap. Acoustic analysis was our ‘delighter,’ the feature that surprises and differentiates. Content quality was our ‘must-be,’ the foundational feature users expected to just work. Kano’s research is clear: over-invest in delighters at the expense of must-be quality and the whole product collapses.

The 80/20 split evolved to 60/40 by v1.3 as our delivery analysis matured. Starting conservative was right. You can always increase the weight of a signal as it improves. Decreasing it after users have relied on it is harder. That’s Kahneman and Tversky’s loss aversion at work. People feel losses roughly twice as intensely as equivalent gains. Telling a user “your delivery score now counts less” feels like taking something away. I wonder if we could have communicated that better, in retrospect.

The First Real Analysis

I remember the exact day we ran the first complete acoustic analysis. Early November 2025, right before v1.0 went live.

A beta user doing a practice investor pitch. Transcript score was strong: clear problem statement, solid market sizing. Under the old system, encouraging feedback, move on.

The acoustic analysis told a different story. His pace averaged 178 WPM, fine, but variance was extreme. Racing through market opportunity at 220+ WPM (nerves) and crawling during financials (uncertainty). He used “basically” seventeen times. Two pauses over four seconds. Not power pauses, but the kind where someone loses their thread.

When we showed him the combined assessment: here’s what you said (strong), here’s how you said it (needs work), here’s exactly where. He sent us a message I still have saved:

“I’ve given this pitch eleven times. This is the first time anyone told me I speed up when I’m excited and slow down when I’m unsure. I thought I sounded the same the whole way through.”

That message illuminated something about what Daniel Pink calls Mastery in his Drive framework. People can’t improve what they can’t see. The text-only version gave users mastery over ‘content.’ Delivery mastery was invisible. They had no feedback signal, no progress to track, no way to know if they were getting better or just more comfortable with bad habits. Acoustic analysis opened an entire mastery dimension that had been locked.

The Product Lesson: Finding Your 10x Moment

If you’re building a product, especially an AI product, there’s a concept I keep coming back to: the 10x moment. It’s the point where your product stops being “useful” and starts being ‘I can’t go back to not having this.’

Text-based feedback was useful. Valuable. Users came back.

Acoustic analysis made ExecReps ‘real.’ It was the difference between a product that told you ‘what to say differently’ and one that told you ‘how you sound when you say it.’

In Hook Model terms, acoustic analysis transformed our variable reward. Text-only feedback was becoming predictable. After a few sessions, users could roughly guess their content score. Eyal is explicit: predictable rewards lose their pull. Acoustic analysis reintroduced variability. Every recording surfaced something unexpected. ‘I didn’t know I did that’ is the most powerful variable reward a coaching product can deliver.

I’ve learned this about 10x moments: they’re usually hiding in the thing your product should do but doesn’t yet. They feel obvious in retrospect. ‘Of course a voice coaching tool should analyse the voice.’ When you’re in the weeds of building, though, the temptation to optimise what exists instead of building what’s missing is enormous.

The framework I use now is simple: “What is the most obvious thing our product should do that it currently can’t?” Not the clever thing. The ‘obvious’ thing. The thing a non-technical friend would ask about at dinner. ‘Wait, your voice coaching app doesn’t listen to people’s voices?’

That’s where your 10x moment lives.

What Acoustic Analysis Taught Me About the Mission

When communication coaching was something only Fortune 500 executives could access at $500–$1,000 an hour, those coaches were listening. They caught the pace changes, the filler words, the confidence drops. Human ears doing acoustic analysis with years of experience.

Every product that had tried to democratise this before us stopped at text. Grammar checkers, script analysers, AI writing assistants: all content, no delivery. None could hear you.

By going acoustic, we closed the gap between what a $1,000/hour coach provides and what everyone else has access to. That’s the mission we started with at Product Coalition, in a way: making product management knowledge accessible. This feels like a natural extension of that.

Executive presence isn’t about talking points. Anyone with ChatGPT can generate those. It’s pace and pause and conviction and clarity. It’s what got me rejected from that design agency. Deci and Ryan’s Self-Determination Theory says people need competence feedback to stay intrinsically motivated. Our text-only product gave users an incomplete competence signal, half the picture. Acoustic analysis completed it. When people feel competent, they don’t need external pressure to practise. They come back because they ‘want’ to.

What Came Next

Shipping v1.0 with acoustic analysis in November 2025 was just the beginning. Once we could hear, we needed to understand. The Voice Performance Score in v1.2 broke delivery into Command, Eloquence, Engagement, and Consistency. Then v1.3’s Executive Performance Score unified content and delivery into a single metric tracking progress over time.

Each was its own battle. All downstream of the same decision: stop being deaf, start listening.

Four months of a product that could only read. One afternoon hearing a user who didn’t know she said “um” forty-three times. And a bet that the obvious missing piece was worth the engineering investment.

Because the metrics were fine. The product was still incomplete.

That dissonance, between what the data says and what your gut knows. If you’re building something that matters, learn to listen to it. Pun fully intended.

I had just graduated from university in London. Design degree. A portfolio I was proud of. I’d interviewed at a design agency I’d been obsessing over for months. The kind of place with exposed brick and people who used ‘kerning’ as a verb. The creative director had spent forty-five minutes going through my work. He loved it, laughed at my jokes, and shook my hand, saying he’d be in touch.

He was.

“Jay, I have to be honest with you. Your work is great. Your attitude is great. But we can’t employ people who talk like you.”

People who talk like you.

I’m from East London. Cockney. Not the charming Guy Ritchie kind. The actual kind, where “th” becomes “f” and sentences end before they technically should. The kind that, apparently, disqualifies you from working at a place where your job is to design things with your hands.

I didn’t argue. I didn’t feel angry, not at first. I felt something worse. I felt like he was probably right. That’s what rejection based on how you sound does. It doesn’t just close a door. It makes you believe the door was never meant for you.

The Hidden Filter

Something nobody tells you about professional life is that there’s a filter sitting underneath every other filter. It’s not on any job description. No recruiter will mention it. It’s there in every meeting room, every pitch, every interview, every promotion committee.

It’s how you sound.

Not what you say. How you say it. Your accent, your cadence, your filler words, whether you uptalk or downspeak, whether your voice carries the invisible markers of a particular postcode or tax bracket.

I remember reading Daniel Kahneman’s Thinking, Fast and Slow and it felt like someone was explaining my own life back to me. He and Tversky showed that humans make snap judgments, what he called System 1 thinking, based on surface signals, then rationalize them after the fact. That creative director didn’t spend forty-five minutes evaluating my portfolio and then make a reasoned assessment. He made a gut decision in the first thirty seconds of hearing me speak. Everything after was confirmation bias in a nice chair.

Any product team that’s studied cognitive biases would recognize the pattern. We just usually apply those insights to button colors. Not to someone’s career. I sometimes wonder if that’s the biggest blind spot in all of product management.

I spent the next twenty years building a career despite that phone call. I led product teams, founded companies, and grew Product Coalition to over a million readers. I sat on the Harvard Business Review Advisory Council. I built Find Your Grind into a $20M EdTech company.

At every single stage, I watched the same pattern repeat. Not just for me. For everyone.

The engineer who has brilliant ideas but gets talked over because she pauses too long between thoughts. The sales leader who loses deals not because his product is worse but because his delivery doesn’t carry what someone like Cialdini would call ‘authority signals’. These are the vocal patterns and confidence markers that make listeners trust the speaker before they’ve processed the content. The first-generation professional who has all the skills but none of the communication patterns that come from growing up around boardroom tables.

Communication coaching exists. It’s just not for them. It’s for Fortune 500 CEOs who pay $500 to $1,000 an hour. Everyone else gets a line in their performance review that says “needs to work on executive presence,” with precisely zero guidance on what that means or how to do it.

The Realization That Broke It Open

Sometime in early 2025, I was watching the AI space consume everything. Writing emails. Polishing documents. Drafting presentations. Generating images. Building code. Every piece of professional output was getting an AI layer.

Except one.

Your voice. The way you speak, persuade, inspire, connect was completely untouched. No infrastructure. No tools. Nothing.

Then I realized something I haven’t been able to un-think since: your voice is your last IP.

In a world where AI can write anything, design anything, code anything, the one thing that’s still authentically, irreducibly you is how you communicate when you open your mouth. It’s about autonomy, that fundamental human need to express your authentic self. Your presence in a room. Your ability to land a point, hold a silence, turn a hostile question into a moment of connection. That’s not something you outsource to a language model.

Yet there’s nothing helping people develop it at scale.

Building the Thing

I started building ExecReps in the spring of 2025. The concept was deceptively simple. AI-powered practice for high-stakes conversations. You speak. It listens. It gives you feedback on pace, clarity, filler words, confidence, structure. An Executive Performance Score to track improvement over time.

Not “speak like a TED Talk.” Not “sound more corporate.”

Not “lose your accent.”

That last part matters to me more than any feature we’ve ever shipped.

If you’ve worked in product, you know BJ Fogg’s model. Behavior happens when Motivation, Ability, and a Prompt converge. My entire v0.1 was designed around one question from that framework: what’s the simplest possible action at the moment someone is motivated to improve?

Press record. Speak for three minutes. Get feedback.

No onboarding carousel with seven screens. Just a microphone, an AI, and the lowest possible Ability threshold Fogg would accept.

On July 7th, 2025, I shipped v0.1. Google OAuth. Stripe. Voice recording, transcription, GPT–4 assessment, admin dashboard, support chat. It was all duct tape and ambition.

That first version could do exactly one thing well: listen to you speak and tell you what you could do better. No archetypes. No voice performance scoring. No team analytics. Anyone who’s used the Kano Model would recognize what we shipped. The must-have quality, nothing more. The basic expectation that has to work before delighters matter.

It was enough.

It was enough because it proved the one thing I needed to prove. That people would open a browser, press record, speak into the void, and care about what came back. It was a test of Nir Eyal’s Hook Model. I needed to know if the basic loop would close. Would an external trigger (an email invite) lead to an action (recording a workout), produce a variable reward (personalized feedback that surprised them), and create enough investment (seeing their score, wanting to improve it) that they’d come back without being asked?

That first version was a test of whether the hook existed at all.

The Product Lesson: Founder-Market Fit Is Not a Buzzword

I want to talk to the product managers reading this, because this is the part that took me fifteen years to understand.

We talk a lot about product-market fit. Important questions. There’s something that comes before all of it, though. The thing that determines whether a product has a soul or just a roadmap.

Founder-market fit.

Not “I spotted a market opportunity.” Not “I read a McKinsey report that said the executive coaching market is worth $15 billion.” I mean: has this problem left a mark on you?

Daniel Pink’s book Drive breaks this down perfectly. Extrinsic motivation, like money or market opportunity, fades the moment things get hard. Intrinsic motivation is built on Autonomy, Mastery, and Purpose. The founders who survive aren’t optimizing for TAM. They’re driven by Purpose, a problem they can’t stop thinking about because it happened to them.

That phone call in London wasn’t market research. It was a scar. Scars make better products than spreadsheets.

The first reason this matters is survival. Every product hits a trough where nothing is working. Users aren’t growing. The feature you shipped didn’t move the needle. Pink’s research is unambiguous. Purpose-driven motivation outlasts reward-driven motivation under sustained difficulty. If your motivation is “the market opportunity is large,” you will quit during the trough. If your motivation is “I got a phone call that told me I wasn’t good enough because of how I sound, and I know millions of others got the same call,” you will not quit.

It also calibrates your intuition. When you are the user, you make a thousand micro-decisions correctly without needing data. Kahneman’s work on expert intuition shows it develops in environments with clear feedback loops and repeated practice. This is exactly what founders get when building for their own problem. You know which feedback to give first because you know what would have helped you.

Finally, your story becomes your moat. In a market that’s about to get crowded, and the AI communication space will get crowded, the company with the founder who lived the problem will always sound different from the company that identified an opportunity. Users can tell.

When I tell people what ExecReps does, I don’t start with features. I start with a phone call from a creative director who liked my work but not my voice. Every single time, something shifts in the conversation. They’ve had their version of that call too.

The Uncomfortable Part

I want to be honest about something. This is a building-in-public series, and I’d rather be uncomfortably honest than comfortably polished.

When I shipped v0.1, I wasn’t sure it would work. Not the product. The idea. Previous voice coaching products had failed because they misjudged the Ability variable in Fogg’s equation. They asked users to do too much. Record a full presentation. Complete a 30-minute module. Invite colleagues to listen. The Motivation was there. The Prompt was there. Yet the Ability gap killed them.

My bet was that a three-minute solo workout with instant AI feedback was below the threshold where behavior happens. Not “I should do this” but “this is easy enough that I just did it.”

I didn’t know it would be different. I just knew I had to try. I’m still not sure we have the balance exactly right. I wonder whether we’re asking for too much, or even too little. We’re constantly tuning it.

There’s a version of my career where I keep running Product Coalition, keep advising startups, keep writing articles about product management frameworks. It’s a good career. Comfortable. Respected.

But there’s that phone call.

Every time I hear about a talented person who can’t get past the invisible communication filter, who gets the performance review that says “needs more executive presence” with no tools to develop it, I hear that creative director’s voice again. We can’t employ people who talk like you.

Fifteen years of building products taught me that the best time to start is before you’re ready. So on July 7th, 2025, I pressed deploy on something that was emphatically not ready. A foundation. A starting line. Voice recording, transcription, AI feedback, and a deeply personal bet that this problem was worth solving at scale.

What Comes Next

So this is the first post in a series. I’m not sure what the cadence will be, or even what the second post will cover. Maybe the tech stack. Maybe our first ten customers. The point is to do it in the open. I’ve spent years writing about how other people build products at Product Coalition. It feels right to turn the lens on myself.

I wanted to start here, at the very beginning, because the origin matters. It’s the thing I come back to.

It’s my simple filter for every hard decision. Does this feature serve the person who got that phone call? Does it make executive-level communication development accessible to someone who can’t afford $1,000 an hour? Does it help someone’s talent get heard rather than filtered?

If yes, we build it. If no, we don’t.

Twenty years between a phone call and a deploy button. Let’s see what happens next.