Why We Decided to Redesign the Feature Everyone Loved

My name is Mat and I’m the Chief Creative Officer at Speak4.

I made that title up. That’s what creatives do.

It also happens to be the most accurate description of what I’ve done here over the years. I helped found Speak4, vetoed the deeply unsettling original spelling of “Speek4” (yes, really), designed our logo, designed our application, designed our websites, and spent the better part of the last several years obsessing over one simple idea:

Make everything better.

As Speak4 grew, we started holding biannual company retreats. During one of our product planning sessions, we were brainstorming ideas for future features when I made a suggestion that was met with equal parts curiosity and laughter:

Redesign Everything.

To be fair, I deserved the reaction.

We weren’t drowning in customer complaints. Our partners were happy, our development team was busy building new capabilities, and we had a healthy roadmap. Nobody was asking for a complete redesign.

And yet, I couldn’t shake the feeling that we needed one — not immediately or recklessly, but eventually.

Because I’ve learned something after years working in advocacy technology:

The moment a feature becomes successful is often the moment it stops improving.

The Problem With Successful Software

Most software doesn’t become outdated because it fails. It becomes outdated because it succeeds.

A feature solves a problem. Customers love it. New customers arrive because of it. The company moves on to building the next thing.

Then another feature gets added. And another. And another.

Years later, you’re looking at something that technically still works but was never designed for everything it’s now expected to do.

I’ve seen this throughout the advocacy software industry. Platforms accumulate features, workflows become more complicated, user interfaces become cluttered, innovation slows, and teams become reluctant to touch the things customers already like. Eventually, nobody remembers why something was built that way in the first place.

At Speak4, we’ve always tried to challenge that mindset.

Why We Started With the Feature Everyone Loved

If I was serious about redesigning things, where should we begin?

The ugliest feature? The oldest feature? The one generating support tickets?

Nope.

I wanted to start with the feature people loved most: our Landing Page Builder.

A lot of organizations switched to Speak4 because of it. Agencies loved it. Associations loved it. Advocacy professionals loved it.

So naturally, I wanted to tear it apart.

Not because it was bad, but because it was important.

The Landing Page Builder was one of the defining features of early Speak4. If our goal was to build the best grassroots advocacy platform possible, then our most important feature deserved the most attention.

When we looked closely, three things became obvious:

1. It had been designed for a much smaller feature set than it now supported.
2. It was built on technology choices made when Speak4 was a three-person company trying to move as fast as possible.
3. Many of the ideas we wanted to pursue in the future simply weren’t going to fit within the existing architecture.

None of those problems were visible to most users.

But they were visible to us.

And that’s enough.

Building for What’s Next

One of our core beliefs at Speak4 is that advocacy software should never be optimized solely for today’s requirements. It has to be built for tomorrow’s opportunities as well.

Many of our most successful innovations came from asking a simple question:

What if we approached this problem differently?

StoryTeller Mode started that way.

Instead of asking how we could improve advocacy letters, we asked whether a personal video might sometimes be more impactful than a letter at all. Years later, StoryTeller remains one of the most unique capabilities in advocacy technology.

The same thinking led to Send+, AI-powered message enhancement, scheduled advocacy delivery, and countless other features throughout the platform.

Not because we wanted more features.

Because we wanted better solutions.

That’s an important distinction.

We don’t build things because competitors have them. We build things because partners have problems worth solving.

Why In-House Development Matters

Of course, redesigning a major feature is one thing. Actually building it is another.

That’s where our CTO came in.

One of the advantages of Speak4 is that our development team is entirely in-house. The people designing the product, planning the roadmap, and writing the code work together every day.

That sounds obvious. In software, it’s surprisingly rare.

The original plan for the new Landing Page Builder was straightforward enough. We scoped it, designed it, and built a roadmap.

Then development started.

And everything changed.

Not because the project was failing.

Because we kept finding better ideas.

Our CEO often says:

No plan survives engagement with the enemy.

In software development, the enemy isn’t another company.

It’s reality.

The moment developers begin building something, they discover opportunities nobody could see during planning. Workflows improve, interfaces become cleaner, new possibilities emerge, and assumptions get challenged.

Sometimes we’d redesign an entire section because we discovered a better approach halfway through development. Other times we’d spend days exploring an idea only to arrive back where we started — except now we understood exactly why we belonged there.

That’s not wasted effort.

That’s product development.

And it’s one of the biggest advantages of having a team that lives and breathes advocacy technology every day.

The Result

The response to the new Landing Page Builder has been overwhelmingly positive.

Which is fortunate.

Because taking away something people love is terrifying.

But we weren’t replacing it with something we merely thought was better. We were replacing it with something we knew was better because we had spent months questioning every assumption, refining every workflow, and obsessing over every detail.

The result is a cleaner experience, more flexibility, a stronger technical foundation, and a platform that’s better prepared for the future.

More importantly, it lays the groundwork for what comes next.

Not a complete redesign overnight.

Not change for the sake of change.

Continuous improvement.

Deliberate evolution.

The same philosophy that has guided Speak4 since we launched.

Why This Matters

We believe what makes a great advocacy platform isn’t replacing every tool an organization uses, building the biggest software suite, or accumulating the longest feature list.

It’s doing advocacy exceptionally well.

That belief influences every product decision we make.

When we identify a gap, we don’t ask how other platforms solved it. We ask whether there’s a better way to solve the underlying problem.

Sometimes that leads to small improvements.

Sometimes it leads to entirely new categories of features.

Either way, the goal remains the same:

Build the advocacy platform we would want to use ourselves.

Because better always exists.

And that means there’s always something worth improving.