Yes, You Can Meet 100 Customers Per Year

Create the Company Culture that Wins by Focusing on Your Customers

Jim Morris
Jan 7, 2019 · 13 min read
Image for post
Image for post

I used the process below to personally meet with 100 customers per year. Including my team, we got into the hundreds. You don’t have to worry about reading customers’ minds when you can ask them good questions directly. Having the entire product team and engineering leadership meet weekly with customers brought customer awareness in our company to new heights. Product and Engineering teams cannot “outsource” customer insights to the customer facing teams (sales, marketing, client success, customer support) and expect to make products that win.

Others feel this way: here and here.

Including the product development team in customer meetings brought our thought leadership to bear every week. Not only did this show more empathy for customers, it resulted in better products coming out of engineering.
— Matt Parsons, EVP, Client Success, Registria

Attend 100 meetings per year with these practical steps:

  • Meet with 2 customers or prospects each week (one hour each)

Constant contact with customers keeps them top of mind. Many of our internal ideas fell to the way side when presented to customers. And many of our best ideas originated from customers.
— Erik Skurka, Head of Product, ReviewTrackers

Overview of the process for sustainable customer meetings:

  • Require pre-meeting questionnaire

Require pre-meeting questionnaire

To be useful in the meeting and to make preparation for the meeting painless, I asked the client facing teams to fill out a one page questionnaire about the prospect or customer and put it in a known location on our shared drive. (Having a shared drive such as Google Drive, Box, or Sharepoint is crucial to efficiency). This questionnaire had no more than 10 questions and provided exactly enough background on the customer and the state of their relationship with our company that I could be a credible participant in the meeting (same for my team members). The client facing team should know this information before getting on the call anyways so it shouldn’t be that much extra work. I could read the questionnaire in the 60 seconds that the video conference was starting up.

Sample questionnaire questions

  • Names and job roles of the people from the customer or prospect who will be on the call

Follow ground rules for meeting with customers

So what do you say in these meetings with customers and prospects? It is assumed that you, the product team and the engineering leadership are the company experts about the company product offering and how companies use that product in the market. The client facing teams often don’t have that depth of knowledge and from my experience really appreciate having an expert on the call. Some companies use Sales Engineers to fill this role but not every call has a Sales Engineer in attendance and your team can fill that role. Make sure that these basic expectations are followed by you and your team when participating on client facing calls.

Ground rules for meeting with clients and prospects:

  • Don’t promise any additions to the software platform (it’s always tempting to be a pleaser)

Write down observations in a consistent way

For most of the meeting, you’ll be in listening mode. Feel free to jump in and clarify things for the customer but take your colleagues direction on how much to talk. After a few of these meetings, you’ll see how your colleagues represent your company and your product offering. You’ll also get the hang of when to talk. While you’re observing you can take the following notes.

Observation notes to take:

  • Company/Product representation. When you first attend meetings you might be surprised about how the company’s product offering is being sold. Note down anything to add, modify or remove about how the client facing teams represent the company’s product offering.

Ask customers consistent questions

So you’re not just there to be an observer. Typically, the product development team creates several slides to present at the end of the customer meeting. Everyone uses the same slides and the slides are updated once per quarter. These slides cover the current state of product development and strive to get insights from the customer. You want to pull information out of the client at this stage not just keep pushing information.

Include these items in your part of the presentation to the client:

  • Recently released features (with business benefits)

Quickly (but smoothly) go through the product update portion. Then transition to a discussion meant to extract insights to benefit the entire product development organization. Engage the customer in a series of questions to understand their situation with the goal of understanding how to be indispensable to them now and into the future.

Questions to ask of the customer or prospect:

  • Where do they think your product offerings make the most positive impact on their business?

Demo potential products and ideas to elicit feedback

Once you’ve covered the larger questions, you can spark discussion about the future direction of the product offering. For some ideas, you might need an NDA to proceed. For existing customers, this should already be in place. It’s a good idea to remind the customer that there is an NDA and that these discussions should be kept confidential. For prospects, it might depend on whether they have signed an NDA.

