Month: July 2015

Dealer Systems in the Consumer Space

I was writing an article about how I look at tech strategy, and it was getting a little long, so I thought I would just stop and give an example. I have had the good fortune, over the years, to develop early versions of online credit, menu systems, and e-contracts. These are primarily dealer-facing systems, with the attendant limitations.

If you have been reading my blog, or McKinsey, or pretty much anything, you are aware that the next challenge will be to put these tools into the hands of online customers. The table below lists the capabilities these customers have today.

Gadgets Table

You can gauge how much room there is to improve the customer experience by comparing your favorite dealer systems to the gadgets available online. Dealers operate at a distinct advantage and, through competition, we can expect that advantage to diminish.

I am not saying that an online customer is going to run, say, a credit aggregation system. Dealer systems are feature rich, and designed for trained professionals. What I am saying is that there will be a component of your favorite dealer system designed to run in the consumer space, and that it will be a competitive differentiator.

If you are in the dealer system business, this insight is not new to you. You are already working on ways to engage customers before they come into the dealership. My point is that this strategic imperative applies equally to all the functions listed above (plus some I didn’t want to get into, like pricing).

This means that you can take strategy tips from systems outside your functional area, and outside the dealer space. There are some common themes, leading to a generic strategy. Schematically, the strategy looks like this:

B2C Diagram

I included “partner system” as a placeholder for, say, a DMS if you are upstream of one, or a finance source or product provider network. You and your partners are facing the same strategic imperative. You will want to make sure that your responses to this imperative are in alignment.

By “plugin,” I mean any webpart, Iframe, or redirect that exposes your core system’s functionality to the online customer. A web service might do the job, but you lose control of your distinctive customer experience. Plus, they’re harder for the host site to adopt.

As with any software, success in the consumer space requires good functionality balanced with ease of use, but the decisive factors are:

  • Which web sites you’re on
  • Which dealer systems you plug into

As I like to say, the interfaces are the strategy. If you are an independent, like eLEND, plugging into every system fore and aft (see diagram) is an option. If you’re Route One, you have a special relationship with the captives and their dealers. If you’re Dealer Track, this is why you bought Dealer.com. Among credit systems, the battle for consumer space is already underway. I will survey the space in a later post. For now, let’s consider the other dealer systems.

The interfaces are the strategy

I listed menu systems as “TBD.” I know something about menu systems, and I don’t think anybody has a good way to present a menu on a consumer web site – much less an iPhone. I have seen a four column menu attempted, and I have seen “click here to run video.” Remember that the goal is to present products, and a menu may not work in this space. Instead, I would recommend using an expert system.

Ironically, the customer end of Customer Relationship Management is basically passive. I listed “personalization,” above, as one possibility for opt-in marketing. My profile on the BMW web site tells them about my vehicles, where I bought them, and how they were financed. The site offers some useful features in exchange, which unfortunately most sites do not. Because it’s an infrequent purchase, customers are unlikely to create profiles on automotive sites. Portable profiles like “log in with Facebook” are a partial solution.

Payment calculators are a disgrace, and blatant fronts for lead collection. They have more contact fields than they have numbers. Those on dealer sites ask you to configure the vehicle first. Finance sources do a better job, for obvious reasons. You may think it’s clever not to give a payment until the customer has chosen paint and rims, but – she is one click away from her credit union’s web site.

This recaps a key point from the generic strategy – dealer advantages will be arbitraged away. It also touches on an interface question. What is the appropriate recipient of customer payment data? Is it just a lead, or should it dovetail with your credit system? My purpose here is not to answer all the questions, but to demonstrate the principle.

Your web plugin is like a survey marker, with which to stake out territory in the consumer space. Some sites are more valuable than others and, of course, the host site must also find value in the relationship. In my next post, we’ll explore this space and discuss the opportunities for specific dealer systems.

Sensitivity Testing Model Assumptions

We have all made them, those wonderful Excel models with their hockey sticks and their double-digit rates of return. You may have strong accounting and Excel skills, but a financial model is only as good as its assumptions. In this article, I’ll give some pointers on how to corral your assumptions and, most importantly, how to validate them.

Whether it’s a project or a new business unit, the typical financial model looks like an income statement. It will have rows for revenue and expense items, and columns showing these items as they change month over month. If this sounds too basic, you may skip ahead to the section on sensitivity testing.

