Product planning: scoping an insights feature

Overview

Mike and Nick held a wide-ranging product planning session, primarily focused on scoping a new stats/insights feature. The conversation branched into architecture concerns (how to collect and migrate stats), sharing mechanics, and a series of side discussions covering home view performance, settings UX, the talat Call and screen-share feature, and upcoming releases. The outcome was agreement to draft a proposal for the stats work, built with global, per-meeting, and per-speaker views in mind from day one.

Key discussion points

Scope of the stats/insights feature

• Nick pushed to generalise beyond "a stats page in talat" to asking "where could we capture statistics from?", identifying three surfaces: global usage stats, per-meeting stats, and per-speaker stats.
• Per-meeting stats: Nick argued it is "legitimately viable" and "quite cool", a visual review tab showing speaker dominance and the ebb and flow of a conversation. Mike thought it less important if stats is primarily a marketing tool, but agreed it is worth considering.
• Nick disagreed that stats is just a marketing or screenshot tool. Good meeting stats still market the product and are shareable internally. He floated the light-hearted angle of highlighting a "blabbermouth" who dominated a call.
• Per-speaker insights: Nick suggested navigating to a speaker's profile to get insights about them, an engagement hook. Example: lots of calls with someone who does not use talat, say Sam; send Sam some insights and they say "I never knew that about me, where's this from? Oh, it's talat." Could tie into a refer-a-friend flow. Mike liked it.

Naming: insights vs stats

• Mike noted WhisperFlow calls it "insights" not "stats", which both preferred. Nick worried they might regret the name if they later build deep meeting insights (for example, "you talked about this topic for the 300th time this year", cross-meeting conversation threads). Possible resolution: namespace the deeper feature separately, or surface a light-bulb "insight" banner within the stats view.

Candidate stats/metrics discussed

