« Introductions - or, who is this guy and why is he blogging? | Main | Too strange ... »
June 11, 2006
Customers and users
One aim of this blog will be to discuss choices facing designers of data integration software. It's easy to talk about "knowing the customer" when developing a product, and naturally every designer works hard to do this. Nevertheless, now and then I find myself refocusing on an aspect of our market position that is easy to overlook - the distinction between users and customers. This week, prompted by various happenstances, I have been doing just that.
The distinction can be summarized simply enough. Customers are those who make purchasing decisions about which software their enterprise will use: users work with the software to implement solutions. In many cases these may be the same people, acting in different roles from day to day. In other circumstances - in many, I would hope - users have huge influence in purchasing decisions. Nevertheless, there are numerous enterprises where decisions are made top-down and users just have to get on with it: and, of course, outsourcing is an increasing trend where the user may well have little or no say in the choice of toolset.
As product designers we therefore face two issues: we must appeal to customers in order to be selected as the tool or platform of choice, and we must meet the needs of users to make that choice work. Let's start with users, and in another post I'll cover how we address our customers.
Here at Microsoft, the development teams are encouraged to engage very directly with our community of users, partly through online forums where the public can post any issue for us to help out with. I was applying some business intelligence to the forum usage statistics, in particular to analyze activity on our Integration Services forum. That was quite an eye-opener. We had almost 1000 active members in the last financial quarter, and almost 10000 posts. At around 100 posts a day, that places us among the most active forums at Microsoft, coming in just after programming languages such as C#. That's pretty remarkable for a data integration application and it tells me two things, at least.
First of all, and simply, we clearly have a lot of users out there, actively exercising the product and asking questions. Scaling design issues to cover such large numbers is a unique, and stimulating, aspect of designing products at MS. It is also difficult, because it requires great depth of focus - on the needs, and feedback, of individual users, while also addressing the general case of thousands of slightly differing scenarios.
For example, we released a little shared-source metadata toolkit to the web. Within a week it had around 1000 downloads. The program manager was delighted to see 10x more instances of his work in the wild in one week than he had seen at his previous company in years. But our unit manager put it in context. Her background was working on the WebData data access stack for Microsoft, where she saw 1000 downloads per day for new releases. Working at that scale - well, it's a different world.
Secondofly (love that word!), we should consider who these thousands of users are. That's not too difficult to work out - they are by and large developers, active in the same fields as the C# or VisualBasic developers whose forums we most resemble. The market segment we see reflected in our online community is a demand for data integration as a general developer activity. Not data integration for Business Intelligence specifically (although we are being successful there too) but data integration as something that everyone who works with data has to do. This makes a lot of sense - we all have a ton of data, but it is rarely in the format, or of the quality, or as integrated with other relevant data, as we would like. We talk often of BI for the masses. Well, this is data integration for the masses, and it is clear that the masses need it.
In fact, Colin White's detailed report on data integration for TDWI showed that custom coding is still a most significant solution to data integration problems. Living as we do, at the confluence of hand-coded development and code-free applications, this is fertile ground for us.
In another post, I'll write about customers and the demands they make of us - and how we strive to resolve those with the demands of users. Meanwhile, I would be delighted to red any comments you may have on the distinction I have been making here - in my experience, It's a somewhat neglected area.
Posted by Donald Farmer at June 11, 2006 2:45 PM
Twitter 
LinkedIn 
YouTube