ALIGN – Chapter 1 – The Power of Preparation


I created the Customer Advisory Board (CAB) program at Altera Corporation in 2001. It all started when my boss at the time, Robert Blake, complained that we seemed to be planning products by looking in the rear-view mirror. He wanted us to look into the future.

We agreed to our purpose straight away: to align our product roadmaps with key customers. We began by inviting these customers to meet with us face to face at our headquarters in San Jose, California. In these forums, we strove to learn what they were trying to do, with an eye toward developing products they would want to buy in the future.

Understanding what customers want is not an easy, nor obvious task. You can’t simply throw a few customers and product planners in a room and say, go! There’s more to it than simply asking, “Hey, customer, what do you want us to build for ya?” At least, that’s what we came to learn after a few initial rocky meetings.

Engaging directly with customers could be fraught with pitfalls. Unintended expectations could be set, sore topics mentioned, or one might alienate the very people one wants to understand by talking too damned much, pitching products, and failing to listen. No, simply throwing a group of people in a room and seeing what shakes out is a recipe for disaster. Even so, aligning with customers face to face is worth doing. It’s just that, to do it well, it requires planning, training and focus. Over a decade of running the CAB program, I learned many lessons the hard way. I’ve written many of them down in this book. My hope is that by sharing my experience, I can save you from such trials.

This book is intended to teach you how to not only side-step pitfalls, but to engage with customers in such a way so as to discover their insights that matter. In this book you’ll find:

  • Specific skills for face to face engagement with customers
  • How to cultivate an aligning mindset
  • Clear roles for each member of the uncovering team
  • Step by step recipes for running customer alignment meetings
  • Example scenarios inspired by real experiences
  • Tips for correcting counterproductive behavior

This book is derived from concepts and skills that proved to be effective for us in the CAB program. These concepts transformed us from a disparate group of individual amateurs to a team of professionals. I hope they can do the same for you.



The concepts, examples and strategies contained in this book are my own, even if inspired by my experience working at Altera Corporation. The advice herein in no way represents the actual processes or procedures followed by product developers and managers at Altera Corporation. For example, the specifically named ‘customer alignment’ or CA meeting was wholly created by Laura Reese, and is not a part of Altera Corporation processes.

Furthermore, the views expressed in this book are solely those of Laura Reese, and, unless otherwise noted, are in no way intended to represent the views, positions, or opinions – expressed or implied – of Altera Corporation or anyone else.

In this book, real people are referred to by their full names, including first and last names. All other people, who are referred to by only their first names, are fictitious. Any similarities to real people are coincidental and unintended.

I apologize in advance to anyone with the first name of Tom or Bob. In this book, Tom and Bob tend to not perform optimally.


The Power of Preparation

Arriving at work one morning, I was in an upbeat mood. A strategic customer alignment meeting with XYZ Corp was scheduled for ten o’clock. Everyone was ready, and every detail had been taken care of. We’d prepared for over a week, and today was the day.

An email marked ‘Urgent’ greeted me after I turned my computer on. It was from Nathan. I had a bad feeling about it. Nathan was my key attendee, and was our lynchpin Subject Matter Expert (SME). As I clicked on the email, I prayed, Please don’t cancel. Please don’t let me down.

Unfortunately, my fears were confirmed. “Laura, I’m sorry, I can’t attend the meeting today. There’s an accident on 17. Besides, I’m fighting a nasty head cold. I recommend Jacob as my replacement – he’s on cc. If he can’t make it, call me at home and I’ll help you find an alternate. – Nathan.”

This was disappointing. XYZ Corp was our company’s third largest customer, accounting for over 10% of revenue. The XYZ division joining us in an hour drove a healthy chunk of that business. They were industry leaders. As such, we were eager to align our product roadmap of FPGAs (Field Programmable Gate Arrays[1]) with them.

It had been radio silence from XYZ recently, but now they were sending four valuable employees: an in-the-trenches engineer, two influential engineering directors, and the CTO. Their strong lineup was hardly an expression of love for us, however. Rather, it was testimony to the fact that our products were critical to their success. The truth was, they weren’t our biggest fans at that moment. We’d burned them recently with a software update, which had set their schedule back by weeks, maybe months. The market they served was intensely competitive. Time to market meant everything, and we’d inadvertently compromised their plans. No, they were not happy with us.

Thankfully, the software issue had been resolved just in time for this alignment meeting. However, their wounds were still fresh. It wouldn’t be easy to get them to open up, and that was one reason why I needed Nathan’s presence. He was great with customers. If anyone could unlock customer information, it was him. For one thing, he brought technical credibility, and nothing keeps an engineer talking like an audience who understands what’s being said. But there was more to it than mere comprehension. When you get engineers around a white board discussing a problem, you see camaraderie, ad hoc teaming, exploration, creativity, brainstorming, common purpose, head scratching, and inspiration. There’s something special about a conversation between people who understand a topic in-depth. Nathan was the kind of colleague who could connect in this manner with just about anyone, no matter their personality type. His knowledge of our products, and of the industry as a whole, was simultaneously broad and deep. Yep, Nathan was perfect.

I should have been in a panic, but I was calm. How could that be?

A few years’ beforehand, Nathan’s cancellation would have singed me like a three alarm fire. But now, I knew I could draw on my team of competent attendees. Nathan’s alternate would bring the technical credibility we needed. More importantly, I was confident he would ask skillful questions, build trust with the customer, and demonstrate genuine interest. He’d connect, and, in the end, he’d strengthen our relationship with the customer. How did I know all this? Because I’d taught him how.

Rewind a few years, however, and the prospect of inviting an alternate to a customer meeting would have been as appealing to me as a round of Russian roulette. Back then, there were only a handful of people who I felt comfortable putting in front of customers, and even some of them could be unpredictable. But an alternate? No way. They might talk too much, or ask leading questions. Worst of all, they might attempt to sell the customers on our products, coming off as sleazy used-car salesmen. I’d seen every cringe-worthy behavior you could imagine. We’ll review some specific examples later in this book.

To be fair, colleagues from engineering, marketing and other departments usually behaved professionally. It was glaringly notable the few times when they didn’t. The problem was that I never knew when they were going to derail the conversation. Even the most diplomatic among them, including high level executives, could make awkward comments, or steer the discussion off course. Whether due to outrageous gaffes, or tiny peccadilloes, each misstep added up over the course of a meeting. The consequences were consistent: the customer would stop talking and we’d come away with little useful information.

So why did we continue? Why did we book more meetings? Because there were times that magic happened; we’d connect. Everyone could feel it. The conversation would carry forward on its own as excitement crescendoed. Suddenly, the customer would jump up, grab a dry-erase marker, and brainstorm ideas on the whiteboard. Thus inspired, we were in flow. Pencils scratched over engineering notepads, and laptop keys clicked. We happily recorded outpourings of customer insights, ideas and vision.

Out of that magic came revelations that we might never have otherwise encountered. Out of that magic came a deep understanding of what the customer was truly trying to do and why. We learned what was getting in their way, and explored ways we might help them overcome such obstacles. We heard stories, not just data points. We understood the context and importance of each piece of the customer’s situation.

On these occasions, when we connected with customers, I’d wonder, could we cultivate that magic? Could we avoid whatever prevented that magic from materializing? Could we learn to exchange useful information with customers and avoid alienating them?

I began observing our behavior in the margins of my notes. After a few customer meetings, the truth emerged: we were winging it.

People were coming to the meetings unprepared. They hadn’t read email briefings and had skipped pre-meetings. Then they’d show up and steer the conversation according to their own agendas. Otherwise cordial colleagues sometimes became argumentative when they didn’t hear the answers they wanted to hear. That made me angry. I wondered, didn’t people know how to behave?

Then I imagined myself in my colleagues’ shoes. Like me, they had decisions to make, projects to push forward, and interminable meetings to endure. The customer alignment meetings took them away from their work. They were being placed into an impossible position. They were expected to behave well with customers, but hadn’t been told specifically what was expected. I hadn’t explained the meeting goals to them, nor their specific roles in the meetings. I hadn’t provided behavioral tips, such as how to deal with seemingly irrational customers, how to ask skillful questions, or how to take useful notes. No, I hadn’t trained them, and yet I expected perfect behavior. How naive of me.

