Why we built Charlie conversation-first (after watching adoption kill our previous company)

I watched a $10 billion company struggle with software adoption. Then I left and started my own company. We hit the same wall.

That company closed.

The problem wasn't features or pricing. It was something more fundamental.

Looking back now, I see the pattern. Most software optimizes for time saved. Very few optimize for adoption rate.

With Charlie, we designed for adoption from day one. The results have been completely different.

Here's why we built it this way.

I watched adoption kill efficiency at a $10B company

Before building Charlie, I worked at a company valued at over $10 billion. They sold low-code automation platforms.

Big clients. Million-dollar implementations. The technology was solid. The implementations were fast.

But adoption was brutal.

Here's what would happen: Management would buy in. They'd see the ROI potential. They'd commit to the platform.

Then it would hit the actual users.

The users didn't see anything in it for them. It was just another constraint from management. Another system to feed. Another dashboard to maintain.

So they'd do the minimum required to stay compliant. They'd fill in what they had to. But they weren't using the platform the way it was intended.

The most telling moment: the company's own salespeople wouldn't use the internal CRM.

A company selling automation platforms couldn't get its own sales team to use basic automation. The cobbler's children going barefoot.

The ROI that management expected? Never materialized. Not because the software couldn't deliver - because people weren't actually using it.

So I left and tried to do it better

I started a company with my co-founder. We were going to build project management tools for trade show booth design agencies.

We knew this industry. We understood the pain points. We knew the workflows.

And we made the exact same mistake.

We built complex dashboards. Lots of features. Required setup and configuration. The promise was compelling - automate your project management, save hours per week.

Decision makers would get excited. They'd see the potential.

Then we'd try to get their teams to actually use it.

Same story. Users saw it as something imposed on them by management. Not something that made their lives easier.

We tried multiple iterations. Different features, different approaches to the product. But we kept building the same type of software - dashboard-first, feature-rich, setup-required.

The adoption problem followed us through every iteration.

Eventually, that company closed. Not because we couldn't build good software. Because we couldn't get people to use it.

The pattern I missed

Looking back, the formula was obvious:

Efficiency = Time Saved × Adoption Rate

If you build software that saves 10 hours per week but only a few people use it, you haven't actually created much value.

If you build software that saves 5 hours per week but everyone uses it, you've delivered more real efficiency.

Most software companies obsess over the first number. They add features, optimize workflows, squeeze out every minute of time savings.

Almost nobody optimizes for the second number: will people actually use this?

We had to rebuild from scratch with a different question.

Not "How do we save users time?"

But "How do we get more people to actually use it?"

The answer: conversation-first

The breakthrough wasn't adding AI to existing software. It was starting with conversation.

Everyone knows how to talk to someone. Everyone knows how to ask questions and get answers. You don't need training for that.

With Charlie, we made conversation the entry point. Not a dashboard. Not a complex interface. Just: say hi, and Charlie walks you through the process.

This turned out to be the key to adoption. Because the barrier to entry is the same as talking to a colleague.

If you can't discuss with the AI, you'd struggle with a real colleague too. That's our standard.

But to understand why this works, you need to see why traditional software fails.

Why dashboard-first software has low adoption

Here's how most software gets built:

Someone identifies a workflow that needs automation. They map out all the features needed. They design a dashboard that shows everything.

Then they expect users to adapt to this system.

This is called progressive disclosure - you only see what you need, when you need it. Your field of vision isn't polluted by things that aren't relevant yet.

Take Monday.com as an example. It's powerful. It can do a lot. But when you first open it, you're looking at:

• Projects to set up
• Columns to configure
• Automation rules to define
• Reports to understand
• Settings to adjust

Before you can do any actual work, you need to learn the system.

Now imagine you're a manager. You see the value. You understand that once everything is set up, this will save time.

So you buy Monday for your team.

Your team sees it differently. They see another system imposed on them by management. They see more work - filling in fields, updating statuses, maintaining data.

They don't see "this makes my life easier." They see "this is another thing I have to do for my boss."

So they do the minimum required. They fill in what they have to. But they're not using it the way you hoped.

We saw this exact pattern with a prospect recently. He'd onboarded his whole team on Monday for project management.

His team saw it as an obligation. "We have to fill this in for you" was the attitude. Not "this helps me get my work done."

The software was built for the manager, not the end user.

That's the core problem with dashboard-first software: it optimizes for the person who buys it, not the person who uses it.

Conversation-first inverts this

With Charlie, the user experience is:

1. Say hi to Charlie
2. Charlie asks what you need
3. You tell it (or upload a file)
4. Charlie walks you through the process step by step

No dashboard to learn. No setup required. No training needed.

Charlie learns your process. You don't learn Charlie's interface.

This is why adoption is higher. The friction is the same as talking to a new colleague.

And if someone struggles to communicate with Charlie, they'd probably struggle communicating with a real team member too.

The moment we knew it worked

We went back to the same audience. Trade show booth agencies. The people who'd resisted our previous software.

One prospect stands out.

Before the meeting, one of the partners - about 60 years old - told us: "We'll be implementing AI when I retire."

He thought AI was hype. Another buzzword that couldn't actually do the work. To be fair, we understood his skepticism. Everyone's getting bombarded with AI hype from every direction.

Not subtle. We walked into that meeting knowing we were facing skepticism.

At the time, Charlie was still a prototype. We'd built it as a proof of concept using Claude, loaded with my co-founder Sugir's expertise on how to create trade show quotes.

My co-founder opened Claude. Asked the prospect to give us a real project. Something he was actually working on.

