A Project Manager’s Perspective on Building Solutions That Perform

A performance issue that appears in production is rarely just a production problem.

Many times, it is something we could have anticipated much earlier—data volume, user behaviour, business logic, concurrency, dependencies or simply the way we planned to test the solution.

I recently experienced this on a project. We identified a performance problem, implemented optimizations and tested the changes. Yet we discovered that the solution still had limitations when exposed to the actual volume and processing demands of the business.

It made me think about something simple:

The customer doesn’t care whether the feature works. They care whether the solution works.

Performance is therefore not a separate testing activity. It is part of the solution.

Here are a few things I believe Project Managers can do differently.

1. Get Excited About Data

We get excited about requirements, features and timelines.

We should get equally excited about data.

How much data can one user generate? What about each role? How many transactions could happen during peak hours? What will the volume look like six months or two years from now?

Even simple calculations can expose potential problems early.

If a process takes 100 seconds to process 100 records, that behaviour deserves attention long before the application reaches production.

Data is not just something the application stores. Data influences how the application performs.

2. Don’t Let Performance Disappear After Design

Performance is often discussed during architecture and design.

Then development begins—and somehow performance becomes a QA responsibility.

Instead, build a performance strategy during design itself.

Define:

Expected response times
Expected data volumes
Concurrent users
Critical transactions
Performance metrics
Acceptance criteria
How performance will be tested and measured

QA should prove that we meet those expectations, not discover them for the first time.

3. Decide How Performance Will Be Proven

“We will do performance testing” isn’t enough.

Ask:

Manual or automated?

How many users?

How many actions?

How much data?

What level of concurrency?

Which business processes?

Which dependencies?

What metrics will we collect?

What constitutes a pass?

Manual testing may tell us whether an application feels responsive. But if we need to simulate 20 users processing hundreds of records simultaneously, automation may be necessary.

The testing approach should come from the behaviour we need to prove.

4. Understand How Performance Changes Over Time

An application that performs well today may not perform the same way when its data and usage grow.

Ask:

How will this application behave as its workload increases?

Will performance gradually degrade? Will it stabilize? Are there thresholds beyond which it becomes unacceptable?

We shouldn’t test only today’s workload.

We should understand the application’s performance behaviour as it grows.

5. Be Obsessive About Housekeeping

Data keeps accumulating.

Transactions, logs, audit records, temporary data and attachments can all become part of the system’s long-term workload.

So cleanup, archival and purge shouldn’t be emergency activities.

They should be part of the solution design.

Good data hygiene is long-term performance insurance.

6. Test the Solution, Not Just the Fix

This is perhaps the most important lesson.

When a customer reports a problem, we naturally think:

Find the cause → fix it → test the fix → close the issue.

But a fix can change the behaviour of the system. It can move a bottleneck somewhere else or create a new constraint.

So after fixing a problem, ask:

What changed because of our fix?

And more importantly:

Does the complete solution now deliver the outcome the customer expected?

We shouldn’t just prove that the reported problem is gone.

We should prove that the solution works.

7. Keep Watching After Go-Live

Go-live isn’t the end of performance management.

Real users and real data will eventually tell us things that testing couldn’t completely predict.

Establish baselines and monitor important indicators such as response times, processing times, errors, queues and transaction volumes.

The objective isn’t to watch dashboards all day.

It is to know when the system starts behaving differently before the customer has to tell us.

The Bottom Line

Performance shouldn’t disappear somewhere between design and development and suddenly reappear as a production incident.

As Project Managers, we don’t need to become performance engineers.

But we do need to ask the right questions early:

How much data?
How many users?
How many actions?
How will we test it?
What does good performance mean?
How will it behave as it grows?
How will we maintain it?
How will we know when performance starts to deteriorate?

Because ultimately:

The customer doesn’t care whether the feature works. They care whether the solution works.

And performance is part of that solution.