It was time to rectify the situation. Firstly, I needed to educate myself. I sought guidance, and found much wisdom in books, many of which are listed in this book’s appendix. I learned questioning techniques from Rory Clark, the “creator of Focus $elling®, a … system that (teaches) leadership, teamwork, and performance through the renovation of individual mindsets.”[2]

As I developed my own, in-house training program, I received invaluable feedback from a colleague in the HR department, the ever insightful, Eva Condron, (title).

I was eager and ready to go. I developed a training class and invited about fifteen people. Two people showed up – two people who needed training the least. They mostly listened in my meetings, and the few questions they’d ask were usually good questions. So, I let people know that if they wanted to meet with customers, they were required to undergo training. I petitioned the heads of each department to nudge their teams to attend. In the end, nearly everyone who took this training embraced it. Many said they felt relieved, for they finally understood, with absolute clarity, what their roles and responsibilities were. They were gratified to learn exactly was expected of them, and often more importantly, what was not expected. They developed alignment skills, and contributed ideas for improving our customer engagements, which were included in subsequent training sessions.

Within a year, our customer alignment program had transformed. We spent less time preparing, and gathered useful information at every customer meeting. With our success came demand from the field. Our sales teams had long been wary of putting their customers in front of what they called, loose cannon ‘factory’ people. With visibility and positive customer chatter about our meetings, they became more comfortable with bringing customers to us. Sales teams began requesting customer alignment meetings, or CA meetings. They saw CA meetings as a means of strengthening relationships with their customers.

Attendees from our engineering teams also began asking to come to meetings. Previously, CA meetings were regarded as disruptions to their schedules. CA meetings were sources of annoying action items. After attending the training, they saw value in hearing directly from customers. They came to understand that the objective was not to pick up action items, but to learn customer goals and challenges, which they enjoyed doing.

As for me? Well, I gained confidence in the team. Dozens of colleagues, across multiple departments, could be called upon to help us in the product planning department to uncover information we needed to define better products. We became a team capable of uncovering the customer information that mattered to us. We were in a good place by the time XYZ was due to visit.

And so, as I ‘replied all’ to Nathan’s email, I was calm and relaxed. Jacob would be up to the task. He’d bring all the technical credibility we needed. More importantly, I was confident he would ask skillful questions, build trust with the customer, and demonstrate genuine interest. He’d connect, and, in the end, he’d strengthen our relationship with the customers. How did I know this with such certainty? Well, he’d attended my training sessions, and I’d witnessed him wield the skills he’d learned to great effect.

You see, customer alignment can be done. But each meeting requires planning, and each attendee must be trained to use their innate skills in the context of a larger team effort. Each team player must understand her role within the team, and play that role at the right time. This doesn’t mean people must alter their personalities. They simply need to adjust some wording when they ask questions, take proper notes, and sharpen their listening skills. All of this can be learned, and all of this can be taught.

This book is derived from the ‘Subject Matter Expert’ or SME training that Jacob, Nathan, and dozens others underwent. It’s a compilation of specific and actionable tips that worked for us. These skills proved invaluable as we aligned with customers during my tenure in the product planning department at Altera Corporation from 1999 through 2012.

This training was developed in the context of the semiconductor industry. While most examples derive from that world, the concepts translate to other industries outside of Silicon Valley. If your goal is to align with customers or stakeholders, there’s probably something in this book that you can use. These concepts can work in non profit organizations, accounting agencies, widget manufacturers, or law offices. That said, the tips contained herein are a starting point. Use what works for you, adjust the advice as it makes sense for your situation, and build upon your experience.

These techniques are not complicated. Anyone can learn them, including technical engineers, experienced marketers, or even … high level executives.



But I Want to Wing It!

It was clear we were all winging it in customer alignment (CA) meetings. While I too like thinking on my feet, and find planning and training to be utterly boring, I realized that by failing to develop our customer interfacing skills, we spent too many mental cycles thinking about what to say. Worse, for those of us who spent no time thinking about what to say, the results could be disastrous. Foots inserted into mouths, regularly.

Corporations usually provide sales training to their customer facing employees, but don’t extend such lessons to their internal engineering and planning teams. My colleague, Eva Condron, called such internal employees, Subject Matter Experts (SMEs). When SMEs lack basic training in interacting with customers, sales teams loathe having them in meetings with customers. That’s unfortunate, because often, customer insights that matter most are aired precisely when customers talk directly with product developers about their future plans and goals.

This book is intended to bridge that gap. It’s intended to provide easy-to-remember tips for SMEs so that they can reliably interact with customers. The goal isn’t about issue resolution however, the goal is to align roadmaps and improve the planning process by eliciting trustworthy, unbiased and useful customer insights and information. Customer-facing SME training, is essential if this sort of information is desired by the product planning team.

Ask yourself this: what’s your focus during a customer meeting? Questioning techniques? Interpersonal skills? Probably not. No, you focus on the discussion, and as you do, you naturally snap into whatever conversational habits you’ve developed over your life. That could mean you interrupt as soon as you disagree with what’s being said. Or, it could mean you ask verbose and wandering questions that do more telling than asking. In some contexts, these tendencies have merit, in others, they can be disruptive. Conversely, going by instinct could mean you never utter a peep. That could result in failing to gain critical information.

Focusing on the conversation is the right thing to do, and that means that optimal conversational skills must be made into habit. The way we question and listen needs to be automatic, or second-nature. With training and preparation, well honed uncovering skills free you up to … think, listen, and strategize. Ultimately, you get the information you’re after.

When we leave questioning skills to chance, when we let attendees roll their own questions in real time, our meetings go awry. Untrained attendees disrupt the flow of conversation, transmit unintended messaging, or fail to ask what they truly want to ask. Or, they ask well-meaning questions, but in such a way that the customer volleys back with hollow, unsatisfying answers. Too much of this can compromise the spirit of the meeting. Training delivers the benefits of unearthing relevant information – all while freeing up people’s minds to mull deeply into the topics at hand, without wondering if they’re about to upset the customer.

If you’re sold on the concept, and you want to develop these skills, skip ahead to the next section. If not, continue reading.
Still with me? Still not sold? Don’t worry, I’ve anticipated this reaction, and have lovingly prepared this chapter for you. Below you’ll find some common objections I’ve heard from colleagues who wanted to opt out of training. Below each objection I’ve written my typical responses. Sometimes I convinced the heretics. Other times, I convinced their bosses to “convince” them to improve themselves and their contribution to our customer uncovering efforts. If you identify with any of these objections, please read the corresponding response.

Objection: “I’m already great with people. I can opt out of training. Right?”

Uh, no. Even if you’re a hit at parties, you need alignment skills training. Here’s why.

Effective CA meetings are team efforts that require specific planning and specialized language. Imagine a professional soccer match. Each player knows their role: what part of the field to cover while the ball is being handled elsewhere. Now imagine a soccer game of six year olds. Every player rushes for the ball wherever it is. They run over each other, trip up, and in the end, the ball moves haphazardly. This vision, of six year olds playing soccer (football if you are outside of the US), came to mind often in those days prior to training. Which team do you want to play on? Winning with professionals, or losing with a bunch of novices?

When you’re part of a team, you should know your role. You know when to step back and let your teammates carry the ball. You can identify when your teammate is in trouble and help without getting in the way. Teammates with common training can execute strategies and pivot to new tactics as needed. They think as one.

Secondly, even if you’re good with people, you may find that training improves your game. Those benefits can extend beyond the customer meeting conference room. When I learned these skills, I was raising two elementary-school-aged daughters. I used my newfound skills at home, and discovered they invited independent thinking and honest communication. My elder daughter used to argue with me a lot. When I learned to suppress unintended messaging, she seemed to argue less. Before learning these skills, my younger daughter seemed reluctant to tell me about what was going on at school. After I learned how to ask questions, she revealed that a girl, who I’d thought was her best friend, was, in fact, bullying her. Both girls began cooperating without manipulation or crude systems of punishment and rewards. These customer aligning techniques enabled us to talk to each other as family partners working toward common solutions. That’s how it should be in customer meetings as well.

