Saturday, May 30th, 2009
Good practices at work
A couple weeks ago I talked about a new approach we're taking at work where we prepare but we don't plan. This week we seriously benefited from the strategy and I want to spend some time going over what we did right, what we did wrong, and what I learned from it.
So here's the situation. We recently released an CRM (Customer Relationship Manager) that our resellers can use to manage all the contacts for their entire organization. When coming up with the structure, there was a question about how we should handle group permissions.
For example, maybe an insurance agency has some people selling HRAs and other people selling insurance. How should the agency control which contacts different people can see and how people can interact with these contacts? Or maybe an agency has branches in two different states and sales leads should be confined to only the appropriate branch. Suffice to say, there are a lot of different ways people might choose to use a CRM and we needed to support as many of them as possible.
About a week of the initial CRM development was spent planning and implementing this permission structure. Near the end of that week it became obvious that we just didn't know enough about how the product would be used to make some of the more important decisions. We ended up throwing together a pretty simple set of features and releasing it.
So to summarize, we released the CRM without really knowing how group permissions should work. The product was functional but a piece of it was missing.
We've now had two weeks to observe how our clients are using this system and now we feel completely comfortable making the design decision that we previously were unable to make. It's unfortunate that our new plan makes the week we already spent on this completely wasted, but that makes our decision to wait on this particular feature all the more valuable.
If we had made assumptions about what we needed, we would have been backing ourselves into a corner and the resulting product would have been crippled for months or years because of it. By waiting to make any definite plans, we allowed ourselves a couple of weeks to observe our users which in turn gave us real actionable information instead of baseless assumptions. So sure we wasted a week, but overall the process worked.
There's one important thing that I took away from this beyond an overall sense of satisfaction. In the future, I should try to be more aware of which early decisions are based off real, solid information and which ones are wild guesses. I might not always have enough information, but I can at least be more aware of what information I don't have. Posted by Tyler King
This post has 2 Comments CRM police
May 31, 2009 at 07:26 am
Good idea - but were you able to calculate the potential costs of your users being upset about not having the correct access OR when you change, that they have to get used to a new approach? Think 'change management' man May 31, 2009 at 09:45 am
Good question. It turns out that this feature in particular is almost entirely back-end. I would guess that exactly zero of our users will realize that this feature wasn't fully developed initially. Also, I think that worrying about change like you're suggesting is becoming a thing of the past. People are getting used to the beta culture of software these days. Our users may have to learn to use new features regularly, but they much prefer that over not getting the new features at all or having to wait 6 months for a massive release. "Deploy early and deploy often" |
More about me:
My friends:
Sites that I really like:
Paul Graham Essays
Academic Earth Mint.com Lifehacker The Consumerist Deadspin Turf Show Times Failblog Get Rich Slowly |
|
Blog |
Portfolio |
Resume |
Bio |
Contact |