Customer Connected Engineering


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.

Download the Draft
You can download the slides (38 slides) as a PDF:

Key Activities
The following is a visual overlay of key Customer Connected Engineering practices on top of our existing product life cycle in patterns & practices: 


Here’s a summary of the key activities in Customer Connected Engineering:

  • Customer Advisory Board.  The Customer Advisory Board is a set of customers that act as a sounding board for the project.
  • 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.
  • Prioritization. Customers help prioritize by providing input for the product backlog, the sprint backlogs and iteration planning sessions.
  • Feedback. Customers provide feedback during iterations and for release.

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.  You need to frame the discussion and create something that people can react to.  The more thoughtful the frame, the higher the quality feedback you get.  You create the frame by figuring out the customers, their needs, and the business goals.  You 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.
  • Shared problems.    The customers you 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.  Without an opinion, you’ll get randomized.  Have an opinion so you can rationalize the feedback and priorities from various customers.  Each customer will be coming from different perspectives.  It’s your job to frame the feedback and understand the perspectives.   You should also know your own assumptions.  When people challenge your assumptions, you understand why you are changing your opinion.  For example, you might have an idea on a user experience.  Your customers then provide their reaction, which leads to you revising your design.
  • Synthesize the feedback.  Step back and look across the scenarios and requirements.   Look for common denominators.  Prioritize across your highest ROI items.
  • Scenarios are King.  Scenarios are the backbone of Customer Connected Engineering.  The end-to-end scenarios are one of the most important outcomes.  It’s one thing to look at a list of scenarios in a document.  It’s another to walk through stories and scenarios with customers.  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 customers see inside your process to understand how things work.  It’s sharing your decision making approach so that customers understand how trade-offs are made.  It’s also about sharing design goals as you know them.  It’s also about making customers aware of important changes along the way, instead of at the very end when you ship.  It’s opening up the door to the workshop and letting customers watch and participate as you build your deliverables. When they understand why you made a decision / tradeoff, you are more likely to have a satisfied customer, even if they disagreed with a specific decision.
  • Incremental value.   Find a way to flow value.  As the project progresses, customers should get a sense that you are delivering value along the way.
  • Fail early, fail often.  Share releases with your customers so they can share feedback.  You don’t want to be surprised when you’re ready to ship.  Share early and share often.  Use the feedback to improve.
  • Timely feedback.  A big benefit of Customer Connected Engineering is timely feedback.  
  • Stay flexible.   Be responsive to feedback.  Acting on feedback will show customers you value their input and that it makes a difference.  The more they see the impact, the more they’ll engage.
  • Real world solutions.  If you have a working implementation, you have a significant starting point. Where you can, find examples of specific customer solutions that solve some of the same scenarios and challenge you are facing.   For example, to speed up your success, rather than chase your competition, you can look to working solutions.

Got feedback?  Since this draft of Customer Connected Engineering is a work in progress, please share your stories, questions or thoughts in the comments below.


  1. Everyone’s immediate response should be one of the following.
    a. “hell yeah”
    b. “amen”
    c. “duh!” – my personal favorite
    d. All of the above

    At its essence this is saying “you have to ask customers what is valuable to them”. (you can add your own ‘duh’ here).

    I’ve been a consultant for 16 years with over 30 customers. What I’ve seen and learned is that when any producer (software, hardware, books – anything consumer driven) runs off and builds without involving customers throughout the production life cycle their efforts typically fail miserably.

    Why would guidance or guidance frameworks be any different?

    The whole WORLD is focused on being able to deliver more value at a lower cost.

    I’m pretty sure that there’s a consensus that fixing problems earlier is easier and far cheaper than later.

    Involving the customer is how you do it.

    Doesn’t TQM, XP, agile and the plethora of project management knowledge all incorporate some level of identifying what the customer values? hell yeah

    I like how CCE formalizes the customer involvement. Everyone has a tendency to “self-valdiate” through intellection and minimize the need for human interaction (something about geek tendencies towards introversion). This manifests itself as “I know what’s important, I’ll just go ahead and create it and when people see it they’ll see that I’m smart and wonderful”. The road to ruin.

    We see this most evident in perf and scale. People spend massive amounts of time focused on thinking about what might be the problem and never test/measure. This is the exact same issue.

    CCE uses customers to test and measure the effectiveness of your product early and often.


  2. Thank you

    Your contribution to the community with the variety of topics are extremely valuable and you provide such a refreshing sense of direction among complex chaos.

    Keep up the good work, I am sure I speak for many when I say that you are an incredible human being.


  3. @ Andy

    Good stuff. I like your precision around “self validate.”

    I agree that projects fail when there’s not enough customer connection. Too many unchecked assumptions stretched over too long is a recipe for failure.

    That’s a great way to summarize it – “CCE uses customers to test and measure the effectiveness of your product early and often.”

    @ Henk

    Thank you. I’m a fan of standing on the shoulder’s of giants and lifting others up.

  4. Hi folks,

    This thread centers on a pet peeve – that people invest tons of time, money and hope in projects which fail because what they (the inventor) believe is the golden future is not recognised as such by the market.
    The surest way to get quality feedback is to try and sell the product. If you ask someone, ‘Do you want one?’, you’ll quickly know what’s great and what stinks.

    My article on this topic, with example: – A classic inventor’s mistake

Comments are closed.