The benefit to our home life, was a pleasant byproduct. In the end, if you’re unwilling to learn the common language of alignment, are unwilling to learn how to work with your team, it is probably best that you do not attend customer alignment meetings. At best you’ll be a fifth wheel, at worst, you’ll disrupt the game.

Objection: “I’m too busy. I don’t have time for this stuff.”

If you’re invited to customer meetings, and the people organizing the meetings have recommended you learn these techniques, there’s a reason. Learning these skills will save you time in the long run. You’ll learn a common language for aligning. When everyone is working from the same playbook, preparation meetings take less time as everyone on the team immediately grasps their own role and goals. When everyone on the team knows common aligning tactics and skills, it frees you up to focus on the particulars of each customer. You may find that customer meetings become more efficient and enjoyable since you now avoid wasting time on conversations that offer little value.

“I’m an expert in my field. The last thing I need is more corporate training.”

If you are a key subject matter expert within your company, there’s a chance you’ve cultivated a bit of rock star status. Your work is critical to operations, and everybody knows it. That’s awesome. Congratulations. People respect your work, dare I say, they envy you.

You’ve probably put a lot of work into your subject of expertise. Now I invite you to put just a small amount of time and effort into honing your interpersonal aligning skills so that you can play the role that you alone are uniquely qualified to play. By pulling lessons from this book, you’ll understand what the rest of the team is doing, and sit back as you let the team move the customer to a place where she can begin providing insights on your topic. Perhaps the discussion will illuminate how she uses your technology in unexpected ways. Revelations about how your technology might be improved, streamlined, or altered, may come to mind.

Objection: “I’m an introvert. I’m terrible at talking with people. The last thing I want to do is meet with customers.”

Fair enough. Perhaps all this talk of connecting with customers is scaring you off. Don’t worry. There are ways of managing customer meetings so that you can talk sparsely. In fact, your reticence to open your mouth is likely an advantage. This is because the goal of a customer meeting is not to listen to you, but to listen to, that’s right, customers. The majority of the talking should be done by the customers which means the majority of the listening will be done by you. That said, by learning the concepts contained in this book, you may identify times when your voice is needed in the conversation. The skills you learn here may help you identify proper times to engage in conversation – especially when the topic moves onto material you, and nobody else knows or has the perspective for. Give it a chance.

Yes, every CA meeting attendee must undergo training.

Whether you burst with confidence, or lack it entirely, it takes but one untrained person to completely derail a meeting. It doesn’t matter if you’re an introvert or an extrovert, a preening rock star or a silent wallflower. If you go into a customer meeting winging it, or failing to play a specific role on the team, you could unwittingly do real damage. You don’t want to be that person, do you?

What do you stand for? What’s your company trying to achieve? Are you trying to create the best product within your market? To explore new niches? To continually improve customer satisfaction? To align your roadmap with your customers’ roadmaps? All of the above?

If you want to be a valued contributor to moving the company forward, then I’d advise you to do everything you can to align your company with key customers. This training is your ticket to do just that.


Why Align with Customers When Customers Don’t Know Jack?

Steve Jobs famously said, “It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.”

I can’t tell you how many times I’ve heard colleagues, especially from the marketing department, repeat this tired quote. Sometimes, the words of Mr. Jobs would be invoked to deflect a disconfirming data point we’d gathered from a customer. Usually, Mr. Job’s words were used to explain why there was little value in attending, or even holding, customer alignment meetings.

Whoa – how does one combat the sentiments of a Silicon Valley deity such as Steve Jobs?

All I could do was agree. Maybe that sounds crazy, since this book is about aligning with customers. But parse the statement out. “A lot of times, people don’t know what they want until you show it to them.” In other words, they can’t tell you what they want until they know what’s possible for you to deliver. That’s indeed a big part of an effective CA meeting – sharing a glimpse at possibilities on your roadmap. But, and this is a big but and it cannot lie:[3] sharing your product plan is not your lead topic. Yes, it’s important, and it has its place in a CA meeting… and that’s in the second half of the meeting, not the first.

No, the first order of business, ad the true goal of an alignment meeting, is reflected in a less well-known known quotation from Steve Jobs. He said, “You’ve got to start with the customer experience and work back toward the technology – not the other way around.”[4]

Exactly. This is what a CA meeting is all about. The key to aligning with customers is first learning what they are trying to do. The team starts by uncovering their objectives. Only after understanding what the customer is trying to achieve, and discovering what challenges they see before them, does it make sense to discuss possible technological solutions you might offer in the future. If anyone on the team fails to understand this, the meeting can go awry and lead to disappointing results.

What better time than now to give you a preview into the four main objectives of a customer alignment meeting:

  1. Uncover customer information: specifically, their goals and challenges
  2. Build relationships
  3. Continuously align plans
  4. Document and disseminate information to stakeholders

We’ll get into more detail on each of these later in the book, and you’ll learn ways to achieve these goals with ease. Once you and your teammates are adept at all four, you should find yourselves making more informed decisions and planning better products.

Your team will be much better versed in what customers care about, and as a result, more likely to develop the kinds of products they’ll want to buy. Additionally, your team will better understand your competition. You’ll know whether they’re making good or bad decisions. Why? Because you’ll know what customers are trying to do.

So read on, because that’s not the whole story, and beware: there are some gotchas.

Chapter 1 – Introduction, Part Deux – This is What Winging it Looks Like

[1] If you’re unfamiliar with the term, FPGA, think, customizable logic computer chip. If that doesn’t do it for you, just think, computer widget of some sort.
[2] Rory Clark,
[3] Props to Sir Mix A Lot

ALIGN Chapter 1, Part Deux – This is What Winging It Looks Like

(Previous chapter:  ALIGN Chapter 1 – The Power of Preparation )

This is what winging it looks like

Imagine you’ve been invited to a CA meeting, but no one has explained why you’ve been invited, nor what the overall objective is. But, you think, it’s called a customer alignment meeting, what more information do I need? I’m no dum dum. I’ll figure it out as I go along.

In each scenario below, you are the lead character. You have a specific title, and certain perspectives. Think through each example as if you are that person, and ponder what’s really going on. At the end of each scenario, ask yourself, was the meeting successful, or did it derail? Can you identify what went right or what went wrong? We will refer back to these examples later in the book as we learn aligning skills.

For now, let’s take a look at what not to do. Let’s see what it looks like when you wing it.

Scenario 1: Customer Attacked

You are the resident expert, the Subject Matter Expert (SME) for a lynchpin, proprietary technology, that is at the core of your company’s product portfolio. You find yourself in a customer alignment meeting, and the host has gotten the customer’s Chief Engineer talking. And boy oh boy, is he talking. He lists one lofty pie-in-the-sky suggestion after another. He says he wants half the power, twice the performance, and all at lower cost. Oh, and don’t forget, the device must power up in an instant, with the option to boot up with a full factory reset, or with its context and cache memory in tact from the last save.

You try to maintain an expression of calm, but internally, you’re boiling with anger. This idealist is completely untethered from reality. You’re a talented engineer, and sure, you could deliver on one of these requests, maybe even two… but all of them? Impossible. It’s not technically feasible. Simple as that. There are trade-offs to be made, not to mention the minor detail that you are bound by the laws of physics, and the finite pile of cash the country has printed!

Unbelievably, the meeting host encourages the customer to keep spewing unrealistic demands, and the customer obliges. It’s madness. Back at your desk, you already have a to-do list longer than you can comprehend, much less get through. Now, you have to sit here as impossible requests get tacked onto your to-do list? Oh, hell no. The tenet, “the customer is always right” crosses your mind, and you think, no, in this case, the customer’s dead wrong.

It occurs to you that, by indulging the customer like this, by allowing him to brainstorm unrestrained, the team is leading him to believe his wish is your team’s command. Simply by listening to these unrealistic demands you’re tacitly committing to delivering them … and you’re not willing to sign up for any of it. It’s an all out assault, and you cannot let it go on any longer.

What do you do?

You decide to set the customer straight. He needs to understand that his needs are about as realistic as building a machine to teleport people to Mars, even if, at this moment, you’d like very much to shove him into such a contraption. During a brief pause, you interject. You explain, as gently as possible, how outrageous his requests are. You estimate the cost of doubling performance, and explain that he can either have lower power or higher performance, but not both. You go to the white board and draw a diagram that shows how the power architecture cannot possibly be used to do the power modes he’s requested. It would have to be redone from the ground up. And even if you did that, performance would suffer. The way he envisions power up and memory accesses would be a burden to all the customers who did not want such features. You point out that none of his requests come for free. Even if you could implement half of his requests, costs would skyrocket beyond any price points he’d be willing to pay.

