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.

Customer Connected Engineering (CCE) at patterns & practices

Customer Connected Engineering (CCE) is a collection of practices for engaging customers during the planning, development, and release of code and narrative guidance. Instead of simply collecting customer requirements up front, or getting feedback after the fact, it’s continuous involvement of customers throughout our life cycle. By involving our customers in the process, we improve transparency and increase the probability of shipping what’s most valuable to our customers. By partnering with customers, we improve our ability to understand end to end scenarios as well as priorities. By shortening the cycles of feedback we also improve our ability to learn, to reflect, and to adapt our deliverables as we clarify the wants and needs of our customers.

At patterns & practices, our approach is optimized towards external and largely unknown customers. Internal projects with identifiable stakeholders can also use CCE, but it will take a different form.


At patterns & practices, we use an approach we call Customer Connected Engineering (CCE). As the name implies, we engage with customers throughout the project. Our customers help us ship better software and deliverables that meet their needs. At the heart of customer connected engineering is a customer advisory board. The advisory board is a set of customers that helps influence what we build. The customer advisory board helps identify scenarios, prioritize the scenarios, comment on designs, test early preview bits, and give timely feedback during planning and development.

In addition to the advisory board, we have an open community that allows for any community member involvement. After the initial phases of some weeks, we will typically start releasing code and guidance “drops” in the community. The community is also the place, where we provide the main support of a deliverable during the development and after it is released. Internally we ensure the alignment with the product directions with a set of technology stakeholders, typically from the product groups that provide and own the platform technologies. In agile projects, the assumption is that you have the end-customer or proxies being engaged in the development. CCE ensures customer participation in a group inside Microsoft, like patterns & practices that has have many end customers as the target.

Customer Connected Engineering Overlay

We use a combination of XP / Scrum for executing projects at patterns & practices. So if you’re doing XP/Scrum most of this isn’t new. The following diagram is an overlay of customer-connected activities on top of our development process:


The activities on the left-side of the diagram below are core activities in our patterns & practices projects. On the right hand-side are customer-connected activities. Here is a brief description of each of the activities:

  • Customer Advisory Board. The Customer Advisory Board is a group of customers that act as a sounding board for the project. This is a smaller set of customers that act as a proxy for the rest of our customer base. We build a Customer Advisory Board to help us stay on track with customer demand in an agile way (see Customer Advisory Board section below).
  • Stories / Scenarios. Customers share stories and scenarios. Stories and scenarios are narratives that capture and share usage scenarios for your product. The scenarios help show requirements in context.
  • Backlog Prioritization. Customers help prioritize by providing input for the product backlog, the sprint backlogs and iteration planning sessions. The advisory board provides their prioritization ongoing. For some projects, we open up a survey to the broader community to help with prioritization in the earlier phases before Vision / Scope.
  • Frequent Delivery. Unless you deliver frequently you’re asking for feedback on what? We deliver frequently to the Customer Advisory Board to give them something concrete to provide feedback on and also to give broad visibility (outside of the Customer Advisory Board). This means being able to ship high quality code (or wireframe prototypes, chapter drafts for written guidance) every iteration. Always being “done”.
  • Feedback. Customers provide feedback during each iteration and for release. What’s important is that it’s earlier instead of later. It helps us course correct midstream instead of miss the mark at the end of the project.

Some of the things in the CCE column most people would say are Scrum/XP include: Stories/Scenarios, Prioritization, Demos, Drops, and Feedback. The thing we do – that Scrum/XP do not cover is include some practices which help a Product Owner gather feedback from a user community and aggregate that for the development team: The Customer Advisory Board, CodePlex forums, Advisory board selection and calls.

Why Customer Connected Engineering

Shipping the wrong thing is expensive. Customer Connected Engineering when done properly provides more benefits than tax. Some of the benefits include:

  • Customers help you identify relevant scenarios.
  • Customers help you verify, prioritize, rationalize and refine the scenarios.
  • Customers evaluate and provide feedback of your deliverables against the scenarios.
  • Customers better understand your trade-offs and have more visibility into your process. This builds trust and increases probability for adoption and usage.
  • Customer become your greatest evangelists.