You need to realize that the more you have played around with a system’s parameters so that it gives you better results, the less likely it is that it will work in the future – Marcel Link

The first thing you want to do is extract your assumptions from the formulas on the model sheet. For example, if you think you can add 100 users each month, type 100 in its own cell and label it “monthly new users.” Every formula that uses the 100 figure should reference this cell. Later, if you decide the correct figure is 120, you only need to change it in one place.

If you expect to add 100 users per month, this is a linear increase. A chart of your total users will be a straight line. If you think that transactions per user will also increase linearly over time, then your total transactions will show a quadratic increase – or order n-squared, as we old coders like to say. This chart will be a parabola. To validate your model, it is important to understand the order of its time series variables.

People sometimes mistake a parabolic increase for an exponential one. You will only have an exponential series if there is compounding, like an account that accrues interest, and then interest on the interest. For example, you may think that your user base will grow by 10% per year, but compounding it is optimistic. When in doubt, make a chart of the series and use the Excel “trendline” feature.

Ultimately, all your assumptions will flow to net income, like monthly user fees, the user adoption rate, and the associated expenses. You may also have constant values (or values considered constant for the scope of the model) like the number of U.S. car dealerships, and annual new vehicle sales. Extract all of these from the formulas.

The goal is to have only formulas on the model sheet, and all parameters on a separate sheet. By parameters, I mean the constants as well as the model assumptions. For example, you may have a variable date that marks the launch of a new phase, or a true-false flag that toggles a partner relationship.

Once you have the parameters on a separate sheet from the model, add formulas here to summarize the results. You might want to see a summary of the income variables, an IRR of the net cash flows, and maybe a chart. Now, for analysis, you don’t need to look at the model sheet. You can experiment with the parameters, and see the results on the same page. The model sheet sits in the background and does all the work, like a subroutine in a computer program.

I always include a time series chart with one or two key income items. This helps me to see the impact of changing parameters, plus it makes a great presentation. This is the ideal setup for analyzing the model – as well as goal-seeking a desired result, which brings us to the headline topic.

Demo Model

It’s human nature – the first thing you do with a financial model is set the parameters to justify your business case, and then you fixate on those settings. Psychologist Danny Kahneman calls this “anchoring.” All future discussions will now start with the anchor settings.

The way to prevent the model from misleading you, and your client, is to sensitivity test the parameters. First, though, let’s look at some common sense tactics that don’t require math.

  • Find historical data. Always, always, always work with actuals wherever you can find them. If your client has previously rolled out one system, that tells you how fast they will roll out the next system. Also, link your model values to reality, like – how many trainers are available?
  • Find objective estimates. Ask people for numerical answers to specific questions – without anchoring. How many dealers can you sign up in a month? At what price?
  • Use the buddy system. Do not be the lone modeler. The last time I did one of these, I reviewed all the assumptions with my client’s CFO. I also sat with a financial analyst and walked her through each and every formula. Consultants talk about getting “buy in,” but this is really about getting accuracy.
  • Write good documentation. For each row in the spreadsheet, write down what you think it means and how you got the number. This is a lot of work but, trust me, you will be surprised how valuable it is. Does your SAAR figure include used vehicles? Does your revenue include sales tax?

You also need to accept, and communicate, that the new project might not pencil. No one ever likes to hear that, but it’s better than making a bad investment. Sensitivity testing will show you what happens when the parameters move away from the ideal. For example, maybe it still shows a profit, but below your hurdle rate or outside your timeframe. By the way, it’s good form to establish these thresholds up front.

For each parameter in the model, you want to determine how “sensitive” the results are to a change in the parameter. Some of these, you will know from the order discussion, above. For example, if net income is linear with price, then a 10% increase in price will mean a 10% increase in income. On the other hand, if you modeled the decrease in sales due to increasing the price, then you have a downward sloping parabola (for which you should perform a separate supply and demand analysis – but, I digress).

Sensitivty Table

Set up a separate sheet, like the one shown above, and list what you think are the most realistic values for each parameter. Next to these, list what you think would be its best and worst case values.

Run the model for each case, changing one parameter at a time, with the others set at their baseline values. Record the results for each run. In this case, my result variable is cumulative net income over some time horizon. You might be using IRR, discounted cash flow, or a breakeven period. For a breakeven period, “strong” means a shorter period.