Despite striving to remain calm, you become aware that you’re sounding angry now, even combative. But you’re justified, because his requests are outrageous. He demands the impossible and clearly does not appreciate the complexity of your job or your technology.

It had to be done; you had to educate him. And so you did.

What happens next:

The customer apologizes and explains that he wasn’t familiar with all of your constraints. He sits back in his chair and turns his attention to the front of the room, and waits for the host to continue the meeting. Within minutes, a colleague from the product planning department is reviewing slides that show details of the next generation devices the company is planning to build – devices you’ve already agreed to design. Now the team is back on track, and you’re getting feedback on real plans, not blue sky pipe dreams. The customer answers the host’s questions, but with slightly reduced enthusiasm.

You’re satisfied that the meeting is at last back on course.

Scenario 2: Horrified VPE

You’re the Vice President of Engineering. You arrive early, and informally chat with the customer. You discovered that you both attended the same university. Remarkably, you’re also both avid sailors. You swap tales of high seas adventures. By the time the CA meeting begins, you feel satisfied; you’ve developed an amiable rapport.

The host, Bob, leads a round of introductions. He reviews the agenda, confirms with the customer that the agenda meets his needs, and then launches into a presentation titled, What We Heard Last Time. It’s a bit cringe-worthy. It’s a verbatim regurgitation, quotes, of what this same customer said in a similar meeting a year before. What a waste of time, you think. Obviously, the customer knows what he said last time he was here. However, the customer looks interested, so you stay quiet, even as you roll your eyes. Bob is obviously not an expert on the underlying subjects. You can’t wait for him to move on.

Fifteen minutes later, the customer stands in front of a PowerPoint presentation. He’s come well prepared, and has clearly put effort into his slides. At the moment, he’s reviewing a functional diagram of his next generation product, in which your devices play a major role. A person from the marketing department asks him what protocol he’ll use between two devices. You’re horrified. Anyone who knows anything about telecommunications equipment should know the answer. It was a stupid question.

What do you do?

Embarrassed, you answer on the customer’s behalf. “It’s Interlaken,” You say. And, having followed the presentation so closely, you volunteer, “… with what, 16 channels?” The customer nods in agreement. Satisfied, you glare at the marketing engineer and attempt to telepathically transmit, no more stupid questions.

A few minutes later, a director from product planning asks, “What do you see as the biggest challenges in your way, challenges that might keep you from getting to market in the timeframe you’ve described?”

The customer nods slowly, as if he’s digesting the question. Then he pauses, and looks up at the ceiling. Oh boy, you think, we’ve really put him on the spot now. You can’t stand the silence, and bail him out by offering a list of possible answers to choose from. “You know, such things as managing power, uncertainty over which protocols to choose, shifting customer demand, supply disruptions, those kinds of things.”

The customer looks at you and considers for a moment. “Yeah, all of those I suppose.” He returns his attention to the block diagram.

Whew, disaster averted … but not for long. As the customer talks about power, a design engineer asks, “In what ways do you design for power?” You can’t believe your ears. The customer just finished saying he was designing into an ATCA chassis. It’s an industry standard. Anyone can read the spec and answer that question. There are specific power requirements, specifying power supply, ambient temperature, and maximum operational power. You can’t stand to let the customer answer such a stupid question, so you let the design engineer what’s what. You say, “They’re designing with an ATCA chassis. It’s an industry standard. You can look up the power constraints in your spare time. There’s little point in wasting everyone’s time now with that question.” The design engineer looks down at his hands.

Incredibly, over the next half hour, every single question is embarrassingly stupid. Every time, you feel you must save the customer, so you answer on his behalf.

You think, What a bunch of dopes this younger generation of engineers are. Who hired these people? You’re embarrassed they’re on your team, as they seem utterly immature, clueless, and unprofessional. You mentally note who each person’s managers are. You’ll be having a few chats in the near future.

At the break, Bob, the host, approaches you in the hallway. You expect him to thank you for your attendance as he surely appreciates the busy schedule you keep. Instead, and incredibly, he asks you to stop answering on behalf of the customer. You’re incensed. You say, “I’ll tell you what, I’ll stop answering as soon as people stop asking stupid questions.”

The host explains that there’s no use for the customer being there if you answer for them. He doesn’t get it. You fire back, “I can tell by your questions that you don’t know the first thing about these technologies. Who the heck are you to tell me what to do?”

Scenario 3: TME Save

You’re a technical marketing engineer, responsible for the roll out and marketing of all high end products. You craft marketing campaigns and plan for collateral, including software patches, that support customers in using these products.

The CA meeting starts, and the host asks the customer what the goals are for her next generation product. Straight away, she laments that the interfaces need to be nimbler. The software seemed to have been designed for high bandwidth, large burst data packets. But that’s not what she wants. She’s frustrated because they can’t seem to design around it. They’ve tried various compiler settings, and various PCS modes. Having studied the architectural diagrams in the data book, she can see that what she wants to do is physically possible. However, the supporting software and IP don’t give her the controls she needs to make use of the architecture.

You can’t believe that no one on your team is saying anything. Only a month ago, you put out a press release announcing a software download that provides precisely the tools she’s describing. The patch includes a user mode that would allow her to do exactly what she’s asking for.

What do you do?

It’s time to educate everyone. You explain what’s included in the software patch, and point out that it’s already available online. You pull out a business card. On the back, you write the full path to the file so she’ll be sure to find it straight away. As you hand her the card, you tell her to contact you if she runs into any problems. She thanks you. You look around the room to get congratulatory eye contact, with mixed results. Never mind, you’re a hero.

It occurs to you how passive everyone is being. No one’s selling this customer on all the technology that’s currently available that she could make use of today. You pull out a glossy product brochure and walk the customer through the big sellers, explaining why they’re popular with customers. She nods with appreciation.

Out of the blue, the host asks the customer to expand on her performance goals.

She explains that the device she’s using is barely meeting timing, and they have more functionality to add. She worries that they won’t make their targets.

You ask what software build she’s using, and she tells you.

“Oh,” you say, “well, in the next software release you’ll find a compile mode that better optimizes the routing, and rebalances registers. We’ve found that the typical design sees performance gains of twenty percent. I imagine you should see some improvements there. You may want to upgrade to the latest build and check it out.”

“Oh, okay.” She says, while writing in her engineering notepad. “Well then, I guess I’ll move on to packaging. We’re developing a handheld unit. 1mm ball pitch won’t do. We need 0.8mm.”

It just so happens that you’re on the cross functional packaging planning committee. Yet again you’ve got precisely the solution for her. “In three months we’ll be introducing the part you’re using, but in a package that is 60% smaller and with a ball pitch of .8mm. It’s ideal for handheld form factors.”

“Oh, thanks. I’ll let the team know,” she says, again, scribbling in her notepad. She thanks you and turns her attention back to the host, letting him know that she’s done. You too look at the host, expecting a nod of appreciation. Instead you receive an unfriendly glare. You’re perplexed. Did he not witness you saving the day? What on earth is going on?

Scenario 4: Customer Soul Sucking

You’re the customer in an alignment meeting. The week before, you spent hours collecting stories from colleagues and preparing a presentation to share with this key supplier about your company’s roadmap. You want them to align with your roadmap, because their technology is critical to your success in the market. Now you’re midway through your presentation at the supplier’s headquarters in Silicon Valley. You’re explaining how an ASSP[1] supplier has you by the ovaries[2] as they’ve cornered the market with their interface device. That phrasing gets a few chuckles. You continue to explain that have no alternatives and this supplier, who you’ve come to despise, is squeezing every penny out of you. You can’t go on paying these highway-robbery prices, otherwise you’ll no longer be competitive. It’s a dire message you’re sharing. A couple people laugh at your phrasing, and you look at your audience.

