Developing for the Customer

A few months ago, I was invited to the University of Waterloo to do a presentation for a class of entrepreneurial and computer science students. I went into this presentation under the notion that I would just be talking about our product, SoapBox and the journey we’ve been through over the last 4 years. After I presented, the professor of the class noted “Here we have a CTO that has spent the last hour talking to you about the importance of the client”. I had never thought about it that way but it was true. Since the inception of our company, and during the development of SoapBox, we have always kept in mind the needs of our clients.

SoapBox wasn’t actually a company until we landed our first set of clients. We were located in an incubator, the Digital Media Zone, where potential clients tour through daily and see us working. We literally built our product with would-be clients peering over our shoulders asking questions about functionality and expressing their needs for the type of tool we were creating. They basically provided me an ad hoc set of User Requirements that would turn into the first version of SoapBox. Keeping the needs of the clients in the front of our minds right from the beginning has been the key to success.

Here are 5 ways you can code for your customers.

Interact with your clients.

Talking to the people who use your software every day is critical for their continued engagement and ultimately the success of your product.  Prior to our Chief of Client Success, Jess joining the team, I would meet with our clients and directly address concerns and needs for the tool. The best part of these meetings was getting to see first hand how our clients use SoapBox. Often, how you envision the use of your product is not exactly how it turns out in reality. It can sometimes be surprising to see how clients have hacked parts of the tool to get the most out of it for their business. It’s fascinating to see these hacks so we can further improve the platform, not only meet the clients’ needs but to exceed expectations. As we have grown our business and client list, Jess’s Client Success team interact with the clients, and I meet with her team to debrief and make sure the clients are happy with the product and learn what we can do better.

Code with Empathydeveloping-client

I have this quote that I like to share with my development team: “Every decision we make, every line of code we write, affects the way real people experience our products.” Since the beginning, real people have been using our innovation management program. By real, I mean that it wasn’t built for the younger technology-savvy generation. This was built for people working on the front-lines, at all ages with varying degrees of technology know-how. These people are doing their jobs and want to do them well, without needing to learn another software tool. I like to really emphasize this point when we’re onboarding new team members. This is particularly important to me because as developers, they are writing thousands of lines of code at the basal level and I have to trust them to make the right call. Every line of code is a decision and if I can help them think of the customer at every decision point, I am also setting them up for success in their development.

Create User and Client Personas

Just as it is important for the marketing team to create buyer personas, developers should have customer profiles. Particularly for SoapBox, we really want to ensure the success of our clients by providing them with powerful technology. Keeping in line with the previous point, we always define our clients by 4 key characteristics – stage of adoption, size, geographical distribution and device types used. This is in addition to our user personas which determine the types of users that engage with our platform (users, managers, administrators and idea partners). These user and client personas help to guide the decisions that the developers make when they are coding and frames how we create new features for our clients. When we launch new features, we want to make sure that given their user and client persona, the user can fully engage with the tool and be successful.

Say No (Sometimes)

As developers, we always want to make sure we provide a powerful but easy-to use tool so when clients come to us with request, it is easy to want to default to yes. Sometimes though, it’s better to say no. If it’s not a feasible request, it simply doesn’t make sense to promise something that isn’t possible. Also, sometimes, there is a better way to fulfill their request that they may not have considered. As developers, we should always be looking to develop in a way that sees the vision of the business realized, the product scalable and build features that address the root of the clients’ problems. For example, one of our clients came to us and asked for a better UI for the idea tags we display, so that administrators could see them clearly when scanning for ideas. Looking into the usage statistics for tags, we found that no one had ever clicked on a tag, and that displaying them was visual noise. Getting to the root of the issue, we discovered that the administrators wanted a more versatile way to sort ideas. So we said no to tags, but build more enhanced sorting and filtering capabilities, and they loved it.

Key Metrics by Design

I wish we had incorporated more metrics into SoapBox when we first built it. Without key metrics, it’s difficult to know how your clients are using your product, and as you add new capabilities, how those metrics change over time.  Knowing better now, we’re really pushing to build our product with key metrics at the core level to track everything on the system from operations to performance to usability, so that we can go back and optimize our process and product overtime.

 

I hope these suggestions will help you develop with your customer at the heart of the product. Reach out on twitter ( @grahammccarthy ) if you have any tips yourself out want to learn more.