He uploaded the proposal PDF.

Sugir started talking to Charlie - and I mean talking, using voice-to-text. No typing required. Just speaking naturally.

Charlie started working through it. Step by step. Out loud.

"I see you've uploaded a booth design for Event Name. Let me walk through creating the quote the same way you normally would."

The prospect watched Charlie identify the booth dimensions. Break down the floor plan. Start categorizing the work needed.

"First, I'll create the line item titles across all categories, then we'll get to pricing."

The prospect was nodding.

That's exactly how he'd do it. Line item titles first. Then prices.

Charlie kept going. Line items started appearing - electrical, flooring, walls, graphics. Across all 15 categories a trade show quote needs.

At one point, the prospect interrupted: "That line item title, I'd write it a bit differently."

Sugir asked Charlie to adjust it. It did. Instantly.

The line items kept appearing. The quality matched what the prospect would have done himself.

Then he said it: "I didn't know this was possible."

The demo itself took about 45 minutes - this was an early prototype, very step-by-step. The whole meeting lasted about two hours. What would normally take him half a day was happening in front of him.

He was sold. Same meeting. Same person who'd said "when I retire."

Why the demo worked

It wasn't the time savings that convinced him. He could have guessed we'd save time.

It was watching Charlie follow his exact process. And seeing that he could just talk to it.

No learning curve. No new methodology to adopt. No typing required. Just speaking naturally like you would to a colleague.

Charlie explained what it was doing at each step. He could see the reasoning. He could interrupt and make changes.

It felt like working with someone who already knew the job.

Compare this to traditional software demos:

"Here's how you set up a project... now configure your columns... here's where you define automation rules... now let me show you the reporting dashboard..."

By the time you get to showing actual value, the prospect is already overwhelmed. They're thinking about training costs, setup time, change management.

With Charlie, the value is immediate. Upload a file, start talking, watch it work.

The barrier to trying it is the same as asking a colleague for help.

The unexpected discovery

After that demo, we started working with more prospects. We kept seeing similar patterns.

But one thing surprised us: the age of our users.

We'd assumed younger people would adopt faster. They're digital natives. They use ChatGPT for everything. They're comfortable with AI.

Our average user turned out to be 48 years old.

This didn't make sense at first. Aren't older users supposed to resist new technology?

Then we realized: they're not early adopters. They don't chase tech trends. They don't try new tools because they're new.

But they've felt the pain of creating quotes manually for longer. Much longer.

Someone who's 30 has maybe done a few hundred quotes in their career. Someone who's 48 has done thousands. They've spent countless hours on floor plans, line items, pricing calculations.

When we show them Charlie, they don't care that it's AI. They care that it solves a problem they've had for 20 years.

The conversation-first interface matters even more for this group. They don't want to learn another complex system. They just want to get the work done.

And when the barrier is "can you talk to someone?" - they've been doing that their whole career.

This taught us something important: optimize for adoption, and you don't just get early adopters. You get everyone who actually feels the pain.

Why incumbents can't just add conversation

You might be thinking: okay, so why doesn't Monday just add a conversational interface?

They could. Technically.

But here's the problem:

Their users have already learned how to use Monday. They've invested time understanding the dashboard, the columns, the automation setup. They've built muscle memory around it.

Adding conversation means those users would need to unlearn their current way of working and learn a completely new interaction model.

That's a huge friction cost. For Monday's existing customers, switching to conversation-first might actually feel harder than staying with what they know.

We don't have that problem. We built the experience conversation-first from day one. Our users never learned a dashboard approach. They started with conversation, so there's nothing to unlearn.

That's the advantage of building fresh versus retrofitting an existing paradigm.

Where this leads

Right now, Charlie is web-based. You log into an app and start a conversation.

But we're thinking about where lowest friction actually lives.

For quote creation, a web app works. People are at their desks, working through proposals.

But for other workflows - project management, on-the-go updates - a web app might still be too much friction.

That's where we're headed: a mobile-first experience — either a mobile-optimized web app or WhatsApp, with a potential native mobile app if it proves higher leverage.

Imagine you're managing a large concert. You're on site. Something comes up.

Instead of: Open laptop → Log into Monday → Find the right project → Update the task → Notify the team

You: Send a voice note to Charlie on WhatsApp.

"Hey, the Imagine Dragons concert is going well but we have a sound issue. Need John to check the setup before doors open."

Charlie processes it. Updates the tasks. Notifies John. Replies back confirming it's done.

You never left WhatsApp. You just talked to Charlie like you'd talk to any other team member.

This isn't built yet. But it's where conversation-first leads.

The lowest friction is no friction at all.

The real lesson

Most software companies ask: "How do we save users time?"

We learned to ask: "How do we get more people to actually use it?"

The formula hasn't changed:

Efficiency = Time Saved × Adoption Rate

But most companies only optimize one side of that equation.

Conversational AI's value isn't just efficiency. It's that more people will actually use it.

We watched adoption kill our first startup. We also watched it be an obstacle to ROI at a $10 billion platform.

So with Charlie, we designed for adoption from day one.

Conversation-first. Process-aware. Progressive disclosure. Voice-enabled.

The barrier to entry is: can you talk to someone?

If you can, you can use Charlie.

That's why a 60-year-old who thought AI was hype became a customer in a two-hour meeting.

That's why our average user is 48, not 25.

That's why we're seeing adoption rates we never saw with dashboard-first software.

Optimize for the right variable.

Building specialized AI agents? I'm documenting what we're learning - the wins and the mistakes. Reach out at will@willgyt.com if you want to compare notes.