Ten people sit around a large conference table. You feel like something isn’t quite right, but carry on anyway. You describe the challenges you’ve encountered implementing the block diagram that’s projected on the screen. Eight of the attendees seem to be following. But, you haven’t heard many questions. One attendee, in fact, is doing the head bob. His head slowly lowers as he dozes off, only to jerk back upright when his neck strains too much. You can forgive him though. You think to yourself, haven’t we all been there? Another attendee has his nose buried in his laptop. Periodically he types, but you get the sense he’s tuned out from what you’re saying. You walk to one side of the projection screen and see that he’s going through his email inbox. Hmm. I guess he’s not interested in what I have to say, you think. You resume your presentation.

After a few more minutes, it occurs to you that no one is taking notes. You’ve been pouring your heart out and they’re letting the words fall like beautiful snowflakes onto the surface of a lake, to be lost forever in the deep, dark, forgetting water. Will they remember what you’ve told them? Will all your efforts have any effect? Do they even care? You look at the person staring into his laptop. He’s not typing, rather, he seems to be slowly scrolling down the page. Is he reading a newsfeed? Top ten ways to annoy your customers! You won’t believe number 8!

You lose energy, hurry through the remaining slides, and ask, “any questions?”

Bob and Tom start talking at the same time, but then Tom yields to Bob with an upturned palm as if to yield the floor.

Bob asks, “Are you going to adopt variant A or variant B of the upcoming IEEE standard DEF?”

You think for a moment. You hadn’t said you’d be adopting this specific standard, but it’s commonly used within your industry. Even so, you do have an opinion on the matter, as you attended some of the IEEE meetings on the subject. “Well, I can’t say I speak for my entire company, only for my group. Variant A is desirable for low power features, and variant B for high performance.” You pause, considering which one you would choose if you had to pick today, and why.

As you’re mulling over Bob’s question, Tom rapid-fires multiple, unrelated questions. “Do you use Linux or Windows and if Linux, which build, and if Windows, how many cores? And do you expect our software to take advantage of: just one, two, or more than two at a time?”

Whoa, can you say, context switch? Goodness, where do you even start? You try to remember what specifically he asked, and your brain plays back the very last question about the number of cores you expect the software to use.

You answer, “I suppose we’d want your software to use whatever cores are available to the degree that using more cores improves compile time. I think I’d want you to make that decision based on your own research.”

“And which OS?” Tom demands.

“Our company uses Linux exclusively,” you answer, then add, “Ubuntu.” You’re not sure what else to say, as you can’t remember all of the questions that were rapidly fired at you.

Tom nods with approval. “Yes, yes, it’s nice to meet a customer with sense. Ubuntu is far and away the best choice in OS. The latest Debian stable distribution is just, what can I say, it’s elegant. Unity, the user interface, is simple clean and powerful, and as someone who is a die-hard open source software devotee, I can tell you that Ubuntu is a paragon of awesomeness. I actually worked in South Africa for a while, and on one project I worked with a team at Mr. Shuttleworth’s company, Canonical Limited. Wow, what a bunch of true engineers. I learned so much. So, so much.

Tom winces briefly. It seems that someone kicked him under the table. You take the pause in the monologue to say, “Well, I don’t know much about operating systems or their development. I’m a hardware engineer. Ubuntu seems to work fine, but it doesn’t really matter to me. I only care that my HDL compiles and my circuits work in the lab.”

Before Tom can comment, Bob swats you back to the other side of the table with a question about that IEEE protocol.

“From your answer about DEF, am I to understand your company will adopt variant A? After all, throughout your presentation, power seemed to be a top priority.”

He’s got it all wrong. “No, I can’t say that. Yes, power is a big priority, but as long as we’re within our power budget, we then want to optimize for performance.”

“So then variant B?” Bob asserts.

“Well, no, it’ll depend on the project we’re talking about, I can see us using either standard.”

Bob writes something in his notebook. You think to yourself that in reality, you’re likely to adopt an entirely different spec, one that is being secretly developed by a consortium of three powerhouse technology giants.

Bob looks back up and asks, “So if I were to tell you that our devices are likely to drop variant B, and might only support A, would you use variant A?”

“Uh, well I suppose, in some cases sure.”

Bob scribbles some more in his notebook.

You’re about to tell him about the alternate consortium, but Tom asks another question, switching the topic back to software. Your brain blanks out as you context-switch back to that topic, a topic you neither care about, nor have any influence over. You ask Tom to repeat his question, and answer the best to your ability. In doing so, you completely forget to share any details about your preferred interface standard, or that consortium that these people are clearly unaware of.

The host calls a break. You sit down, tired. You feel like a heavily swatted ping pong ball. You shake your head as you realize they’ve lost the plot. They are going to leave this meeting not understanding what you care about. At this point, you no longer care; let them believe what they want.

Next Chapter: Chapter 2 – Goals and Mindsets

[1] ASSP = Application Specific Standard Product

[2] A similar phrase was used by an irate customer in an actual customer meeting. I include it here purposefully. Here’s why: real people, face to face, say things like this. While your initial inclination may be to quietly forget this comment, or sanitize it in your notes with something like, “their supplier had a monopoly on product XYZ,” don’t. Later on, when we discuss capturing notes and summarizing the meeting, you’ll learn that these phrases are precisely what you want the wider organization to read. Why? Because nothing conveys the actual feelings of the customer like the words from the customer’s mouth – especially when the words are so specific and … salty?

ALIGN Chapter 2 – Goals and Mindsets

(Previous Chapter: Introduction, Part Deux – This is What Winging it Looks Like )

Goals and Mindsets

Four Points of Alignment

The customer-meeting scenarios in the prior chapter were examples that ranged from useless wastes of everyone’s time, to borderline mayhem. They resulted in biased, useless, or incomplete customer information. In this chapter, you’ll learn what it takes to convert such an ad hoc collection of behaviors into a skillful session of uncovering customer inputs that matter.

If you read through the Winging It scenarios and thought events unfolded successfully, then don’t even think of putting this book down. You need to read on. Why? Because you’ve been doing it wrong. Read this book and discover a whole new world of aligning with customers effectively.

Though the scenarios in the last chapter were fictional, they were constructed from my experiences in real meetings. In those occasional moments of mayhem, we were like untrained children in a soccer match. In order to work together as professionals, we would need to acknowledge, and agree upon, four fundamental points of alignment: Goals, Mindsets, Skills and Roles.

In the Winging It scenarios, our goals were misaligned, and often, misguided. Lacking clearly defined common goals, attendees navigated their own courses. Some tried to be genuinely helpful, but their timing was wrong. Others garishly thumped their egos, putting what they believed to be their vast wisdom on display. Whatever the individual objectives, the team was not united in achieving a common purpose. This led to chaos, miscommunication, and failure to learn what the customer was trying to do. This could leave the customer feeling bewildered, and leave us with little, if any, useful information.

Secondly, each of our mindsets were incorrect. We could be reactionary, defensive or, as is the case with many experts and highly skilled individuals, self-centered. Inadvertently, and despite the best of intentions, we discouraged customers from sharing.

Our customer facing skills were lacking as well. For example, we asked poorly structured questions, asked loaded questions, talked excessively, and jumped from one subject to another too quickly. That unskilled behavior occasionally turned customers off to us completely, as we seemed to lack diplomacy, consideration, and sometimes interest.

Lastly, our roles were not clearly defined. No one took notes, people spoke for too long about pet topics, and others randomly interjected questions whether they applied to the discussion or not. The order and flow was bumpy as our attendees took control at their whim.

It needn’t be this way. If everyone agrees on common goals, mindsets, skills and roles, CA meetings can be highly productive. The following chapters explain exactly what these goals, mindsets, skills and roles should be. Once adopted, you will begin uncovering highly useful customer information, and may find yourself looking forward to customer meetings.


The Aligning Team’s Goal: Understanding Customer Goals and Challenges

In every customer alignment meeting, the singular goal is to see the world from the customer’s perspective. It is to learn the customer’s objectives and challenges. Specifically, the team’s goal is to work together to uncover the following specific future-looking information:

  • Customer’s goals from the customer’s perspective
  • Customer’s challenges from the customer’s perspective

Your goal, when attending a CA meeting, is to uncover the customer’s goals and challenges. If you understand this one concept, and forget everything else, you’ll be at an advantage over others who have never read this book. You’ll be a key contributing member of the aligning team, since you’ll be pursing the same objectives as your teammates.

