Satya Nadella's strategy for Microsoft is "Mobile First Cloud First". That's helped keep teams inside the company stay focused on the right objectives, but it only describes the "what" and not the "how". For the how, we should think "Quality First Customer First". Quality can mean a lot of things and I listed out some testing aspects in my last post. In this post, I'm going to go into more detail around the Customer First aspect of Software Engineering.
Who are your customer?
To have a strong engineering team, you need to going the extra mile to understand your customers. The complexity in any IT department is determining who your customers are. Many of the services we provide are based on requests from our internal company business group (groups like finance, marketing, sales, etc.) or they are based on the need to provide efficiency and gain higher productivity with our internal engineers and employees. When your customers are internal to your corporation, it can be confusing on who you are trying to please. For example, if your marketing team wants your team in IT to create a company homepage in order to market your company's products better, are your customers the people in the marketing team or the customers external to your company that come to your company's homepage to buy your products? Let's make this easy. Your customers should always be people external to your company, people who potentially will spend their own hard-earned money for a service or product your company provides. Those "customers" who are in the marketing teams or any other business teams, well, they are just your coworkers. They don't make money from the work you do. Like you, they help make the company money from the work you do. Yes, you need to work together and be really clear on what needs to be delivered, but in the end, your customer is your company's customer whether you are in an IT department or not.
What do your customers want?
If you are a software engineer who understands your customers well, consider yourself lucky. I find that one of the hardest things for engineers to figure out is what their customers want and how to create it in a way that appeals to a large customer base. Engineers need to think about 3 types of customers:
- Those who are new to using your service or capabilities and how best to onboard them
- Those who use your service or capabilities regularly and have feedback and input that you should be collecting
- Those that have problems with your service or capabilities and you need to make sure you have a clear path for support in order to hear about their blocking issues and fix them
How do you learn more about your customers?
The Inside-Out Method: So how do you connect with your external customers in the 3 categories I described? I posed this question to the engineering leadership community within my organization and got some interesting answers. What I found most often is that engineers want to engineer a way to connect with the customer. This is the inside-out way of thinking about customers. What I mean by this is the thinking starts with things that are happening already inside your team (inside the company) and extend those ideas out to reach the information out there (outside your company) that can be used to understand your customers. There are a few different ways to approach this.
1. Telemetry and Flighting: You can focus on telemetry and instrumenting your code to collect usage data on all the capabilities you provide to the customer. Gathering, analyzing, and reporting this data will gain you insights into what your customers are experiencing. Flighting features to a smaller segment of your customer base and using telemetry data to see how the customers are using those features allows you to experiment and tweak features to make them the best for your customers.
2. Quality of Service: Focusing on overall quality of the service your customers are using is very important. Engineers should measure key metrics like MTTD/MTTR (mean time to detect/mean time to resolve issues in Production). As an engineer, spend more time being involved in troubleshooting issues in your production environment so you can firsthand see how your code is being used and where it may be breaking.
3. Integrate customer into your process: If you are using the agile methodology, create user stories and tasks to track standard items that will help keep the focus on the customer as part of your sprints. Add acceptance criteria specific to customer needs. In my team, we have a set of Engineering Fundamentals focused on the customer and that show up as tasks for every sprint.
The Outside-In Method: Next, consider some outside-in ways to understand the customer more. Unlike the first, this approach doesn't look at typical engineering work with a customer filter on it. This approach actually doesn't consider engineering at all but looks for ways to understand what the customers are actually experiencing with your features and services through a change in mindset and internalizing the customer experience. There are some activities all engineers should do to get closer to your own customers.
4. Be the customer: You should dogfood your own products. What I mean by this is use what you are creating and be your own customer. This will help expose issues your customers may have when onboarding to your service or using it in their normal routines.
5. Know the customer: Go visit a customer and watch them use your product or service. Sometime you'll need to go to them, but sometimes you can bring a set of customers onsite for a usability study. This allows you to see how regular customers use your features, and gather input from them. Also consider hopping on support calls. Listen to how the customer has problems using the feature or capability that you created. Talk to the support engineer to find out what changes or new capabilities are needed to reduce customer call volumes. This can gain you a lot of insight into that third segment of customers I mentioned earlier, the ones that use your service but have blocking issues. Finally, consider going to conferences and seminars that your customers attend and ask them questions about their experience using your product or service. Stepping away from your computer to talk to your customers can be a huge learning experience for any engineer.
6. Competitors: Understand how your competitors handle their customers. This is similar to being the customer because there may be cases where you are a customer as well as a competitor. For example, in the software industry, it's easy to see how other software companies handle their customers. As a customer, apply your learning from your own experiences with software to the software you are creating.
As you work through all these items, look for ah-ha moments.
What I have found is that there is a great way for an engineer to truly internalize and understand the customer and that is by having that "ah-ha" moment. That time when the engineer is being a customer themselves and having a poor customer experience or an awesome one. They can't engineer their way out of it. They feel the frustration or the joy as a customer. This can happen a few different ways. Consider having your engineers do an exercise to walk in the customers' shoes. Ask them what the customer would want to see if they came to your company website. I tried this exercise with some of my engineers and some came up with items like showing our customers the company customer satisfaction rating or the throughput of the service. Why would a customer want to know that? When I go to buy something on amazon.com, I don't care how many other people are buying things on amazon right then or whether they are pleased with what they found. I just want to buy something. Don't get caught in thinking like an engineer when you are trying to think like a customer. One of my engineers had a difficult experience at a bank doing a wire transfer and was able to relate it to his own job and had that "ah-ha" moment. In the day-to-day routine of any person, including engineers, you can find times when you are a customer and you can see how this relates to your own customers.
Telemetry data, owning tasks in a sprint related to the customer experience, or talking to your customers can be helpful. Figuring out how to get your engineers to their ah-ha moment is powerful as well. Once they internalize the customer experience and their awareness increases, they will look at everything they do at work through a new lens, the lens of the customer. To understand your customers and how they use your software, you have to experience it, not engineer it.