School, Work

How I Prioritize to Make the Most of My One-Woman Team

Leave a comment

Over the past 18 months, I’ve been quickly taking on more at my current company. I’ve moved quickly from a specialist role into a manager role as well as from a role solely supporting our Sales team to one that supports the entire Revenue team. My current role, the Sr. Revenue Strategy & Analytics Manger (I know – it’s a mouthful), is a role that was once held by multiple employees.

Because of this change in dynamic, for the past 6 months, I’ve been tasked with getting the work of two people done as just a single contributor. Though I’m efficient, I am not two people, so my life saver in maintaining my trust with colleagues as well as my sanity has been prioritization.

Though this is nothing revolutionary, it’s been ground-breaking in making my work more rewarding as well as making me a more impactful partner to the leaders I work with. Specifically, as I analyze my projects going into 2022, I’m using the same framework that I learned not only in my Sales role before this but also from my very first Ops manager: the effort vs. impact matrix.

The Effort vs. Impact Matrix

Every time I re-evaluate my project prioritization, I’m using the matrix above to classify everything on my plate. When our organization went through a re-org, this is what we used to prioritize handing off tasks between teams. When I set my goals after taking over the RevOps position, I put every project through this matrix. Even as a Sales rep, when I was working through my deals and accounts, this was the matrix I used to decide what activities I needed to do in a day to get the most out of my book of business.

The matrix forces you to classify every single activity as either high or low impact and either high or low effort. This should help you narrow in on the quickest, most impactful activities, while giving you time to fill in the gaps with quicker, smaller wins and plan for the long-term major wins. Here’s I usually utilize this list:

  • High Impact, Low Effort (“Home Runs”): These are the activities I want as my top projects to be working on in this moment. They’re going to allow me to have the most impact as quickly as possible. These will have the highest return on investment for my time commitment.
  • High Impact, High Effort (“Big Bets”): These are the activities I want to kick out a bit as I make more incremental improvements and do more research. There is a huge return on these projects, but it may involve additional work that can be done through other projects or potentially a learning gap I need to bridge.
  • Low Impact, Low Effort (“Quick Wins”): These are the activities I like to use to build confidence with my partners and may use to progress us closer to some of our more long-term goals. They may not necessarily be the biggest return, but if used correctly, they can build momentum and even progress more long-term initiatives.
  • Low Impact, High Effort (“Fall Backs”): These are the activities that I avoid until I can’t avoid them any more. Until they become a major impact, have added value to another higher impact project, or a simpler solution appears, these are things I put on the back burner immediately.

Where I’ve Applied This

I use this in almost every aspect of my life, including personal decisions. I cannot stress enough how useful this framework can be. However, I’ll provide a few examples across different positions and projects where it’s been most useful.

The first time I was introduced to this was in my Account Executive role. They used this exact matrix to talk about how we should be prioritizing our customer interactions. They pushed us to create a list of sales activities we needed to accomplish in the day and forced us to put them through the matrix. This immediately got rid of all the mediocre touch points I had arbitrarily created during my Sales process and pushed me to create more meaningful deadlines and follow-ups with my customers in order to justify interactions being in the matrix. I became not only more efficient, but honestly, a better partner to my customers.

Within that same Sales role, our leaders used this framework to classify accounts. We thought of “Impact” as the actual revenue we could recognize with this customer and “Effort” as the likelihood that customer would buy from us. Since we were selling “seats”, it was pretty simple to classify “Impact” as the size of the company. “Effort” on the other hand became a combination of a few different factors comprising of industry, volume of ideal contacts, familiarity with our product, tech literacy, and more. My entire book of business was classified in this matrix, which helped me further customize my outreach to the “Home Runs” and “Big Bets” while automating my outreach to my “Quick Wins” and “Fall Backs”.

Moving into Ops, this matrix is my life saver. Every quarter, I put my projects back through this matrix. Each quarter I’m working to knock out while I need to get done while collecting more and more project requests from my partners in our Revenue leadership team. As I near my standard quarterly check-in, I’m compiling every project within our Revenue Operations scope, and running it back through this matrix. This helps me catch anything that may have become easier but been put to the wayside prior due to having a high effort to execute. It also helps me surface projects that may be becoming a large pain to the business than previously. Being a one-woman team in my current company, this is what keeps me sane, and also helps me build trust with my colleagues by openly communicating why I may or may not have time to execute against all projects that have been requested.

Of course, I can’t leave out how this helps me in my group projects at school. To be a good team member, it’s important to always deliver as much value back to the team as possible. When working in a group for school, especially while also working full-time, this can be really difficult to balance. For me, it’s helped to think of the overall project or work we’re doing in small chunks and put these through this matrix. When I see a “Big Bet” on the matrix, I’m trying to find ways I can quickly progress out team to moving that over to the “Home Run” category. When I see a “Quick Win” on the matrix, I’m trying to volunteer what limited time I do have to knock those out and help our team continue to progress. It can be really difficult to be a good teammate when you’re also working 40 hours per week, but when you’re making those most of those hours you do have for the course by prioritizing in this way, your limited time becomes 10x more impactful to the broader team.

