This post is a write up of how we do Customer-Connected Engineering on the Microsoft patterns & practices team. Our Customer-Connected Engineering process has been a key part of our success and impact in the software industry. While this write up is about how patterns & practices implements Customer Connected Engineering, you might find that you can tailor and adapt some of the principles for your scenario or context.
I've been a part of the Microsoft patterns & practices team for several years. I've shipped a lot of things and learned a lot...
I think of a persona as a specific (yet generalized) instance of a role to "personify" and represent what users that play that role, might be like. While we originally argued over the details of the personas, a great by-product was that we focused on the distinctions across our various customer sets. This helped reduce ambiguity during product design. It also helped us make calls on where to put our resources and effort.
On the Microsoft patterns & practices team, we use Vision / Scope as a key milestone. It’s where we frame the problem, identify the business opportunity, and paint a vision of the solution. It’s a forcing function to get clarity on the customer, their scenarios, and our scope for the project. We generally use a “fix time, flex scope” pattern, so this means having a candidate backlog that we prioritize with customers.
Customer Connected Engineering (CCE) is a practices we use across our patterns & practices teams for engaging customers throughout the life cycle. We involved customers during the planning, development, and release of our deliverables. This is a draft slide set that shares how we do Customer Connected Engineering inside patterns & practices, including our key practices and guiding principles.
12Page 1 of 2