The sensitivity for each parameter is simply the proportional change in results, divided by the proportional change in the parameter. Geometrically, you would like to know the slope of the line defined by the change in results – except that the parameters all have different units.Triangle2So, what you are computing is the slope of this line on a logarithmic chart – rise divided by run, with your independent variable on the horizontal axis. The steeper the slope, the greater the sensitivity.

This analysis tells you which parameters you need to focus on, in terms of both model accuracy and critical success factors for the project. A sensitivity value of 1.0 is high. It means your results depend directly on this parameter. You will want to spend time validating this number and then, when the project launches, you will want to manage to it.

Sales-Driven Development

Larman BookI invented agile development. No, that’s not as cocky as it sounds. Every development manager I know has been trying to reduce cycle times, forever. At BMW, we did quarterly releases of call center software, and that was on client-server technology. As a profession, we have always been as agile as possible given the tools of the day.

What we call “agile development” is the ability to release software early and refactor it later. People generally overlook the high cost of refactoring, but I’ll save the critique for a later post. You can read The End of Agile, over at Effective Software Design. What I would like to present here is a practical approach that served us well at MenuVantage, and which is still relevant today.

We were operating in a highly competitive, fast moving market. Our sales people would come in and say they had just lost a sale because Brand X had some feature we didn’t. Better yet, they would have closed the sale on the promise that we would have it in next release. The developers complained about “sales driven development,” which, today, sounds like it could be a book title.

Our cycle ran from development on the local laptops, through automated daily builds, to the hosted production servers – every six weeks. I know that the scrum literature talks about producing “shippable” code every two weeks, but few shops actually move to production that frequently unless they are in a consumer market, running AB tests. I assume that most of my readers are developing business software for dealers and finance sources.

One innovation in our process was a second QA environment, on the company extranet, where product owners could preview the work in progress. Business requirements were thin, as I’ll explain later, and the extra environment gave us some ability to iterate within the six week cycle. I dubbed it “rolling QA,” in the process document.

When we deemed that it had rolled enough, we froze this code and moved it to production.   Meanwhile, “nightly QA” would already be in use for the next release (see diagram). We also maintained a second copy of production, called “post-prod,” that we could use just in case we should ever need to diagnose and fix a critical problem in production.PipelineAs each release went live, the product owners would meet to negotiate the content of the next release. This expression, “product owner,” is another thing that bugs me about scrum. In this case, though, the meeting included the legal owners of the company. We might differ over development priorities, but we had absolutely congruent goals for the company.

In preparation for the meeting, we would have pulled together a short list of the highest priority change requests, and estimated them – in hours. We did not use “complexity points,” because sales and finance people are much happier thinking in hours. For one thing, it facilitates a discussion about how many developers there are and how many hours they work. If you are uncomfortable having this discussion, trust me – using an arcane metric instead of hours will not make it easier.

Within the development team, we did use complexity to derive each estimate, by counting how many modules, pages, queries, etc., had to be changed. Contract developers have bid projects this way forever. I am thinking, in particular, of a spreadsheet used by Ernst & Young’s Advanced Development Center. Over time, the conversion factors are updated, so “institutional learning” about the estimates is captured.

We used conventional bug tracking software to manage the backlog. They get better every year. I will note that the last scrum system I used, JIRA, is a repurposed bug tracker. This is part of the reason why I find agile is better for enhancing an existing product than it is for the initial release – but that’s the other post.

My job was to collect high level requirements, write specs, and groom the backlog. Requirements were at the level of, “we need rollbacks so that we can do Sign & Drive.” This is actually not a bad formulation for a scrum story card. Readers will recognize the complexity concealed within this simple request – the UI changes and the math, lots of math.

The goal of the planning meeting was to distill the “short list” into an even shorter list of requests we could accommodate in the release. Don’t be surprised if your short list becomes a LIFO stack. That’s human nature. If something was hot two cycles ago, and it was never scheduled, then it probably isn’t hot anymore.

Development would start the meeting by presenting the short list and announcing how many hours we had available. Initially, we might have been paring a 3,000 hour short list down to 1,500 for the release. After a few cycles, though, everyone was able to predict what the final slate would be. The meetings became shorter and less contentious.

This is where we really enjoyed the advertised benefit of agile – and what motivates me to endorse this approach. The group learned that if we didn’t get all our requests into this release, we could rely on the next one, and the sales team developed a feel for how much they could promise.