Who's driving the bus?

April 28, 2008 by cspag

Here at DTS, we're very focused on consulting-type software development. As such, we have very direct access to our end users and customers. Our work is "clearly" defined and prioritized by our customers and we receive direct customer feedback every two weeks. We do not have a dispersed customer base, it's usually a single organization. However, last week I had lunch with a friend who does more "shrink-wrap" development. His customers and end-users never define or prioritize their needs. In fact, unless it's by pure happenstance, the developers never meet or know their customers. The functionality and feature set for the software is defined by an internal customer proxy who has his "finger on the pulse of the customer".

Now a disclaimer: I've never worked on a shrink-wrap team, I've always been on consulting development teams. Given that little disclaimer, I don't understand how a customer proxy can really define what an entire unseen, unknown customer base really needs. I know that some organizations do prototype or "focus-group" type testing to gauge what their customers want. But my friend's team develops on a gut instinct of what their customer base needs. I'm not sure this ever can truly deliver quality and value to a wider audience. I think it leads to Microsoft Word-type deals, with tons of functionality that only a few people actually use. Don't get me wrong, I think a lot of good things come out of gut instincts. I think there is a lot of value to anticipating user needs. It's part of innovation.

The other point my friend made was that in the shrink-wrap world of DVD-based delivery systems, organizations are hard pressed to keep up with the rapidly changing demands of large customer bases. Their release schedules and update maintenance schedules must be horrendous. They can't respond rapidly to changing or evolving customer needs. The best they can do is provide patches and updates via the web. New functionality is released on the next release...on DVD...every 9 to 12 months.

I do see a solution to this problem and I think the folks at Rally really embrace the ever evolving needs of their dispersed customer base. It's how they gather and prioritize their customer's needs that impresses me the most. Rally has a community website where users can enter feature requests. The other users in the community can vote on the usefulness of the feature requested and provide additional feedback and comments on the feature request. Based on these entries and their associated popularity, Rally is able to understand their user needs and prioritize them. Many of the features requested by their user community show up in very frequent releases of their web-based solution. No DVD's or anything. Just a quick release and instant functionality to their customers. Speaking from personal experience, I've seen functionality we've asked for implemented within a single 7-week release from when we requested the feature.

To me, this is as close as you can get to your customers if you're doing "shrink wrap" software development. For those of you out there doing shrink-wrap development in an agile manner, how do you engage your customer base to deliver high value, quality software? I'm very curious how customer proxies work in agile organizations? How do you define and prioritize your customer needs if you never get to interact with your customers? When I think of these types of questions, it makes me very happy to be on a consulting development team. Sometimes I think I take the close relationships we have with our customers for granted. After this conversation with my friend, I think I'll value the collaborative nature of our relationship with our customers a whole lot more.

Permalink