Conclusion

Prioritization can be used in any role, and 100% should be! If you’re not doing this on paper, you’re probably doing it in some way. The times where I find it most impactful are those where I feel like I have a lot of things to do and not enough hours in the day to do them.

I know we’ve all felt this way at some point in life, careers, or school. It can feel really wasteful to take a step back and slow down when you’re in that moment. However, the value you will get in return to running all those tasks through a matrix will save not only your time but also your mental health. Give it a go next time you’re in this loop! I promise it’s worth it.

Women in Tech, Work

Hiring the Best: 3 Ideas to Diversify your Hiring Pool

Leave a comment

This article is a little different from my usual but was sparked by an incredibly exciting event in my professional career: hiring my first official direct report!

Though direct management experience will be a first-time experience for me, I’ve spent a lot of time researching, learning about, and putting into practice some best-in-class hiring practices. From taking courses in recruiting to interviewing in others’ hiring loops to networking to help colleagues find new talent pools, I’ve gained a lot of great tips along the way that have made me super proud of the candidates I’ve sourced for my own direct hire.

Start with Referrals

This is an awesome way to quickly start seeing candidates. Don’t be shy to ask previous colleagues, current colleagues, and beyond if they know anyone qualified for the position. Be even more proactive and peruse the networks of colleagues you trust using tools like LinkedIn. Asking for introductions can often be easier than asking someone to pull a name out a hat for your role, so get creative and go hunting for them.

It’s important to note that while referrals are an amazing way to beef up a candidate pool and they often come with glowing recommendations from the colleagues that refer them, recruiting and hiring solely in network can be detrimental to hiring diversely. Not only will you likely source most of your candidates from a small group of companies, which can lead to cultural baggage being brought to your company, but you also open yourself up to recruiting from racially, culturally, gender homogenous networks.

Referrals are an awesome start to the process, but you must be cognizant of the effort placed by individuals to create diversity in their own networks. To combat this, it’s important to further expand your pool of candidates and keep an open mind to all candidates rather than overweighting a referral.

For me, this meant constantly bugging every coworker I knew to look in their networks as well as using my LinkedIn to find 2nd degree connections with people I trusted. This helped me pick up around 25% of my candidate pool, and set a starting point for what skill sets to search for in other candidates.

Network, Network, Network

Hiring doesn’t start when the job post goes up. A good hiring manager is consistently networking to find quality candidates for their next role. Admittedly, this is one of the toughest ways to recruit good candidates, as it falls on the hiring manager to put themselves out there. However, it’s one of the easiest ways to diversify your network against the homogeny that is often persistent in corporate culture.

Join groups that support categories that are underrepresented in your field, your industry, and your company. If you are a member of one of these underrepresented groups, this can be an amazing way to get resources you may not have access to in your own corporate environment as well as elevate others like you. If you are not a member of one of these underrepresented groups, it’s an incredible way to share your own resources with these groups as well as more quickly diversify your own network. Simply diversifying your own network can lead to personal benefits through diversifying thought, ideas, creativity, and perspective in your own work.

This is probably one of the most long-term and difficult solutions to implement, but the return is exponentially higher when it comes to not only expanding your pool of candidates but also expanding your horizons. The most important factor is building and maintaining these networking relationships long-term.

Given the pandemic, this is where I personally could use the most work, though, I was still able to bring in about 10% of my candidate pool from a few connections I’d made through student organizations I’d joined while back in college. Personally, this was something I had more of a pulse on while in school than professionally, and I’m hoping to get back to that now that I’m more confident in my own career trajectory.

Market Yourself

Companies far too often put themselves in the driver seat on the hiring landscape while the best candidates have competing offers from multiple organizations. If you too want to hire the best (and you’re not a Fortune 100 company), you need to be marketing yourself to talent that is not actively looking for your company.

View your position as an opportunity for your candidate to make their next move, improve their skills, and work for a great company. What do YOU have to offer a candidate? What skills can YOU help a candidate develop? What skills are a must have in your job description? Who is your ideal candidate? Who is a candidate you could hone into the perfect employee? What does your company have that others don’t?

Once you can confidently pitch what YOU bring to the table (yourself as the hiring manager as well as your company), you are ready to find quality candidates and hire the right one. It’s important to put on your marketing hat, hone your pitch, then start doing the ground work to find candidates, whether that be through LinkedIn, job boards, an internal recruiter, or a recruiting firm. Center around what you’re looking for and what you have to offer, and go find the candidates that you think can get you there. Be sure to personalize! The best candidates are getting plenty of messages from other prospective companies.

