MeetDone

Day 36 of building MeetDone.

One thing I think I underestimated:

the hardest step is not signup.

It is the first paste.

MeetDone turns rough meeting notes into a follow-up email.

That sounds simple from the builder side.

From the user side, the ask is heavier:

"Paste real notes from a real conversation into a new tool."

That is not just product curiosity.

That is a trust decision.

And once I looked at the objections more closely, the pattern got obvious.

People do not only say:

- wanted to see the output first

They also say:

- not ready to trust it yet

- notes were too sensitive

That changed how I think about onboarding.

If your product starts with sensitive input, the job is not only to explain the workflow.

The job is to reduce the trust gap before the first real paste.

So now I think users need 3 things before that moment:

1. Proof that the output is worth it

2. Clarity on where the data goes

3. Confidence that sensitive stuff is handled responsibly

If those answers live only in a footer link or a legal page, they are probably arriving too late.

I think this applies to a lot of AI products.

We say:

"Try it."

What the user hears is:

"Give me something real."

That is a much bigger ask.

My working rule now is:

if the first step requires real data, trust is part of onboarding.

Not a separate thing.

What usually matters most for you before you paste real information into a new tool?

Day 35 of building MeetDone.

One signup objection I keep coming back to is:

"Wanted to see the output first."

I think that is one of the fairest objections a user can give.

If the whole promise of the product is the transformation,

asking for signup before showing the result might be backwards.

With MeetDone, the promise is simple:

messy meeting notes in,

send-ready follow-up email out.

If I ask for an account before someone can see that output,

I am asking them to trust 3 things up front:

- that the result will be good

- that setup is worth it

- that this is different from every other AI tool they have already ignored

That is a lot of trust before proof.

So I think there are really 3 options here:

1. Keep signup first

2. Show a sample output first

3. Show one real output first, then ask for signup

Right now I think option 3 is the most interesting.

A sample shows the category.

A real output shows the value.

And if the product is easiest to understand by seeing what it does,

moving the proof later in the flow may just be bad onboarding.

I think this applies to a lot of products, not just MeetDone.

Sometimes the best onboarding fix is not better copy.

It is showing the result earlier.

My working rule now is:

if the product promise is output quality,

show the output before you ask for commitment.

Would you gate the first result, or the second one?

Day 34 of building MeetDone.

Yesterday I wrote that asking users to pick one reason is easier than asking them to type first.

Today I hit the next layer:

the answer choices themselves matter more than I expected.

If the options are vague, the feedback is vague too.

Stuff like:

- confusing

- bad UX

- not for me

sounds useful.

It usually is not.

Those labels tell me how the user felt.

They do not tell me what to change next.

So I am trying to write answer choices that sound more like the blocked moment.

For example:

- wanted to see the output first

- too much setup

- not ready to trust it yet

These are better because each one suggests a different fix.

- show the output earlier

- shorten the setup

- add more proof

That is the rule I am using now:

every answer choice should point toward a different next move.

If 2 options would lead me to the same fix, the list is probably too generic.

I think this is where a lot of feedback forms quietly fail.

We focus on getting an answer.

We do not focus enough on whether the answer reduces the next product decision.

A good option is not just a label.

It is a small hypothesis about what is blocking the user.

That is one of the things I am trying to get right with MeetDone now:

not just collecting more feedback, but collecting feedback that narrows what to change next.

What is one feedback option you use today that is probably too vague?

Day 33 of building MeetDone.

Tiny change today.

But I think it matters more than it looks.

I stopped asking users to type feedback first.

Now the flow is:

- pick one reason

- if none fit, hit "other"

- then type

That sounds smaller than it is.

Because if someone is already leaving, a blank text box is a lot of work.

And most of the time, I do not need a paragraph first.

I need direction.

Stuff like:

- too expensive

- not clear enough

- need more proof

- not relevant

is already enough to tell me where to look next.

If they want nuance, "other" is there.

I think this is where a lot of feedback collection quietly breaks.

We ask for a level of effort that does not match the moment.

Then we wonder why:

- response rate stays low

- only the most opinionated people answer

- the feedback we get feels heavier than it is representative

Right now I would rather get 20 quick signals than 2 essays and silence from everyone else.

Because the point is not collecting longer text.

It is reducing the next product decision.

That is the rule I am using more now:

make feedback easier than leaving.

If the user wants to say more, great.

But I do not want typing effort to be the price of giving feedback.

What has worked better for you:

multiple choice first, or text box first?

Day 32 of building MeetDone.

One thing I keep noticing as I improve the exit-feedback flow:

the same feedback can mean completely different things depending on who says it.

Take a simple line like:

"Too expensive."

That sounds clear.

It usually is not.

If that comes from a visitor, it might mean:

- the pricing page did not justify the value

- trust was not there yet

- the product is for someone else

If it comes from a free user, it might mean:

- the free plan is enough

- the upgrade value is not obvious

- the paywall showed up too early

If it comes from a pro user, that is a different category again.

That is not conversion friction.

That is churn risk.

Same sentence.

Different fix.

I think this is where a lot of feedback analysis quietly goes wrong.

We collect the words.

We skip the context.

Then we treat repeated phrases like one pattern when they are actually several different problems sitting on top of each other.

So my rule now is:

raw feedback is not insight.

Context is what turns it into something you can act on.

That means I do not just want the answer.

I want to know whether it came from a visitor, a free user, or a paying user.

Because good product decisions usually come from the combination of:

- what they said

- when they said it

- who said it

The sentence matters.

The segment changes the meaning.

That is one of the reasons I am storing exit feedback with user context now inside MeetDone.

What do you trust more when you read feedback:

the repeated phrase, or the segment it came from?

Day 31 of building MeetDone.

One thing I realized today:

the same page can mean completely different problems.