For new software not necessarily in development, it’s a great idea to get feedback early and often in the process (don’t develop in a vacuum). This is the beginning of a Customer Discovery Program and certainly not the only aspect. Some companies insert a disclaimer slide about future offerings to explain that they are not guaranteeing the delivery of the products about to be described. I would always add that these products are not being sold yet and that we are using these demonstrations to elicit feedback from customers. If enough customers declare interest in buying the software then we would proceed with development.

I might do a screen share and show a prototype or just describe the potential product. Then you want to capture the interest of the client by asking what problem it would solve for them and whether they would pay for it. Make sure to find out if the solved problem is big enough for the customer to spend money or just an annoyance that they would not seek a solution for.


So there you have it, in two hours a week, you can now sustainable meet 100 customers in one year and get insights into your product offering and the customer’s business as well as getting directional feedback on the usage of your product and their interest in your potential future offerings.

Remember to transcribe these notes immediately into a centralized folder or even a centralized document. Each week, these consolidated notes should be passed around and reviewed by the product development team. Highlights should be brought up by individuals at group meetings to make sure that key insights are being disseminated. Learnings should be incorporated as soon as possible into the Product.

This is the start of the continuous dialog with customers and prospects that keeps the product development team and its product offering relevant and important to the market.

Common Barriers to User Testing

Agile Engineering is useless because you’re sending ideas to the engineers without having user tested them

You have the best engineers that recruiter’s fees can find and you’re wasting their time. Untested ideas are the business equivalent of guessing. You probably don’t let your finance team guess at the numbers when closing the books. Why would you let your Product Managers guess at ideas and occupy precious engineering time.

I know why you are sending untested ideas to engineers. These are the common barriers to user testing.

  • You’re too busy

You’re too busy

You’re a Product Manager and your boss told you that you’d be the CEO of your product line. Sounds great until you realize that you’re actually responsible for everything in the software development lifecycle. You run the agile team. You write the documentation and release notes. You make your own wireframes. You try to do your own user testing. You do the marketing and social media outreach. All while keeping up with current trends in an amazingly fast moving environment.

Soon enough, you’ll be sucked into every part of the business as the subject matter expert, sales engineer, product marketer, customer support agent (gasp!) and slowly you’ll stop creating new and interesting ideas. You’ll be overworked so your creativity will plummet. You get too close to deadlines and do the bare minimum to get through meetings with the executives by making elaborate mockups and presenting confidently. Bad idea. You should push back. Eventually the metrics will bear out that your ideas were just guesses. Mediocrity is inevitable.

Don’t have right kind of Designer on staff

Many people educated and employed in the field of Design are Visual Designers and Graphic Artists. These professionals were more common in the early days of Internet development because of the transition from traditional media where these designers were in high demand. Marketers, MBAs and executives tend to be more comfortable with these types of designers since they are still in the push mentality of business where branding, beauty and boldness are more important than usability, value and simplicity. Don Draper wins every time when we mistake Advertising and Branding for User Experience. Television and Radio are the land of Advertising and Branding. Websites and Apps are the land of User Experience. Don’t confuse them.

Every tech business needs a User Experience Designer (or UX Designer for short). Other folks call it a User Interaction Designer (UI Designer) or Director of Usability. If you can have only one designer on staff, choose the UX/UI designer. You can always outsource the Visual Design at the end of the project when you know your User Experience is awesome. One way to justify this choice is that modern designs for websites and apps are likely simpler designs in the age of Mobile First.

Wrong team in place

Simply put. You likely don’t have a qualified UX Designer on staff. Stop here. Find one. That’s your top priority.

If you have a qualified UX Designer, then read on.

Do you have enough of the core Product team to cover the necessary areas of Product Management?

  • UX designer owns the user

You’re lucky and smart like Steve Jobs and Elon Musk