This is where I thrived in adding new candidates. I deep-dived on LinkedIn to bring in about 50% of my candidates from this group. I tried to target top tier candidates that may be a step above what we were hiring for, candidates just below my qualifications that I could easily teach the skills they were missing, as well as candidates perfectly qualified given their current experience that should be looking for this role as their next role. My goal was to match organic applicants and referrals with this pool, which involved personalizing messages for around 10 individuals for every 1 candidate I hoped to add. This was not an easy feat, but it has contributed to some of the most pleasantly surprising applicants in my pool.

Conclusion

To get the best talent, you must see the best talent while you’re hiring. These are just a few ways to hit the ground running and make sure you’re casting a wide enough net to keep diversity in mind and find the best possible candidate for your role.

The best companies are those built on diversity and this starts with the way in which we hire talent. As a hiring manager, you are the owner of your talent pool, and you have the power to be part of a recruiting process that gives people from multiple backgrounds, genders, races, sexual orientations, experience levels, and beyond the seat at the table. Prioritize doing your own diverse recruiting – though the work on the front-end may be costly, the quality of employee you will hire by seeing a larger, more diverse pool of candidates will pay for itself in the long-run.

School

OSU CS467 Update

Leave a comment

Wanted to provide a brief update on my CS467 class at Oregon State. This week, we hit our midpoint, so I’ve created this fun demo video to talk more about where the team is at, what we’re working on, and what we have left to do.

In my video, I call this out, but one of my favorite dynamics of our group is our weekly group programming. I’ll dive more into how our group is really using this to drive our project forward.

Group Programming

Each week, my teammates and I meet for 2-5 hours across 1-2 meetings. The purpose of these meetings is to give updates and brainstorm, but it’s turned into one of the best places for us to knock out key initiatives.

Our project involves 15 rooms and a parser to navigate between those rooms and perform actions on objects within those rooms. This makes it incredibly easy for each group mate to own 5 rooms and the functions that occur in their rooms. However, we quickly recognized that there was some shared navigation and other verbs that crossover between our rooms.

In the first week we started coding, we transitioned our group meeting from an update meeting to an actual working session on navigation. Then our second meeting to a working session on our parser. These incredibly important brainstorms and group programming sessions has allowed our group to not spin our wheels independently working towards the same solutions but rather put our heads together and knock out things much more quickly.

These group programming sessions have been fundamental to us staying ahead of schedule and have made it so much easier for each team member to knock out their sections so much more quickly. Because we’ve worked as a team to discuss these things and all get on the same page, there’s no confusion on how to use these overlapping functions when we begin to work independently.

Implementing Group Programming

Though this is likely not the perfect solution for every project, I’ve found it incredibly valuable and a great reminder that taking the time to source feedback and brainstorm with others, though sometimes time-consuming, can actually allow a team to operate at a much higher efficiency.

This also doesn’t have to be independent to the actual backend or programming. I can think of several scenarios in my own work in Revenue Operations where I’ve been presented a problem, gone about executing a solution, and then been sent back to the drawing board when it didn’t quite meet the moment upon roll out.

There’s a lot more people involved in workplace solutions than just the programmers, developers, and project managers. Though you may not want to bore a salesperson, customer or other end user with the actual execution, it’s so critical to consistently be re-engaging with these parties to make sure you’re staying on track with the end goals and not getting too deep into just making the code work.

What’s Next?

The rest of our project timeline is dedicated to knocking out our individual portions independently and using our group time to improve the game’s usability. I’m feeling really confident about where we’re heading and even more confident that the dynamic we’ve built as a team is allowing us to do that much more quickly.

I’m really learning a ton in this course and surfacing some new ideas for collaboration that I’d really love to take back to my workplace. Group projects can be incredibly difficult, but I’ve been pleasantly surprised at how well our team has worked together and want to scale that dynamic into other projects I’m working on outside of school.

School, Work

Criticism vs. Feedback

Leave a comment

Since I started this blog for my Capstone cource, it’s about time we dive into an update on how the project is going! This week, I want to get a bit vulnerable and call myself in to be a bit better as a teammate.

One of my teammates had an “Aha! moment” this week, which is what I usually call it when a programmer just has a break through on how to fix a really complex problem. You may get it in the middle of the night, during work, taking a shower, etc., but it comes out of nowhere. All the sudden you have a breakthrough on how to solve a really complex problem and it’s time to hit the keyboard.

For my teammate, that came this week in solving some of the key requirements for an input parser on our text based adventure game. He went above and beyond to knock out hours of coding to bring the team forward weeks in our progress simply on pure motivation and excitement to fix the problem.

Where I’d like to call myself in, is in my response to that. My group mate was so incredibly excited to have built our input parser to handle all the scenarios, but all I was focused on what the length of the solution and how it could be done better to minimize it.

As I spoke through recommending that we try going with a different solution, I quickly recognized I was deflating my group mate’s excitement. Though I was trying to help us forward the project by making recommendations, I was not being a part of the solution and rather info dumping ideas back on someone who had done incredible work to remove a potential roadblock for our team.