Why the aligning teams’ #1 goal is to understand customer goals and challenges

Understanding customers’ objectives are critical to planning future products. You can only do so much with a singular data point of a specific request. Without context, that request is meaningless, as it’s impossible to extract a line to the future from one data point. When you take the time to understand the customer’s view of the world as if you were in their shoes, you gain critical insights into small implementation level decisions that form an essential part of big product portfolio level decisions.

I’m reminded of many internal development planning meetings. We, in the planning department, would meet with a handful of engineers whose job was to design, develop, manufacture, test, and produce the products we were proposing to build. Engineers who accepted every line-item without pushing back were rarer than bored CEOs, indifferent to cost-cutting; they didn’t exist.

Inevitably, we’d review and scrutinize every single implementation request. It was in these meetings where I was thankful I understood the customer’s objectives as well as I did. Even better, often, I’d invited these very same engineers to CA meetings, where they’d heard first hand what customers were trying to do. By being clear on what customers were trying to achieve, we were in a position to sensibly trade off implementation options as a team.

If, on the other hand, my knowledge was limited to a simple laundry list of customer requests, and I’d never invited any product developers to meet with customers directly, we’d be lost. I wouldn’t be able to justify any of our requests, and the product definition would be watered down to a point where it might not address any markets.

By knowing the wider story of what customers were trying to achieve, I was generally able to explain whether features were must-have ‘table stakes,’ nice-to-have bonus perks, or market-changing disruptions. All of these insights that matter, when defining a product for a particular target market.

Again, consider the winging example #3, where the TME solved the customer’s problem too early, and, as a result, failed to learn what the customer was trying to accomplish. Now, imagine that soon after a CA meeting, an executive, who didn’t attend the CA meeting, says the IP patch, the one that solved the customer’s problem, should be removed from the website. From that director’s perspective, the patch has caused nothing trouble, as it’s caused a documented spike in hotline calls. The director thinks the IP should be simplified, or removed. The conventional thinking is that, by providing customers so much control, it’s causing more problems than it’s worth.

If all you knew was that the customer had a problem that the patch solved, your case might be lost. On the other hand, if you understood the story behind her need for such functionality, you could create an irrefutable, business substantiated, prospectus. The director cold then make a strategic decision, instead of merely eliminating a tactical headache, and potentially losing an important customer. You’d be in a position to tell a compelling story as to why this feature was important. Alternatively, your team might come up with another workable solution. Knowing what the customer is trying to do is significantly more valuable than knowing a specific feature requirement out of context.

Uncovering customer goals gives you the story, not just data points.

Demands for new features often come in faster than they can be dealt with. On one hand, specific feature requests were nice, in that they were quantifiable and simple to comprehend. However, when they came without context, they were at best meaningless, and at worst, fodder for bad decision making.

When you ask a customer to share goals and challenges, you are learning their hero’s journey, their story. If you collect enough of these stories, from numerous customers, you start to get an idea of what directions they are going in. You begin to put together schemas, or generalized frameworks, of what your best and most insightful customers are trying to do. Suddenly, specific feature requests can be understood in context. The reasons for pursuing a new product development are easier to get across, as you can tell the story of the market overall to decision makers within your company.

Misguided Agendas

In the absence of a clearly defined goal for the uncovering team, individuals tend to pursue their own ad hoc, even if well-intentioned agendas. They can flit from one topic to another, depending upon where the conversation is at any moment. Here are some examples of misguided agendas that have no place in CA meetings:

  • Collecting answers to specific questions, when they don’t apply to the customer in attendance.
  • Fishing for specific data.
  • Solving current technical problems.
  • Pitching current products or already established roadmaps.
  • Spreading FUD (fear, uncertainty, doubt) about your competition.
  • Taking on unnecessary action items.
  • Educating customers about the market or existing products.

Problems may arise that needs solving, or, you may realize the customer is unaware of currently available technology that may help them. The first portion of a CA meeting is not the correct time to address those solutions. The right time is later. No solutions should be discussed until after you’ve uncovered all of the customer’s future goals and challenges, and ideally these discussions should be decoupled from the CA meeting. Only after you’ve learned what your customer is trying to do, and confirmed you’ve heard the entire story, is it okay go back and fill them in on missing information, or propose a solution. You could do this at the break or after the meeting in an email or short discussion. But it’s best to decouple issue resolution from a CA meeting entirely.

There are a couple reasons why this is the case. For one, if you jump on these topics too early, you rob the customer of any incentive to tell you their goals and challenges. They might think you’ve already solved every problem. If that’s the case, they’ve little incentive to share their situation. This is the last thing you want! So, don’t derail the conversation by solving current technical problem during the CA meeting.

Also, by solving tactical problems in the same meeting, you should realize that you are setting misguided expectations of customers. You’re effectively telling them that, when they attend CA meetings, they are getting a team of top technologists and executives to accelerate and prioritize their problems then and there. Not only will you subvert the normal processes for issue resolution, but your subsequent CA meetings may have the customer going through the motions of appearing to fill your CA meeting goals merely as the price to be paid for problem prioritization. This might become their only reason for attending onsite. The customer might leave happy, but you’ll likely walk away with low quality information.

Take care to stick to the objectives of the CA meeting throughout. Don’t mix in other objectives or you risk diluting your results.

Start with uncovering customer goals and challenges.

After introductions, the first order of business is to uncover customer goals and challenges. This may seem awkward, or rude. You may think you need to present your roadmap first, simply out of courtesy. After all, you reason, you don’t want to put the customer on the spot. But here’s the thing: if you fail to diagnose what the customer is trying to do, you may waste everyone’s time talking about present-day solutions that are irrelevant.

If you spend too much time talking about subject matters that customers don’t care about, they’ll lose interest. Once you’ve lost a connection with the customer, the meeting is wasted. Put aside, for now, the product or service you want to discuss. Start by learning what the customer is trying to do, as well as what obstacles the customer is trying to overcome. Only after that full story, from the customer, has been heard, restated, confirmed and understood, is it appropriate for you to discuss anything else. Only after you know what the customer cares about, is it time for you to share your roadmap, technology under development, or solutions.

This can feel awkward. Remember the technical marketing engineer (TME) in scenario #3? The customer was describing a solution she needed – a solution that you had already developed and delivered to the market. It was freely available online. So you told her about it.

Bad move. Do you remember what happened next? That’s right, she stopped talking, she stopped sharing. That was unfortunate, because the entire point of the meeting was to listen to her, not to the TME.

Instead, the TME should have ask questions to understand why the customer wanted such fine-tuned control of the interface. The TME should have sought to uncover the nature of the product the customer was building, and the function she was trying to implement. Instead, the TME provided her with a ready-wrapped solution. In doing so, the team forfeited any chance of understanding what the customer was trying to accomplish. What’s the point of a CA meeting if the team discourages the customer from talking? If the team had, instead, asked questions to deepened their understanding of what the customer was trying to do, they might have learned that she needed to be able to throttle the data flow to specific values, but in real time. A statement like, “customer needs fined tuned control of the interface” is practically useless for the purpose of planning next generation products. However, a statement such as, “customer’s goal is to be able to throttle between 100Mbps and 200Mbps in increments of 20Mbps on interface XYZ – in real time. She needs this capability ASAP and then in at least the next three generations of her product called QLP.” That’s information that could be used to inform the planning of subsequent builds of the software IP. We’ll explore this example further when we discuss how to craft good questions.

Look into the crystal ball.

Notice that what we’re after, the customer’s goals and challenges, are future-looking and aspirational. You want to know the customer’s roadmap: where they’re headed and why. It may feel awkward to start asking about the future, when you haven’t discussed the current situation yet, but start in the future – you must. Don’t worry, as you ask future-looking questions, the customer won’t be able to stop himself filling in details about their current circumstances. However, if you start with questions about the current situation, you’ll find yourself mired in the here and now. You can’t change the here and now. You want to learn what the customer is trying to achieve, so you can build products that they can use … in the future. So start in the future.

As Wayne Gretzky famously said, you want to skate to where the puck is heading, not to where it is. Remember, this meeting is called a customer alignment meeting. You want to align roadmaps. That means you need to know where the customer’s roadmap is headed.

