5 Product Lessons for First-Time Founders

Drowning In Support Tickets? Maven AGI is here to help.

Maven AGI platform simplifies customer service by unifying systems, improving with every interaction, and automating up to 93% of responses. Seamlessly integrated with 50+ tools like Salesforce, Freshdesk, and Zendesk, Maven can deploy AI agents across multiple channels—text, email, web, voice, and apps—within days. Companies like Tripadvisor, ClickUp, and Rho slash response times by 60%, ensuring quicker support and exceptional customer satisfaction. Don’t let support tickets slow you down

Request a free personalized demo today.

Hey Shifters!

There's nothing that gets me more excited about working on Chezie than building product. I love every part of it: carving out the future roadmap, gathering feedback, reviewing designs, and watching features evolve from concept to production.

At the same time, I’m convinced that product development is the easiest thing to get wrong as a founder because every new feature feels like positive movement. It's deceptively easy to confuse motion with progress.

After three years of running product at Chezie, I've learned some hard lessons about what matters when building software. And since many of you are working on your products, I wanted to share these lessons with you.

1. User Experience Trumps All

User experience is about so much more than just interface design - it's about how people feel using your software. I learned this lesson the hard way.

Last quarter, we ran a customer feedback survey to understand where we could improve. The results were both disappointing and enlightening: most of the feedback centered on things simply not working as expected. The basic functionality that we took for granted wasn't performing reliably.

Sure, customers often give early-stage startups some leeway when it comes to bugs or issues. But the reality is that if a customer purchases your product to do 2-3 key things, and one of those things doesn't work consistently, they're going to be upset. You only have a few chances to gain a customer’s trust, and once it’s gone, it’s really hard to get back.

The good news? This feedback gave us a clear roadmap. Instead of chasing new features, we needed to focus on making our existing features work flawlessly. It wasn't about adding more functionality - it was about making our current functionality reliable.

We've since shifted our focus heavily toward bug prevention and rapid bug fixing. Because at the end of the day, the best user experience isn't about flashy features - it's about your product doing what it promises, every single time.

2. There Is Such A Thing As Too Much Product

Every SaaS founder (myself included) starts with this grand vision of what their product will become. We dream up feature lists a mile long, imagine countless integrations, and plan for every possible use case.

Most people switch to new software because they have one or two core problems they desperately need solved. That's it.

Our first customer, Chegg, had one fundamental problem that I’ve since learned that every ERG team faces: they didn't know who was a member of which employee resource group. That's it. They just needed a way to track ERG membership.

We solved that problem well. Members could log in and join ERGs, and admins could see membership data on the backend. Simple but effective.

But we started building additional features too quickly. We launched a budget management feature before we fully perfected our core membership functionality. Looking back, we should have gone deeper on membership tracking first - giving admins more detailed member data, better reporting, and deeper insights.

The lesson? Pick one core problem and solve it exceptionally well. Only after you've nailed that - and have customers who love you for it - should you start exploring what else they need.

3. Have an Opinion

I'm a huge fan of opinionated software products - ones that take a clear stance on how things should be done. Take Linear, for example. They don't just offer project management software; they have a specific methodology for how software should be built, complete with published documentation explaining their philosophy.

When you choose Linear over something like Jira (which is notoriously awful), you're not just picking a tool - you're buying into their opinion about how software development should work.

At Chezie, we've taken a similar approach to ERG management.

Here’s an example: one of our most frequently requested features is recurring events - the ability to schedule monthly or weekly events that repeat automatically. We've intentionally chosen not to build this.

Why? Because we have a strong opinion about ERG engagement recurring events are often a crutch that leads to low participation.

Think about it - when companies run the same "Monthly Member Meeting" over and over, engagement typically drops. There's nothing special or compelling about it, and it becomes easy for members to skip because there’s always a chance to join the meeting next month.

Instead of adding recurring events, we make users duplicate events manually. It's a small friction that forces ERG leaders to think intentionally about each event they create. Is this event worth the effort? Will it drive engagement?

This stance occasionally frustrates users, but it aligns with our core belief: ERGs should focus on creating meaningful, unique experiences that drive real engagement. Sometimes the best feature is the one you choose not to build.

4. 10x Better or Don't Bother

If your product isn't dramatically better than what someone's already using, they won't switch. This is especially true in B2B software, where changing tools means changing ingrained habits - not just for one person, but for entire teams.

Let me share a recent example from Chezie. We've been working on a Slack integration that includes several features:

• Syncing membership between Chezie and Slack channels

• Sending notifications when someone joins an ERG

• Broadcasting messages to ERG channels

For that last feature - broadcasting messages - we had two choices:

1. Ship a basic plain-text message builder quickly

2. Wait and build a full drag-and-drop Slack block kit builder

The easy path was option one, but focusing on being 10x better makes you ask:

If we just offered plain text, why would anyone stop using their current process of typing directly in Slack?

It wouldn't be compelling enough to change behavior.

Instead, we're taking the time to build a proper block kit builder that will make creating Slack messages as intuitive as building emails. It's taking longer, but it will be significantly better than the current solution.

This is crucial because in enterprise software, your biggest competitor isn't usually another product - it's the status quo, in other words, you're not just competing against other tools; you're competing against the way we've always done it.

To break that inertia, you need to be dramatically (at least 10x) better than the existing process.

5. Watch Out for Trap Doors

Sometimes a feature request seems obvious - until you build it and suddenly face an avalanche of related feature requests you hadn't anticipated. I call these "trap door" features.

Our budget tracking feature is a perfect example. On the surface, it made sense because ERGs need to track their spending. But as soon as we launched it, customers started asking for integrations with their expense systems - Expensify, Concur, and dozens of others. Many of these systems have outdated APIs or are difficult to work with. Unlike calendar integrations where you only need to support Google and Microsoft, the expense management landscape is fragmented across countless vendors.

Had we known this cascade of requests was coming, we might have approached the feature differently. Today, we can build expense integrations, but customers have to pay for the custom development 🥰.

The lesson? Before building any new feature, consider what other features it might force you to build next.

Product development is exciting, but it's also deceptively complex. After three years of building Chezie, here's what I would share with another first-time product builder.

1. Focus on reliable user experience over new features

2. Solve one problem exceptionally well before moving to the next

3. Take strong stances on how your product should work

4. Make sure new features are dramatically better than existing solutions

5. Think carefully about what commitments you're making with each new feature

Most importantly, remember that not every feature request needs to be fulfilled, and not every good idea needs to be built right now.

Would love to hear from other founders: what's the most important product development lesson you've learned? Reply to this email and let me know!

See you next week,

Toby