This is Part III of the "Breaking Down Departmental Barriers" series. The articles in the series are:
III. 4 Tested Ways for Amazing Collaboration with Sales & Product (You are here)
Two weeks ago I wrote about how I got a reality check by my mentor when I griped when things seemed out of my control. Last week I laid out the tangible ways my colleagues benefit from professional services getting involved with what they're working on.
But what does it mean to "get involved"?
Getting involved means we are supporting our colleagues, not replacing them. Support can come in many forms:
- Leading and participating in a diversity of voices - How often do we find a differing perspective useful when we're stuck on a problem? If we find that useful, it is only fair to assume that our colleagues may find that useful as well. Sometimes it takes someone new to bring in a fresh idea to overcome inertia or unblock a proverbial jam.
- Taking on work that makes sense - Some people end up wearing a lot of hats (especially in startups). I'm no stranger to a common predicament: I'm tasked to work on something that someone else can probably deliver at a higher quality at a much faster pace.
- Upfronting work before it enters our pipeline - Where there is work, there are preparatory activities that can be done before actual work begins. Getting involved here means we are doing whatever is necessary to prepare for a project to come.
The idea of why and how we support our colleagues is clear, but what exactly can we do get more involved and collaborative with our colleagues? I've personally tried the following tactics at one point or another in my career:
Participating in sales kickoffs and join in on the brainstorming
Many organizations run sales kickoffs at the beginning of the year to strategize for next twelve months of selling. In one of my previous positions as PS manager, I was invited to join our org's sales off-site kickoff and I took the opportunity to not just learn, but also participate to inject a professional services theme to the annual sales strategy. Not only did I learn what and how the sales team planned on approaching prospect this year, I was enlightened on why they decided to sell they way they did. I understood the motivation and the themes they wanted to tackle, specifically they wanted to tackle one specific product line because we wanted a first-mover advantage over a competitor of ours, and that gave me an invaluable perspective on some of the decisions made throughout the year. If I didn't attend the kickoff, I probably would have been scratching my head wondering why the team pushed so heavily on one product and ignored the rest.
Participation isn't just one way - I was asked on our preparedness on the product line we wanted to focus on, and I gave some valuable insight on how to segment prospects so we can focus on the ones that have the highest probability of an easy integration. This gave the sales team an additional qualification point when they are closing their sales throughout the year: they're not just closing sales based on how fast they can sign on the dotted line, but now they are qualifying them based on PS criteria of integration success.
After the kickoff, armed with the strategy from the top of the implementation funnel, I was able to better prepare the PS team on the type of integrations to come. We prepared documentation to specifically cater to the targeted segment, and that allowed the team to easily service that segment when the prospects became clients.
Participating in sales kickoffs helped with 3 things: understanding sales strategy and motivation so we understand the work to come, providing technical insight to improve the quality of prospects, and front-loading work to prepare for when prospects become clients
Attend and Represent Trade Shows with our BD Colleagues
I confess: I love going to trade shows with my BD colleagues. It is a great way to socialize and build a good relationship with my BD colleagues, but more importantly, it offers an amazing opportunity to learn from the market. The trade shows I attended allowed me to interact with customers and prospects alike and conversations with them allowed me to understand their pains and problems. By meeting so many of them in one place, I started to gain a greater understanding of the market and its pains as a whole, rather than on a client-by-client basis.
Going off-site and spending time with my colleagues in sales also offered me a chance to build a rapport with the sales team, especially those of whom I don't necessarily see eye-to-eye every day. Over a few drinks, some of my colleagues let down their guard and we were able to be totally honest with each other We talked about our differences and similarities without the formality that exists in an office setting,.In the end, we gained a frank understanding of our motivations and modus operandi, and that goodwill continues on well after the trade show wrapped up.
Pattern Recognition Sessions to Improve Our Product
We are privileged to a lot of information from our clients, and the market at large. We also know the problems and pains they face, so it only makes logical sense that we would have opinions that drive product development. Product teams are really hungry for that type of feedback, but they usually don't have the time to take in a proverbial firehose of raw information. That's where PS teams can aggregate feedback into themes, and run what I call "pattern recognition" sessions to help product teams understand market forces that they may not be aware of. These product recognition sessions are structured to introduce aggregated themes and encourage debate on the best ways to attack those themes. I find at the end of the session, we leave knowing that our clients will benefit from improvements in the platform that are designed specifically to attack anticipatory pain, and product knows what they're focusing on will truly make an impact to clients and the market as a whole.
Team up with Product for a "Product Idea-thon"
Developers have hackathons where they invest a concentrated period of time bringing to life an idea that they have had but never had the time to actually execute on. Expanding on the notion of the hackathon: an "idea-thon" is when product and professional services get together to incubate a product idea based on client pains, anticipatory or otherwise. It's exciting to hash our a product idea, complete with with UI mocks and workflows, and present that idea to the greater team to share in that excitement. No code is actually written, because the goal here is to simply incubate a productidea that is off the product roadmap. It sounds like a crazy idea, but a "hackathon without coding" exercise can yield some great ideas for product evolution going forward.
The most cynical amongst us would argue that an exercise like this is equivalent to our teams just "doing our jobs", and we're just getting in the way of the product team. There is are some big differences between regular product development and the notion of an "idea-thon":
- We are incubating ideas, not coding a full blown product
- We are focused on tackling non-urgent problems
- We are primarily addressing client pains (anticipatory pains are great here)
- We are incubating ideas that is otherwise off the current product roadmap
If you're looking for ways to engage our adjacent colleagues, plan out and execute on some or all of the above exercises. You will find that you will gain new perspectives that will help our day-to-day mentality, and our colleagues will gain a new perspective as well. They're not make-work projects: each of them hasa defined goal and has worked in the past for me. Give it a try and start participating!