In other words, you want to be like Captain Oveur in the movie Airplane and ask, “What’s your vector, Victor?[1]” Current issues can be noted and addressed later … after you’ve uncovered the full picture of the customer’s future goals and challenges.

Uncover goals and challenges in the realm of the customer’s expertise.

Keep the conversation in the realm of the customer’s expertise. You want to talk about what they’re trying to achieve, not to learn their opinions of how you should design your product. They’re not experts in your company’s technological trade-offs, nor in details of your operational or budgetary constraints. Those are your concerns. So don’t ask them for their opinions on such matters.

Remember scenario #1, when the customer was attacking you with that barrage of unrealistic demands? You played defense, explaining the tremendous challenges that would prevent you from implementing what they were asking for. Here’s the problem, your technology is not the customer’s area of expertise. Instead, get the customer talking about why they require such features, ask them what are they trying to accomplish. That’s their area of expertise, and that line of questioning will get you information that you can use to guide your organization’s decisions.

When you feel backed into a corner, defending your designs, it’s time to turn it around and ask questions to uncover what the customer is trying to do. Use the feeling of defensiveness as a trigger, to remind you to put the questions back on the customer, to ask what they’re trying to accomplish. It may feel like descending deeper into the abyss, but I assure you, it’s the way out.

Uncover all of the customer’s goals and challenges, not just one.

Note that the alignment team’s goals are plural. They are to uncover customer goals and customer obstacles. The customer may have three lofty goals, and five looming, pernicious, and terrifying obstacles in their way. Uncover them all.

Gauge the importance of each goal.

When customers have multiple goals, it can be overwhelming to understand which matter the most. Which do you focus on? There’s a neat, simple trick to assess this: ask them their cost of inaction. Ask what would happen if they did nothing? Ask what would happen if they failed to achieve their goal. The answer will tell you how important the goal or challenge is.

For example, the customer might answer, “If we do nothing, we’ll lose market share to our competitor.” In this case, you know it’s somewhat important but hardly dire. However, if the customer says, “We’ll be out of our jobs,” then you know this goal is of supreme importance. But don’t stop there, strive to quantify the cost. Who will they be losing their market share to? How big is that market with respect to their overall revenue? If you think these questions are too personal or will move the conversation in the wrong direction, then save them for later. But do ask.

To be fair, everything your customer tells you is important. However, that can result in a large data set. Teasing out the most important sentiments puts various insights into context and priority. Knowing the cost of inaction gives you a good idea of the relative importance of each goal and challenge.

Patience is an asset.

Often we walk into customer meetings with our heads full of questions, and we want to ask them straight away. Be patient! Your first order of business is to uncover all of your customer’s goals and challenges. Later in the day, perhaps after lunch, you’ll have your chance. Only after you’ve fully uncovered the customer’s story is it appropriate to ask any questions that do not directly elicit the customer’s goals and challenges.

For example, perhaps you are like Bob and Tom from scenario #4. You want detailed information such as whether the customer will be adopting variant A or B of a new technology, or which operating system they use. Of course you want to know these things as they directly impact your plans. But be patient. While these may be legitimate to ask, they are not appropriate to lead with.

Indeed, you may find that the customer fills in this data as you ask about future goals and challenges. In the course of uncovering, you may find that out of ten questions you had going into the meeting, you’re left with four outstanding questions that haven’t been answered. Wait for the appropriate time to ask them. Work with the host to identify a good time. At the very least, wait until the team has learned all of their goals and challenges before even thinking about asking these very detailed and somewhat self-centered questions. If you ask these too soon, the customer might stop being so forthright? Why? Because the message you’re sending is that all you care about is your narrow set of questions. It’s selfish. The customer would rather answer questions about what they’re trying to do, not what you’re trying to learn.

What success looks like

A CA meeting is successful, if, at the end, you can answer these kinds of questions from the customer’s viewpoint:

  1. What is the customer trying to achieve; what are their goals? For example: What market are they going after? What product are they attempting to develop? When you look at each feature they are developing, what market need is that feature addressing? In which features do their customers care about? In which features do their customers see value, and which features are required without question[2]?
  2. What are the challenges the customer sees that may be in their way? What obstacles will they need to overcome to deliver a winning product to their market place?

Your number one goal in a CA meeting is to see the world from the customer’s perspective, learning their objectives and obstacles.

This sounds easy enough, but beware. We all come to meetings with our own agendas and interests. Your colleague might be working on a project where an implementation decision needs to be made by the end of the day. The sheer urgency of their responsibilities might prompt them to rapid-fire questions about that specific technology at the earliest perceived opportunity in the CA meeting. If they don’t know that uncovering the customer’s story must happen first, they might take over the conversation too soon, and, as a result, fail to uncover the customer’s goals and challenges. This is why it’s critical that everyone on the team work from the same playbook, understands the goals of the team, and follows the proper order of a CA meeting.


The Aligning Team’s Mindset: Focus on the Customer’s Future

The mindset of the alignment team should be one of genuine curiosity. They should strive to be unhindered by bias, corporate constraints, or pre-conceived ideas. Every member puts aside concerns of their own projects. They focus on understanding how customers see the future from their perspectives. Remember those individual agendas that I said are not appropriate in customer alignment meetings? Each team member must leave those behind when they enter a CA meeting. Attendees must clear their minds before they enter the room.

Clear your mind.

We play a central role in our own storylines. We’ve lived them for so long, it can be difficult to assume another’s perspective. But that’s precisely what your job is in a CA meeting. Put aside your own aspirations, agenda, and corporate edicts. Then, simply strive to understand the customer’s storyline, from his or her perspective. Don’t worry, after the meeting has ended you’re welcome to pop back onto your own perspective.

This sounds easy, but it can be difficult, and even scary. Our discursive minds generate thoughts and we like to latch onto them, as if they are a part of us, as if they define us. Letting such thoughts go can feel like a loss of control or a loss of self. For many, this is not a pleasant feeling. I assure you, however, that if you develop this ability, your customer’s perspective can become much clearer.

Sure, I can advise, “put your thoughts aside before entering the CA meeting.” Intellectually, you might agree to do this. But carrying this out can be a monumental task. It takes mindfulness, training, and an ability to step away from being the center of your universe. This section provides some tricks for adopting this clear-eyed mindset.

Let go of fear, corporate edicts, technical constraints

In a chapter one scenario, you were a SME who felt uncomfortable letting the customer go on and on about what he wanted. You felt you were communicating tacit commitment to build what the customer described. Imagine that your company has been clamping down on costs. Executives have decided to halt all developments in the area the customer cares about. How could you sit there and listen to the customer talk about what’s wanted, when you know damned well that your company will not deliver what’s being asked?

My colleague, Andy Turudic, described such a situation to me. He observed, “The biggest problem in the company was fear. (Sometimes) those CA meetings turned into going through the motions. We pretended to listen but mainly, we were telling. For example, (one customer came in) begging for double precision floating point[3]. They came in to tell us about their next generation machines. Their customer had told them, The public utility won’t supply any more electrical power to the building, but we’ve gotta keep doubling the performance every two years. This statement took me by surprise. I don’t know that it was in that particular meeting where the light bulb first turned on, but that was when I first heard it. But our team ignored the comment. They had incentive to not make any mistakes in the architecture, to not do anything risky, and get their bonuses. Plus, they’d been told (by management) that we wouldn’t be doing double precision. This fear, knowledge, and a broken reward system, made them ignore the comment. Implementing (what the customer was asking for), well, we would never do it because it might affect bonuses if it didn’t work out. That was the thing with engineering: the company didn’t want to do anything super brave or new because it might fail. When I talked to the DSP engineers, I learned there were other customers who were asking for this for quite a while, but we kept hand waving and head-nodding. We pretended to listen, but then followed by telling the customers what they were going to do with the features we planned on building. It didn’t include what they needed. It was kind of sad.”

My colleague’s experience was not an isolated event. The thing is, when you’re working to develop a product, there are all kinds of constraints. You’re steeped in these realities day in and day out. It’s almost impossible to put them aside when you’re talking to a customer. But put them aside you must. Otherwise you’ll only see the customer’s perspective through your own filter of constraints, fear, and pre-conceived notions. And you want to experience the world from the customer’s perspective, not yours. I know, it’s difficult, even frustrating. The first step is acknowledging you have your own perspective. Then, do everything you can to shed it for a few hours at least. Here are some tips for getting into such a mindset.

