The benefits of applying product management discipline to IT

At Murphy USA, CIO Greg Davidson has created a "software product mindset" around the company's software development, improving its SDLC.

Murphy USA applies a software product mindset to its SDLC
Murphy USA

What’s the difference between an application development team at a software products company and an application development team at a gas station/convenience store company? 

Well, for one thing, the software company generates revenue from its software products, so the software is treated like a product, with a product manager and a rigorous and automated software development life cycle (SDLC). The product manager at the software company is acutely aware of the competition, and the features that competitors in the market are developing.

At a company that sells gas and snacks, you would think product teams focus on gas and snacks, not on software.

Guess again! At Murphy USA, which runs 1,400 stores and services several million customers daily across 25 southern and midwestern U.S. states, the IT team treats its mission-critical software application the same way a software company treats its biggest seller.

greg davidson murphy usa Murphy USA

Greg Davidson, CIO, Murphy USA

Greg Davidson, CIO of Murphy USA, uses his background running product development for Sage Software and R&D at Platinum Software to create a “software product mindset” at the $12 billion gas and convenience store company. He explains in the below Q&A.

What is MURPOS?

MURPOS is Murphy USA’s point-of-sale (POS) system that we leverage across all 1,400 of our stores. We have a software development team that manages our MURPOS code base. This code base not only includes the software that drives Murphy USA’s in-store POS terminals; it also manages all interaction with our gas pumps, which themselves are treated as POS devices. These systems are responsible for processing the majority of our $12 billion in annual sales.

Does the MURPOS product team work differently than the team that supports, say, ERP? 

Yes, this team of roughly 20 people works differently than our other development groups primarily because of the scale and importance of the application. For MURPOS, we have a full-time dedicated software product manager who thinks about releases, the competition, and our roadmap for new features. POS products on the market are always coming out with new features that deliver advantages to our competitors. Our product team looks at those vendors and asks how we can keep a leg up on them. Our product team is highly aligned with our business partners, and we know that our product contains features that are unique to us. We want to keep it that way.

How did you create the product team?

When I inherited the team, I said, “You are a software development team with a product; you can work more efficiently by applying some product discipline.” 

So, we put in a full-time product manager who is responsible for thinking about the product roadmap and product releases. He has two resources, a requirements analyst and a technical writer, who work closely with the software development team to drive requirements and capture technical specifications. 

We’re also implementing automated testing, which will allow for cost reduction, greater and faster test coverage, increased change velocity with increased quality, and ultimately increased customer satisfaction.

What was most challenging about moving to the product management model?

When I joined Murphy USA, I inherited a classic development model: here are some developers; here are some requirements that have come in from our retail group. We were not a product group that was thinking about cranking out releases or building automated test suites; we weren’t thinking about automated builds. We didn’t have repeatable processes in development or testing. As a result, it took a longer time to get releases through the SDLC, and time to market suffered.

The primary challenge we initially had to overcome was resistance to change, although that was relatively easy to overcome. Understandably, the team wanted to do the work the way they had always done it. But once we began gathering detailed requirements for changes that were bundled as a release, and we were able to improve quality and speed to market, they saw the power of the new approach and adapted well. As our new automated testing team comes together, we’ll be able to move even faster, just as my software product teams in the past have.

How are you improving your SDLC?

We are evolving our SDLC to be more product-centric. Our deliverables now include product release notes and product technical documentation, and we are now building product roadmaps. Within the roadmaps, we are not only calling out release schedules and new feature content, but we will also be evaluating competing POS systems. Our newly implemented change management and release management processes do a great job of managing the details behind the entire lifecycle of product changes. 

Ongoing continuous improvement includes the development of automated software builds and deployments. My goal is to get to the point where we’re able to do nightly builds of the code base and nightly deployments of the new code to the QA environments. The nightly builds and deployments will allow us to cycle through defects at an increased velocity, which improves our competitive stance.

What performance metrics do you use to reinforce the product management approach?  

In addition to traditional performance metrics, we have started to measure credit card transaction speeds, and soon we’ll be measuring API call round-trip performance with our central customer loyalty system. The credit card transactions are measured in seconds, and the API calls are measured in milliseconds.

We started measuring credit card transaction speeds when EMV (the new Europay, MasterCard, and Visa standard for the chip card) was introduced. When the chip cards first rolled out, processing time was 10-15 seconds. We are implementing a fast chip that will get us down to three seconds.

What advice do you have for CIOs who want to establish product teams vs. traditional applications teams?

If you lack software product company background yourself, then I would look for people who have it. I don’t think someone with a classic IT application development background can lead the product group. 

I would also train some people in software configuration management, including automated deployments, since the goal is one seamless delivery mechanism. Adding DevOps talent is also key, especially for companies that are deploying to hyper-convergent and cloud platforms. Once you have some software product professionals on your team and deliver quick wins, you can start to drive the new SDLC across all of your applications groups.

About Greg Davidson

Greg Davidson joined Murphy USA as CIO in November 2016. Prior to that, he was Director with AlixPartners and previously held CIO roles with Urban Science and Active Aero Group. Davidson holds a BS in Computer Science from Wayne State University.

Copyright © 2017 IDG Communications, Inc.

7 secrets of successful remote IT teams