Product Development Principles, Part 1: Customer Obsession

Product development is hard. Innovation is hard. We are continually building new things, at new scale, and addressing new challenges posed by our customers. While we try to learn and improve, innovation necessitates doing many things for the first time. It is often impossible to figure out exactly what we should do and how we should do it in advance of, well, doing it. We don’t get Lego kits with instructions. Heck, we don’t even really get Legos. Sometimes the physics, the building blocks, and the construction techniques are simultaneously fluid.

Fortunately, there are some general principles that dramatically improve our ability to build great products. In the context of our teams at Splunk, there are four principles I highlight as critical for us to embrace so that we can build world-class products:

• Customer Obsession
• Data-driven Decision-making
• Ownership
• Cadence

Part 1 of this series talks about Customer Obsession. In each of these parts, I propose some questions that are helpful to ask of ourselves and our teams in the spirit of these principles. Pursuing these questions helps build the capabilities to answer them, all with the goal to build world-class products for our customers.

Customer Obsession

Our purpose in product development teams is to deliver value to customers. Some teams have internal customers, some have external customers, and some have both. Regardless, every one of our teams delivers value to their customers through products they build or expertise they provide. Moreover, we aim to build products that provide a delightful experience. Despite enterprise software’s reputation for lagging in design elegance, we believe it’s possible to deliver both great value and great experiences at the same time; in fact, we believe that these goals reinforce each other.

Compounding the product development challenge, our teams are working to deliver something new and improved, different from what has been done before. They are innovating, providing value against unmet needs. Whether it’s building breakthrough analytics to detect cybersecurity threats before they can wreak havoc at a large bank, or improving test automation for software developers to assess system-wide effects of their changes, we’re always innovating.

To build great products, especially industry-leading products, we must be obsessed with customers. What are their problems today? Tomorrow? How can we best add value for them? What is working for them? What’s harder than it should be? What new solutions can we provide for them?

Start with the value

The reason to start with our customer is simple. Value is delivered when customers use our product. That is the point of impact. That is where the idea of what someone might do with the capabilities we build turns into reality. Obsessive attention to this moment, the actual realization of value in the world, is fundamental to understanding both customer needs and how you can fulfill them.

This concept isn’t unique to enterprise software products; it’s deeply embedded into every successful business. Muhtar Kent, former CEO of Coca-Cola, talks about routinely spending time at the point of impact to understand customer needs. At DoorDash, employees regularly do deliveries to experience the system in person and stay close to their customers. These are visceral ways to learn about how value is being delivered. It’s no coincidence that leaders of successful companies champion this ethos.

Surprise and delight

Customers are full of surprises that are both challenging and encouraging, but always enlightening when you recognize them. One of my earliest distinct ‘customer surprise’ experiences was while CTO and VP of Engineering at aPriori, visiting an automotive customer. We built software for mechanical design and manufacturing engineers to quickly assess, in detail, what would be required and how much it would cost to build what they were designing in a CAD tool. Our target users were designers who were actively shaping parts in CAD systems while cross-referencing aPriori for cost information, or manufacturing engineers who were getting ready to make the thing.

That day at the customer’s office I was getting a tour of aPriori in action. Rather than talking to designers, my host was walking me through the offices of their procurement department. On desk after desk were stacks of printed screenshots of aPriori. Several people were actively using the product, so we stopped and asked them to show us what they were doing. One procurement specialist explained that she regularly negotiated with suppliers about parts they were building but lacked detailed information about manufacturing processes, costs, and how small variations might change things; in short, she was flying blind in a lot of supplier conversations. With aPriori she found that she had a wealth of detail to discuss with suppliers, making it much easier for both parties to come up with a good, timely, cost effective solution. This is where the screenshots came in; they were the only way she had found to extract a complete picture, which she could then use to compare notes within her department or to send to the supplier. We hadn’t built any elegant reporting or export capabilities in the product at that point, much less any true collaboration features.

That stunning insight was worth 10 customer visits. First and foremost, it crystallized an entire way of using the product (procurement negotiations) that we hadn’t been focused on. Second, it highlighted exactly how the product fit in and delivered value for that user, but also what the product lacked to make it that much more delightful, powerful, and easy to use. These surprises also suggested where to keep digging, and in talking with other early customers we found similar patterns. Using those insights, we immediately opened up a theme of work on reporting, export, and collaboration, which led to a wealth of capabilities that added a lot of value for customers.

