Customer-Connected Engineering at patterns & practices

“If you don’t take care of your customer, your competitor will.” – Bob Hooey

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.

What is Customer-Connected Engineering

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 Customer-Connected Engineering, but it will take a different form.

Overview of Customer-Connected Engineering

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.

Customer-Connected Engineering ensures customer participation in a group inside Microsoft, like patterns & practices that has have many end customers as the target.

Customer Connected Engineering with Software Development Activities

We use a combination of eXtreme Programming (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.

Summary of Key Customer-Connected Engineering 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 in Customer-Connected Engineering

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.

Types of Customers for the Customer Advisory Board

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.

Prioritization

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.

Acknowledgements

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

You Might Also Like

Top 20 Best Software Engineering Books of All Time
Customer Connected Engineering Slides (PDF Download)
How To Effectively Pitch a Business Idea
Best Practices at patterns & practices
Lessons Learned in patterns & practices