Crisis management has always fascinated me. At least from the perspective of the watcher, I think it’s analogous to the train wreck or car accident you know is about to happen, but can do nothing to stop. Despite tons of research, thousands of articles and hundreds of classes, we still seem to have learned nothing. If a crisis hits the level of being called a crisis, it’s already too late. At this point, an issue has escalated to such a state that it warrants crisis management and involvement at all levels of organization.
Too often that “involvement” includes only a narrow definition of “all levels.” Look only as far as recent news stories and you find that more often than not, the people managing the crisis have very myopic views of inclusion and leave off a fairly large contingency of stakeholders. One wonders what the insular group has to gain from excluding those most unlike themselves. Unfortunately that includes the most vulnerable. Kim Crayton (@KimCrayton1 on Twitter) speaks often on the how the “lack of inclusion is a crisis/risk management issue”. She also authored “prioritize the most vulnerable” and “intention without strategy is chaos” as part of her Profit without Oppression guiding principles. It would seem to be that we could all take a lesson from her book on how we approach our next “crisis.”
In my observations, we see those in crisis doubling down on this foundational error by making decisions in isolation and ultimately not including those who will be most impacted (or often most knowledgeable). If we as decision makers and participants would take a step back to think through our true intentions and made sure to bring the most affected to the table, we might ultimately be more successful in avoiding the crisis in lieu of the management.
My team spans timezones and continents and first languages and areas of expertise. We manage ongoing customers and new project implementations. In the pre-pandemic days, we crossed oceans and land masses to learn and laugh and share together.
For most of us, the pandemic hasn’t been easy. We’ve been uprooted from routine, separated from our family and friends, or maybe, quarantined too close to them. My team has stood strong through the changing dynamic and I’ve learned a lot from them. My team
Thrives on challenges – As our customers were responding to the pandemic and pushing us for solutions, my team got engaged and excited to deliver on those solutions. They truly looked to the uncertainty as opportunity and delivered on it.
Supports each other – as life continued, we together celebrated successes and life events and showed compassion to schedule changes or adjusted to uncertainty. They showed flexibility and compassion with each other and sometimes with themselves.
Craves the connection – not surprising given the general closeness of the team, but the remote work left us all craving our connections to each other. Zoom fatigue and increased workloads and life interruptions makes it hard to prioritize those virtual meetings, but 1:1 check-ins were much appreciated.
Needs to smell the flowers more (and nurture the roots) – sometimes we get so caught up in the issues of the day, we forget to focus on how far we’ve come or what else we need to do to cultivate our roots to make our ecosystem stronger.
Needs more bees – Just like nature, we need an army of bees to bounce around between the team members, and expertise and cross pollinate the knowledge. As an organization, we have a fairly strong set of documentation but still have challenges with its maintenance and ensuring it’s consumed and recalled when it’s needed.
Clearly, I have spring on my mind given the flower and bees analogies. I’ve been very lucky to have the team that I’ve had during this most challenging of times. We did a see a bit of turnover, but we were also able to bring on some new talent that invigorated the team dynamic, despite the remote onboarding and continued work. We continue to get challenged by what is going on in the world, but I know that we’ll be able to pull together to deliver the best we can.
I’ve often found myself in roles at the intersection of sales, professional services and support (and as an extension, product, although not directly relevant to today’s post.) Throughout my career, my selling style has really evolved into the valued partner, solution expert who can help customers or prospects leverage whatever product/service I’ve been associated with to solve their problems. I’ve noticed recently that it’s much less about the product or service, and much more about aligning to the dream.
It used to be that I would leverage our core values to demonstrate how we can fill the gaps in each organization. As a general matter, this helped establish myself as an expert, but it didn’t resonate as well with my audiences because they would latch on to one or two smaller points rather than grasp the big picture. My next shift had me emphasizing truly meeting customers where there are to solve very specific problems and using that as a basis for a broader conversation of what solving those problems will enable them to do and how it will help them solve much broader goals. I think there is still another evolution in the language of value and being able to leverage your content, your demo, your expertise to enable your audience to truly connect your words and images with their dreams (realized or unrealized).
As I mull through this problem, I started some research and came across The Secret to Selling SaaS – Value vs. Product blog post that references this phenomenon as ‘crossing the chasm’ and states “a customer can go 57% of the way through the buyer’s journey, but still not understand what you’re selling.” And this is very much describes what I’ve been feeling like recently.
An extension of this problem is that the disconnected conversation often results into a directional shift focused more on price and feature/functionality versus really aligning to the audiences goals and vision. Ultimately these opportunities are smaller and less valuable to the customer.
I think my biggest take away so far is that I shouldn’t second guess my methodology and thought process around the importance of having discovery calls and understanding the problem we’re trying to solve before jumping right into to demos and technical discussions. Without it, you can lose your grip on the opportunity and can’t possible promote the right value proposition if you don’t fully understand the audience or their goals.
I think we all know that “toxicity” is bad, but when you are in the middle of a toxic situation it’s difficult to think beyond the immediate moment. It’s very much like sitting through days of rain, or hours of a hurricane without power. You know there is sunshine and rainbows somewhere beyond it, but it changes nothing about the current situation.
These types of situations happen in implementation projects as well. I don’t want to spend any time on the sources of toxicity, but more importantly, what happens after you are able to successfully remove it. Below are 3 key positive outcomes that can arise.
The entire tone of the project changes
Once you have been able to remove the toxicity, the tone of the entire project can change. It doesn’t happen overnight. You usually need to spend a bit of time retooling the project plan, realigning resources and level setting expectations. The project team can grow closer together for going through the shared trauma of the experience.
Improved efficiency
Toxicity encourages bad behavior. It makes team members less likely to speak up, share ideas and innovate. Why would/should you bother if those ideas will just get shut down. Once the toxic environment has been cleared, those previously silenced lines of communication are re-opened and those creative ideas start flowing again. Team members find and implement innovation and process efficiency. The biggest challenge here is ensuring that the questions raised are done so in a constructive way. You don’t want to risk putting these opportunities at risk because people are reacting to where you came from as a project team rather than seeing it for the positive impact.
Improved communication
It can be truly refreshing to see the lines of communication open after the shared experience. As the project manager, it can be incredibly frustrating to find out all the things that hadn’t been communicated previously. Take a moment to acknowledge your frustration, but then let it go. This speaks more to the situation than you it does for you as a project leader. Everyone was feeling the negative impact and people didn’t feel comfortable sharing. The power that the toxicity had over the project is very legitimate. Be understanding and positive – the other team members now feel comfortable sharing with you. This will make the remainder of the project much more successful.
Conclusion
Toxicity sucks just as much in project management as it does anywhere else. The goal as the project manager is to diagnose it early and do what you can to minimize it, or even better remove it. Once you do that, plan a conscious project reset – schedule, team members, expectations, etc.
The standard process for selling software to customers involves sales driving the sales process then handing over to services for implementation and ongoing support. Sales people are incentivized to sell more, but services is ultimately responsible for delivering. Even in scenarios where services is involved in some portions of the sales process, more often than not the contract that is ultimately signed contains an element of surprise for services.
The Technology Services Industry Association felt this was an important enough issue to address as a theme at their 2018 conference. Bo Di Muccio, Ph.D., distinguished vice president of research, Professional Services, for TSIA, expressed the problem simply as a disconnect between supplier and consumer objects.
“This is because a rigid separation of sales and service motions is a way to guarantee (even exacerbate) a disconnect between supplier and consumer objectives. This is something TSIA has been documenting for some time. The traditional CapEx tech sales model is a “make, sell, ship” concept that is, quite frankly, more or less completely focused on the need of the supplier to sell boxes, software, speeds and feeds, etc., and almost not concerned at all with the customers’ use of the solution or their business value in adopting it. The role of Services in that model is to implement what’s sold by Sales, offer some training on how to use it, and fix it when it breaks. But because the customer, in this model, pays up front for the solution, now owns it, and is more or less required to keep renewing the insurance policy (maintenance contract) on the solution, the supplier is whole whether the customer is getting value or not.”
This blog post goes on to challenge us that this issue becomes exacerbated in our new reality, where everything is a software as a service. In this age, customers are expecting faster implementations and subsequently, faster time to derived value. Any disconnect between sales and services results in delays and negative impact to the customer.
What causes these disconnects? And how do we solve them?
Sales training – There are several parts of the sales training process to be considered. First, there is the basics of solution selling and understanding customer problems. Second, there is a fundamental understanding of what the software solution can do. Ideally, there is also someone in the sales process who understands where the lines of delineation exist between what is not possible and what is possible but requires custom implementations. Lastly, it’s also important that the sales team is taught how to sell your particular products in the most effective way to ease the onboarding and ongoing support (or at a minimum set expectations with the customer on more complex implementations).
Lack of Services voice – Often times, services is engaged in the sales process in very limited ways. It might just be to draft the statement of work based on the little bit of information provided by sales. Hopefully, services also has a place in reviewing the contract as is it evolves to ensure it aligns to costs, and services. Services should also make sure their voice is heard in sales training/enablement processes. Is the services organization promoting the value their customers are deriving? Has the services organization developed the sales tools required to get the information necessary to properly scope projects; or to educate the sales teams? If not, the services team isn’t doing themselves any favors.
Changing market landscape – we hear it constantly that the pace of business is changing so rapidly, and companies need to adjust to the changing winds of the customers. Services is typically engaging with end users, while sales is engaged at higher levels in organizations. It’s a very real possibility that the market has changed, and that information hasn’t been communicated to services.
The biggest step to be taken to re-align sales and services is better communication. As a sales organization, it’s imperative to keep services up to date on the changing market landscape as well as the customer conversations that occur that impact services (and most of them do). As a services organization, it’s imperative to have a discussion with sales as soon as you see the disconnects. While you may not be able to do anything for this specific contract, you might be able to prevent the same issues with the next one. The lines of communication and respect need to stay open.
I have had the opportunity to work with good and bad product managers, as well as fill that role myself. There are a few key traits that differentiate between the good and the bad, at least when it comes to web, data or technology products. Below are my top 5.
In depth understanding of the product
I find the best product managers truly do understand their product, and where customers are getting value. These are the ones you can rely on to give you an honest assessment of whether the product can be used to solve a problem today, as well as having a strong enough understanding of what it does, to make a determination of whether it can or should do something in the future. The weaker product managers don’t have a strong foundation on where customers derive their value, and therefore can’t help you truly assess what it can do today, versus what it could do tomorrow. This latter group typically will rely on product developers to fill in the details, or the customer facing personnel to provide the use cases.
A solid sense of direction
Another key difference between good product managers and weaker ones is whether they have a sense of direction for the product. Simple things like having a roadmap, or being able to quickly assess whether a new feature request aligns to the strategic direction of the product differentiate the two groups. Customers want to know what you are bringing to the table in terms of new features and functionality. They also want to know that they are being heard, even if those feature requests don’t align to the product direction. Being able to explain the current position, the near-term future direction and respond as to why this request doesn’t fit, is critical to having a solid product ecosystem.
Willingness to meet with customers
Great product managers are interested in how the customers use the system, regardless of how it’s been designed to be used. Further, great product managers want to engage with customers to continue to evolve with the business problem the product has been designed to solve. Those conversations can sometimes be contentious or frustrating, but they are an absolute necessity to continue to be relevant.
Ability to follow through
It is not enough to meet with customers that one time. These days, it is also not enough to gather your information and go off to develop the product in a silo. Customers want and need to be engaged. It’s critical that product managers follow up and follow through. This is almost more important when the decision does not align to the customer request. Customers want to understand why and how – there could be a very good reason that the request can not be fulfilled. The core business problem the customer raised is still a fundamental issue (to the customer). Is your product going to solve it? or do they need to look at alternatives?
Communication is key
At the end of the day, communications is key. This is an underlying theme to the previously mentioned traits, but it’s important to call out separately. Once the new features and functionality has been released, it is critical for the product manager to be able to articulate the feature/functionality, explain our understanding of the problem it addresses, clearly articulate how this feature/functionality fits into the product suite from a contract/pricing perspective and finally solicit feedback as to whether we delivered.
At the end of the day, the best product managers have been a pleasure to work with. They really own the products they manage, and have a very strong understanding of why and how customers use them. They are the starting point for all conversations around the art of the possible, and are always willing to have a conversation to get a new idea, or work with a customer on a problem. They are organized at the tactical level, and open minded at the strategic level.
Today’s question: “why is it difficult to use the same team for implementation projects and ongoing customer success?”
I have had the opportunity to run implementation projects, and be the customer success manager. I’ve also led teams who do both. One of the biggest differences between those project managers who oversee implementation projects, and customer success managers who manage value creation day to day, is the sense of urgency. To demonstrate, let’s dive into each of those scenarios a little bit more.
Implementation Projects
An implementation project is the implementation of a major undertaking, in my case software or data projects. These are either new customers, or customers who are upgrading from an older version of the software. Customers in this position are investing quite a bit of money in their future, while also supporting their existing infrastructure. For the duration of the project, the customer is hyper-focused on this duplication of cost. Further, there are pressures to get rid of the old equipment and software as soon as possible.
The major investment of these times of projects often means that there are additional focus on how the project is going, and how it aligns to the agreed upon schedule. The tendency to pay for these implementations as capital expenditures also adds pressure. Let’s also keep in mind that the day to day business problem, your data or software solves is still occurring while the project is underway. This can often mean within the customer, there are conflicted resources and
Day to Day Success Projects
Once a major onboarding or migration project completes, there are still financial and other pressures. Pressures to deliver value, pressures to prove the right decision was made, the pressures of conflicting business interests, etc. That said, the major implementation cost has already been incurred. The focus has shifted to the general value creation for supporting the day to day business.
This doesn’t mean that the day to day contacts will put less pressure on you. Often time, the day to day business pressure and the close knit relationship of a CSM can mean that the customer team will be even more vocal about their needs. It’s your job as that CSM to help drive that customer value so you lean towards the customer who is in the biggest fire drill, using their voice the loudest.
The Conflict
For a single person filling both the roles, it can be difficult to find the balance between the immediate fire drill, and the longer-term, but often more strategic implementation project. The reality of these types of implementation projects is that the focus should be first on the implementation project, then secondarily on the day to day customer issues. The day to day customer issues will constantly popup as the customers’ business changes, which in today’s fast paced environment can be incredibly difficult to keep up.
If you have done your job well, the implementation project is finite in scope, with a defined methodology for capturing requirements or a set course of action. The bottom line is that it’s a matter of execution. If you constantly enable yourself to be pulled in other directions, you can often succumb to the chaos. The goal is to control the chaos as much as you can. Ultimately it means that the implementation project first, the day to day second. This is an incredibly hard lesson to swallow when you have a day to day team in your face constantly.
A person described as a chameleon is someone who changes their personality depending on who they are with. A project manager who is a chameleon is one that can adapt their methods to match their customer and project. This is can make the difference between a smooth project and one that is much more difficult.
It’s common practice to adopt a methodology that works for you in your current role, but it’s even more critical to be flexible. You never know when you will be introduced to a team that has expectations around how the project will be run, and those can sometimes impact your effectiveness. This is especially true if the expectations are different than project manager’s approach. In these scenarios, it is the job of the project manager to adjust and adapt their behavior to meet the needs to of the project team.
Differences in expectations can manifest in several ways:
fluctuations of communication styles
lack of responsiveness
unexpected escalations
All is not lost on your project when these situations arise. There are several little adjustments that project managers can make to calm the nerves of the project team and redirect the project to a successful close:
adjust project methodology to align more closely to expectations
take baby steps in setting expectations and laying out required information
follow up often using different communication styles (i.e. call recaps, action items/completed tasks, shared project spaces for capturing all the artifacts)
Being a successful project manager is not just about bringing a methodology and walking through a specific set of steps. It’s about observing the entire project team, and stakeholders, understanding the requirements and figuring out how to execute in the most efficient way possible through all the obstacles and opportunities.
I had been working on a very large migration project for about a year when we started preparing for the cutover day (AKA “launch”). As far as projects go, this was fairly typical. We started at an even steady pace, but as time went on we found ourselves putting in more work across the board to mark off all those little things that come up.
We had our punch list of prioritized issues, and work feverishly working through them. We were also aggressively determining/negotiating the true show-stopper nature of each of them. After a couple of close calls where it was unclear whether we would need to push the date, our launch kicked off. Every person involved with the launch had quite a bit of pent of nerves, excitement, energy, etc. Of course Murphy struck and we had to tackle those real-time, last minute issues. After several long days and very specific collaboration across teams, we were able to ultimately deliver.
While I was extremely happy to be live in the new system, this monumental effort (or what had seemed like it a year ago, or even 3 months ago) had no real impact. We did it! But now it was time to move on. The customer had been our customer for many years, and so we were not getting the benefit of working with a new customer. Nor were we getting to do anything new with an existing customer. It was business as usual. It was time to start thinking about all that work we had pushed off, while also helping the customer prep for their next operational weekly cycle.
Once the adrenaline faded, I looked around and thought about how far we had come. But there really wasn’t any fanfare. I’ve come to realize that this is a good thing. The project team had set out to accomplish something and we did. And it worked. And now it’s time to refocus and help the customer realize all those benefits they had hoped to get by the migration.
A couple of weeks ago, I had an epiphany about the role I was playing with the customers I support. For much of my time, I work on large implementation projects, but I spend a lot of the rest of the time working with customers in the role of Customer Success Manager (CSM). The goal of Customer success is help customers derive the most value out of the product, and ultimately helping them meet their business goals. As a Customer Success Manager, this can mean many things. I engage with both corporate and specific business teams, guiding them on the solution and helping them with their individual goals.
It was while I was having one of these weekly discussions that I realized my role had shifted. I was no longer just a project manager or CSM. I was contributing to their business strategy in a consultant role. A consultant is defined as “a person who provides expert advice professionally.” In this particular case, I was leveraging years of experience working with this particular product, in this particular industry. I wasn’t having a tactical conversation about next steps, or how to use the system. I wasn’t discussing the next corporate initiatives. I was sharing my business expertise to help them to determine how they could improve their overall success over the lifetime of this project, ultimately increasing their sales. I was providing value versus just assisting them in getting value out of our products.
In retrospect it seemed like such a silly moment for me. I came into my role with no prior experience in the industry or even directly the technology. My first 3 projects were highly technical and highly industry specific. I jumped in and asked many questions along the way. Almost seven years later, I’ve completed quite a few implementations and special projects, working with about a dozen large customers in the industry. I’m no longer feeling my way, along with my customer. It’s in under these circumstances, that I stand back and put my consultant hat on.