I was practicing a behavior that I myself hold as one of my biggest pet peeves: delivering criticism over feedback.

My “Aha! moment” on Criticism vs. Feedback

A few years back during my undergraduate degree, I was participating in an engineering challenge at CES (the Consumer Electronics Show). There was just six students participating, and I lucked out in landing on of my good friends from another school on my team. Incredibly exciting, as I knew we already worked well together.

The challenge was to find a technology at CES and present that as something that would revolutionize cars by 2025 (yes, just 4 years from now). We spent a day just wandering the show, then came back to our booth to brainstorm as a group with our group mentor. For hours, we sat and debated without making much progress. It was an incredibly frustrating experience filled with research, several pitches, and several ideas tossed in the recycling bin.

It felt like we as a group were spinning our wheels with no real progress while the team up against us was chugging along on their presentation. Finally, after about that 25th pitch of the day, I recognized that my group mate was consistently the one shooting down ideas for being “silly” or “unfeasible” or “not that interesting”. Whether it was intentional or not, it was clearly getting to the group morale.

Finally, our group mentor, tackled the problem head on saying to the critical group mate, “Your feedback and concerns are completely valid. However, let’s try not to be overly critical without providing a solution or recommendation on how to move forward.”

That moment has stuck with me ever since. It felt harsh at the time, but it completely changed the group dynamic. The teammate that had previously been slightly difficult quickly got our team on track, and honestly completely led our team to create a fun and engaging presentation that had the entire judges and executive team from our company sponsor laughing out loud and actively participating in our project.

The contribution this group mate was capable of giving to the team was incredible, but she needed that push to reframe the way that she was contributing. She needed to take off her criticism hat and put on her feedback hat.

(via Xactly, “10 Constructive Feedback Examples for Sales Teams”)

Feedback over Criticism

Criticism is calling out the problems where feedback is also calling out those problems but helping the receiver work towards a solution. Feedback is inherently intended to be constructive and solution-oriented.

The scenario I shared about my bad behavior with my group mate is something I see almost every day in my workplace between cross-functional teams. Feedback is collected or given to the team trying to solve the problem, this team comes to the solution, and the other team complains about imperfections in the solution either privately or directly back to the problem solver.

I see it a ton from my sales reps unhappy with certain product updates. Their concern is obviously valid, but often their criticism is far from productive. Often this criticism lacks context or recommendations of solutions. We simply hear things like, “this does not work for my customers as it leaves out this scenario.”

Though this seems helpful in the moment, the receiving party, the product team, is likely not privy to every single scenario that a customer can face. Product relies heavily on our teams interfacing with the customers to source those scenarios and either recommend their own solutions or share more about how they are solved in current state in order to help the roduct team come up with their own solutions.

Again, the people with some of the best solutions need to be helping the broader team work towards those solutions. If you have your best players just cheering on the team from the bench, you’re missing out on having you’re MVPs dunk on the other team. Having a strong communication between product and sales where both teams trust each other to come with constructive, solution-oriented recommendations is so important to positioning your team to come up with the best solutions.

Where Does that Leave Us?

Let’s bring it back to the Capstone project. As I witnessed my group mate slowly get a little more sad each time I tried to brainstorm ideas with the group, I quickly remembered that CES project team.

What I was trying to deliver feedback on was certainly something I’m incredibly talented at doing. In several group projects, I’ve been tasked to clean up code and help our groups’ solutions become more efficient. However, the way I was trying to deliver that value was incredibly misplaced.

I had spent several minutes essentially playing this back and forth with my group mate where he would share his solutions and excitement, and I would recommend ways to make it better. Instead of giving him the space to share and matching his excitement on this incredible feat, I was too focused on my own agenda and where I wanted to help.

Once I recognized this, I called myself out and immediately apologized for being inconsiderate. Instead of sitting and criticizing, I should have applauded my group mate’s progress. The time he had saved us for future weeks was actually time that I could easily spend working on a separate branch to consolidate before asking the group to review.

That was my final recommendation. I shared my specialty and also excitement for my group mate’s hard work. I offered to be part of the solution and take a look offline before our next team meeting in order to prepare some updates for my group mate’s to review, which was much more welcomed than my consistent “we should do more” comments prior.

My biggest piece of advice is catch yourself when you’re in this pattern. Whether it’s well intentioned or not, it can be hurtful to your team’s dynamic and prevent you from really putting your own skills to good use. Don’t be part of the problem, be part of the solution. Give feedback, not criticism.

School, Work

Building Solutions that Scale

Leave a comment

For the product nerds out there, “building solutions that scale” might be a phrase you here rattled off regularly. In my sales background, this was not a phrase I really heard until I joined the LinkedIn Global Sales Organization in 2018.

At LinkedIn, they called this concept “Leverage”. It was one of our key performance metrics not only for our technical folks, but throughout the entire organization. You were expected to not only hit your result and be a leader on your team but also to scale your success 10x within the organization to bring your colleagues up with you.