The benefits of Customer Connected Engineering largely depend on both how engaged your Customer Advisory Board is and how representative they are of your target customer base.

Guiding Principles

One of the ways to successfully adopt a practice is to focus on the principles. The principles help you avoid getting stuck on implementation details. Implementation will vary from project to project, but the core concepts will stay the same. Here are some principles we’ve found to improve Customer Connected Engineering:

  • Set the frame. A frame is how you look at things. We use a frame to anchor discussions, and create something that people can react to. The more thoughtful the frame, the higher the quality feedback we get. We create the frame by figuring out the customers, their needs, and the business goals. We use the frame to help focus feedback and dialogue. For example, one frame could be an architectural overview. Another frame can be your product backlog. Our most common approach is to use stories and themes.
  • Shared problems. The customers we select for the Customer Advisory Board need to have first-hand experience with the problem. They need to care and be involved in the solution.
  • Have an opinion. Our opinion is one piece of the pie. We need to balance among the economics, the customer scenario, the product direction, the product team, the field, support, and community experts. We also need to balance generalizing a solution for more reach against contextualizing a problem so it’s specific enough to be useful. Without an opinion, we would get randomized. We have an opinion so we can rationalize the feedback and priorities from various customers and perspectives. Each customer will be coming from different perspectives. It’s your job to frame the feedback and understand the perspectives. We also need to know our own assumptions. When people challenge our assumptions, we understand why we are changing our opinion. For example, we might have an idea on a user experience. Our customers then provide their reaction, which leads us to revisit our design.
  • Synthesize the feedback. Here we step back and look across the scenarios and requirements. We look for common denominators. We prioritize across our highest ROI items.
  • Scenarios are King. Scenarios are the backbone of Customer Connected Engineering. The end-to-end scenarios are one of our most important outcomes. It’s one thing to look at a list of scenarios in a document. It’s another to walk through the stories and scenarios with our customers. Our customers can share their goals and their stories in detail. We suggest having a set of straw man scenarios, before you engage with the advisory board.
  • Transparency. Transparency is letting our customers see inside our process to understand how we do things and how they work. It’s sharing our decision making approach so that customers understand how we make trade-offs. It’s also about sharing design goals as we know them. It’s also about making our customers aware of important changes along the way, instead of at the very end when we ship. It’s opening up the door to the workshop and letting customers watch and participate as we build our deliverables. When they understand why we made a decision or tradeoff, we are more likely to have a satisfied customer, even if they disagreed with a specific decision.
  • Incremental value. This is about finding a way to flow value. As the project progresses, customers should get a sense that we are delivering value along the way.
  • Fail early, fail often. We share releases with our customers so they can share feedback. We don’t want to be surprised when we’re ready to ship. We share early and share often. We use the feedback to improve.
  • Timely feedback. One of our biggest benefits of Customer Connected Engineering is the timely feedback we receive.
  • Stay flexible. We stay responsive to feedback. Acting on the feedback shows our customers that we value their input and that it makes a difference. The more they see the impact, the more they engage.
  • Real world solutions. When we have a working implementation, we have a significant starting point. We try to find working examples of specific customer solutions that solve some of the same scenarios and challenges we’re facing. For example, to speed up our success, rather than chase our competition, we look to working solutions.

Customer Advisory Board

When we create our Customer Advisory Board, we want to be selective. The customers we choose need to have deep insight into the problems we’re working on. We search for people that are respected in the community both for their understanding of the technology and building real-world solutions. We focus on customers that are trying to solve the same challenges. We look for customers that have a serious interest in leveraging what we develop or learning from it. We want customers that are “early adopters” and still representative of our main target customer base. Customers that just want to track how we’re doing aren’t going to help. We need customers that will actually run alongside us, taking our work applying it, so we get specific feedback. We want customers who are not shy to push back, to scrutinize our backlog and criticize our direction and execution.


