What I love most about working at a startup is how close I am to the people I’m serving. Almost every task I work on directly benefits our customers. And working at a web startup means I can deliver that benefit as soon as it’s built.

A lack of customer interaction yielded many frustrations at my previous job, where I was part of an enterprise SDK team. I was separated from my users. Requirements were set by product managers; testing was done by quality assurance; feedback came from division heads. User interaction was not part of our process. I did have coworkers who were very much involved with their users, but they were a limited breed. They tended to be designers, managers or developers of the bottom (user-facing) layer of the stack.

I say all of this without issuing criticism. Pairing up customers with developers can be exceedingly difficult in an enterprise setting. We’re not talking about a web app and a site visitor; we’re talking about a multi-layered technology stack and a user of a derivative work. For instance, if I’m working on a module inside an SDK that goes inside a search engine that is customized in a workbench and appears in a dashboard, when is a dashboard user one of my users? This example is not contrived to prove a point; I was the developer in this very instance. The difficulties get even tougher when it comes time to translate the dashboard requirements into SDK requirements. These were complicated problems that dealt with several layers of our technology stack, and product management was a necessary arbiter.

The question is: at what point in the customer interaction process should product management step back and let developers take over? The answer is: as soon as possible. As soon as a user’s problem can be mapped to a particular developer (or a module for which a particular developer is responsible), product management should get out of the way. At this time the developer should consult directly with the customer.

There are two reasons for this. The first is that it reduces confusion. When there is a chain between the customer and the developer, every link is a filter that obfuscates the customer’s needs. When I speak directly with a user, the odds of my understanding the user’s problem are very high. Those odds are dramatically reduced by each person placed between us.

The other benefit is motivation. I cut code because I enjoy solving problems that make people’s lives easier or more enjoyable. Seeing such a problem first hand inspires me to solve it. There is a strong correlation between motivation and productivity, and letting developers interact with customers is an easy and efficient way to boost both. The customer wins, the company wins, the developer wins.