I’m writing today’s post primarily for my own audience. It’s to remind me that tomorrow will always be brighter if you so decide. Yesterday, I had a bad case of the Mondays. The sky was gray, it was dreary and damp and my first couple of meetings didn’t start out on the best footing. Unfortunately, neither the weather nor my schedule cooperated with a brisk walk to get some fresh air to clear my head. I even tried to take a couple of deep breaths to reset but that too didn’t work either.
As I was lying in bed running through all the loose ends, I kept reminding myself that tomorrow will be better. And like this blog and my other endeavors, I needed to really clear the case of the mondays out of my head to focus on a more positive outcome tomorrow. My simple reminder was that tomorrow had to be better than today, and whatever energy I took in to the next day so was going to set the stage for it. I could continue to foster the negative energy or open myself up to the what the universe has to offer with a hope for a better tomorrow. While it didn’t help me with my insomnia, it did settle me enough that I did have several thoughts and ideas about how to solve some of my imminent challenges.
I woke today to blue, sunny skies and a lovely breeze. I was able to get a nice walk in to clear my head (at least of negative thoughts – the allergens were strong). I was able to sit outside while working for a while, and even put some forethought into dinner. These are all small moments of joy that I reminded myself to appreciate today. I’m sure there are some of you who need to heard this lesson today so thought I’d share it.
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 read this Harvard Business Review article “Why WFH Isn’t Necessarily Good for Women” a while ago and I was struck a little bit by my own experiences working from home for the last 10 years. About 5 years ago, I interviewed with someone who told me that project managers couldn’t be effective in their jobs without being present in the office everyday. Needless to say, I wasn’t the right fit for that job, and my interviewer now runs a fully remote company. The pandemic has definitely pushed companies past their comfort zone, being forced to embrace a fully remote environment at a minimum, a fully engaged and remote culture as the ideal.
I attribute some of my success working from home to a fundamental understanding that you are at a disadvantage and need to ensure you really communicate, even over-communicate to some extent. As a manager, this means that I leave my lines of communication open and meet my team members where-ever they need to be. As an employee and project manager, this means I am constantly sharing information and establishing a baseline for my communication, so that when I need to escalate or talk through something, I get treated with the urgency I need.
My current team is primarily compiled with the majority located in one geographic area, a smaller group in another and multiple team members, including myself remote to either location. The primary location was the base of operations for our key customers, with an open door policy that encouraged them to stop by. There were definitely missed conversations and opportunities, that remote team members needed to overcome. But there were also some downsides to the office community, we have identified since work from home has been implemented.
The sense of community provided quite a bit of distraction – In anonymous surveys of team members, and analysis of the numbers, all accounts show that the entire team is more productive. They feel more productive and the numbers show dramatic increases in productivity since the start of the pandemic. Even the most extroverted have taken note and are refocusing their energy to impact their goals, and driving growth for the team.
Boundaries are key– Everyone’s family and home situation is unique, and it’s imperative that each person set boundaries, and the rest of the team abides them. Further, it’s imperative that you communicate these rules to your stakeholders as well. We all need the flexibility to work through a shared workspace, or kids in remote school, or loved ones who got sick miles away. Having an open door policy to discuss each person’s needs allows them to share as much or as little as they feel comfortable, but allows you to provide individual support.
Don’t assume, ask – We did a few anonymous surveys of the team to figure out where we were succeeding and where we needed to improve. We also had did skip level 1:1 meetings across the entire team. This allowed team members to be heard, and for us to continue to figure out how best to support.
There are still some downsides that we need to navigate: including a sense of loneliness, a shift towards too much work in the work/life equation, and figuring out how to retain those connections with customers and our team members as we bring new ones on, or as we navigate how to open the office and balance everyone’s new found enjoyment in working remote with needing to have some presence in the office as a haven for our customers.
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.
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.
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.
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.
“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.
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.
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
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.