Cultivate a compassionate nature.

The team’s objective is to learn the customer’s story straight away. Cultivating compassion is the first step in seeing the world from the customer’s perspective. Straight away, as the meeting begins, set an intention to learn what the world looks like from their vantage point.

If shifting your perspective is not a straightforward exercise, then consider reading the book, Nonviolent Communication, A Language of Life, by Marshall Rosenberg. (You’ll find this, and other recommended reading in the appendix). In his introduction, Mr. Rosenberg describes the first time he was bullied by a classmate. The bully was full of hate, and called him a derogatory name. Little Marshall had never encountered such venom. Despite the hurt he felt, his primary reaction was curiosity. He wondered why the bully was behaving that way. He wondered how he could maintain a compassionate nature even while feeling attacked, so that he could still regard his attacker as human.

He cites a more extreme case, that of Etty Hillesum, a Jewish woman who kept a journal while interned in a Nazi concentration camp during World War II. In that journal, she described how she maintained compassion for the German guards, even as they yelled at her. Instead of focusing on their words, or how their tone hurt her, she looked into them, deeper. With compassion, she saw human beings, struggling with frustration and anger. She wondered about their childhoods or their struggles with relationships. She saw that they were human like her. She longed to help them work through their issues.

Dang, we’re not even a quarter way through this book and I’ve already succumbed to Godwin’s law[4]. Ah, that’s fine. My point is this. In the chapter one scenario, you felt attacked by the customer. You focused on your own story – on how the customer’s requests would make your life difficult. You made the customer into a problem to be vanquished. If your mindset had, instead, been that of a curious, compassionate nature, you might have avoided taking a posture of defensiveness and self-absorbed interest. You would have taken a closer look at what the customer was really trying to do. You would have asked the customers what was motivating the requests, rather than being annoyed that they were being made.

It’s all fine and good to understand that your job is to uncover customer goals and challenges. Until you cultivate a compassionate nature, however, you may find your own thought processes will get in the way. Until you are able to put your agenda and constraints aside, and focus on those of the customer, you may find yourself in a defensive position, and deaf to what’s being said.

So when you feel yourself being ‘attacked’ by a customer who is making unrealistic demands, remember Ms. Hillesum or little Marshall Rosenberg. If they could cultivate compassion for their human abusers, so can you for a customer who cares enough about your product to travel half way around the world and dedicate an entire day to discussing it with you. Focus on customers, and let curiosity guide you in learning about their situation.

Put on your detective’s hat.

This may sound corny, but in my experience, the simple act of imagining you’re a detective, you’ll find it easier to shed your own agendas. If it helps you to get in the right mindset, imagine you’re none other than the masterful Sherlock Holmes, hot on a case to solve the greatest mystery of all: the customer’s goals and challenges. You’ll dispassionately collect clues, and ask probing questions throughout the meeting to put together this picture of truth. Who cares if this imagery is corny; if it works, use it.

Your job is simple. It’s no longer to plan products, but rather, to unearth clues. At this point it’s easier to see the world from the customer’s perspective.

For practice, or if you’re skeptical, try it out on friends and family and you’ll see it works quite well. With spouses, your mileage may vary. Buyer beware. Actually it works with spouses too, but if something goes wrong, all liability is assumed by the user (you).

Cultivate a Growth Mindset.

Another mindset complements all of the above: a growth mindset. This is an open minded attitude seeking continuous learning, and it’s key to understanding the perspective of the customer.

People with growth mindsets believe that anything can be learned. They regard failures as learning opportunities. They let curiosity lead them, whether they look foolish or not. In fact, looking a fool scarcely matters to someone with a growth mindset; their objective is to learn, and be enlightened, not to protect an image.

The book Mindset, by Carol Dweck, compares two ways of thinking: fixed mindsets versus growth mindsets. In a fixed mindset, a person believes that achievement comes from natural ability and failure is an indication of ineptitude. In this mindset, the entire world is a judge, and eyes are constantly evaluating performance. People with fixed mindsets strive to protect their reputations from such judgment. As a result, they pursue experiences that safely bolster their self-esteem. It keeps them stuck in their own perspectives, and renders them unable to shift perspectives to that of the customer.

Whatever mindset you tend toward, I believe there’s something to be gained by reading in Dr. Dweck’s wonderful book. Once you’ve adopted a growth mindset, it’s much easier to be compassionate, to mentally put yourself in the customer’s shoes. Besides, my dear Watson, detective’s hats fit only those heads that contain growth mindsets… and that’s the hat you’ll be wearing in all CA meetings. But do remember, smoking a pipe is not legal in the workplace in California.

Reserve Judgment.

You and your teammates are embarking on a delicate mission. Your goal is to learn what the customer is trying to achieve without leading them or pursuing your own agendas. This is easier said than done. Add to this the need to cultivating compassion, genuine curiosity and a growth mindset, and you have a team of people operating beyond their comfort zones, taking risks, and potentially asking questions that make them look stupid.

Be gentle. Rather than judge a teammate to be an idiot for asking a question that’s out of their depth, support them. After the CA meeting, complement them for taking a risk. Offer to review what happened and come up with strategies for improving.

Later, you’ll learn a questioning technique that makes someone on the team look deliberately foolish. Realize that it takes real courage and a growth mindset for a colleague to put themselves out to look like an idiot in front of their colleagues. Be part of making the team dynamic safe by reserving judgment. Use the post-CA meeting forum to review and improve.

Focus on the Customer.

During the uncovering sessions, when you find yourself about to talk about your trade-offs or your product details, stop. A CA meeting should be held in the customer’s realm. Get back there as quickly as you can. Put on your detective’s hat, think with a growth mindset, tap into your compassion. Instead of explaining your constraints, ask your customer what exactly they think a specific feature request will do for them. What problem will it solve? What objective will it help them drive toward?

Focus on the Future.

You start the CA meeting by asking about future objectives. When you align two vectors, you need to know their direction. So ask about the customer’s direction. Don’t worry, they’ll fill you in on relevant details about today’s projects as they answer.

Keep those future-oriented questions up until you are absolutely sure you’ve uncovered the full story. You keep asking about your customer’s future goals and challenges until they’ve shared everything. Only then is it okay to ask about today, or, sparingly, about the past.

Customer Aligning Mindset in a Nutshell.

Attendees should come to CA meetings with open, growth-oriented, people-oriented, future-oriented, and customer-oriented mindsets.

Yes, the team can bring presentations, questions they’re dying to ask, and information to share. But it should all be put away until those two key questions, What are the customer’s goals and What are the customer’s challenges, have been answered – in full. The first order of business is uncovering the customer’s worldview. Until it is understood, all other business should be put aside.

For example, put aside any preconceived notions you might have. Do you think cost is the main constraint customers care about? Are you looking to confirm that opinion? Don’t. Put all thoughts of cost aside as you enter the meeting. Do you think all customers want higher performance, and even if they complain about high power, they’ll find a way to work around it? Stop. Put that idea aside and pretend like you have no idea what customers want. Only in this mindset will you be capable of uncovering the truth. Don’t worry, you can bring your preconceived notions to the table in the latter part of the meeting.

If you have difficulty with cultivating such a mindset, I strongly advise you read the two books mentioned in this section: Nonviolent Communication by Marshall B. Rosenberg and Mindset by Carol Dweck.

Whatever tactic the team employs, it’s critical that attendees clear their minds, and learn, in the customer’s own words, what the customer’s objectives and challenges will be.




[1] Captain Oveur, Airplane! 1980

[2] We called such features, “table stakes.” In other words, these features are 100% required and obvious, the customer might not even mention them. If you are at all unsure whether the customer cares about these “table stakes,” then wait until the second part of the meeting, and confirm these requirements then.

[3] Double precision Floating Point is a number type that can express very high precision fractions to a computing unit. In other words, it doubles the number of digits after the decimal point to reduce rounding errors for numbers subjected to many math operations.

[4] Godwin’s Law states that every online discussion, if left to go on long enough, will eventually mention Hitler or Nazis.