When I talk to customers, they are happy (in an unhappy way) to talk about their Web performance pain, going into great detail on how every performance issue affects them and why the inability to manage Web performance effectively makes every day an unpredictable challenge.

Pain is a very personal thing. When I drop a rock on my toe (ok, more likely my son does it), you can imagine what I feel, but you don’t actually feel it, especially if you’ve just hit your head on a low-hanging bird feeder (my yard is a minefield of hidden hazards).

Talking to people at all levels of your organization and asking “where it hurts” is key to the success of any Web performance initiative. Building a strong Web performance methodology around one person’s is not a sound way to implement a solution.

From talking to real people doing these real jobs, here is a (very basic) list of some of the things that we are asked to solve:

C-Level

  • How am I doing against my competitors?
  • How does performance affect my revenue?
  • If I want to use the Web for more revenue, what do I need to do to make it work?
  • How does Mobile deliver what I need?

VP, Operations

  • How much will it cost me to deliver the necessary Web performance?
  • What is critical for me to deliver now, and what can I delay until the next budget cycle?
  • How do I ensure that Web performance issues don’t affect revenue?
  • Are my partners helping or hindering us?
  • How do I get Marketing to the table to understand the technology boundaries we have?

VP, Marketing

  • How do I effectively use the Web without alienating customers with slow performance?
  • How do I ensure that our design is delivered appropriately to both fixed-Web and mobile users?
  • What parts of the site are customers unsatisfied with due to performance?
  • Do my promotions scale to handle the surge in customers?
  • How do I get Operations to understand that delivering new experiences with leading-edge technology is critical for us to be successful?

Director, Operations

  • I spend most of my time on troubleshooting conference calls. How can I reduce this drain on my time and resources?
  • My team spends most of its time trying to correlate data between 5 different systems. Help!
  • The latest design is putting a massive strain on our infrastructure. Didn’t anyone test this on the production servers before it went live?
  • I know that we need to take a load of our servers, but I don’t know how to choose a CDN. What do I need to do?

Operations Staff, NOC

  • Man, I get a lot of alerts. How do I tell which ones I need to care about?
  • This sure looks like a problem. How do I show the appropriate folks that this issue is their responsibility?
  • Most of the time, the issues I investigate are with one third-party. Who is responsible for fixing this and does it really affect customers?
  • I get bonused on fast MTTR. How can I figure out what the problem is faster?

The interesting thing about these questions is that each layer is different. But you can easily follow some themes. A simple strand to follow is:

  • The system that generates a lot of alerts because of multiple incompatible monitoring systems
  • Can lead to performance issues that are expensive in terms of money and resources to resolve,
  • That has a substantial ripple effect on revenue and customer satisfaction
  • All of which eventually costs you market share and allows other companies in your vertical to gain a competitive advantage

Pain is a complex and very personal thing. Knowing that it hurts in one place doesn’t always mean that the fix should be applied there.  Asking the right questions is far more important in solving the whole problem, because a few stitches may be hiding something far worse.