Being pushed to apply this principle outside of my engineering background fundamentally changed my success at work and beyond. I’m writing today in hopes of convincing others to also adopt this mindset, especially those in Sales.

So you’re an Engineer…

You’ve probably heard this mindset a lot then. Every single course I’ve taken in computer science and engineering focuses on the importance of understanding the customer problem, building “clean” code / solutions, and providing adequate documentation for the end users as well as future engineers. To build a solution that scales these are all vital.

Understanding a customer or end user’s problem, needs, and wants is always the first piece. The more you know about the full customer profile, the more you are able to predict future needs. This allow you to build your solution in a way that it can grow with the customer vs. fixing it for today’s problem.

Building “clean” code or solutions stems from that clear understanding. I always think back to the old trope from sitcoms of the husband refusing to hire the handyman, fixing something with duct tape, then ending up with far more damage in the end and a bigger bill from the handyman. Solutions to complex problems can be the same. Build and fix your code in a way that allows you to continue upgrading and using your initial framework. Otherwise, you may end up throwing out the whole kitchen sink instead of just replacing the pipe when someone new to the problem tries to fix something.

This leads into the documentation piece. Building solutions that are well documented helps not only your end user utilize that tool more effectively but also helps your future product team maintain and upgrade your solution well past your time working on it.

As an engineer, the one thing more satisfying than seeing your solution put into practice is seeing your solutions evolve and improve well into the future. Keeping the customer problems in mind, providing clear fixes to those problems, then documenting that for future users and engineers provides your solution the framework it needs to scale and reach this goal.

So you’re a Sales rep…

If you’re reading this as a Sales rep, you’re probably like, “I’m not programming or building solutions – what does this have to do with me?” I thought the same thing, so I encourage you to think about what you’re doing every day as a Sales rep. You’re consistently solving customer problems, and you’re also likely working with numerous other reps.

The quickest way to make yourself indispensable as a Sales reps is to adopt this mindset and find ways to scale your solutions for your customers, for your own sales process, and beyond by 10x.

Let’s think about customer solutions first. Finding a way to perfect your pitch to a science is scalability. Creating a sales pitch that fits an industry, role type, persona, customer pain point, etc. allows you as the rep to then take that pitch and find several more customers that fit that same profile and sell them similarly. Though you should treat each of your customers as individuals, you should also find ways to pitch your solution to different personas. This can expand your addressable market, increase your productivity, and improve your confidence in your solutions. When you sell one customer, start thinking about how you find 10 similar customers to sell in the same way.

This leads us into productivity. If you want to be the best sales rep as well as help those around you be their best, you should constantly be thinking about how you do more with less. Sales enablement tools and CRMs exist solely to scale Sales processes, but there’s still a long way to go in scaling the great things that great sales reps do. My entire role in Revenue Operations exists to do just that! Find ways to take your best customer interactions, most productive resources, etc. and use them with every customer interaction. This will save you time, create stronger customer interactions across the board, and make you a lifesaver for the entire team you work with.

There’s an entire industry built around scalability in Sales. Finding ways to implement it day-to-day, even as an individual rep, will make you a top performer and an indispensable resource to your entire organization.

Focus on the Future

Sales teams, Product teams, and organizations as a whole need people who can think for the future and build solutions around that. It will not only make you more effective in your current role but will also set yourself and others up to take your successes and improve on them well into the future.

If you can take one thing from my “jack of all trades” experience, I hope that it is to use the “building solutions that scale” mindset and apply it to every role and every situation you encounter in your day-to-day. You’d be surprised how much time and energy it will end up saving you in the long run, despite your role.

Work

Creating Customer Centric Product Development

Leave a comment

This week, I’ve had the pleasure of seeing a fellow OSU Post-Bacc student that I referred to my start-up finally join the team! I’m in the unique position where I’m still working in Revenue Operations, while he’s joined our Product team as a Software Engineer.

Knowing I was on the Revenue team, Eric messaged me this week asking if I could give him more insight into how we’re pitching our product to customers. He was hoping to capture more about what product features are incredibly important to the way we do business either via a product demo or Marketing one-pager.

This is honestly the first time I’ve had a Product person ask for this, and needless to say, I was proud of my fellow OSU Beaver! What resonated most with me was his reasoning for asking.

Even in the short-term projects I’ve done through the OSU Post-Bacc program, I’ve recognized moments where we were working towards a solution vs. working to please an end user or customer. It was a good reminder on how solutions-oriented folks like developers can lose focus on the customer, especially when they are not given the opportunity to learn and interact with the customer on a regular cadence. It’s our responsibility as a customer-facing team to help give our Product team that visibility of the customer experience.

Product Centricity vs. Customer Centricity

In my research, I found an article that really resonated with me from UserVoice around Customer Centricity vs. Product Centricity. The article quotes Bruce McCarthy, Founder of Product Culture, defining Customer Centricity as more of a subset of Product Centricity:

“‘Being product led incorporates customer wants and needs into a broader perspective of what’s good for the company strategically.’ he explains, it means looking at things through a wider lens, ‘Where is there viable business for us? What is technically feasible and defensible? What can we build that would be unique and differentiated as well as desirable for the customer? Those are kind of the three Venn diagram bubbles that people draw in product, and being customer-centric is one, but being product centric is all three.'” (via UserVoice, “What is customer centricity?”)

I’d definitely recommend checking out the full article at that link. Customer Centricity is just one subset of Product Centricity, not a separate category. Great product teams balance desirability, feasibility, and viability to make the best products for their customers and the business in a way that keeps the long-term product vision in mind.

(via UserVoice, “What is customer centricity?”)

How to Create Cross-Functional Collaboration

One of the biggest limitations on collaborating cross-functionally is creating consistent and insightful mechanisms between Product and Sales teams. We struggle with this at my current company,

So what are a few ways that we are working towards more useful collaboration between our teams?

  • Quarterly Mock Product Demos: This came directly from Eric’s idea. As a leadership team, we’re looking to implement a quarterly mock demo from an Account Executive and mock implementation training from an Account Manager to highlight more about what product functionality resonates with our Customers. This will allow our Product team to ask questions and provide recordings to new hires, while also giving our reps the opportunity to get feedback from Product on other functionality that could be highlighted.
  • CRM Churn / Lost Opportunity Feedback: Though this has required a lot of backend work in our CRM, it has provided an opportunity to drive consistency in feedback and tie feedback directly to missed revenue opportunity. This feedback is not only vital for our Product team but also allows us to work cross-functionally with our Support team as well. Building our feedback around two key moments, churn and lost opportunity allows our Sales managers to make sure we’re being better partners to our cross-functional teams.
  • Product Liaisons: Finally, we’re creating leadership opportunities for our more ambitious Sales reps to lead the charge. The expectation is that these reps consistently meet with our Product team, keep up with current projects, and deliver consistent feedback from the field. It is their goal to take questions or projects from the Product team and collect feedback or examples from their fellow reps. They are also responsible for aggregating field and customer feedback into meaningful suggestions for the product team.

These projects are still in their early stages, but at the very least, they have allowed our Sales reps to feel like they have a seat at the table to effectively advocate for their customers. In addition, they are providing our Product team with more consistent and meaningful ways to get more deep into the customer experience our Sales reps are part of every single day.

How do your Sales & Product teams interact in order to ensure Product Centricity does in fact include a healthy amount of Customer Centricity?

Work

4 Ways to Build Confidence between Sales and Product

Leave a comment

I’ve worked with several companies and on several Sales teams, but I consistently hear the same frustrations between Sales and Product. Sales reps consistently say things like “I could make so much more revenue for the company if only the product did x, y, z” or “I’m not sure our Product team is listening to the feedback from our customers.” While on the Product side, I often hear comments like “Sales is constantly giving us a laundry list of items of features” or “we’re trying to develop one-off solutions for very niche use-cases vs. building the product for scale.”

Comments like these happening cross-functionally can create devastating impacts on culture, morale, and trust internally, but it can also lead to poor outcomes for both Product and Sales alike. How can teams avoid this tension and create cross-functional confidence between teams? In this post, I hope to share 4 best practices that I’ve seen between Product and Sales teams that have helped build confidence and trust between both sides of the business. Each of these is framed to be used by either team to improve cross-functional collaboration.

Assume Positive Intent

This is a lesson that I learned early on in my career, and something that sticks with me to this day. Most people you interact with, especially in the workplace, are not malicious. They mean well, they want to be good at their job, and they want to do what’s best. If you approach your interactions cross-functionally assuming that the other team is bought into doing what’s best for the organization, its mission, and its customers, you will find that it’s easier to collaborate.

From the Sales side, I often find that teammates feel unheard with their Product team. They either feel like the most high-impact updates are not on the roadmap or that updates being rolled out are not in line with what they expected. This often gets brought into internal meetings with Product and even with customers at times and prevents both Sales and Product from truly meeting their customer needs.

From the Product side, I often find that Product Managers and Engineers feel like Sales is creating laundry lists of to-dos for Product with little understanding of the long-term vision or how one-off requests may fit into that vision. This misalignment can often cause Product teams to devalue or misunderstand important needs being brought forward from Sales and customers.

If you’ve ever been on a cross-functional call between Product or Sales, you may notice that these tensions can manifest in incredibly unproductive ways. It can derail Product updates due to misalignment, create hostile meetings between leaders, and even create unproductive siloes that prohibit growth.

The Product and Sales teams that I’ve seen most successfully collaborate are those that have leaders that consistently lift their cross-functional partners up. They walk into each cross-functional meeting assuming that they want the same thing: success for the business and its customers. When you find yourself feeling misaligned, whether you’re on the Sales or Product side, take a step back and remind yourself that the person on the other end of the call isn’t attacking you or your work. They are not questioning or challenging as an attack. They are likely seeking to understand and want the same outcome: to move the business forward.