These surprises happen all the time, even in areas of the product or types of usage you think you know well. The world keeps changing, customer needs keep changing, and even for products that are relatively mature, this shifting context brings fresh insights to life.

Customers and innovation

Jeff Bezos, founder and CEO of Amazon, talks about customer obsession a lot. It’s the very first management and decision-making principle he lists in his first shareholder letter in 1997: “We will continue to focus relentlessly on our customers.” It’s a theme he returns to all the time, 20+ years later and leading one of the most innovative and successful companies ever created.

Innovators can’t rely on competition, existing market conditions, or simple projection of the current trajectory to create the future. Innovators need to be immersed in trying to understand today’s challenges and what tomorrow might look like, so they can create a future that solves problems in ways others aren’t seeing yet. To do this it is fundamental to be close to customers, today and every day. We have to live and breathe their challenges and understand what will add value for them.

Every person on the team should be thinking about our customers. We should be continually studying and discussing the world from the customer’s point of view. What problems are we solving for them? Why is addressing a given challenge more important than another? How are our products actually being used? What is working well for customers; what is not?

Clayton Christensen at Harvard Business School developed a popular framework for thinking about products in an innovation context, called ‘Jobs to be Done’. It’s one of many ways of thinking about the outcomes a product (or service) delivers, in the context of customer needs. The fundamental goal, though, is seeing these outcomes through the lens of the customer, where any one product or time spent using it is just a single element in a more complex arc of their own goals.

Being your own customer

“Eating your own dog food” is a well known idiom in software development, meaning to use your product yourself. In some enterprise contexts this is impractical, but it is often possible or at least partly possible. At Splunk we make significant use of Splunk internally, and as new products are developed, try to leverage them ourselves from the earliest point possible.

There are tremendous benefits to being your own customer, especially early in product development, but this doesn’t replace obsessive attention to customers outside the company. Leaning too hard, or exclusively, on your internal customers (including yourself) has pitfalls.

• Inherent knowledge of context: You know, implicitly, what your larger context of work is when you’re using your product. This informs your thinking about product design and capabilities in crucial ways. You need external customers, however, to make this more explicit and understand whether their context of work is even the same as yours. Insights in one context don’t necessarily translate to another.
• Inside knowledge of the product: You built it, you know how it works. You have a strong mental picture of the product’s constructs. Your customers don’t have that. Any sense of what’s intuitive or not for you is not likely to be shared by customers.
• Over-indexing on nuances of your needs: You can continually tweak the product to address specific needs you encounter. Shortcuts, default behavior, and inclusion or exclusion of new capabilities can all be shaped by a crisp understanding of exactly what would help most in a given circumstance. This can be a powerful design force early on, but over time strongly adapts the product to a specific way of using it that might not be shared by most of your customers. The only way to know is to immerse yourself with them, and use equivalent insight into their specific needs to evolve the product.

In essence, what you seek to do by obsessing over customers is to derive the level of understanding you gain by using the product yourself, but relative to their experience instead of solely your own. This lets you shape product innovation in a way that’s very strongly aligned with how and why your customers derive value from your product.

Next steps: Key questions

One way to start bringing customer obsession to life is to ask and answer key questions. Keep coming back to these; even when they seem simple and well understood, the ever-changing dynamics of the world for both you and the customer means there will continually be fresh insights.

Key questions we are always asking at Splunk:

• Who are your customers?
• How does your product add value for them?
• What else are your customers doing when they use your product, e.g. what is the context in which it is used?
• Is using your product a delightful experience for your customers? If not, what would a delightful experience look like?
• What are the biggest unmet challenges for your customers today? What would add more value?
• Looking at existing lines of work, how will they add value? What will it look like when in customers’ hands?
• How are you measuring customer value and delight?

About Jeremy:

Jeremy is SVP of Engineering at Splunk and leads our global engineering team. He joined Splunk in April 2018. In prior roles, he led the engineering team at DoorDash, led a variety of product and engineering efforts at Twitter, led engineering efforts at two startups in the Boston area, aPriori and Bluefin Labs, and held various engineering and product leadership roles at i2 Technologies. After graduating from MIT with degrees in Computer Science and Philosophy, Jeremy spent 7 years on active duty as a Marine officer, serving in various locations around the world. He also has an MBA from MIT’s Sloan School of Management.