Back to resources

Focusing on Customer Problems


18 March, 2021

Jeff Champa

Jeff Champa

Vice President Product Management at Lexipol

Jeff Champa, Vice President Product Management at Lexipol, shares how he joined the company that was implementing a complex project without anyone being able to pinpoint why they were doing it.


When someone joins a new company that is in the midst of implementing a complex problem, they would, by default, assume that people in the company know what they are doing. Well, that happened to me. A time ago, I joined a company that was implementing a large project already in flight. I started helping the team move the project forward by dealing with blocking and tackling common for any project.

What we wanted to do was to merge two SaaS systems following the 1+1 equals 3 equation. We were in the latter stages of the project when we started to look at our migration plan from a customer’s perspective. We were curious how we could move customers from the old to the new system and make it a great experience for our customers.

Actions taken

It seems that no one ever asked why until we hit the first bump on the road. We wanted all the new technology to be backward compatible with the old technology and that a user could log in, try the new technology and then go backward. Once they would be ready, they could log into the new system. However, our technology team told us that they couldn’t do that.

We had this large project and a hard deadline breathing down our neck. Since I wasn’t happy with the capabilities we were planning on delivering to the market, I started to ask why we were doing this in the first place. I was shocked to realize that the answer had nothing to do with what customers wanted. Things customers were concerned with didn’t require us to merge two systems together and go through a painful migration process.

The problem was that it was a large project, and everyone was rallied around it. Things were moving forward by inertia, and no one was asking why. It seemed that everyone was assuming other people figured it out, and no one asked what the customer problems we were solving.

When I asked if customers would be happier after migration, I was told that they would get new features. I was curious to learn how many of them asked for those features, and to my surprise, no one could answer the question. Fortunately, it was not too late to pivot the strategy and get the features customers wanted without having to go through a difficult migration process. But, more importantly, we managed to keep our customers’ scores rather high.

Lessons learned

  • In many cases, asking why in a big meeting may go bad. I had a series of conversations with other VPs and C-level executives to convince them that pursuing this project was not a great idea. It is important to secure the support of leadership when you are challenging important projects, particularly those already in flight. While asking why may look like a simple question, it can detonate in the midst of a meeting and cause people to become upset.
  • Asking why will save you a lot of time, and it is never too soon to revisit the why. When a team gets hunker down into the details, it is hard to come back out and reassess the big picture. We lost some vital development time trying to merge the systems that we could use to develop some more features or go to market a bit sooner.
  • Having one-on-ones paid off. Talking individually to various functions also helped them secure support from their own teams. When we decided to pivot from the original plan, there was agreement and alignment across all departments.
  • Reassess regularly all of your projects. Ask yourself, “Does this still make sense?” You can start off with good intentions, but implementation can take a twist left or right. The team may have a valid reason to take that twist, but once they do, the whole thing is out of alignment.
  • If you think your actions will cause pain to customers, don’t do it and find another approach instead. If you have to cause them pain, make sure that the benefits will outweigh the pain.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader

Related stories

A Day in the Life of a Product Lead in FinTech – A Series

31 January

Discover the daily struggles, challenges, and moments of delight encountered when delivering banking products around the world. I will share my story candidly and honestly, without filter as much as I am allowed, and offer insights into my approach while providing retrospectives of the results.

Embracing Failures
Cultural Differences
Career Path
Loussaief Fayssal

Loussaief Fayssal


How I failed at my startup

14 October

There are nine specific building blocks and functional areas every org/company need to work to launch the product and provide services to customers. How effectively founders tackle them determine the destiny of the company.

Mission / Vision / Charter
Scaling Team
Building A Team
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

How to Organize, Manage, and Grow Your Team

12 July

Vineet Puranik, Senior Engineering Manager at DocuSign, discusses the impact of roadmaps, organization, and proper management for your teams to procure growth.

Managing Expectations
Vineet Puranik

Vineet Puranik

Senior Engineering Manager at DocuSign

Bootstrapping a Startup While Working Full-Time

23 June

Lucjan Suski, CEO & Co-founder of Surfer, relates how he started a company as a side project and shares his insights on bootstrapping tech startups.

Innovation / Experiment
Lucjan Suski

Lucjan Suski

Co-founder, formerly CTO and CEO at Surfer

Managing Through a Team Reorganization

15 June

Mugdha Myers, former Engineering Manager at Google, discusses the challenges of leading a team through the ambiguity and anxiety caused by a large-scale team restructuring.

Changing A Company
Changing Company
Mugdha Myers

Mugdha Myers

Engineering Manager at N/A