3: Know My Customer

I know my customers, those in the field and those at headquarters.

I'm an engineer; or I was formerly one. Well at least I used to write code for a living. And that gives me insight into a secret engineering credo: we are our own customers!

You see proof of this secret all over the software you use.

Example 1: You click on a button and receive an error message like the following: Function lpzWinRandomFunction returned 0xfe02facd.

Example 2: What should be simple functions (like mail merge) in popular software programs actually require end-users to write "code" in order to get them to work properly (e.g. if/then/else statements, db queries, formatting).

Example 3: Features which have major bugs are left in the software with the excuse that: "It doesn't happen all that often--and the user can just re-start or re-boot. No big deal..."

This kind of stuff is infuriating. It's why software development gets such a bad reputation. Consumers don't tolerate that kind of negligence with their toaster or with their TV. But the industry has been conditioned to tolerate it with software.

We're trying valiantly to be different in our department. Warning: we're not remotely perfect on what I'm going to talk about here. But this is why we have this principle listed: so that we can put it in the forefront of our department's focus.

Good software development starts with understanding one's customer. This can be quite a difficult endeavor. One can always question who the customer is: Is it the Product Manager requesting the solution or feature? Is it his management? Is it the end-user using the feature(s)? And what do we do when priorities conflict among those three. This is a continual struggle for us.

We're doing a couple of things to help with this problem and to better understand our customers.

1) We're dedicating development resources to customers (or portfolios of customers who have similar businesses). We don't actually change the reporting relationship of those developers, moving them to those departments. Not moving them allows us to keep the ability to have a career path and to create centers of excellence in development methodologies, good coding & qa practices, etc. But we leave developers focused on a customer from one project to the next. Critical context is retained as developers continue to understand a customer deeper and deeper.

2) We're dedicating infrastructure generalists to customers so that customers don't have to wade through the technical silos that infrastructure specialization demands. 

3) We're designing iteratively, relying on prototypes. This allows us to have a great idea of what the customer is looking for before we ever start coding heavily.

4) We engage users in testing. We try to take each iteration from our dev environments, through test and staging and into production each milestone. We then ask our users (or subsets of our users) to help us test the bits.

5) We test internationally. This is a hard mindset to change for us. Because the development team is in the U.S., it's easy sometimes to think of the international areas last. We're trying to change that and simultaneously design and ship our solutions in the U.S. and at least a couple of other countries simultaneously. We can't always do it all of the time, but we're doing better at doing a few simultaneously to make sure we iron out localization bugs.

6) We're trying to focus on "listening." It's easy for engineers to be arrogant--to think we know better than others. But that can't be the case. We have to listen or we can't really understand what problems we (and our customers) are trying to solve. Some of the times we have to listen "between the lines," so to speak, where a customer knows that something is wrong, but they aren't quite sure what it is--or what the solution might be. This is an art we practice.

I know it sounds cliche--that we need to "know our customers," but it's a focus that we've needed in our department and one that we're improving upon.