Quantify Customer Impact

I’ve mentioned this several times already: working with a Sales team as a Product Manager can feel like getting a laundry list of to-dos. Without proper quantification of impact to the customer experience, internal processes, or revenue, it can be a guessing game to determine what’s a priority. If you find means to quantify this impact, it will help both teams feel valued and heard in the negotiation of a Product Roadmap.

From the Sales side, it’s super easy, especially in a small organization, to feel like every product limitation is of the utmost importance, especially when you are not tapped into the product roadmap and decision making around it. You start to notice patterns in your own customers, and it becomes incredibly simple to tie lost revenue to these limitations.

From the Product side, you’re consistently tapped into where the Product is in its current state and the cost of the Product requests on your overall roadmap to the future state. It is incredibly understandable to be overwhelmed by all of the information on competitors, ideas for new features, and customer limitations shared by a Sales team when there is a clear vision for where the product needs to go and limited resources to get it there.

Both sides are in a very tough position: Sales must acquire and retain customers despite product limitations and Product must consistently weigh product limitations in the current state against the overall product roadmap. The quickest way to make sure both teams are aligned in this is by creating mechanisms to quantify product needs from your customer base and feedback loops to keep the Sales team in the know.

The most successful teams I’ve worked on use CRM data, ticket requests, and feedback forms to collect this information. Leaders review this consistently and use it to re-prioritize and negotiate the product roadmap. Where you become really dangerous (will discuss this further in the following sections) is turning that into a 360-degree loop where that impact data and the outcomes from it are then communicated back to the Sales team as actions. Whether you’re in Sales or Product, try to find ways to mechanize customer impact and product requests to better align your product strategy to the changes that will provide the most meaningful impact to your customers. Take the guessing out of product development and work together to pull the business forward as a unit.

Collaborate Consistently

The teams I see struggle the most are those that become siloed within the organization. Sales teams aren’t taking the time to deliver feedback or even read about the updates from the Product teams. Product teams are not providing avenues for feedback on product updates or product roadmaps. This siloing is often unintentional but can provide huge levels of distrust or frustration between teams.

Sales teams often stop communicating product requests when they feel like the requests they are making are unheard or unimportant. Delivering customer feedback or meeting with Product can be incredibly time-consuming and difficult to balance against the time that needs to be spent trying to hit a quota.

Product teams often end up siloed when their Sales teams are not providing meaningful information on revenue impact, requirements, or feedback around current and future product updates. Without buy-in from the Sales team on making sure Product goals align with what the end-user needs, it can be difficult to make the right solution to meet those needs.

You want your Product team to match customer expectations, but without the Sales team, your direct front with your customer base, how can you possibly meet your customer needs without simply guessing? This lack of collaboration is often what continues to progress the tension I’ve consistently discussed: Sales feels unheard, Product feels unvalued.

The companies I’ve seen most successful at combating this siloing have leaders dedicated to getting Product in front of customers and Sales as frequently as possible. They meet consistently. They have liaisons between their two teams collecting and sharing feedback on a regular basis. They think of their organizations as one team with one goal: satisfying the end-user. If you’re in a small organization, this may be relatively easy; however, it can often break down in larger organizations. Whether you’re an individual contributor or leader in Product or Sales, find ways to work cross-functionally not only on immediate or urgent needs but consistently. Find mechanisms or avenues to stay up-to-date on current goals, pain points, and updates from your cross-functional partner. Most importantly, be sure to respectfully give as well as receive honest and consistent feedback throughout.

Lead with Transparency

This is basic knowledge if you ever want to be a leader or generally just build trust with others. A lack of transparency causes tension, distrust, and general frustration cross-functionally. It’s important to constantly remember that you are the expert of your own team, but your cross-functional partners probably have no idea what your role or projects entail. Sometimes it can be tedious to remind and educate cross-functionally, but in not doing that, you run the risk of losing trust with these important partners.

From a Sales side, reps are often not tapped into technical specifications, limitations, or decision making. Most Sales reps have never worked in project-based roles, so the way a Product team operates is quite foreign to them. It’s also quite difficult to understand why certain requests may be nearly impossible to execute. This lack of understanding can make often manifest as frustration with the progress made on the Product.

From a Product side, the team is often solution-oriented and can often miss out on key information from the Sales team on what the customer needs and why they need it. Without clear, concise information from Sales, product updates and changes can easily become misaligned due to a lack of transparency from Sales or a lack of understanding of the problem by Product.

Not taking the time to meet your cross-functional partner where they are at in understanding your team, its vision, its needs, etc. is a very quick way to become misaligned. All too often, we assume the other party knows what is happening and understands exactly our intention, limitations, and decision-making.

