Beyond Customer Service: Ownership in Software Development Services
Jerod Venema
Mar 5, 2016 9:21:00 PM
In today’s global economy, companies that provide software development professional services are challenged to compete with worldwide offerings of similar services. How do companies that are based in the US, Canada or Europe compete with resources in other countries that have a lower cost workforce?
There are multiple answers to that particular question, but one key way of differentiating your offering is ownership. What ownership means here at LiveSwitch Inc. (and what you don’t typically get when working with a garden variety outsourcing company) is manifold: learning about a challenge (that may or may not actually even be your problem), understanding it, solutioning it, and seeing it through to completion.
Let’s walk through those steps one at a time and see what they really entail If your outsourced professional services team isn’t helping you in every one of these areas, you should consider if they’re really doing all they can to help you succeed. I’m specifically talking about the software development lifecycle here, but the concepts apply across all divisions of your business.
In the context of learning, a “challenge” refers to anything that a customer might be facing as an obstacle to selling their product. Timelines, bugs, unexpected feature requests, support, quality...these are all typical “challenges” faced during the software development process.
While listening to your customer and learning of a challenge can be explicit (I need X!), it’s very often implicit as well. In software projects, hearing someone mention that something takes them a long time to complete, requires a lot of effort, or is tedious or error prone to execute are all indicators that there’s a challenge that needs someone’s attention. All it takes is an off-the-cuff remark to learn of a challenge faced by your end users.
One challenge recently faced by our team here was a customer issue that was initially reported simply as “the connection fails sometimes”. As you can imagine, this report is not overly helpful for to diagnose the problem. Our team dug in though. Instead of just throwing it aside as “we can’t reproduce this”, we immediately started working with the customer to get more info...which led to really understanding the problem (more on that below!).
Another example would be project timelines. During our initial discovery and proposal phase for a project, we were discussing the “MVP” (minimum viable project) timeline, and during that discussion the customer said “it would be good if we could go live at the beginning of February”. This was the first time any actual target dates were mentioned. They also didn’t want to impact the cost. Impossible? Read on…
Once a challenge is realized, it needs to be understood. Getting to the heart of a challenge can be tricky, but we like to use the “five whys” method. Every time you have a challenge, ask “why” it’s a challenge - and go five levels deep.
In our connection example, the most obvious “why” is “why does the connection fail”, which led to getting logs, information about physical location, networks, etc. We started to realize that it was only mobile devices failing. Next “why” was up - why only mobile devices? Further digging...why only certain mobile devices? Why only on T-mobile on certain mobile devices? The goal: learn as much as possible about what the real problem is as possible so we know what the real challenge we’re facing is.
For our timeline example, we took the same approach. Why February? Once we understood that question (there was an opportunity for an early demo), we asked why that demo was important. As it turns out, that demo was to a large potential customer that had a very specific (and limited) use-case for the application.
These are some simple examples of ways LiveSwitch Inc. learns and understands your application’s unique pain points. Check in with us for Part 2 in this series and learn about ways we follow through with our customers.