Focusing on Customer Problems

Problem

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.