In Silicon Valley, the stories of Steve Jobs (Pixar, Apple) and Elon Musk (PayPal, Tesla, SpaceX, Solar City) are legendary. You are not them so how can you succeed. It’s all about raising the probabilities of success and having less reliance on luck and guessing. You can raise the probabilities of success by meeting users and investing in user testing. Get that probability higher by eliminating bad ideas and nurturing ideas with potential. Expand and tweak the ideas that your target users love not necessarily the ones that your CEO/Founder/stakeholder loves. Without testing, you might eventually deliver the right product but that’s right up there with the concept that thousands of monkeys banging on typewriters will eventually deliver a Shakespeare quality play.

Unfortunately, many product teams are dominated or even run by the CEO or Founder or stakeholder. In practice, this is how most companies are starter. Too often, ideas go straight from the CEO to the engineer without any user validation. Venture Capital funding should not be seen as the validation of an idea. That money should be used to evolve that initial idea so that it works with the market and users to make a great product. This is the wise premise of the The Lean Startup.

You have as many engineers as Google does

Most companies don’t have hundreds of engineers. Google can launch 50 products and be successful if just a handful win. Your hit rate must be higher. You probably need to have 1 winner for every 2 or 3 products that you launch. You can raise that probability of success through user testing. Google does user test their products but they have a much wider margin of error than all other companies.

Never tested ideas before and don’t know how (no culture of testing)

Maybe you have an engineering focused culture. Maybe you’ve never tested before. There’s no time like the present to start. Pick up a copy of Inspired by Marty Cagan or go to one of his public workshops. In the meantime, sign up for an account on and start running people through your existing website or app. Ask them to compare and contrast your site with your top competitors. If you’re a self-improver, you’ll find plenty of things to improve via these simple tests.

Before you send those new mockups to your engineers, run some comparison tests with your current website or app using the site You’ll appear more confident in front of others when you tell them that you worked with target users to choose the company’s next user interface through repeated testing rather than the usual technique of “Just trust me”.

Users don’t know what they want

You believe that feedback from any given user is just anecdotal. Once you witness the confusion experienced by a couple users at your seemingly “ready for engineering” mockup, then you’ll start to believe that a few users can teach you quite a bit. Start with a few user tests and you’ll quickly notice and then fix confusing user interface elements before you send your design to the engineering team saving a few weeks of wasted development.

Don’t boil the ocean with each round of user testing. Boil a thimble.

You might work for a Deadline-Oriented Perfectionist Executive

As a Tech Executive, you have taught the team to present concepts with finished pictures and polished mockups. Why not. This is what you’ve been used to for years. When presented with a concept, you tend to ask questions about the visual design or marketing…Is that the right color? Is that link or button in the right location? Is the name of the feature correct?

Instead, ask what users thought of the concept. How did the concept evolve from the beginning to what you are seeing now. Understanding this evolution is key to understanding how your product team is engaging with your target market and will make the company smarter and more nimble.

Fair enough, but maybe the team is too slow. So you set a deadline for a presentation on a new concept. Combine this deadline atmosphere with a line of questioning that always focused on the look and feel of a concept (rather than its usability and value) and you might be working for a Deadline-Oriented Perfectionist Executive. This is typical since many executives don’t know how to manage Product teams. Unfortunately, this environment relies too much on luck. You’re not encouraging your team to evolve their ideas through working with users.

You’re not giving them the time to test and the intellectual space to fail.

Time and space will raise the probability of success and reduce the reliance on luck. Remove educated guesses…insert evidence. The transparency of explaining and publishing the actual tests within the company will increase buy-in. You can still create deadlines but those should be focused on milestones such as completing the first prototype, completing the first round of testing, turning around the learnings from user testing in a fixed amount of time. If you move in this direction, the team will likely let you know what’s getting in the way of testing and then the real conversations in a successful product-oriented business begin.

Jim Morris founded the Product Discovery Group to make Product teams more productive, happier and more successful by coaching techniques like Customer Discovery Programs.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store