We build a board that is representative of our target audience including various customer types:

  • Key contributors – We consider engaging key contributors, if we have found a reference solution that addresses some of the core challenges.
  • System integrators – We consider leveraging system integrators, which can be aggregators of requirements reflecting multiple customers. We verify that they are still representative of the main stream.
  • ISVs – We consider leveraging partner ISVs that may address extensions compared to our main stream customers.
  • MVPs – We consider engaging MVPs as another source. Often they are early adopters themselves and work with early adopter customers.
  • Customers themselves – large, small, and medium.

Stories / Scenarios

A lot of software projects fail because they miss the scenarios. It’s one thing to imagine or dream up scenarios, it’s another to get them directly from customers and to get them properly articulated in an unambiguous way. A lot of working features don’t necessarily aggregate up into working scenarios, or even the right scenarios. The value of our deliverable can be measured by the problems it solves. Ultimately, we can evaluate our deliverable against actual usage scenarios.


There’s a lot of opportunities for our Customer Advisory Board to help us prioritize and make trade-offs throughout the project. For example, we get input when we prioritize our product backlog. We also want input when we prioritize our iteration backlog. We also want customer input when we prioritize stories during iteration planning.

We make it obvious that we have fixed deadlines and limited resources, which means our main variable is scope. This often helps encourage the board members to engage more actively, because it gives them a clear sense the impact of their feedback.

In Summary

  • Customer Connected Engineering (CCE) is a collection of practices for engaging customers during the planning, development, and release of code and narrative guidance.
  • Customers help ship better deliverables that meet their needs by providing input and feedback throughout the project.
  • Customer-Connection Engineering activities can overlay on top of existing project activities.
  • The Customer Advisory Board is a key part of Customer-Connected Engineering.
    An effective Customer Advisory Board includes customers that have deep insight into the problems that the project is focused on.
  • Customers help provide the scenarios that guide the work.
  • Customers help prioritize the work.


I’d like to thank the following people for their review and contributions:

Ade Miller, Blaine Wastell, Bob Brumfield, Chris Tavares, Don Smith, Eduardo Jezierski, Erwin van der Valk, Eugenio Pace, Francis Cheung, Grigori Melnik, Javed Sikander, John deVadoss, Michael Puleio, Per Vonge Nielsen, Tom Hollander

My Related Posts



This is a simple frame for testing your vision, your pitch for a project, or your proposed solution.  One of my mentors uses it all the time to test the thinking and to make sure the team stays on track.  I’ve adopted because it’s a great way to stay focused on the basics.  Don’t let the basics get in the way of great results.

The frame is pretty simple to use.  You simply walk the categories and ask questions to explore the thinking:

  1.  Who is the customer?
  2. What’s the problem?
  3.  What’s the competition?
  4.  What does success look like?

Here’s how they help:

  1. Know your customer.  Your customer is a strategic decision.  Asking who the customer is, forces you to decide who’s in and who’s out.  This helps you figure out what’s relevant and what is not.  This helps you build empathy for relevant customer problems, once you know who your customer really is.  This helps you determine whether there is a market and whether you will be relevant to your customer.  It also helps you identify your ultimate test bed.  If your customers aren’t happy, you missed the boat.
  2. Don’t be a solution looking for a problem.  Asking what’s the problem forces you to ask whether you are focusing on the right problem.  Is it really a problem?  Do your customers think so?  Is this the next best thing to work on?  Are you playing to your strengths?  Knowing the problem can also help you build customer empathy.
  3. Know what the competition is doing.  You should know what’s been done, and you should be clear on your differentiation.  Are you competing on the problem, the approach, or the implementation?
  4. Know what success looks like.  Asking what does success looks like, forces you to figure out your tests for success.  In this case, I’ve found it helpful to both be able to draw your vision, and to know the key measures that you can evaluate.  The sooner you can draw your vision, the earlier you can beat up the idea to make it better, as well as get people on board.  When you figure out what to measure, it’s important to consider who the opinion leaders are, who the key stakeholders are, and who your key customers are.  Chances are, the tests for success can be very different, especially if your stakeholders lack customer empathy.

It’s a simple frame, but it can help keep you focused on the right things.

Photo by BruceTurner.


