Back when I was in Aerospace writing software for flight avionics and cockpit displays with limited resources, one of the best tools at my disposal as a program manager was the ability to do "what-if" analysis on my program schedule to work around a whole plethora of issues that would ultimately derail a good project plan and the next milestone payment by Uncle Sam. Everything from parts shortages to software development delays (no, never!) to manufacturing issues, test delays (unheard of!), and labor shortages (yes, software talent has been known to look for greener pastures once in a while).

So as the 800-pound gorilla in the room, it was up to me to decide which alternative path to take when something arose to ensure we stayed on plan for the next milestone payment. (Note: I don't really weigh 800 pounds. It's what program managers were affectionately called. Why? Because you never argue with an 800-pound gorilla, that's why.) 

But before I made a decision that would impact critical path on a schedule, I needed to have all the right information, understand all the impacts, and have the proper tools to be able to perform "what-if" simulations to see what the impact of any decision would be on critical path. 

For example:

• If my critical path software subsystem was trending late and would miss the drop point into the hardware, should I add a resource from another non-critical area to ensure we meet the milestone? 
• Or do I swap another totally different subsystem integration out in the test staging lab and put that on critical path instead of the one that is having issues? 
• If I do that, will that affect the overall milestone payment in a negative or positive manner?

So, when I saw Tammy Everts’s (@TamEverts) recent post "When it comes to delivering the best possible user experience, how fast is fast enough?", I thought, what a perfect time to showcase how all you rising 800-pound web performance/user experience gorillas out there can use revenue to show that you mean business when it comes to the optimal performance of your web site or application.

Enter mPulse and "What-If?"

In her post, Tammy offered several citations defining the “ideal” page load time. The answers were extremely diverse and dependent upon many things, including the location (for example, users are less patient in the USA than they are in Australia), type of site, and just plain old individual perception and patience. 

Tammy then boiled it down to a few key factors that you need to make the answer more than just a guess: 

• You measure: Gather data about every user who visits your site and how they use it. 
• You correlate: You take your measurements and analyze them based on your business. Bounce rate, conversion rate, revenue, order value, time on site, all correlated against page load times.
• Lastly, you monitor: What's your performance “sweet spot"? Monitor it, see how it changes over time, and adjust your targets accordingly as correlations change. Lather, rinse, repeat.

So, let's check out mPulse and do a some 800-pound Gorilla what-if analysis work.

Below is an mPulse screenshot of current user data from a retail client. You can easily see the current page load times, and corresponding conversion rate distribution curve. In addition to easily digging into the data on this dashboard, you can also utilize mPulse's "what-if" capabilities to run simulations showing what changes in page load time would do to impact conversion rate and revenue, as well as to run simulations such as:

What if I wanted the conversion rate to be 10.0%? What would the page load time have to be, and how much revenue would that generate over time?

Or looking at it from yet another aspect:

What if my target revenue goals went from $3.5M actual, as shown here, to, say, $3.7M?  What would the conversion rate and page load times have to be in order to achieve those revenue goals?

With mPulse “what-if” analysis, you can look at your data about your end users’ behavior to determine how fast your page needs to be.

Here is our example’s baseline:

Let's run the "what-if" and assume we want page load time to be 4 seconds. Notice the conversion rate and revenue improvements.

What if we were to shave off another second on page load time? What would that give us?

Now let's go the other direction. Say the next release from your agile sprint team shows an estimated increase of page load time to 6 seconds due to some added "heavy" content by your marketing and development teams. What would that do to conversion rates and revenue? Would you still make that content/design change? Maybe not.

Now that we've shown you how moving the page load slider can impact the analysis on the other metric sets, see our "what-if" for a desired conversion rate of 10%:

And  our "what-if" for a desired revenue of $4M:

Now, whether or not you are the 800-pound gorilla in the room or a UX engineer or a business analyst -- or even if you own the performance testing aspect -- you can now run many different “what-if” analysis simulations using your own user data. 

What does this mean for you? 

If your executive management says they'd like to have revenue increase from $5.5M to $6M, as in the example above, you know that your web site would have to be faster by 2.89 seconds. 

However you do that -- reduce content, make your pages "lighter", eliminate some third-party content, use a content delivery network, buy more hardware --  you now have the target you need to make that revenue number. 

You can then drive that result back into the development process, and the requirements process, and to the business owners.   

High Five time!