(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 supplier has you by the ovaries 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
 ASSP = Application Specific Standard Product
 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?