EricBrechner Editor’s note: This is a guest post from Eric Brechner. Eric is author of the book, and blog, I.M. Wright’s “Hard Code.”  At Microsoft, Eric is Director of Development Excellence on the Engineering Excellence team.  His group is responsible for improving the people, process, and practices of software development across Microsoft.  Eric has more than 20 years of experience in the software space, including a tour of duty on the Microsoft Office team.

When I first met Eric, several years ago, he struck me as somebody with opinions and insight.  Time and again he impressed me with his words of wisdom and his perspective on everything from software to career and to life.  He always has a good answer to the tough problems, and never fails to make me think.

Without further ado, here’s Eric on his Lessons in Software … 

Rather than focus on software engineering and craft, I’d like to concentrate on admirable attributes of software developers as human beings. These are attributes of people I like to work for, work with, and have working for me.
The attributes fall into two categories—strength and balance. Strength attributes form the foundation of someone’s being. Balance attributes characterize how someone deals with opposing ideals. Clearly, this is going to be a philosophical discussion. Thankfully, it’s also going to be short.
I chose three strength and three balance attributes. I like working with a diverse set of people, so I narrowed these admirable attributes to just the fundamental set that yields an interesting individual I respect.
Strength attributes:

  • Insightful. Smarts alone don’t cut it. There are plenty of smart people. It’s insight that changes the game. Insight drives the breakthrough. Insight directs the decision. Some people focus on getting the answer. That’s boring—there are lots of answers. Great people focus on understanding the problem—the customer, the scenario, the competition, the partners, and their situation. Great people are insightful. I love working with insightful people.
  • Reflective. Being reflective is necessary to being insightful. Reflective people are curious and seek understanding, both of the problem and of themselves. They feel driven to constantly improve every aspect of who they are and what they do. Reflective people also tend to be self-deprecating and have a broad sense of humor. I delight in working with reflective people.
  • Principled. “Whatever,” is something you rarely hear from a person of principle. Principled people do things for a reason. They have integrity, almost by definition. While I may not agree with the principles of a colleague, I respect him or her. You can trust people of principle to stay true to their beliefs and follow through, whatever the pressure or circumstances. I depend upon principled people.

Balance attributes:

  •  Serving and advocating. You must serve your customers, your team, your management, and your company. It’s not about you, it’s about the customer and the business. However, if you are purely selfless, your career and your ideas will go nowhere. You must advocate for yourself and your innovative ideas. Balancing these two demands in a way that promotes your contributions yet is never about you is challenging for most people. Great people serve and advocate with dignity and grace.
  • Execution and slack. You must execute on projects and deliver on commitments. Great ideas are nothing if they never reach the hands of our customers. However, if you are purely tactical without thoughtful strategy, planning, and design, you will make critical mistakes, burn out yourself and your team, and deliver products and services that lack quality, value, and emotional connection. Balancing execution and slack time continues to be one of the great challenges of software development. Great people clearly prioritize their work, commit to difficult but achievable well-defined goals, and jealously protect their slack time.
  • Trust and risk. You must trust your coworkers and staff. You can’t accomplish anything truly impactful alone. However, if you rely on others to help, there is always the possibility that they may misunderstand your instructions and intent or be unable to produce the results you require on time, regardless of what controls and processes you put in place. Balancing trust and risk is the subject of countless management books and theories. Great people care deeply about their coworkers and staff, develop strong trust relationships with integrity and transparency, and rely upon those relationships to inform and adjust an acceptable level of risk.

If these attributes were easy to embody, the world would be a different place. It takes commitment and courage to be insightful, reflective, and principled. It takes thoughtful and unending vigilance to delicately maintain the balance of serving and advocating, execution and slack, and trust and risk.
The right balance at the beginning of a project is often quite different from the appropriate balance at the end. People challenge your principles, doubt your insights, and question your faith in yourself and your team. You must be strong and believe in yourself, yet balanced and dedicated to those you serve. It’s not easy, and that is why I admire people who embody these attributes.

Additional Resources



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.