The teams that work most productively together consistently educate and re-educate on these important concepts. They are honest about why they are making decisions, why they may not be able to satisfy the other team’s needs, and what they need to work better with their cross-functional partners. Whether your Sales or Product, continually push yourself to better understand your cross-functional partners. Ask questions, assume positive intent, and most importantly be honest! Even if you are not meeting the expectations of your cross-functional partner, the best thing you can do is be honest and direct with that information, so they can adjust their own expectations accordingly.

Conclusion

Whether you are Sales or Product, you and only you can control your own reactions to frustrations with your cross-functional partners. You can assume negative intent and continue that rift between your organizations, or you can step up and change the narrative.

Assuming positive intents, quantifying customer impact, collaborating consistently, and leading with transparency are just a few basic ways to build trust between your teams and ones that I’ve seen work really well in my own experience. Let’s keep this conversation going! In the comments, tell me more about your own experience working cross-functionally and what contributed to some of your best and worst experiences doing so.

Personal, School, Women in Tech, Work

A Salesperson’s Guide to Software Development

Leave a comment

Welcome to my first ever “Decoding the Developer” blog post! This passion project has been a long time coming, but I’m excited to finally be kicking it off.

In this first post, I want to dive into the inspiration behind this blog, and the journey I’ve been on to get here. To put it simply, my mission is to merge my own technical and sales backgrounds to help my fellow salespeople walk a mile in the shoes of their product and engineering counterparts.

From Small Town to Corporate America

Don’t worry – we’re not going to start at my childhood. This was just an excuse to share a cute picture from the 90s!

Growing up in middle-of-nowhere Illinois, I never could have dreamed of studying Computer Science or working in Sales. Those career paths just weren’t paths that most adults around me in my small town had taken.

This gave me quite the identity crisis in my first semester of Bioengineering at the University of Illinois. I was surrounded by 54 kids in my program that had taken every AP course known to man and learned much more than Microsoft Office in their high school technology curriculum.

I took my first true Computer Science course that year and struggled my way through it forcing every new college friend to teach me everything they knew. It wasn’t until my junior year that I found my own love for the study. A friend taught me Python, and I got to immediately put to use my new programming skills the very next semester in a Medical Device course I was taking.

It was a little late to switch majors, so I finished my degree in Bioengineering, vowed to keep learning to code, and jumped into an Inside Sales role right out of college at Wolfram Research (yes – like Wolfram Alpha). It was selling Mathematica powered by Wolfram Language that fueled my hunger to go get that Computer Science degree. Enter Oregon State Ecampus.

Marrying Sales and Software Development

It was when my SHPE (Society of Hispanic Professional Engineers) Penpals came to visit University of Illinois that I finally pulled the trigger on going back to school. Their own passion and excitement to be “a woman in engineering just like Sam” inspired me to follow my dreams as well. Working full-time, Oregon State Ecampus was the perfect fit!

I’ve spent the last 4 years continuing to hone my Sales skills and putting my Computer Science education to work to be the most technical Salesperson on every team I’ve been a part of. With an end goal of getting into Revenue Operations, I soaked up all the programming, project management, and general technical skills that I could.

Continuing to marry my more technical education with my work experience helped me create so many resources that improved not only my abilities in Sales but also those on my team. I was able to create reports, scale processes, and do so much more based on the technical skills I was learning in my Oregon State courses.

I finished out my direct selling career at LinkedIn and finally made the leap into Revenue Operations, a space where I felt like my unique skillset would allow me to better the lives of those around me, move up quickly, and leave a lasting impact on the Sales teams I was part of. I joined Bluecrew, a small startup of just under a 100 employees, and quickly carved out a special place for myself as the Senior Revenue Strategy and Analytics Manager just a year after joining.

Decoding the Developer

This brings us to current state. I’m taking my Capstone course while serving as a leader for the Revenue team at this growing startup. Consistently, I’m interacting with both our Product team and Revenue team trying to communicate and escalate improvements for our customers to a Product team with very limited resources.

In doing this, as you can imagine, there’s always a light tension of Sales wants/needs and Product team capacity. I’ve even found myself frustrated or confused due to slow progress or mismatched expectations with our cross-functional partners. It’s in these frustrated moments, that I often try to take my Revenue hat off and put back on my Product Manager hat.

Courses like Capstone with projects that force students to be not only the Developer but also the Project Manager and even sometimes the customer have completely changed my work behaviors. I’ve improved not only my effectiveness in my own role but also improved my relationship and communications with my partners on the Product and Engineering side.

Why start blogging about this now? I’d like to use my current Capstone project and future projects to help my dear friends on the Sales side get a simplified look at what goes on over on the Product and Engineering team. It’s my hope that this will not only spread the compassion I have for my Product Manager and Developer friends but will also help other Sales folks communicate their concerns, needs, and product visions more effectively on behalf of their customers as well as themselves.

Join me in “Decoding the Developer: A Salesperson’s Guide to Software Development”. It’s going to be a fun journey!