Understanding Your Customer's Business is More Than A Few Conversations

Bill Hoberecht - This email address is being protected from spambots. You need JavaScript enabled to view it.

Having a series of discussions in a conference room to answer the question "What are your problems and needs?" is probably insufficient if your desire is to be a trusted and strategic partner that provides solutions having significant benefit to the business.Here are three methods that long-lived program teams and I have used to develop a deep understanding of the customer (a business unit) and their needs.  Think of these as more advanced methods appropriate for large programs.

 

It's easy to for a program to deliver high value: simply ask the customer to identify their problems and then provide a solution.

Except it doesn't work that way in real life.  Sometimes customers have a solution identified before talking with the technology team, and you never learn about the true need.  Other times, they are fixated on an immediate problem without regard for more significant strategic needs.

Leading a program involves sorting through these dysfunctions and employing a variety of methods to define a program that best supports the business.   I've led IT teams developing products for consumers as well as teams developing systems used by business units.  This article focuses on the latter case.

Approaching IT with a solution (rather than a need) is a behavior that probably seems natural to business unit leaders.  It's an approach I assumed would be effective when purchasing a car a few years ago.  Until I encountered Kim (a top performing sales representative) who guided our interactions along a very different path:

  • Initial Approach: Purchasing by specifying the solution.  I did some research and approached this car purchase as a transaction.  I walked into the car dealership, specified the car I wanted (the solution) and then expected to make a purchase following the car dealership practices.

 

  • Redirected Approach: Understanding me and my needs.  Kim engaged me with probing questions aimed at understanding me before we ever got to discussing vehicles. We had a fair amount of discussion on why I wanted a new car, my intended usage, and much more.  Kim approached the interaction as an opportunity to build a long-term, strategic relationship.

 

  • Experiments/prototypes and feedback. Kim got us into a few different vehicles and asked for my reaction on the interior layout and features, along with feedback on driving characteristics.  This clarified and refined my needs.

 

  • Agree on a solution.  With information now surfaced about my needs, much of which I had not previously considered, we looked at vehicle options.  I selected a vehicle that was the best fit and we proceeded to finalize the purchase.

 

Kim wanted to establish a long-term relationship and didn't want to sell me a vehicle that would disappoint - even if it was the vehicle I had requested when I first walked through their door.  Employing a variety of probing and discussion techniques, my needs and desires became visible and led me to an informed decision on the vehicle to purchase.

So how does your technical program team discover the needs of a business unit?

Having a series of discussions in a conference room to answer the question "What are your problems and needs?" is a start.  But probably insufficient if your desire is to be a trusted and strategic partner that provides solutions having significant benefit to the business.

Here are three methods that long-lived program teams and I have used to develop a deep understanding of the customer (a business unit) and their needs.  Think of these as more advanced methods appropriate for large programs.

These techniques are all predicated on having a high degree of trust between the program team and the leaders of the business operations organization.  Another precursor is having a view of the future - a vision for the business and a corresponding vision of the supporting technology.

 

Develop Shared Goals

It's hard enough to get various IT departments to have shared goals, as program managers have no doubt experienced leading cross-function program teams.  Operations is measured on stability, development on meeting commitments, cybersecurity on intrusions, and so on.

These are each important goals but might get in the way of aligning a program team on delivering value to the business unit.  A long-lived program team should have goals that are directly in support of the business, and my preferred method for this is to have a few common goals that are shared between the business unit and the program team.

If your company has periodic goal setting (e.g., OKRs) and periodic performance mechanisms, then utilize that infrastructure.  A program manager can be more impactful that just having some goals in listed in a program document that can potentially be ignored.  Create goals with teeth that are incorporated into visible organizational scorecards.  These goals can serve to build deep alignment that persists under trying conditions.

Such goals are generally in the language of business value and the target outcomes resulting from the combined efforts of the program and the business unit.

 

Integrate into the Business Unit's Leadership Team

Attend and participate in business unit management meetings, along with any periodic all-hands meetings. 

The topics discussed in these management meetings are an important source of information to help you confirm and reconfirm that the outcomes expected from your program are still relevant and important for the business unit.  The discussion points will also help you identify emerging priorities for the business where the program team might be able to make a significant contribution.

A big "ah ha" for me has been the discovery that surprisingly little time is devoted to discussion of their technology needs. They are operating a business unit and devote significant energy on personnel issues, morale, budget management, business unit performance management (KPIs), progress on achieving goals (OKRs), long range strategic initiatives, and other topics. 

I've found that participating in these meetings provides more information about the business unit than you can ever learn by interviewing those same managers.  Listen attentively for unstated technology and automation needs that are implied and follow up on areas for more in-depth discussion and discovery.  Mash this intelligence with the technical team insights on the "art of the possible."

 

Gemba - Job shadowing

Visit with individuals in the business unit who use your technology/systems/applications.  Observe their workflows, seeing how they use your solution to accomplish their job responsibilities.  Are they using the features as envisioned?  Does the solution enable performing their job function or does it impede?  Will the upcoming solution delivery be of value to those who will use it?

This is a continually performed opportunity to observe the operational value stream that ultimately provides value to end customers.  It's a chance to ask about job responsibilities and how your solution helps today and could be more helpful in the future.

Most of my job shadowing has been in healthcare, with nurses and MDs providing remote and in-office patient care.  If your shadowing visits are like some that I've had, you'll find that most people use multiple applications with inconsistent user experiences, that the individuals are experts in using a narrow set of features specifically for their job workflow, and they are lightning fast.  Just about everyone I've met with has helpful ideas and requests.

Job shadowing requires some easily accomplished preparation.  The agreement and support of business leadership is essential.  Some information introducing shadowing and the reason for the visits will be needed.

The program team members who participate will need some guidance on handling unexpected questions.  We've had questions about elevator repairs, dates for delivering features mentioned during shadowing, and even a question or two on company HR policies.  Prepare your team with suggestions on handling off-topic questions that may arise.

Job shadowing is inherently a 1:1 activity, yet the learnings can be valuable for others.  Have the program team members write a short note on the learnings from that visit.  Share this information openly with program team members and business leaders.  Have a mechanism to analyze this information for follow-up discussions with business leaders and the program team.

In the years following my in-depth discussion with Kim, I continue to be elated with my vehicle purchase, and have since purchased two others!   Kim's approach was quite effective in shifting the discussions towards discovery of needs before we ever touched on possible solutions. 

 

What are your techniques for understanding your customer well and leading a program that can deliver the best value?