leadership
Lessons Learned from GTM Consulting
For the past two years, I have performed part-time, contract go-to-market consulting. My wife had a surgery that had gone wrong 18 months ago, so I needed something that would allow me to take care of her, stay sharp, earn money, and help companies grow.
Most of the work was with small to midsize companies, but the problems and needs mirrored what I have encountered at larger companies. The main difference is that large companies tend to look to software to address problems. In contrast, smaller companies lack the budget for what they view as an unproven solution that increases complexity.
Here are my Top 5 findings:
- GTM plans are often developed at the highest levels, often in isolation, without market testing and validation.
- Sales teams are pitted against one another, rather than working together to help everyone achieve more (i.e., “A rising tide lifts all boats.”)
- Sales teams are focused on selling features rather than solving business problems.
- CRMs are not consistently used and often reflect idealized fiction rather than reality.
- Sales management and teams are not leveraging AI to help focus their efforts.
Here are the related Lessons Learned:
- Identifying common business problems and describing how your product or service solves them should be the foundation of the plan. Perform market analysis. How do companies describe those problems? Their terminology, often found in job ads, can help create effective messaging that resonates. Work to become the natural fit for what your prospects are seeking.
- Individual contributors get paid to win, but sales management needs to create incentives for collaborative efforts that lead to wins.
- For one company, I convinced them to implement a 2% SPIV (like a SPIFF, but team-focused) for every team member who actively contributed to team improvement. SPIV payments were quarterly, and there was a running total so the team could see the fund growth. Initial indications of a positive impact are good.
- Another benefit of collaboration is that it helps teams focus on approaches that work due to ongoing testing and refinement. Collaboration also helps teams focus on a more accurate ICP (ideal customer profile). Sales management can then feed their findings back to Marketing to improve and tailor their efforts.
- Selling is a byproduct of problem-solving. You can’t solve problems if you don’t know what they are. Every interaction with a prospect should focus on gathering information, building trust and relationships, and leveraging prior interactions to demonstrate that your solution will solve their problem and ease their pain.
- CRMs often either lack information or are full of wishful thinking. They focus on activities, and not progress and next steps. Using MEDDIC/MEDPICC as a foundation for reporting is a much better start. Sales managers need to independently validate the information to ensure their teams are being upfront and honest. Trust, coaching, and collaboration work together for the win.
- AI is not a panacea, but it is very effective for research, market validation, prospecting, and meeting preparation. Going in prepared builds respect and credibility, saves time, and lets you quickly qualify prospects in or out. There may be a nurturing program for some of the prospects qualified out for immediate deals, but your time is valuable, and you will go hungry chasing deals you can’t close.
So, what are your thoughts? Have you seen some of these problems yourself? How did you handle them? Let me know in the comments below.
And if you are looking for a Consultant to help your business grow or someone who can add immediate value to your team, then contact me.
Never Panic!
Panic is not a good problem-solving tool, regardless of your position or role. It is especially bad when you are in charge of people or brought in for your expertise. Panic leads to a myopic view of the problem, hindering creativity.
The point in my career when this became readily apparent was when I was working for a small software company. We had a new product (Warehouse Management System) and were launching our third deployment. This one was more complicated than the rest because it was for a pharmaceutical company. In addition to requirements like refrigeration and lot control, there was a mix of FDA-controlled items requiring various forms of auditing and security and storage areas significantly smaller than previous installations. It was a challenge, to be sure.
A critical component, “Location Search,” failed during this implementation. About 10-12 people were in the “war room” when my boss, the VP of Development, began to panic. He was extremely talented and normally did an excellent job, but his reaction negatively affected the others in the room. The mood quickly worsened.
I jumped in and took over because I did not want to be stuck there all weekend and mostly because I wanted this implementation to succeed. I asked my boss to go out and get a bunch of pizzas. Next, I organized a short meeting to review what we knew and what was different from our prior tests and asked for speculation about the root cause of this problem. The team came up with two potential causes and one potential workaround. Everyone was organized into three teams, and we began attacking each item independently and in parallel.
We identified the root cause, which led to an ideal fix a few days later and a workaround that allowed us to finish the user acceptance testing and go live the following day. A change in mindset fostered the collaboration and problem-solving needed to move forward.
But this isn’t just limited to groups. I was a consultant at a large insurance company on a team redesigning their Risk Management system. We were using new software and wanted to be sure that the proper environment variables were set during the Unix login process for this new system. I volunteered to create an external function executed as part of the login process. Trying to maintain clean code, I had an “exit” at the end of the function. It worked well during testing, but once it was placed into production, the function immediately logged people out as they attempted to log into the system.
As you can imagine, I had a sinking feeling in my gut. How could I have missed this? This was a newer system deployed just for this risk management application, so no other privileged users were logged in at the time. Then, I remembered reading about a Unix “worm” that used FTP to infiltrate systems. The article stated that FTP bypassed the standard login process. This allowed me to FTP into the system and then delete the offending function. In less than 5 minutes, everything was back to normal.
A related lesson learned was to make key people aware of what happened, noting that the problem had been resolved and that there was no lasting damage. Hiding mistakes kills careers. Then, we created a “Lessons Learned” log, with this as the first entry, to foster the idea of sharing mistakes to avoid them in the future. Understanding that mistakes can happen to anyone is a good way to get people to plan better and keep them from panicking when problems occur.
Staying calm and focused on resolving the problem is a much better approach than worrying about blame and the implications of those actions. And most people appreciate the honesty.
As the novelist James Lane Allen stated, “Adversity does not build character; it reveals it.”




