I’m one of the newer program managers (PM’s) here on the Microsoft Dynamics CRM team, and this is my first post to the CRM team blog. I hope you enjoy it. Since the features I’ve been working aren’t publicly available yet, I thought I’d write about the process of designing features instead. To me, this process has been a real eye-opener in many ways, so perhaps my experience will be insightful to others. Often, it is tempting to think that building a feature is as simple as coming up with a vision that will instantly materialize.
However, this isn’t the case; far from it. The process of building features is much more intricate than that, and involves several different parties at different stages in time. From what I’ve seen, one of the main responsibilities of a PM is to bring all of these warring factions to consensus so that the feature can move forward to completion. Here’s a brief overview of the many aspects that ultimately affect a feature; they are in no particular order. This list is by no means definitive or even exhaustive, but merely my own impressions.
Product Planners determine at a high level which direction CRM is going to take. These decisions affect many of our day-to-day operations, but they are usually more pertinent to long-term targets such as milestones, release cycles, community and partner beta programs, and so forth.
Marketing keeps us competitive in the marketplace by defining a feature set that is ahead of that of our competitors. We as PMs work together with Marketing to identify opportunities to make CRM better and more attractive to customers. These opportunities often turn into feature ideas, but the reverse is also true: a great, original feature idea can turn into a marketing advantage.
Typically, it is the role the PM to propose a design, or a set of designs, that ‘solves a problem,’ or that eases a customer pain point, or innovates in one way or another. In doing so, the feature also gains CRM a competitive advantage.
Dev will ultimately code the feature, so it is very important for a PM to get their feedback early on about its technical soundness, about how much it will ‘cost’ (in terms of time), and about the feasibility of its individual components.
Test is in charge of ensuring the high quality of CRM software. Features must be tested meticulously and extensively before they arrive at our end-users’ proverbial doorsteps. Therefore, features must be testable so that they can be reliable, and a good design must explicitly call this out. Our current strategy in CRM is based around Scenario Based Testing, in addition to component-based testing tactics such as Scorecards, testable units (TU’s), test suites and build verification tests (BVT’s).
Depending on the type of feature, legal might have to be involved, usually to clear licensing terms, to tweak specific wording in certain dialogs or controls, or simply to rule out things that must be avoided. Our legal department is very technically knowledgeable, so it is fairly painless to explain the details of features to them.
Security has become one of Microsoft’s utmost concerns when building and shipping software. Suitably, features here in CRM undergo rigorous analysis in the form of threat-modeling and code reviews before they are even accepted.
Privacy, along with security, is taken very seriously at MS. Here in CRM, for instance, every single feature must clearly define its implications on users’ privacy, and then attentively address and mitigate their impact. As a PM, my objective is always to minimize, if not eliminate, the use or transfer of personal information.
CRM is deployed in many of our own data centers, which are managed by Operations. Hence, features must not clash with the strict Op’s data center policies; otherwise they might be blocked, or turned off internally. Designs must take into consideration how Op’s will use and deploy a feature so that such things do not happen.
Microsoft Dynamics values the name of its products very much, and CRM is no exception. All of our components adhere to the guidelines put forth by our branding department. The goals behind this strategy are clear: to minimize user confusion, to maintain consistency, and to make CRM stronger in the marketplace.
UE is one of the primary forces pushing the interests of our users. Our UE experts make sure that the feature teams look at CRM from the user’s perspective. In addition, UE is tasked with understanding a feature so that it can be properly documented, and with carefully verifying that all of the text used is consistent as well as helpful to the user.
If the feature surfaces any sort of UI to the customer, then there’s a good chance our interface designers and researchers have reviewed it. We even have PhD’s on board to conduct usage studies. UX not only defines the look of the UI to be aesthetically pleasing, but also helps keep its mechanics simple and intuitive. In turn, this prevents the UI from breaking user expectations.
CRM has a vibrant community of users, partners, integrators, Microsoft Most Valuable professionals (MVPs) and vendors who serve as a great resource to the team. The community can be seen and heard in many ways: blogs, newsgroups, presentations, discussion lists, conferences and site visits. Interacting with the community is a great way to gather feedback, validate or discount ideas, or just to hear a fresh point of view.
SE will inherit, so to speak, all our features, once they have shipped. It is thus imperative to get their advice about how to make the transition as smooth as possible, and to incorporate it into the design. Failure to heed this advice will result in higher costs for us, and a poorer experience for our users.
Center of Excellence
The CRM COE is a very intriguing organization. Its goal is actually to evangelize our product internally, at Microsoft. They are the keystone in our quest to “eat our own dog food,” and have helped deliver several wildly diverse implementations of CRM across different Microsoft teams. It is very useful to observe how the COE implements CRM to get a good sense of what is working and what isn’t.
We actually give a lot of thought to this aspect of feature design in CRM, and I think the result is very much appreciated by our customers. In brief, all features surfaced to the user must be accessible by default. This means, for instance, that they must work properly with screen readers. For native applications, features must include shortcut keys for all menus, actions, buttons and options. For the web, features must also use correct, semantic, HTML tags, must not omit important, informative attributes such as ALT, and many other things.
One of the benefits of working at Microsoft is that the company and its products have worldwide impact. This benefit is not without cost, however. Features must be reviewed by CRM localization teams to guarantee that they will work across all of our international releases – in short, to make sure that they can be made truly ‘global.’
I hope this gives you a broad view of all the kinds of things we do here in CRM, behind the scenes, to design and build features into our great product; it’s very interesting stuff! Please feel free to send me your comments, questions and suggestions.