I’ve been a part of the team since 2001.   Along the way, I’ve seen a lot of changes as our people, our processes, and our catalog of products have changed over time.  Recently, I took a step back to collect and reflect our best practices.  Some practices were more effective than others, and we’ve lost some along the way.  To help reflect and analyze the best practices, I created a map of the key practices organized by discipline.  In this post, I’ll share the map (note that it’s a work in progress.)  Special thanks to Ed Jezierski, Michael Kropp, Per Vonge Nielsen, Shaun Hayes, and Tom Hollander (all former patterns & practices team members) for their contributions and insights to the map.

Best Practices by Discipline
The following table is a map of the key practices used by the patterns & practices team over the years.

Discipline Key Practices
Management Team
  • Milestone Reviews
  • Product Portfolio (correlated with customer & business challenges/opportunities)
  • Team development  (leadership skills, communication skills, … etc.)
  • Backlog
  • Connection with customers and partners
  • Fireside chats
  • Meeting with key stakeholders in the app plat space
  • People review
  • Scorecard management
  • Tracking overall team budget
  • Weekly Status
  • Articulate the inner (scope) and outer (context) architecture (these involve time)
  • Articulate technical principles – drive technical tradeoffs discussions
  • Be aware of roadmaps of the company, and build trust to make sure they are current
  • Be familiar with competitive tech.
  • Customer connection.
  • Groups’ technical strategy and product model.
  • Know actionable industry trends.
  • Overall design with functional breakdown.
  • Relationship with key influencers in the product groups.
  • Spikes / explorations including new approaches (technology and process)
  • Technical challenges
Development Team
  • Ship running code / guidance at the end of each iteration
  • User Stories
  • XP / Scrum with test-driven-development
  • Continuous build and integration
  • Iterations
  • Retrospectives
Product Management
  • Asset Model
  • Customer Surveys (feature voting, exit polls)
  • Standardized product model (app blocks, factories, guides, etc.)
  • Blogging throughout project (planning, development, release)
  • Case Studies
  • Community Lead
  • Customer Advisory Board
  • Customer Proof Points
  • Own Vision / Scope
  • Portfolio Planning
  • Project dashboard
Program Management
  • 5 customers stand behind it
  • AAD Sessions (Accelerated Analysis and Design)
  • Backlog
  • Exec Sponsor
  • Product owner from M0
  • Quality over scope.
  • Scorecards
Release Checklist
  • Release Checklist
  • Release Mail
Test Team
  • Automated tests
  • Focused on overall quality (functionality is tested by dev)
User Experience Team
  • Authoring Guide
  • Content Spec (Content scenarios and outline)
  • Doc Tool (Template for standardizing content formatting)

Some practices are obvious, while some of the names of the practices might not be.  For example, “Fireside chat” is the name of our monthly team meeting, which is an informal gathering and open dialogue.   I may drill into some of these practices in future posts, if there’s interest and there are key insights to share.



My recent road trip was a great reminder how quality is durable.  As I passed through familiar territory, it was interesting to see how many building and places stood the test of time.  Whether it was a business or a building, it was quality that survived in the long run.  Some of the restaurants I remembered were gone.  Every restaurant I remembered that was high quality, was still around.

Competing on Price Fails in the Long Run
Competing on price failed, time and again.  There was no customer loyalty when it was the price play.  There was no compelling distinction beyond price.  Chasing the price play, meant getting priced out of market by somebody better or cheaper or you name it.  There are only so many corners you can cut before your value is insignificant.  On the other hand, the quality play is focused on differentiation and distinction in terms of value.  In a globabl market, where cycles of change are faster, competing on price is a game I just don’t want to play in.

Do You Stand Behind Your Work?
One of my most important tests, and it’s a simple gut check, is, do you stand behind your work?  It’s a cutting question.  When your results are something you’re proud of, and quality is your game, and continuous improvement is your way, and excellence is your bar … you set yourself up for success.  When you can put yourself into your work, the journey becomes as enjoyable, if not more so, than the destination.

In times of change and uncertainty, driving from quality is a guiding principle that helps us find our path.

Photo by Cornell University Library.