patterns & practices

patterns & practices

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.

The Microsoft patterns & practices team has been around since 2000. The patterns & practices team builds prescriptive guidance for customers building applications on the Microsoft platform. The primary mission is customer success on the platform. As part of that mission, patterns & practices delivers guidance in the form of reusable libraries, in-tool experiences, patterns, and guides. To put it another way, we deliver code-based and content-based guidance.

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.

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.