Inside MeetDone, a lot happens in /app.

But someone leaving that page might be:

- stuck on signup

- trying their first email

- unhappy with the generated draft

- hitting the upgrade wall

- thinking about deleting their account

Same page.

Not the same moment.

And definitely not the same fix.

If I treat all of that as one bucket, the feedback gets dumb fast.

"User left /app" sounds like data.

It is usually not enough to act on.

So the rule I am using now is:

pages are technical.

States are real.

That means I do not just want to know which route someone left.

I want to know what situation they were in when they left.

Not:

"They bounced from /app."

But:

- they did not finish signup

- they had notes but did not generate

- they generated a draft but did not use it

- they hit the limit and did not upgrade

That feels more annoying to build.

I think it is much more useful after.

Because product decisions do not come from routes.

They come from understanding the job the user was trying to do.

I think this mistake shows up in a lot of products:

we organize our analytics around screens because that is how the app is built.

Users experience the app through states, not routes.

That is one of the things I want MeetDone to get better at now:

not just asking for feedback on the page, but asking in the right state.

What gives you better product signal:

the route, the user state, or the combination of both?

Day 30 of building MeetDone.

One decision I made today:

I did not ship the exit-feedback survey on mobile.

At first that felt a bit wrong.

"Same feature everywhere" sounds clean.

It sounds complete.

It sounds like the disciplined thing to do.

I think it would have been the lazy version.

Because exit intent on desktop and mobile is not the same thing.

On desktop, the signal is clearer:

- mouse leaves the tab

- the session feels like it is ending

- there is space for the question

On mobile, it gets messy fast:

- app switching looks like exit

- scroll behavior is noisier

- a popup feels heavier

If I copy the same pattern across both, I am probably not collecting better feedback.

I am just creating more friction in the worse context.

So for now the survey is desktop only.

That means less coverage.

I think it also means better fit.

This is one of those product choices that keeps coming up:

do I want consistency,

or do I want the feature to make sense where it lives?

I am starting to think a lot of early products make the wrong call here.

We chase parity because unevenness looks incomplete.

But sometimes shipping it everywhere is what actually makes the feature worse.

The rule I am using more now is:

do not copy the mechanic.

Copy the intent.

If the intent is good feedback with low friction, the implementation does not have to look identical on every device.

What would you choose more often:

ship everywhere for consistency, or only where the UX actually works?

Day 29 of building MeetDone.

One thing I am starting to believe:

a badly timed survey gives fake signal.

We spend a lot of time thinking about the wording of a feedback question.

I think timing matters just as much.

Because if the survey shows:

- too early

- before real engagement

- every time someone returns

you can get more responses and worse answers at the same time.

That is the trap.

More volume feels like better learning.

Sometimes it just means you interrupted more people.

So when I added exit feedback to MeetDone, I also added brakes around it:

- wait for real dwell

- wait for actual engagement

- show it once per session

- back off for days after dismiss

- back off longer after submit

That will probably reduce the number of answers.

I think it improves the quality of the answers that remain.

Right now I would rather get 10 real objections than 50 lazy ones.

Because one honest answer like

"too much setup"

or

"needed more proof"

can change the product.

A weak answer from a badly timed popup usually just creates noise.

I think this is true for a lot of product feedback:

signal quality matters more than response volume.

The point of feedback is not collecting more text.

It is learning something you can actually fix.

That is the rule I am trying to follow now:

protect the signal, not just the response rate.

When you ask for feedback, do you optimize more for volume or for quality?

Day 28 of building MeetDone.

Yesterday I wrote that analytics tell me where users leave, not why.

Today I ran into the next layer of the same problem:

even feedback can be too generic.

"Why are you leaving?" sounds like a smart catch-all question.

I think it hides too much.

Because someone leaving signup and someone not using a generated draft are not having the same problem.

One person might mean:

- too much setup

- need more proof

- not ready to trust it

The other might mean:

- tone was off

- needed too much editing

- missing details

Same product.

Completely different fix.

If I ask both people the same vague question, I get blurrier answers and worse product decisions.

So the rule I am using now is:

match the question to the moment.

Not:

"Why are you leaving?"

But:

- "What stopped you from creating an account?"

- "What stopped you from trying your first email?"

- "What stopped you from using this draft?"

- "What stopped you from upgrading today?"

That small change matters because a good feedback question should narrow the fix, not widen the guess.

I think a lot of builders already know they should collect feedback.

The harder part is asking in a way that makes the answer useful.

Generic questions create generic answers.

Specific questions create fixable answers.

That is the standard I am trying to build around with MeetDone too:

not just collecting objections, but collecting them at the right moment.

What generic question are you still asking users that is probably hiding the real issue?

Day 27 of building MeetDone.

I shipped a tiny thing today that probably should have existed earlier:

an anonymous exit-feedback question.

Because analytics were telling me useful but incomplete things:

- people hit pricing

- people hit signup

- people left

That tells me where the drop-off happened.

It does not tell me why.

And "they left" can mean very different problems:

- not clear enough

- not relevant

- need more proof

- need pricing clarity

- not ready yet

Same exit.

Different fix.

If I guess wrong, I can spend a week improving the wrong thing.

So I added one small rule for myself:

when the reason changes the next action, ask directly.

Not with a long survey.

Not after someone already disappeared for good.

Just one short anonymous question close to the exit:

"What stopped you from trying MeetDone today?"

I like this better than another dashboard because it creates usable signal fast.

Analytics help me see the shape of the problem.

User language helps me decide what to fix first.

I think a lot of early products stay stuck here:

we collect events, but not objections.

And objections are often more useful than another clean funnel chart.

My rule now is:

analytics tell me where to look.

feedback tells me what to change.

What do you trust more when users bounce:

analytics, calls, or one-question exit feedback?