Blogs

In my previous posts, I’ve talked a lot about how E2.0 has less to do with technology than with people, that it’s really about enabling more effective people-to-people relationships, not simply implementing new technology.

I think this is an important point to make because in my travels, I see most organizations still treating E2.0 as a technology domain rather than an organizational capability. They want to buy a tool or a platform to enable E2.0—as if the installation of software will somehow catalyze all the wonderful benefits E2.0 promises an organization.

In case you’re wondering, the installation of software by itself definitely won’t get you any closer to realizing the benefits of E2.0—and it might actually set you back a ways from being able to do so: the negative experience of a poorly executed rollout can sour users on E2.0 and make it very difficult to make things right down the road.

And while there’s lots of non-technology things you need to do to make E2.0 a success, one of them stands out:user segmentation analysis. This is a fancy way of saying know thy users; but since getting to know your users is notoriously difficult, I want to illustrate through one good way to structure the process of getting to know your users.

Who are your users?

At its heart, user segmentation analysis is about understanding who your users are, exactly. It should be a key part of any technology initiative, because ultimately you can’t deliver a suitable technology solution without knowing whose problem you’re trying to solve.

All organizations have at least a rough user segmentation in place already, e.g., knowledge workers versus process workers, home office versus field reps, shared services versus line of business—organizations typically have a variety of ways they conceptualize the different kinds of folks who work there.

User segmentation analysis begins from these existing categories of users and expands upon and deepens them, giving them more nuance, detail, and accuracy.

For example, the distinction between home office and field reps: are all field reps the same, or are there important differences between managers and line level reps? Are there a variety of roles within the home office that need to be considered (managers versus line level employees, functional area)? Are there any important similarities between home office and field reps that need to be kept in mind?

What do they do?

So far, you’ve got a list of user types relevant to the technology being implemented. But you can’t stop there, because now that you know who your users are, you need to determine what they’ll be doing with the new technology you’re planning to give them.

For those of you out there with an application development background, we’re really talking about identifying business level use cases, i.e., the scenarios or activities that each user type will engage in using the new technology.

In terms of the home office versus field reps example, for E2.0 capabilities, they might look something like this:

• User Type: Field Rep – Manager
  • Use Case 1: collaborating on performance reviews
  • Use Case 2: participating in projects as team member
  • Use Case 3: contributing to knowledge base
• User Type: Field Rep – Project Manager
  • Use Case 1: collaborating on group deliverables
  • Use Case 2: managing team projects
  • Use Case 3: accessing knowledge base

How are they going to do it?

At this point, you know who your users are for the technology you’re going to provide and you have an idea of what they’re going to do with it. All that remains now is to begin to sketch out how they’re going to do it.

This isn’t the place for detailed architecture and system-level design (these will happen during implementation), but rather for decisions about what capabilities will be required to support the use cases you’ve identified. And while you’re at it, you also need to determine what the division of labor’s going to be between the new technology you’re implementing and any existing technology.

The best way to link capabilities to use cases is to create a matrix that indicates what capabilities are required by each use case.

The final word

By the time you’re done with the user segmentation process, you have a great foundation for rolling out E2.0 capabilities in a way that meets the needs of your key users. You’ll also have the data points you need down the road to inform tough decisions about functionality tradeoffs and funding as well as to help socialize the organizational importance of the E2.0 capabilities you’re delivering—all of which increases the chances of success for your E2.0 initiatives.