Balancing speed and quality in early product development

Startups live on speed. It’s one of the few undeniable advantages you hold over bigger, slower competitors. While they’re waiting on approvals, you can build, ship, iterate and repeat. While they’re debating with PR, legal, and brand teams in meetings, you can get live feedback from users. Speed is how you create momentum, attract early believers, and outmanoeuvre incumbents.

As Brighteye's Product Mentor, Jono Hey, states:

“Smaller companies, by staying close to customers, reach the right product faster through small errors and quick adjustments and build an edge over large companies too scared to move at pace.”

But speed without discipline is a trap. It can feel productive in the moment - releases are flying out, experiments are running - but underneath, users are frustrated and you’re not making an impact. Suddenly, what was once an advantage starts working against you.

The real challenge isn’t choosing between speed and quality. It’s learning how to run fast and build well enough that users trust what you deliver. In other words: speed gets you in the game, but quality keeps you there. Jono shares:

“It’s the pace of learning, not shipping, that makes the biggest difference.”

1. Speed ≠ hurry

Going fast doesn’t mean rushing blindly. It means eliminating friction and focusing energy where it matters most. The best early-stage teams don’t build more; they build less - but more intentionally. They focus on getting to insight faster by lowering the cost of being wrong and Jono concurs:

“In the early days, focus on building the right thing over building it right. I keep in mind that ‘A kick-ass half is better than a half-assed whole.”

Practical ways to move fast without rushing:

• Ship fewer things, but sharper. Instead of scattering effort across multiple half-finished features, pick one problem to solve per sprint. Get to a learning outcome before moving on.

• Shrink the experiment. If your MVP looks like a stripped-down product instead of a focused test, it’s too big. The smaller the test, the faster you can learn.

• Lower the wrong-turn penalty. Don’t over-invest in code when a no-code prototype, clickable Figma flow, or concierge test can give the same insight in a fraction of the time.

Rule of thumb: if you can’t explain in one sentence what you’re testing and why, you’re not moving fast - you’re probably just thrashing.

Scott Eblen, VP of Product at Monzo and a Brighteye mentor, commented:

“This is one of the most common problems I see with product development teams.  A lot of companies parrot the narrative about speed from Silicon Valley companies and jump on the latest hacks to go faster but they lose track of whether they’re actually making impact more quickly.” 

2. Quality is not just code

When people talk about “quality,” they usually mean bugs. But users rarely quit because of one bug—they quit because the product feels inconsistent, confusing, or unreliable. Quality is about whether the product makes someone’s life easier. It’s about coherence, usability, and trust.

Practical guardrails for quality:

• Define “good enough” before shipping. Write down three things:

  • Non-negotiables (must-haves, like onboarding working end-to-end).

  • Acceptable trade-offs (nice-to-haves, like unpolished design).

  • User promise (the core experience we’re guaranteeing).Having this clarity up front prevents endless debates and avoids slipping into chaos.

• Validate with quick user tests. Five users are often enough to spot fatal flaws. If three of them stumble in the same place, it’s not “good enough.”

• Favour consistency over polish. Early users forgive simple and scrappy. They don’t forgive confusing or broken.

Jono shared:

“Users will forgive some quirks and shortfalls if you solve their core problem better than anyone else. You should believe that each new release will improve the experience and then find out whether it has.”

And Scott added:

“One of the positive shifts in product development has been to pivot from Minimum Viable Products to Minimum Lovable Products.  This slight tweak on positioning towards a more emotional understanding of the customer helps keep teams aware of qualty”

3. Treat experimentation as a discipline

Startups often confuse “experimenting” with “trying random things.” Real experimentation is structured learning. It’s not about activity - it’s about clarity.

Good experiments are:

• Rooted in a clear hypothesis - e.g. “If we don’t require X and Y for onboarding reduce onboarding steps from 5 to 3, activation will increase by >Z%”.

• Focused on isolating a variable

• Designed to deliver an answer in days or weeks, not quarters

But beware the experiment trap, where everything becomes a test and nothing ships. If every new idea requires a 6-week A/B test, you’ll stall out. Related, make sure the experiments help move the business forward.  If you run well structured experiments but they’re not changing the trajectory it’s worth reflecting on whether you’re testing the right things. Sometimes, the boldest move is to commit without perfect data. Experiments guide, but conviction builds products.

4. Know when to slow down

There are moments when speed starts doing damage. You’ll see it when it happens:

• Users lose trust. Bugs, inconsistencies, or half-baked features become too obvious to ignore.

• Teams are firefighting. Instead of building, everyone is fixing yesterday’s shortcuts. or team health becomes unsustainable.

• Metrics don’t improve. Despite constant shipping, growth and engagement stop moving.

When this happens, the answer is to pause, recalibrate, and realign. We recommend running a quarterly product quality reset. Once every few months, dedicate a cycle to cleaning up debt, fixing what’s broken, and closing the gap between what you promised and what you delivered.

Slowing down isn’t failure - it’s how you preserve trust so you can accelerate again.

Scott adds:

“Building experimentation muscle in a team is hard.  People come from different backgrounds and have different expectations, but embedding this rigour pays off.  Diverse stakeholders can help identify flaws in hypotheses such as not recognizing multiple factors that could influence a test variant. Counterintuitively, part of the good experimentation discipline is also knowing when to ignore data.  Sometimes you lack that.

Jono chimes:

“Avoid clutter by removing what isn’t working. The smaller your product and codebase, the faster you can build.”

5. The real equation: speed + quality = trust

At the end of the day, users don’t care about how quickly you ship. They care that what you ship works, solves a real problem, and feels like it was built with care.

In the very early stage, bias toward speed. Your goal is to learn, not to impress.

As you find traction, raise the quality bar. Trust becomes your differentiator and focus is your friend, as Jono states:

“Focus is a killer advantage of a small company. The progress you can make on a problem when your entire company focuses on solving it is remarkable.”

At every stage, remember that speed and quality are not enemies. They are partners in the same goal: learning faster, delivering better, and building user trust.

Speed gets you noticed. Quality keeps you alive. Trust is what compounds over time.