Should Developers Know the Business Customers?

We often hear that we need to ‘know our customers.’ We need to know what their needs, wants, and desires are.

What made Steve Jobs so great at what he did was that he intimately knew what his consumer base wanted… and then created the best darn product out there. He revolutionized the way we listen to music, and changed the way we interact with technology.

As developers, we often can have a tendency to want to create something that we seriously think will be helpful or useful to others. We want to make the best products and we want to add those features that… well, we would use. We hate wasting time.

Often though, this doesn’t exactly fall in line with what the real customer might want.

“But it’s new and cool, dude.”

We hear statistics around how much of the features of a product aren’t used. I mean, look at Microsoft Word or Excel. I would bet that 95% of those features aren’t used. What the heck?

In Agile/Scrum we have a Product Owner, sometimes a liaison, or representative of the customer. What would happen if we have the team show off the software to actual customers, get revisions and edits, and build what they want? I’m working with a company right now in which I suggested they do just that: Put their development team in a position to speak with customers. So far? It’s working.

Now, I wouldn’t suggest that all companies do this, but for this particular situation it works.

Deploy. Show your customers, get feedback. Inspect, adapt, refine. Improve. Oh wait… yes, that can include the whole agile team and developers too. 🙂

18 Replies to “Should Developers Know the Business Customers?”

  1. If your customers are likeable and can articulate what they need and why they need it it can be great to meet up. It can be really motivating for the team.
    I think true collaboration with customers is the holy grail – a customer as part of the team. So hard to achieve in most cases.

  2. I agree with Tom – the potential is there for the kind of collaboration that is the very essence of the Agile Manifesto. And I’ve seen it work well.

    I don’t agree likeability should be a prerequisite, though. The biggest ratbastard stakeholder on the planet who can communicate clearly and concisely what needs to be built will drive progress more effectively than an affable, pleasant, stream-of-consciousness stakeholder who couldn’t communicate an intelligible user story with two whiteboards and a hand puppet.

    1. I believe it depends on how your developers handle themselves with respect to customer interaction. You may experience disruption when your talented yet introverted engineer clashes with said ratbastard. Given your environment, the “product owner as a meatshield” strategy may be well suited.

  3. Pingback: Should Developers Know the Business Customers? | Agile | Syngu
      1. They’d still want extra pay OooOOoO 🙂

        Seriously tho — this devs meet customers is wishful thinking imho. There is a reason there are geeks, and there are smoothy salesmen/customer relations people, and that they are different people.

        If you really had someone who was both, not only would they be few and far between, but they’d be entrepreneurs starting their own business and not easily available in the labor pool.

        Maybe in Japan the engineers are presentable enough to work in a car dealership for a few months ala the toyota way, but most software devs are not.

        Also a single point of contact for the customer has always made sense, and I think that too much interaction can muddy that aspect.

        Bottom line: Sales owns the customer and sales isn’t going to put developers they don’t know personally in front of their customer. See wishful thinking above 🙂

        1. IMHO passing information like this through sales is the root of the problem. Sales have their own agenda (to hit targets) and will often twist the users story accordingly to try to keep both parties happy. They also make there own assumptions about what’s easy/difficult to do and miss the best solution to a problem. If you want a good product you need to cut out as many middlemen as possible between the user and the developer.

          Some developers may lack experience at dealing with customers but that doesn’t mean it isn’t something they can learn. In the right context customers are find it refreshing to speak to a straight talking developer and will make allowances for their possible lack interpersonal skills. Modern dev teams that collaborate constantly don’t lack these skills anyway.

        2. Why not try it out? Wouldn’t it be valuable to try and see? It may not work for every company, but I would bet that some companies would… benefit from it… potentially. Wishful thinking!

Leave a Reply