Playbooks by XANT
The sales engagement space was seeing a gradual shift from one-off interaction attempts to a more cadence-based system of engagement. Playbooks was launched as the eventual replacement for the existing XANT (formerly InsideSales.com) offering, PowerDialer.
To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. The information in this case study is my own and does not necessarily reflect the views of XANT.
My Role
During my first year at XANT (formerly InsideSales.com), I was the Lead Product Designer for Playbooks. Setting the tone of design for as many as three other designers, I worked with the entire engineering organization (nearly 70 engineers) and a small team of product managers to take Playbooks from its opening launch day in January 2017 to its multi-million dollar ARR status it had the following year.
I transitioned to Director of Product Design during my second year, where I oversaw the work of five designers and one product researcher on the project. During this time, we built dozens of new features, spent hours upon hours of time researching out in the field, and successfully facilitated dozens of design sprints and workshops.
Stay Focused & Generate Revenue
Playbooks guides reps to focus on the accounts, people and opportunities that will actually generate revenue. Playbooks does this by prioritizing a reps daily tasks and enables AI driven engagement, giving reps the control they desire and the results sales leaders need.
Personas
Sales Development Representatives
Working through lists of prospects and leads, a Sales Development Representative spends huge portions of their day trying to connect with those leads and prospects through phone calls, emails, or other means of communication. With an overwhelming number of leads, an SDR needs a tool that gives them the consistent touches and organization automatically, with little effort from them.
Inside Sales Reps / Account Executives
Account Executives (also called Inside Sales Reps) spend their time closing deals for their sales organizations. They need to stay organized and make sure they are touching each of their opportunities consistently as the deal progresses through the various stages of the sales process.
User Flow Map
While a huge portion of our user base sits within the Account Executive persona, the core usage from the product comes largely from the Sales Development Representative persona. Because of this, most of our efforts are focused around building an engaging and effective tool for those individuals.
In order to create a user flow map, my design team spent a few months of time in the field, researching, observing, and interviewing our users. Through this research, we took hundreds of data points, organized them into Jobs to be Done, and then created a user flow from the results. We are constantly evolving and updating this flow as we continue to research our users.
A typical SDR takes a short amount of time early in the day to organize their day, their tasks, and prioritize how they are going to complete their work. Then, they jump into the next most important task, determine how to connect with that person, and then personalize the touch point. Throughout the day, they update their records to keep them clean, and keep an eye on their own progress to make sure they are going to hit their goals.
Our Design Process Evolution
I joined the InsideSales.com team (now XANT) in January 2017. I first started as a product designer, the first one the company had ever hired, and was joined my first day by the Director of Product Design who was also a first for the company. Together, we had to find a way to learn the product, understand the company structure, and build out an effective strategy for injecting design thinking into the product. 
Creating a Design Team From Scratch
My first mission with Playbooks was to tackle the backlog of design work that was needed. Front-end engineering for new features had been put on hold while the company searched for a new designer. The company had previously worked with a web designer, but that person had been stressed out, overworked, and was in over their head trying to build a product. They had left the company nearly 6 months before we arrived.
My first few projects were a little bumpy as I tried to navigate communication channels and learn which engineers I was going to work with. I was responsible for doing the design work for 60 front and back end engineers as well as a team of 20 data scientists and data engineers. This presented a really unique challenge and here I learned how to stick to proper design processes and when it was appropriate to fast-track certain things in order to ensure engineering was working.
I also relied heavily on the engineers themselves to make decisions that I didn't have the time to make myself. We were burned a few times with poor choices, but overall the engineers proved that designers weren't the only ones who could make good design choices.
A few months into the project, our team started to expand. We hired two additional junior-level designers, giving me the opportunity to mentor and teach two new entrants to the field. A year later, we brought on another senior-level designer to help with the workload.
Introducing Design Processes
With the first few months of our time spent largely focused on catch-up work, we decided to put design process on the back burner. Once we finally had our heads above water, we changed course and started to find ways to inject design thinking into our engineering and product culture.
We were working with 8 different engineering teams who all had different needs, focuses, and ways of communicating. Our first challenge was communication. At the time, there was no mandated communication platform at the company, so we had to use four different chat programs to work with various teams. Once the company changed policy, we were able to define channels within Microsoft Teams where conversations around design, product and engineering could take place.
We also felt stretched and we weren't able to work as closely with the engineers as we would have liked. Instead of being able to work collaboratively alongside them, we often had to build out design work before the engineers began and then provide documentation and specs through InVision for them. Engineers often struggled to fully understand what we were trying to accomplish and this led to things being built that didn't match our vision. Over time, we began to provide more and more documentation, trying to think through all possible states and fringe use cases before hand.
But the real improvement in communication didn't take place until long into my time as Senior Product Designer. Once I had become comfortable with the various teams, I began including select engineers in the design process earlier and earlier. At first, I was nervous to do this because I had seen some of the design efforts these engineers had previously pushed into the product and I foolishly thought their opinions would be less valuable. After working with these engineers over time, I realized that their input up front was actually saving us all time and effort later on. I was able to create designs that were realistic, functional, and even better than what I could have conceived on my own, so I pushed further and further into bringing engineering into the process at the beginning.
Using Design Sprints to Solve Problems
As our influence on product and engineering grew, we began to see more and more requests for design help coming from other organizations and projects in the company. We soon found ourselves solving problems that had little to do with design but because we had identified processes that helped solve problems, we were able to bring that expertise to others in the organization.
We had a unique opportunity come our way from another product within the organization and decided to use that opportunity to run our first Design Sprint. We brought in five cross-functional stakeholders into a large room for a week in one of our offices and worked on solving the problem together.
In our first design sprint, we spent hours upon hours crafting a very large prototype. We worked well into the night and found ourselves with little sleep in the morning. Our prototype was then tested with five prospective users and we analyzed the results as a team. The learning from this was to try and find ways to put less design energy into the prototypes and more focus on creating artifacts that could lead the interview in the direction we wanted to go.
We have continued to use Design Sprints often, and we have also modified the structure in ways that reduce the amount of time needed while still achieving effective outcomes. We have run more than a dozen sprints and workshops over the course of the following year.
Tracking Our Maturity Model
After 18 months at the company, the Director of Product Design took another opportunity and I was given the chance to step up into the role. I embraced the challenge and tried to find ways to continue to push both myself and the members of my team on the Playbooks product.
I introduced the concept of a Maturity Model quickly as I wanted to better articulate how we needed to grow as a team and influence the organization more that we currently were. I created a model that was structured to fit our organization and our unique design and engineering processes. Where our team didn't have an ideal designer-to-engineering ratio, things had to operate differently than they might at other organizations.
The model continues to guide us as we find ways to improve our processes as a team and collaborate more with engineering, product, and leadership.
The Product Experience
Adding Leads & Contacts to Plays
Adding Leads and Contacts to a play is the core feature that makes Playbooks a worthwhile tool for a sales rep. Playbooks automatically builds a set of tasks scheduled a present number of days apart. Plays can be customized to change the types of interactions, the content of emails, and the time in between each step, all while automatically scheduling the next step for each record.
Prioritizing Tasks
When a sales rep has more tasks to complete in a day than they can realistically accomplish, Playbooks gives the rep the tools they need to make sure they are prioritizing the right tasks at the start of the day. Reps can choose this on their own, or sales managers can build advanced, customized sort methods based on fields in their own CRM, ensuring the hottest, best leads hit the task list first.
Real Intelligence on Leads, Contacts & Accounts
Using our pool of over two billion data points, Playbooks can offer up real intelligence for the leads, contacts and accounts inside each sales rep's CRM. Reps can see valuable information like how likely this person is to open or reply to an email, whether or not they are an influencer at their company, or how likely they are to engage in a meaningful conversation over the phone.
Task & Organization Automation
So many of the tasks a sales rep faces are incredibly repetitive and simple. Playbooks can help a sales rep stay organized and become even more efficient by handling simple tasks for them. Move records in and out of plays based on criteria, add tasks based on email interactions, or even trigger notifications based on lead type.
Phone & Email Verification
Knowing which phone numbers or email addresses in a set of leads actually work is a huge undertaking for any sales rep. Playbooks takes the pain out of that process by showing verification next to any number or email in a sales rep's CRM, indicating the quality and the type of contact it is.
KPI Tracking & Leaderboards
Sales reps are often competitive in nature, so Playbooks provides leaderboards and KPI tracking for those reps. Broadcasting metrics to a screen can help motivate sales reps and increase productivity.