• Words spoken (global, all speech talat transcribed for you, ideally per-speaker) and words dictated.
• Time saved, similar to Whisper (based on typing versus dictation speed), as a separate stat. Nick wanted to lean into the "how much time we've saved you" framing.
• Speaking speed or words per minute, treated as a global personality trait ("do you plod through your speech"). Mike confirmed they already have this in the prototype, using word timings to calculate the average.
• Utterance length: "are you a monologuer?" (already covered in Mike's archetype prototype).
• Number of meetings and hours of meetings (some users wear this as a badge of honour).
• Contribution rate: your share of talking relative to the number of people (10 in the meeting, you do 20% = 2x).
• Questions asked and question-asking rate; question-answer rate (next to speak after a question), acknowledged as "fluffy" but fine if in the right ballpark.
• Target app usage: "your favourite app that you talk to is Terminal", already captured per dictation.
• Streaks and a heat map (a colour-coded map). Nick's twist: meetings are anti-productivity, so consider an inverse streak, the most days without a meeting or the biggest gap without recording. Weekends should be excludable.
• Where you spend time on calls (derived from the calendar invite or which app holds the mic lock). This metadata is not currently stored, so tracking would need to start.
• Meta-analysis: a time-of-day heat map of when you are busiest, average audience size, average meeting length, tags over time.
• "Your voice" fluff (catchphrase, most-used word, voice profile). These felt like the fluffier end of the list, but people demonstrably want them (a user pointed at WhisperFlow's version, and another requested it ages ago).
• Per-meeting comparisons: "this meeting was 10% longer than usual" or "you talked more than usual", bell-curve style.
• Using chapter data for meeting stats: who talks most per chapter, or which topic matters most to each person.
• Percentage of speech assigned to people, potentially gamifiable to nudge assignment.

Multilingual concern

• Word-based metrics like words per minute do not translate cleanly to every language. Chinese and Japanese are written without spaces between words, and segmenting them into words is genuinely ambiguous, which is why speech recognition for Chinese is scored on characters rather than words. The natural unit there is the character, which in Mandarin maps almost one to one onto syllables, so a speaking-pace stat should measure in whatever unit suits the language and normalise so the figure stays comparable, rather than forcing a single word count. Being able to answer questions like this live inside the app would be the dream.

Archetypes / caricatures

• Mike has previously floated an archetype ("what sort of talat user you are"). Nick warned they must be extremely careful: abstract avatars only, no depicted gender or ethnicity (a coin-flip chance of being wrong on gender). Mike cited 16 Personalities as a popular, well-executed reference with generic characters. Agreed to explore it.

Sharing mechanics

• Tension between shareable stats and stats that are too personal or identifiable, possibly splitting "share stats" from "deep dive stats".
• Nick was relaxed for an MVP (people will screenshot anyway; most know the Mac clip shortcuts). Mike pushed back hard: sharing should be promoted and as easy as possible, ideally a shareable card. Nick agreed, possibly a card per section.
• Social posting limits: some networks support web-intent compose URLs but text only, no image; others can only open a blank compose panel with no prefilled text or image. Fallback: a copy or download button rather than OS-level share sheets.

All-time vs time-bound stats (unresolved disagreement)

• Nick: all-time stats matter most for chest-beating ("I've got six million hours in this game"), with no date-range ambiguity. Time-bound (30-day) stats are more interesting from a business-function view than as shareables. He rejected the "people want to compare to each other" logic.
• Mike disagreed strongly, citing Spotify Wrapped: being time-bound makes it comparable ("it's been a busy month" against someone else sharing theirs). Different date ranges feel odd to compare.
• Nick countered that an archetype should be near-immutable, not swinging month to month. Both agreed to concede they could offer both (for example, all-time speaking rate plus last-30-days meeting counts). Nick pointed to how far another app takes date ranges and comparison cards as an example of how far this could go, while cautioning against going too far down the rabbit hole.

Stats collection & migration architecture

• Core problem: stats cannot be reliably derived from current database state, because users can delete meetings and clear dictations (there is a "clear all" button and a dictation retention policy). So aggregates must be stored in separate stats tables.
• Existing users' data must be bootstrapped, which risks a painful "stop the world" migration that may need re-running if a stat is missed.
• Meeting stats face a timing issue: speaker assignments may not be finalised when a meeting ends and can change over the next couple of days. Mike proposed a slower-cadence background process: generate on meeting end, then do a second pass later, marking what has already been processed rather than a one-off migration.
• Nick clarified his mental model: the migration creates the future-proof schema, but data population is application logic (a background thread, timers or triggers, or lazy-loaded on first visit to the insights page). A pure SQL data migration "would be our end".
• Nick rejected the shortcut of deriving v1 stats with no table; it just kicks the same question down the road. Better to pay the cost now and be forward-thinking to minimise migration churn.
• Nick briefly floated a separate stats database. Mike: "No, Nick, you're crazy."
• We looked at another stats-heavy app we have built as a reference for long-term windowing, aggregation, and comparisons, if only as an example of what not to do.
• Agreed they must be able to rerun or regenerate stats (a slice or the full set), always on a background thread so it does not stall the UI.

Home view performance (side thread)

• Nick's home screen is starting to load slowly, with a visible gap before rows paint. He is a fairly light user; heavy users will have disproportionately more meetings.
• Fixes: load a chunk (for example the first 100 meetings, no scroll) then lazy-load the rest, since people rarely care about old meetings. Nick's ideal is to not show the main window until data is ready (a few extra milliseconds) so the first paint is the rows.

Settings UX (side thread)

• Mike praised the settings as consistent and clean but "information overload for the average user". Whisper's app is basically one big settings page, yet feels more approachable.
• Suggested custom components, big buttons, banners, friendlier (less rigidly consistent) grouping, and possibly an advanced settings section per group. Nick agreed but noted it is organisational overhead they have deprioritised; he has already shrunk the settings list and reworded much of the filler.

talat Call / screen share / sync (major side thread)

• Nick strongly wants to ship talat Call and talat Sync, partly because he needs it (so he and Mike do not have to juggle separate dev instances) and it is so close.
• Basic screen share is working at around 10fps. Envisioned first-class features: snapshot the video into the talat timeline, plus an ephemeral scribble layer before screenshotting, which would be powerful for sketching over a shared design.
• Blockers and risks: we still need to settle which video codec we can use, and there is uncertainty about how peer-to-peer screen-share bandwidth scales.
• A concern was raised about maintaining a service that carries an ongoing cost when we sell lifetime licences, so anything with a per-call cost needs careful thought before it ships.
• Distribution loop: running a call and inviting guests to the web view is a way to get people in. Push talat, push the user's promo code, and optionally share the live transcript with web guests as a hook ("I can see the real-time transcript, how does this work? Oh, it uses talat").
• Custom protocol handler reinstated as talat://, so web links attempt to open the app; currently a fuzzy focus-loss heuristic decides whether to fall back to a download page, which could be made first-class.
• How to ship it: Nick favoured an experimental or advanced settings section users opt into, over the overhead of a separate nightly binary (separate icon, binary, database, and release track).

Other side notes

• Transcription accuracy: "talat" was occasionally mis-transcribed despite the vocabulary boost being on; Nick wondered if he had made it worse.
• Meeting detection: currently keyed off mic input (a binary signal). The same approach works for audio output, so start/stop recording could become more heuristic with app output as an additional positive signal. Leaving that alone for now.
• Voice-reference edge case: with a one-to-one system-audio lock, a video that played an advert and then a speaker produced two very different voice fingerprints, so the system saved no voice reference (deemed correct). It confused Nick as a user, so he has logged a toast to explain it ("we couldn't learn this voice because it sounded confusing").
• Toast and notification redesign: toasts have not kept pace with the app; no timer or clear dismissal, and undo buffers (for example link or unlink meeting) give no sense of how long you have to click.
• Summary generation: Mike changed his summary model mid-meeting (nice that it is possible). Nick hit confusion when he could not manually summarise; his model was set to "no summaries". He wants a "generate with..." model picker on the summary page, and lamented the lack of context menus (right-click to generate a summary, or a split button with options).
• A teleprompter was discussed as a low priority. Mike thinks it fits the app well, but it should stay low priority for now.
• A calendar fix: some users syncing several calendars at once saw duplicate events, now deduplicated with a global key. Nick separately found recurring meetings from one calendar type only showing the next occurrence, due to a weak dedup key; likely rare.

Decisions made

• Proceed with an "insights" feature, generalising to global, per-meeting, and per-speaker surfaces, and build with all three in mind from day one to avoid migration churn, even if global ships first.
• Data population is code and application logic, not a SQL data migration; the migration only creates a future-proof schema. Stats stored in separate aggregate tables with a way to regenerate them.
• Use a background process on a cadence (generate on meeting end plus a later second pass, tracking what is processed) rather than a one-off upgrade migration.
• No separate stats database; keep it in the existing one.
• Mike to use AI to draft the ticket or proposal and iterate on it. Format flexible; a formal RFC is not mandatory.
• Priorities: get stats/insights and refer-a-friend done; the teleprompter stays low priority.
• No release today; take a lower-stress day, since the diff between recent versions is already large and a release would be a distraction.
• Lean towards shipping talat Call and Sync via an opt-in experimental settings section rather than a separate release binary.
• Fix the home view first-paint performance via chunked, lazy loading (separate ticket).

Additional notes

• Nick has merged to main an option (off by default) to lock system audio when a meeting starts with only one person scheduled on the system-audio channel (that is, one-to-one calls).
• Already logged: the voice-reference toast, and the open question around the video codec for talat Call.