Interested in marketing, product management, customer support, design and startups? On our blog the Intercom team share thoughts, tips and lessons learned from five years of product building. Intercom is the first to bring messaging products for sales, marketing & customer service to one platform.
The engineering interview presents a unique opportunity to showcase your company’s engineering culture and values to potential new hires.
It may be a candidate’s first substantial interaction with your company, and just as you would build a great first experience for your customer, it’s equally important to build a great interview process for your candidates.
After spending months interviewing at companies of various sizes and success, I saw firsthand the unique styles of interviewing and testing across our industry. It struck me that most of these interviews were so far removed from the daily routines of a software engineer. Rather than test resourcefulness and basic foundations, a lot of these interviews tested random bits of specific knowledge that could easily be looked up with a Google search.
Most interviews are so far removed from the daily routines of a software engineer.
At Intercom, the interview process is different. The premise is simple: build a smaller version of the Intercom Messenger, dubbed “Minicom,” in a set of amount of time. After you get the basic functionality working, you can choose which features to build out and what parts of the product you would optimize. At the end, you demo your product and explain the reasons behind your product and design decisions, and even explain what else you’d build if you had more time. It’s always interesting to see where people focus their time and whether they care about getting something into customers’ hands quickly. During the interview, you also do pairing sessions with Intercom engineers where they help you with any problems you might have run into along the way.
Now that I’ve been at Intercom for a couple of months, I can see that our interview process is a great reflection of the way we work.
We ship to learn
Our shipping philosophy is to start small, build cupcake-sized products and iterate quickly. Minicom is a perfect representation of this philosophy. It is literally the smallest possible demo that you believe you can build in the short amount of time provided, that adds maximum value. Shipping is our heartbeat at Intercom and we actively ship to learn. We understand that a product built over an interview isn’t going to be perfect. We let our candidates explain their design decisions and what they learned along the way. We also ask them what they would do differently if they had more time, to hear how they would apply these learnings in the future.
We are collaborative
At Intercom we inherently believe that the best work is done when people work together – playing to their strengths and leaning on others to to help with their weaknesses. The pairing sessions achieve this. These sessions mimic a real world experience and are there to help you achieve your goal and test your collaborative skills. I remember I made a list of things I couldn’t look up on Stack Overflow or figure out, and during the pairing session I was able to ask for help and get them solved quickly. This is something I still do almost everyday working at Intercom.
As someone who is very passionate about building things, the pairing session was like a dream come true. I had the opportunity to work on parts of the stack that I was familiar with and lean on a couple of talented engineers to help me complete the task. At the end of the interview I got to demo my creation to a group of engineers that were genuinely excited to see what I built. They even gave me a round of applause and thanked me for my time at the end of it. When I walked out of that building, it was clear to me that Intercom had valued my time and had provided a collaborative environment that I enjoyed working in.
We value learning curves
We also care a lot about rate of learning. As a company that’s growing very quickly, we have to constantly iterate and learn new things along the way in order to be successful. Testing engineers for curiosity, skills and potential ensures we hire people who can scale with the company as it grows. Even if our candidates don’t have much pre-existing knowledge of our particular stack, we believe that if they have strong fundamentals and a fast rate of learning they will be very successful here at Intercom. Or, in the words of Stanford Professor John Ousterhout, a little bit of slope makes up for a lot of Y-intercept.
Interviewing is a two-way street
As much as we interview a candidate, it’s important to know the candidate is also interviewing us and evaluating us as a potential workplace. That is why it is important for us to respect the candidates’ time and build an interview process that is transparent. It is difficult for a candidate to judge a company’s culture in a single day and hence creating an interview process that communicates this culture best will help both Intercom and our candidates make more informed decisions.
We teach what we preach. Whether it’s building cupcakes, or our belief that the best work is done in teams, our interview process tries to mimic our engineering culture and values. At the end of the day, whether or not the candidate and Intercom are a good fit for each other, we want them to tell their friends and coworkers what a great experience they had regardless of the outcome. We’ve done a lot to try and make our interviewing process personal and transparent.
Sometimes your customers really want to use your feature or product, but they also want something else that simply isn’t compatible with it. People really want to be slim and healthy, but they also really want soft drinks and fast food.
McDonalds and Weight Watchers are selling wildly different products, but they’re competing for the same customers. This is what we call indirect competition.
Your direct competitors are targeting the same job-to-be-done with the same solution as you. If you want a burger, McDonald’s and Burger King will both satisfy that job with the same outcome.
Unlike indirect competitors, secondary competitors compete on outcomes. For example, video conferencing and business class flights compete on outcomes as they’re both hired for the same job – business meetings – but solve the problem in a different way.
In indirect competition, there are two different jobs a customer wants to do, but the jobs themselves are competing with each other. Software products experience these types of conflicts all the time:
“I want to allow payments in my product, but I want to minimize the amount of third-party integrations we rely on.”
“I want to add this analytics tool, but I also want to optimize response times.”
“I want to know how my team spend their time, but also to show we’re a trusting work environment.”
It might go against logic, but humans are perfectly okay with maintaining multiple conflicting opinions and desires. We want to have our cake, and eat it too.
There are two conflicting forces here. The attractiveness of the outcome of your product vs the other product. Your marketing should work to make the alternative outcome less attractive, or reposition your product so the outcome is no longer in conflict. If you’re wondering how to achieve this, check out our article on marketing using jobs-to-be-done.
Manage your indirect competition
A customer of Intercom was perplexed. Hundreds of companies had signed up for his A/B testing product, but very few had taken the plunge beyond a trivial test. All the customers really wanted to use the product, knew how to use it, and understood the value. He used Intercom to message these users and identify what was going wrong.
The point is customers don’t experience your product in a vacuum.
To address these concerns, he added a message schedule downplaying the importance of clean code and up-selling his product. He sent the following message to non-users on day three: “If no one is using your product, who cares how clean your code is?” On day seven, he sent another well-timed message: “This morning your team can add more code, or add more customers. Which do you want?””
These messages were effective. Many resulted in installs. Some resulted in technical debates. But most importantly all of them produced extra insights into their business, which is what you need when you’re starting out.
Know your real competitors
Jonathan Klein, the former president of CNN, once identified his network’s indirect competition this way: “I’m more worried about the billion or so people on Facebook every day versus the 2 million people watching Fox News.”
The point is customers don’t experience your product in a vacuum. They experience it alongside every other product, service and idea fighting for their attention. Some of these will compete with your brand and some will contradict it. Understanding all these forces helps you counter them with your marketing efforts.
As a startup scales, the importance of infrastructure engineers simply can’t be overstated. They’re the ones making sure your app is secure, that uptime looks good, and that the rest of your engineering org has the right tools to build features your users need and want.
Will Larson has managed infrastructure teams for some of the biggest names in software. Today he’s leading Foundation Engineering at Stripe. Partnering with the Infrastructure, Data and Developer Productivity teams, his group builds the tools that support every Stripe engineer and keep Stripe reliable and performant.
Previously, Will was an engineering leader at Digg and then at Uber, where he scaled infrastructure engineering from a small team to more than 70. All the while, he’s been sharing his latest thoughts on infrastructure, devtools, management and more, on his Irrational Exuberance blog.
I hosted Will on our podcast, where we talked about how he keeps his team innovating, hiring generalists vs. specialists, managing in a high growth environment and more. If you enjoy the conversation, check out more episodes of our podcast. You can subscribe to it on iTunes or grab the RSS feed in your player of choice.
What follows is a lightly edited transcript of our chat.
Todd Royal: Will, welcome to Inside Intercom. Can you just give us a feel for what you’ve been doing in your career to date, as well as the work you’re doing today at Stripe?
Will Larson: When I graduated from college I was actually teaching English in Japan for a year, and that’s when I started doing a lot of tech blogging. One of the blog posts was about this Yahoo! product called Yahoo! Boss, a build your own search service, and they contacted me. Here I am teaching English – and although I studied computer science, I had no experience – somehow this blog post turned into a job at Yahoo! It was a miracle. I was at Yahoo! for a couple of years, learned a ton there, and then joined Digg. I always describe Digg as Reddit but better. It went bankrupt and the product failed, so there’s no actual evidence that it’s better in any way, but in my heart it certainly is a superior product.
One of the exciting things about a company that is going through a little bit of change, a little bit of chaos, is there is a lot of opportunity, and for me that opportunity was getting to move into management. I stayed at Digg until the company closed and through this talent acquisition where we joined SocialCode. After a few years there I started thinking about what I wanted from my career. Until then, it had been very haphazard, and I thought about what I wanted to do next.
I wanted to work at a company that was growing very quickly. At that time, the fastest-growing company by some definition was Uber, and so I went. One of my friends who had worked at Digg had moved there, and I went to work on the infrastructure engineering team. That was just a transformational experience. I learned more in the two years I was there – going from 200 to 2,000 engineers – than the entire rest of my career really. But, I also got a little bit worn out. Such chaotic growth was a lot to be part of.
About two years ago I joined Stripe, where I’m working with the foundation engineering team. That’s our developer tooling, our data engineering, and our infrastructure engineering group.
The tenets of foundation engineering at Stripe
Todd: What’s the nature of the work you’re doing day to day with the foundation team?
Will: We have such a large remit that we work on quite a few different things, but there are core properties of infrastructure and core things we do for the company. We think about security as our north star. Stripe moves money, so security is important for us. It’s better for us to be down if we’re insecure than it is for us to be up and insecure.
We think about security as our north star.
Secondly, our companies depend highly on us, so we spend a lot of time on the property of reliability. Third, a little bit unusually, we think about usability. Our biggest customers are externally these merchants that depend on us, but internally we have more than 300 engineers that depend on the tooling, platform and infrastructure we provide. How can we make sure that we’re creating as much leverage as possible for these engineers who depend on us? We’re really thinking about building infrastructure as a product to serve them.
Finally, we think about latency. How can we make it fast? How can we make it responsive? As Stripe becomes an increasingly mature company, efficiency will get more important for us, but right now we’re very focused on making sure that we’re proving the very best possible experience to the merchants. Our internal operating efficiency in terms of our infrastructure spend, etc is a little bit lower on our priority list.
Making the shift from maintenance to innovation
Todd: You wrote a great blog post about the struggle for infrastructure engineering teams to shift from working on maintenance and tech debt to delivering innovative features. Why do you think that is, and where do you see the tension between these two modes of working?
Will: That’s a really interesting and important question. When I first joined Uber, I was actually hired as a DevOps manager, which was kind of funny in the sense that I literally didn’t know what DevOps was. One of the things I found as I’m desperately Googling “What is DevOps?”, was a book called “The Phoenix Project”, written by Gene Kim. It’s a great introduction to DevOps and in particular the Kanban style of managing projects.
The core tenet of the book is that you only get value when you ship things. There’s this point in infrastructure management when you are a little bit on fire, when you have so much stuff you need to do. You have to get extremely myopic and extremely focused on just shipping things. There’s no value in doing work, there’s only value in finishing work. This is the core part of toil management of teams that are pretty underwater. You spend so much time making sure that you ship as many things as possible, and part of that means not spending any time on things that don’t add to shipping.
You need to go from just solving problems to actually selecting problems to solve.
This gets really challenging on the flip side, when you come out of this firefighting mode. All of a sudden, you need to figure out what to work on. You need to go from just solving problems to actually selecting problems to solve. One of the challenges is that all of your muscles for learning from your users have atrophied, because you just don’t do it.
Think about something like product management. When you are working through toil there’s not a huge role for product management in infrastructure groups. Then you pop out and all of a sudden you need product managers, but you haven’t probably prioritized hiring them, or you haven’t built this relationship with them. Making that switch from being very focused on managing the completion of projects to user discovery, user validation and building these relationships can be a rocky time for infrastructure groups.
Todd: What you said about only getting value when you ship really resonates with me. At Intercom, one of our engineering principles is that shipping is our company’s heartbeat. There’s a lot of emphasis on making sure that we’re shipping regularly, and it can be a struggle.
To your point on product management, how does engineering at Stripe partner with product management. What are the unique pieces of your development process?
Will: Like most small companies, initially Stripe had this “everyone does everything”, generalist model. Back then engineers were writing all of the technical writing, all of the documentation, writing the code, doing the product management, and reaching out to the business partners and trying to establish partnerships. We had a great culture of the generalist, and that really worked with us for quite a while. One of the special things about Stripe is that so many of the early employees, especially those who are still there at Stripe in increasingly large roles, started out as real generalists, with an incredibly broad skill set.
When you get larger, sometimes it helps to have someone who’s done it before. It helps to have someone who’s not learning on the fly. We’ve moved more and more towards having specialists in certain high-leverage spots across the company. One of those is definitely product management.
Back to the point of us switching from toil to innovation and learning how to actually get real feedback, people don’t like to give negative feedback – even if your software or your tool doesn’t work well. People tend to say what they think you want to hear. Learning how to get people to actually tell you what they actually feel about your software is a skill that product managers are hugely valuable for.
In terms of Stripe’s product management, we’re adding more and more and we’re defining their role more clearly. Historically, the engineer management role and the product management role had a lot of overlap.
There’s a classic challenge where very few infrastructure engineering groups have product management. They tend to rely on the senior engineers or the engineering managers. That’s a blessing and a curse. The blessing is that you are your own customer. You’ve used these tools, and you are building for people whose needs you understand. The curse is that sometimes being your own customer blinds you, particularly as you’ve been in infrastructure longer and longer as opposed to using the tools. It can be easy to get a little bit disconnected from what the users actually need.
This is definitely something that we’re thinking about. How can we use product management? Right now we’re really focused on building the skills of our existing engineers and existing engineering management in product management, but I suspect even in infrastructure we’ll have product management in the long term.
Hiring in a high growth environment
Todd: With the growth you’ve experienced at companies like Stripe and Uber obviously comes a lot of hiring. What are some of the things you’ve been doing at Stripe to stay productive and stay focused during that kind of growth?
Will: When I think about hyper-growth, companies growing this quickly, the most important thing is being very reality-based. What I mean by that is you can add folks to a team that is growing quickly, but it will actually slow the team down. In the long run though that team will be more effective and will have more capacity, but in the short run it’s going to get slower. You have to be very honest about the trade-offs that you’re making in terms of maximizing for certain durations of time. Sometimes these trade-offs are really uncomfortable because there is no acceptable trade-off to make and you have to make a trade-off anyway. Be very consequent in your reasoning and understanding the consequences.
The things I find most important are problem selection, solution validation and pure execution.
That said, there’s a few things that really matter, and the thing that is most important, more important than literally anything else, is onboarding. Stripe has spent a lot of time trying to make our onboarding process as effective as possible. We have this program called Dev Start, which is the onboarding bootcamp model, a little bit similar to what Facebook has done. We get (new hires) to ship a very simple commit on the first day. Also, in the first month they ship something meaningful, something usually that they can see as a user-facing thing. That’s incredibly powerful in terms of building a community of new hires, and as you grow quickly, maintaining a community is one of the very important things to do. It’s also powerful in terms of that rapid experience of getting a commit up, getting it deployed, maybe debugging it if something goes a little bit wrong and actually building the competency with the day to day tools.
Todd: The other thing that comes with hiring is evaluating skill sets and deciding what things you want to focus on as a company for the future. What are the skills that you value most now among engineers in today’s market?
I do think there are three meta skills that are incredibly important. Those are problem selection, which means picking valuable problems; solution validation, which is actually making sure that your approach solves the problem; and then third, execution. Something that I think is incredibly important across all of the those is the ability to communicate well and to be an effective collaborator in a larger community of developers around you. In terms of Stripe’s general theory around hiring generalists when possible and specialists when highly leveraged, I do love to get people who have general experience. But the things I find most important in the folks that we hire and the folks that I’ve worked with are problem selection, solution validation and then pure execution.
Todd: The fact that you’re talking about problem selection and solution validation suggests that you’re really looking for engineers who are problem-oriented and focused on outcomes. We’re that way too. Our software engineers are actually called product engineers internally for that reasons. We want to find people who are focused on solving problems rather than just the technology.
Evaluating a jump into management
Todd: Last thing on growth: As you’re hiring and onboarding engineers at this rate, you obviously need management as well to jump in, corral the teams and lead people. From one engineering manager to another, what advice would you have for engineers who are thinking about making that leap into management?
Will: Career advice is always dangerous, because the devil is in the details. I think the most important thing is to move into management for the right reasons. Historically, at many companies there’s the sense that management is a promotion or that there’s different compensation. Increasingly at the top-tier companies in the Valley and I imagine elsewhere, it’s possible to go quite far in your technical career and get compensated equivalently to the management role.
You will get a number of opportunities to move into management. I lept on the first one, and occasionally I regret that.
One of the illusions of management is that you have a lot more control or you have a lot more authority or power. You have a lot more opportunities to make decisions for more folks as a manager, but also the constraints of being a good manager are quite challenging. You have to keep your team happy, you have to make sure your team is doing something they love, you have to keep your peers happy, you have to make sure that the product management or the design or the other engineering manager you’re working with are happy with what you’re doing, and you have to keep the company and your management chain happy. To actually do all of those to me is the hallmark of a wonderful manager, but also doesn’t necessarily give you a ton of flexibility in the decisions you make. It can be more decisions to make but less actual control in doing them at times. Going to management because you want to help is critical. Going into it for control, for compensation, definitely doesn’t.
One of the choices you do get to make is in what company and what environment do you move into management? Picking a company that has a healthy management culture is so important. So much of what you will become as a manager is based on your first experience, and you as an experienced engineer will get a number of opportunities to move into management. I personally lept on the first one that I got, and occasionally I regret that, because I came up in a bit of a firefighting, chaos management culture, and I’ve had to unlearn a lot of those lessons over time. Really try to find a company where you want to become like the managers there, and start your management career in that environment.
Todd: That’s an interesting way to think about it. Are there things that have stood out to you as being indicative of strong management culture or things that you would say engineers thinking about making that move could count as positive signs?
Will: Is there a management culture or are there many different types of management cultures? Something I’ve been thinking about a lot is that in fast-growing companies or very early companies, management is largely around change management. How do you solve more and more and more different problems? This is very much an evolutionary role where you’re always dealing with a new problem and you’re trying to get a reasonable, good enough solution in place and then move on to another problem. At more established or slightly slower-growing companies it’s much more of an optimization game. How do you make the team a little bit happier? How do you get a slightly stronger person in the door to fill in for someone who has left? How do you improve your relationship with someone a little bit more? How do you get a few more story points done in this sprint? It’s a very different feel.
A lot of the challenges that folks have in terms of first moving into management, but also moving between management roles, is not understanding that there’s these two extremely different skill sets, and thinking they can take what they mastered at a more mature company in terms of making the folks who are there happy and iterating incrementally, and apply it to a place where they have to be extremely consequent about solving problems as sufficiently possible and then moving on. They’re extremely different outlooks for success.
Speeding up your time to alignment
Todd: At the end of 2017 you published a Twitter thread of lessons learned, and one that struck me really reads, “In a scaling organization, the ability to be consistently aligned within and across teams is a marker of excellence. Time to alignment is your re-org success metric.” What to you does successful time to alignment look like?
In a scaling organization, the ability to be consistently aligned within and across teams is a marker of excellence. “Time to alignment” is your reorg success metric.
Will: Alignment is about having truly shared goals and everyone agreeing on those shared goals. As you change the team composition, as you move teams to different areas or refocus them on different problems, it damages trust a little bit, and you have to rebuild that trust. When I think about time to alignment, it’s how long does it take to rebuild that trust and for the teams to start operating effectively again. A litmus test here is the time it takes before you can comfortably ask a team that’s just been reorged or moved to do something they don’t want to do without being afraid that they’re going to revolt or get upset with you. How long does it take to actually build that relationship and that trust again after the last change, to be able to stretch them a little bit into doing something uncomfortable?
Alignment is about having truly shared goals.
A lot of this is just communication. Communicating honestly and with some vulnerability. Sometimes one of the hardest parts is that often organizational changes are solving a problem that no one really wants to talk about. Maybe there’s a manager who’s really struggling, but you can’t just say, “We’re doing a re-org because this person is struggling.” Instead you talk about doing a re-org to solve a proxy goal. That’s when you end up with communications that people read and it doesn’t resonate with them. It sounds fake, and it’s because you actually aren’t able to talk about the actual goals. Avoiding having to talk about proxy goals is quite important, but then if you do have to pick a proxy goal – sometimes you really do – make sure you pick ones that aligns as closely with your actual goal as possible so that people don’t read this plan or read this reasoning and think about the classic “They left to go spend time with their family,” which everyone’s thinking, “This is a lie”. You have to be careful about triggering that sensation in folks.
Todd: Are there ways in which you’ve seen that really break down in the past?
Will: The marker of re-orgs not going well is the time to next re-org. As a general rule of thumb, the frequency of re-orgs tends to imply when the re-orgs or the org changes are not going super well. Thinking about user testing and solution validation, I find that you can do this with anything including a re-org proposal. If you find some of the impacted teams, find someone you can trust, and run it by them, they can tell you immediately if it actually resonates. Maybe this is not a marker specifically of what’s wrong, but if you actually go do some user validation with the users of this re-org, they can almost always tell you. Sometimes you have to communicate a little bit to try to get around the proxy goal versus real goal element, but really just asking people if it makes sense, and if they say no, it probably doesn’t and you should keep working on it.
Todd: You’re also an avid reader, and one of the things that you often do is share key takeaways from what you’ve been reading on your blog. What’s one book that you would recommend every engineer read, and why?
Will: The most interesting book I’ve read this year was “Good Strategy, Bad Strategy”, which is a great exploration of why sometimes when we try to solve problems, our strategies just don’t work. But really the book that I’ve been most influenced by is “Thinking in Systems: A Primer”, by Donella Meadows. It’s a book about solving problems, but more about understanding problems. In particular, humans tend to think about things causally, like the server is down because we pushed a piece of bad code, but sometimes problems are much more complicated. You upgrade a small dependency, which made your API a little bit slower, which caused connections to start backing up in your proxy, which caused health checks to start flapping, which caused APIs to start failing 10 percent of the time. And it’s really thinking about that type of problem, where it’s not just A then B, but actually..
Prior to joining Intercom as a Product Manager, I had never run a structured beta. When it came to finally running my first one, I was surprised to find very little information online that could help me.
I’ve run a lot of successful betas now but I learned my craft through tribal Intercom knowledge, built up by other Product Managers over the years.
The content I did find online was overly prescriptive and too focused on the specifics that weren’t going to be relevant to a wider audience with different products. To address that deficit, I’ve put together a guide on how we run betas here at Intercom.
Short on time? Here are the key takeaways:
Understand the problem that you’re trying to solve
This will pinpoint why you’re running a beta and help to define what you want to learn as early as possible. This should be done before you even create a build plan.
Paint a picture of what success looks like
Decide how you will measure it so you can assess whether or not you are solving the problem adequately.
Consider who should get access
Start small with early adopters who already experience the problem you’re trying to solve. Broaden the audience over time to include users who haven’t asked for the feature.
Decide how you’re going to pitch
Work on how you’ll pitch and describe the solution in a way that makes the most sense for your users.
Get feedback direct from your customers
Jump on customer calls and send targeted messages based on usage of the beta to gather feedback. Create one source of truth that keeps this up to date and organized.
Evaluate the findings
You should evaluate all of your learnings and feedback against the problem you set out to solve. Decide whether or not you are holding something of value back from non-beta customers or if it falls short of the bar you set out to exceed.
Decide when to ship
Set a timeline to make a final call on whether and when you will ship the feature you’re testing – this is a crucial forcing function to avoid becoming paralyzed by the mountain of feedback.
Step 1: Why should you run a beta?
One of the biggest pitfalls Product Managers continuously make is planning a beta as the feature approaches customer readiness. That’s too late – you’re likely asking the question “Will we beta this?” because you feel you should be. Instead, asking yourself, “What do I want to learn as early as possible?” should be your starting point.
Start with why and everything else will fall into place.
For any project that contains uncertainty you should be considering whether you will release an early version to a group of users from the outset. At Intercom, we scope small. It can feel uncomfortable but there’s always a version that can be released early that you can begin to learn from.
The answer to “What do I want to learn as early as possible?” will inform how you roll out the final feature, not just your beta. Start with why and everything else will fall into place, like who will get access, when do they get access, and what they will get access to.
Not every feature you build will require a beta. We have shipped new functionality that didn’t allow for or justify the overhead of running a beta. An example of this was enabling customers to capture an email and replace the standard conversational reply on outbound messages.
Our new feature required considerable volume and we were working under tight timelines so we decided it would be better to release and learn rather than run a half-baked beta. As a form of QA, we worked alongside our Content team to dogfood the new feature on our blog and see how it performed in a short period to decide whether it was worthy of release or not.
Betas are not for finding bugs. Betas can be a great safeguard against bugs but it’s dangerous to release things to beta that you are not confident in your QA efforts on.
Step 2: What does a successful beta look like?
You need to define what success will look like for you by outlining what metrics are relevant and need to be measured. You should also set targets for these as a benchmark.
Success metrics are essential for comparing progress to.
Success metrics are essential to having something tangible in place to compare progress to, inform actions, provide a mechanism to fight for during the beta and post release, and prompt important questions.
When the new reports for our Inbox product were in beta, we gave users the ability to switch between the old-style reports that were available to all of our customers and the new reports that were only available to those in the beta.
We had adoption and engagement metrics in place with targets we wanted to hit. These metrics suggested a large cohort of customers switched directly back to the old reports on every login. To learn the real reason why this was, we decided to remove access from the old reports once we were confident that the new reports were doing what they should.
We learned two things very quickly from this:
The majority of customers switched back to the old reports out of habit
Two specific insights our old reports were enabling in a better way were being catered for poorly in our new design
We iterated on our new reports design and then were in a much better place to rollout and replace reports in a more informed and confident way.
Step 3: Who should you invite to your beta?
You need early adopters who are likely to get started with the new feature or product right away and be all right with something that could be a little rough around the edges. To find these people, we start with conversation records of customers who have requested the feature or experienced the problem we aim to solve.
Your solution should be the only incentive needed.
You should always start with a small rollout and then increase the audience based on adoption and feedback. Unless there is a risk or downside to the beta, such as breaking a primary workflow, you should opt in apps and notify them, rather than asking if they want to be included. Asking if they want to be included is just an additional step that creates a hurdle. Of course, this varies wildly as a rule of thumb depending on your business.
As your beta matures, add a random selection of other users who haven’t experienced the issue or requested the feature to ensure you aren’t only receiving feedback from a biased group.
Incentives are built in to many beta programs but if you feel like you need one to get usage, you should ask yourself two things: Do you know who needs this? And does anyone need this?
The solution should be good enough as an incentive in and of itself or else something is wrong. We scope our betas to include at least some customer value, otherwise where is the hook?
Step 4: How to communicate your beta to your customers?
When it comes to beta messaging at Intercom, we rely primarily on messages sent via our own Intercom messenger. We use tags to manage beta participants and send messages that are contextual to them being in the product. The other major benefit is that customers can start conversations, ask questions and provide feedback via this message.
Here’s what you should include in your message:
1. Stress to the customer that it is a beta in order to set expectations.2. Describe the problem.3. Describe what the solution is and where they can find it. Be visual.4. State that you need feedback in order to improve the feature and are building the most impactful solution.
Step 5: How to get feedback on your beta
Specifying that you’re running a beta in order to capture feedback should be enough to kickstart organic feedback loops. People who offer feedback without being prompted are invaluable. You shouldn’t underestimate the importance of jumping on calls with these customers early on. You don’t need to conduct state of the art user research sessions, just ask for a few minutes of their time.
Be careful not to burn bridges with customers.
Before the call, you should review what they have and haven’t done then jot down the qualitative questions you care about them answering the most. Invite an engineer and designer involved in the work to listen in and make sure to capture every piece of feedback.
You can’t rely solely on proactive feedback. Usage metrics are crucial for feeding into whether the project is a success or not and will help inform the questions you ask. Sending a message requesting feedback to people who don’t use the feature is a waste. Only a small set of customers will use the feature and provide quality feedback so it’s important not to burn bridges. Targeting your messages is key to getting the most out of feedback opportunities and keeping on the good side of your beta users.
Step 6: Making sense of beta feedback
It’s crucial to capture every insight and information point during the beta process. Product Managers often fall into the trap of tracking some feedback on Post-its, lodging others in their brains’ feedback depository and spreading the rest between different scraps of paper and Google docs. You’ll hate yourself when it comes to crunch time and you need to make decisions.
One of the best ways to consistently track all of the qualitative feedback is to create a spreadsheet before ever adding a beta customer. Remain disciplined about adding EVERYTHING in here, even duplications of feedback or questions about the beta.
You can then codify your feedback to make it as useful as possible. Below is an example of how to codify beta feedback:
Column 3 – Summary. This is my concise version of their feedback
Column 4 – Reason. The issue, cause or problem actually being expressed
Once you’ve gathered a significant amount of data, this method of storing feedback will help you easily communicate the patterns and findings to anyone who is interested.
When it comes to dealing with feedback, there are some core principles to keep in mind:
Always chase for the why
The majority of feature requests should be considered and acted on post release, unless there is a worrying trend and the problem you set out to face wasn’t actually the most important problem
Look out for patterns of the same question – either the UI or logic is confusing, or this will help inform what info product education docs should provide
Step 7: Is your feature ready to ship?
Your success metrics and qualitative feedback will ultimately dictate what and when you should release. However, setting a timeline for when you will make that all-important call is great as a forcing function for actions. This can vary depending on the complexity of what you are betaing and the certainty of the solution, so there’s no rule of thumb here.
Set yourself a timeline as a forcing function.
When we launched the new Respond Reports from beta, there was a mountain of feedback. In an ideal world, it would have been great to bundle these into what we launched. However, this would have delayed replacing an existing report with a better reporting feature for the 95% of customers not in the beta. So it made sense to release what we had and benchmark the other requests and feedback for iteration and improvement in the near future.
Before making your final decision, you should step back and ask yourself some questions:
Do you feel confident that you have solved the problem enough to warrant releasing your feature? Use measures of success and a general sense of qualitative feedback to guide you.
Is it replacing something that exists already? If it’s better than what is currently available to everyone, you should probably ship it as soon as possible.
Does your marketing team want to announce at a particular time or in a particular way?
As with most processes, how you run your betas will evolve with your business. At Intercom, we’re always learning and iterating with each additional feature.
Change aversion is a concept well known to designers and product managers. It’s the negative reaction users have to changes in your product, whether that’s functional changes such as updates to product features, or interface changes such as visual redesigns.
History is littered with cautionary tales of introducing change. When Twitter changed its “faves” icon from stars to hearts, users threatened a mass exodus. Similarly, the same pitchforks are raised every time Facebook tweaks its design, with users threatening to delete their accounts unless the site reverts to its original design. (It never does, and people quickly forget.)
On the surface of it, the evidence looks clear: users hate change – even when it improves their experience with the product. How does anyone ever introduce anything new then? A recent visual redesign of our Inbox shows us that change aversion is actually a lot more complex than this.
Every change starts because of a problem
Why do a redesign at all? As the heart and soul of managing conversations, Inbox is a busy place where many hands need to work collaboratively to collectively resolve customer issues. As an essential tool in many of our customers’ work days, being able to work efficiently within it is something we actively think about and optimize for.
Our goal was to help our customers feel in control.
When we learned that our customers were sometimes struggling to quickly address incoming conversations in different inboxes due to inefficient workflows, we decided to restructure our product to make it easier to monitor inboxes and switch between them. Our goal was to help our customers feel in control as a team handling large volumes of conversations at scale.
We had also shipped a number of features in the previous months and needed a different UI architecture to support those changes. As a product and design team, we’re always striving to improve, so we also wanted this opportunity to clarify Inbox’s navigation and refresh its look to be more modern and in line with our flagship Messenger.
What we ended up shipping
A picture is worth a thousand words, so let’s just cut to the big reveal – the before and after shot of our inbox:
As you can see, the difference between the old and new inbox is night and day. But at Intercom we ship to learn, and like most everything we release, this giant leap was taken with many small steps.
Because so much of the inbox interface was changing, from the main navigation to having circular avatars to the behavior of our message composer, we ran nine parallel betas to ship, test and tweak every single change both together and in isolation.
Going back to the key workflow problem we were trying to solve, the most important change for us to test was moving the top navigation to the left. Having a vertical list of inboxes would scale well and give our customers one-click access to monitor and drill into incoming streams of conversations they’re responsible for.
We found customers on our beta reacted positively to this change and preferred the new way of displaying inboxes on the left, because it was faster for them to monitor conversation volume between multiple inboxes and navigate between them. Managers were able to see which individuals or teams were busy to help prioritize workstreams. They also felt the product was more streamlined and usable as a result. Given this feedback, we felt excited and validated about our left navigation approach, and started thinking about how we would roll it out.
While this testing went on, we were simultaneously iterating on the visual design direction. Because we hadn’t changed the look of Intercom in several years and were on the cusp of a broader brand refresh, we decided that introducing a clean, minimal and softer new visual language would give us a blank state from which to build on later.
At this point we asked ourselves: should we consolidate everyone on all the different beta tests into a single beta with the dark grey left navigation (since we got a positive steer on it) and then tweak the colors afterward? Or should we move everyone on the different betas directly to our final proposal with the light grey left navigation?
Since our customers work in Inbox for long periods of time, we were conscious that any big change could really disrupt or frustrate customers. And so, we decided to be safe and find a new group of customers to beta test the final proposal with the light grey left navigation.
We shipped the new changes to 70 customers on the original Inbox to gather their feedback. Here’s the change they saw:
As we were most curious about the new color changes in our proposal, we carefully monitored conversations for feedback in this area. But to our surprise, most customers were not bothered by the colors, and instead mostly reacted positively to the navigational change.
Armed with this feedback, we wanted to reduce the number of different betas we had so they’d be easier for us to maintain and accurately reflected the decisions we had made. So we moved 80 customers from the dark grey left navigation to the light grey version. Here’s the change they saw:
Which unfortunately garnered some of these reactions…
Why the drastic reactions?
From the very beginning of this project, we knew we needed to roll these changes out carefully, listen to customer feedback to understand what is actually causing problems, and adjust. We took these comments to heart and immediately started analyzing why this seemed to suddenly become such a huge problem and adjusting our designs to better suit our customers’ needs.
We suspect that customers on the dark grey beta were already used to seeing the navigational change with more contrast between the left nav and the rest of the page. So when they moved to the light grey beta, they only focused on the new brighter colors. And for customers who went straight onto the light grey beta, there were many changes at play, so the colors were no longer the focus point of the feedback.
It became clear to us that the feedback we got was not just due to what we shipped (which was the same in both cases), but largely influenced by the experiences our customers were used to. The original design had anchored their perception, which resulted in a mixed bag of extreme reactions.
What we learned
Change is never easy. From our journey redesigning Inbox, we realized that while users may not automatically hate change, it’s also impossible to predict how exactly users will react and how visceral their reactions might be.
So the next time you plan a similar redesign, remember:
Understand where your users are coming from: what their habits are, and what their most recent beta experience was. This will be your best approximation for how they might react to your change.
Always remind yourself and your team of the problem you’re solving. Do this often. Otherwise, it’s easy to get bogged down in tiny layout details without seeing the full picture or broader impact of your work.
Everyone has an opinion on the design – from your team to your customers to your watercooler buddy. These opinions might be polarizing, but it’s up to you to decide which ones to act on to ensure a successful redesign. It can be helpful to use the DACI model to make sure there’s the right level of involvement from various stakeholders.
Oh yeah, and color is hard
A month ago, we rolled out a new look for our brand and tweaked our color palette and fonts, among other things. So as a final step in rolling out the new Inbox, we updated our visual style with the product once more to more closely align with our new brand.
We hope you enjoy responding to your customers more efficiently in Inbox and feel more on top of your work. As always, please let us know how you find the changes!
In a time where buyer behavior has rendered cold calling nearly obsolete, successful sales prospecting begins with using tools like live chat and social media to build relationships.
Dan Swift, CEO of Empire Selling, has built his career around the latter. Back in 2012 Dan joined LinkedIn as a senior sales leader charged with launching its social selling business – training LinkedIn’s own global sales organization in the process. He’d go on to become the VP of Sales at Sprinklr, guiding the company through its own high growth period, before striking out on his own. Today with Empire Selling he’s helping B2B companies drive revenue and deepen customer relationships through digital and social selling training.
I hosted Dan on our podcast to break down the challenges and rewards of sales at high growth companies, the do’s and don’ts of social selling techniques, how salespeople can use content to play the role of trusted advisor, and more. If you enjoy the conversation, check out more episodes of our podcast. You can subscribe to it on iTunes or grab the RSS feed in your player of choice.
What follows is a lightly edited transcript of our chat.
Adam: Dan, welcome to Inside Intercom. Can you give us a quick rundown of your career to date and the types of companies you’re now working with at Empire Selling?
Dan: I’ve been in enterprise sales now for 18 years. The last 12 of those have been in leadership positions. My first real job was at GE Capital in Australia, and then I moved back to London and joined a company called Complinet, which was a back office compliance software company. It was ultimately acquired by Thomson Reuters, so a 200-person company got swallowed up by a 45,000-person company.
Fortunately LinkedIn found me 18 months later. At LinkedIn, I launched the social selling business and brought LinkedIn Sales Navigator to market. After about two and a half years there I joined Sprinklr, a social media management technology company, and was there for three years as a divisional vice president. January 1, 2018 I officially started my role as CEO of my own company, Empire Selling.
We’re essentially helping B2B companies drive revenue and deepen customer relationships through digital and social selling training. We do live workshops and a ton of speaking engagements. Right now we’re working with some Fortune 50 companies, all B2B, down to much smaller startups here in New York City. The only exception is some B2C work with financial services and insurance companies.
Adam: How was your experience of getting your own startup off the ground while being a leader in a high growth company? Is there anything that you’d recommend for someone going through something similar?
Dan: The best advice I’ve got is to be completely transparent with what it is that you’re doing. When I joined Sprinklr, I made it very clear to the leadership team that I had this business, it was very much a side hustle, and I’d be doing it evenings and weekends. That transparency came upfront, and the leadership team basically said, “Anything you do externally, any teaching, any learnings you get, bring them back in-house. Make sure the Sprinklr sales organization benefits from it.” In that way, both parties win.
In terms of trying to figure out the viability of a business while still working, use the time when you’re gainfully employed and getting an income to test content or the technology. Make sure you’ve got that viable program or platform. Do your research on the total addressable market and the market readiness for whatever you’re doing. Have that income coming in to pay the bills before you go do this, and definitely try to get some clients that are going to be with you for the medium term when you get started.
Scaling sales in periods of high growth
Adam: Looking back at your time at LinkedIn and Sprinklr, both companies were going through extreme periods of growth during your tenure.What’s it like riding that trajectory, particularly as someone in sales? Obviously there are a lot of challenges that come from that. What sticks out?
Dan: Definitely some advantages as well, as you suspect. You tend to have something unique or something that’s very much in demand, so the advantages should be obvious. You tend to be able to sell slightly more easily, and it definitely helps in a sales position when you’re working for a well-recognized brand like a LinkedIn.
But the challenges, there’s a lot of them. You tend to get pretty large quotas, because the leadership team believes that the market opportunity is there and they’ve made certain commitments to the board. You have to sell a lot more of it to get there and make the same kind of money maybe that you’d make at another organization.
It’s not as easy as some might think. For example, when I was at LinkedIn we launched a brand new product. LinkedIn was known at the time for talent and marketing solutions, and we had to educate and challenge our prospects with what we were bringing to market, which was LinkedIn Sales Navigator. People didn’t think of LinkedIn as a sales tool. In fact, the team that I was responsible for was selling into the highly regulated financial services and insurance market. Obviously, social media is not at the forefront of everyone’s minds in those sectors, and certainly not when it comes to selling. There’s definitely challenges there.
With fast-growth companies also comes a mixture of cultures. Some cultures are super supportive in these kind of environments, very entrepreneurial and incredibly compassionate – at least the real fast-moving, forward thinking-ones. Others are not as good from a cultural perspective, a little toxic. It really does depend on the leadership team.
Adam: That example of financial institutions is really interesting, because it’s such a large, traditional industry that’s used to doing things in the same way for a long period of time. How do you begin to approach that problem of trying to get them to switch from some sort of existing solution that they understand really well to something more digital, like a social solution?
Dan: Sure. We actually brought in The Challenger Sale to help us do that, because you’re essentially challenging the status quo. You’re challenging a way that the industry has worked for decades. Also, you’re helping them get to a place where they realize for themselves that they actually have a challenge or a problem, or they could be operating way more effectively. In this example, the way we challenged was teaching them that there was a lot of stuff going on on LinkedIn in terms of members engaging with other members, particularly high net worth individuals. Then we’d get them to think about this as potentially just another channel they could be operating on to win those high net worth individuals.
Adam: One thing that is always a challenge as you scale is keeping your processes aligned. Whether it be from LinkedIn or Sprinklr, what’s one particular moment where you really had to change how you and your teams worked? How did you solve that?
Dan: When they’re growing incredibly quickly, oftentimes the company will outgrow the infrastructure. I think a couple of things jump to mind. The first one is communication. You have to communicate clearly. You have to have a common language around whatever it is that you’re doing, and a specific operating framework. For sales, we brought in a couple of different methodologies. We used Force Management, a growth play company, which allowed us to have that common language so we could really expedite one-on-one meetings, team meetings, and the way that we communicated around deals.
The other part of it is culture. You’ve got to have the right culture, because you are going to outgrow your infrastructure, and when things do start creaking it’s the people around you that you’re going to lean on. That’s why culture’s so important. Essentially, you’re going to battle every day, and you want to have those people around you to support you. When systems start creaking, they’re the ones who are going to look out for you.
Hiring and holding onto talent
Adam: You can’t really talk about scaling culture without talking about hiring. When you were hiring in these positions, what were the hard and soft skills that you looked for most?
Dan: A lot of people think it’s critical to bring in that individual with the 20 years of software sales experience, but oftentimes that individual might not necessarily be comfortable in the new market. Conversely, you might have incredibly talented individuals with less sales experience but incredible domain experience.
You need a little bit of both. The people with 20 years of enterprise sales experience can really help the people nearer to sales take a more strategic approach with account management and that sort of stuff, but then the people who have that domain experience – in my world that’s social media – can help the people coming into the space. When I’m building my teams, I always have a little bit of something from each different area. Diversity is so important to make sure you have the right mix and the right collaboration.
In today’s world, people jump around a lot, which makes it difficult to see if someone has capabilities in sales.
Then, specifically on hard skills, I’m looking for people who’ve got a proven capability in sales, a proven track record. To prove it in sales, you’ve really got to be somewhere longer than two and a half years or so. In today’s world, people do jump around a lot, which makes it difficult to see if someone has capabilities in sales. That’s when the interview process becomes critical. Then soft skills, coachability. You’ve got to be able to pivot. You’ve got to be able to take feedback so you can move forward 10X. Coachability is huge.
Adam: On the flip side, in a time when competition is so high for talent, how do you sell your company to candidates to make sure that they were aware that this is the right opportunity for them?
Dan: First of all, it’s me understanding what they want to do, and what they think they’re capable of, to make sure it is the right fit before I try and sell them on anything. I want to make sure that they understand they’re coming on a journey with the company and with me as their leader and make sure they’re the kind of person you want to hang out with for eight hours a day, five days a week at least. I think that’s pretty important.
I’m known for being a compassionate leader. I show a ton of vulnerability because everyone should do that to be able to learn and get better and help the people around you feel comfortable asking questions. So that in conjunction with a good hiring process, normally gets you off to a pretty fast start.
Yes, there is a great war for good talent, but I think there’s a stronger thing happening where a lot of companies do not have a particularly strong middle management layer, particularly in sales. Everyone knows the biggest reason people leave a company is their boss. If we can solve that across the sales industry and help sales leaders become more effective and more compassionate, but more up to date on things like social selling and new ways of approaching a traditional sales industry, then I think you might see less movement around SaaS companies.
Adam: Is part of that taking more time to carve out different types of career paths rather than standard management tracks?
Dan: It’s definitely that, but it’s also taking the time to slow down and understand what it is the individual is looking to try and get from the experience. When you actually do that and you get to know the individual as a human being, that individual working for you not only will go 10X what they probably would’ve done otherwise, but you build a very special relationship. You get to do some very special things together at incredibly fast-paced companies. It sounds obvious but so many leaders don’t do that.
The foundations of social selling
Adam: A major area of emphasis and success in your career has been social selling. Can you just define social selling for us? How is that different from something like social media marketing?
Dan: Over at LinkedIn, social selling was all about leveraging your social network to find prospects, build trusted relationships and ultimately achieve your sales goals. I think all of that is fine, but I think there’s a misconception around social selling, that ultimately a social seller is just going to sit on social media and not leverage other channels like the phone or email or, increasingly, video. That’s not the case.
Social media marketing is leveraging social media one to many. It’s a company trying to hit up a ton of consumers to pass on a message. Whereas social selling is one to one. It’s identifying an executive, a middle manager, a practitioner, whoever it might be, and leveraging social media, and maybe relationship data, to find a warm path into that individual rather than cold calling. Or, perhaps it’s leveraging some social insight about that person as a human being to reach out warmly and get a meeting.
I always want to align to how buyers want to be engaged, and a lot of the research says they want to be engaged on social media.
Adam: Zooming out a little bit, how has software sales changed to the point where this channel has risen in importance?
Dan: It’s less about what’s changing SaaS and more about what’s changing for buyers. There’s a lot of research out there that cold calling is becoming less effective. The latest report, I think it was from the Harvard Business Review, says it’s not going to work 97% of the time. It does work 3% of the time. Now, as a salesperson, I always want to align to how buyers want to be engaged, and a lot of the research says they want to be engaged on social media. It’s more about how we want to serve our customers and how we want to engage with people than it is about any changes in SaaS.
Adam: As an example, let’s look at the “ungettable” call or meeting. How might you use social selling to start building that relationship?
Dan: Imagine you’ve got an executive who we know is an economic buyer, he or she’s got the money to buy whatever it is that you’re selling. There’s three parts of social selling that I evangelize. The first one is your network. You have to build and nurture your network. Build it, connecting with every single person with whom you have a meaningful business interaction every single day. Because the bigger and better your network, and if you nurture that network with content, chances are you’re going to be able to get yourself a warm introduction from someone in your network who trusts you because of the content you’re sharing.
Now, the second part of it is, once you’re with the executive or even in your outreach through someone, that executive’s going to care about things like white papers to educate them. Contrast that to a practitioner, who might just want some tactical guidance around how his or her day could be better. It’s making sure that we use the right content in our outreach.
Then, finally, if you’ve done enough and that warm introduction has worked, that executive is going to look at your LinkedIn profile to see who you are, because it’s natural human curiosity. If that person looks at your LinkedIn profile and sees a traditional resume and sales-y approach to LinkedIn, mentioning things like performance against quota and all that sort of stuff, it’s a bit of a turnoff to a buyer and definitely an executive. But, if your profile talks about how you’ve got this rich history of helping executives and buyers like him achieve his goals, then that’s a very different emotional experience. The conversion tends to be way higher if you take that approach. Network, content and profile are the three big pillars that can be needle moving.
The worst thing is that they just blast out corporate content over and over and over again.
The 50/25/25 content mix
Adam: I imagine that mix of content you share is crucial, because I certainly can’t see this being effective if all you’re sharing is corporate piece of content after corporate piece of content. You’ve got to position yourself as a human being too, right?
Dan: Absolutely. I have a 50/25/25 rule. Before I explain too much of what it is, I’ll explain the worst thing that people can do on social media. The worst thing is that they just blast out corporate content over and over and over again – information promoting the company that they work for morning, lunchtime, afternoon, evening, five days a week, sometimes seven days a week. All you’re doing there is positioning yourself as a salesperson to your network. You want to position yourself as a trusted advisor, so it’s critical to share content, but you’ve got to get this blend right.
50% can be what I’ve just described, all that corporate content. That’s okay. It’s a channel. You want to educate. 25% should be around what I call industry content. That’s not anything produced by your company, but information that you source that can be helpful to your target buyers about the industry they’re in, so they can become better professionals, more productive and successful. Then, the final 25% should be nothing to do with any of that. The final 25% has to humanize you on social. For me, it’s coaching, it’s helping people be the best they can possibly be, and anything that I find, I read or I’m sent that I think will benefit people in my network, I share. That’s the last 25%. You need balance as a person on social.
Adam: Sales in many ways all about measurement. Social selling is a much more longer term play, so how do you measure its success?
Dan: It’s actually a little easier to measure than perhaps people think. There’s a lot of talk in the market that you can’t measure the effectiveness of social media. I think that’s just not accurate. Here’s a couple of things that you can think about doing. The first thing is the number of warm introductions you get on LinkedIn to your prospects. That could be measured on a weekly basis. Then there’s the number of meetings with each prospect type: economic buyers, champions, influencers and maybe coaches. Measure the number of people you’re getting in each of those because then you can see where your outreach is working and where it’s not and be able to tweak.
If a buyer looked at their profile right now, what kind of experience would that buyer have?
Next, look at the opportunities that were started with content that you shared on LinkedIn, Maybe someone liked that content, took the conversation offline and that started a new opportunity. That can be measured. When I was at LinkedIn and Sprinklr, we actually used Salesforce for that. All we did was link all the opportunities back to whatever generated it. We could see at the end of every quarter how much revenue had been influenced by social.
Adam: Obviously, LinkedIn is the most natural outlet for this type of material but do you need synergy between your Twitter presence and your Facebook presence as well? How does that fit into the picture?
Dan: Yeah, definitely. The more you get into this, Twitter becomes an interesting channel too. You definitely have to have consistency across all the social channels, and that’s the way that you present yourself, and also the photos that you pick and the tactical way you describe who you are, which is super important. I use Twitter less as a communication tool and more as a research tool. There’s a ton of great stuff that companies are putting on Twitter, but also the individuals that you’re trying to sell to are putting things out on Twitter about themselves. It gives you great insight and a great opportunity to leverage that insight to bridge an introduction.
Adam: When it comes to social selling, what’s something that our listeners could do in the short term to start driving results?
Dan: First of all, they should think about how they’re positioning themselves on LinkedIn. If a buyer looked at their profile right now, what kind of experience would that buyer have? Would it be a bit of a turnoff because you’re just a little egotistical and talking about yourself and promoting yourself, because you’re trying to appeal to recruiters? Or, are they having a much more trusted advisor kind of interaction where they look at your profile and say, “That’s amazing. I’ve got to talk to this person.” That’s the first thing.
Another real quick win is connecting with every single person in your organization. Now, that’s easier if you’re working for a 200- or 300-person company, obviously. If you’re at a much larger one, perhaps you connect with everyone in your division. But it’s amazing who knows who and LinkedIn, obviously, opens so many doors through warm introductions.
The high potential of video content in sales
Adam: Empire Selling covers a lot more technique than just social selling. As someone that’s been in this space for as long as you, what other emerging sales channels are you really excited about?
Dan: The thing I’m most excited about, particularly for this year, is video. It’s going to be fascinating to see how video develops. There’s amazing companies out there who are doing it really well. I don’t know yet how executives are going to feel when people like me reach out to them with video. I’m not sure yet whether that’s going to be the right vehicle, but I think it is going to be powerful for middle management prospects and practitioner prospects for salespeople to use video.
Adam: What about that application really sticks out to you? What are the companies who use video well doing that’s so interesting?
Dan: A lot of it is the back end that a company’s going to be able to see, the data in terms of how are sellers using it? How are they performing? What sort of messages are landing when someone opens the video? How long is the person watching the video? Do they sit on the video all the way through to the end? Do they share it with people? You start getting a lot of good insight, and you can start tweaking your messaging accordingly. I think it’s just a bit of that, but it’s ease of use as well. Salespeople, for the most part, want to have tools that are going to be incredibly intuitive, and just quick and easy, right? Video does it really well.
Adam: Dan, thank you so much for sharing part of your day with us. Before we go, where can our listeners go to learn more about Empire Selling and generally keep up with your latest insights?
Dan: You can go to empireselling.com. You can find us and follow us on LinkedIn,
These days it seems like everyone wants their service to become the next big platform – every budding entrepreneur begins their pitch by stating their aspiration to become the next Uber, Airbnb or Facebook of their field.
But what do we know about building technological platforms? People know a platform when they see one, but in some important respects, we actually know very little about how they develop. They have not been around long enough to study in great detail and dissect their constituent parts in order to understand their anatomy. Instead, we need to find another specimen which shares some of the DNA of the species platformicus. We may have just such a genetic cousin in a “technology” that has been around for several thousand years and is continuing to evolve and grow – the city.
How the city relates to platforms
At first glance a city might seem very different from a technological platform. Cities are jungles of concrete and steel; they are towering, glittering examples of humanity’s imposition on the natural world. Cities allow us to defy nature, to live and grow in population sizes that would have been unsustainable in earlier periods of human history. It is not an exaggeration to say that they are one of the most important innovations in human history.
Cities are really transformative for the way they enable one thing: connections between people.
However, cities are not ultimately defined by the steel and the concrete, or the road networks or the infrastructure. They are not simply ways to stack human beings in increasingly compact spaces. Cities are really transformative for the way they enable one thing: connections between people. And that one thing is what binds cities and platforms together in their genetic similarity.
Maximize network connections
When a city’s infrastructure and environment facilitates increasing interactions between people, then there are more connections and, as a result, more ideas, more patents, more GDP per head, more jobs and more productivity. Theoretical physicist Geoffrey West, a leader in urban theory and the scientific modelling of cities, noted in his book Scale that “the job of a city is to facilitate and enhance [the continual exchange of information, goods and money between people] by providing the appropriate infrastructure . . . to encourage and increase social connectivity”.
Similarly, platforms create value by facilitating connections between consumers with producers, and indeed, in cases such as Airbnb and Uber, by allowing consumers to become producers. Everything about a platform is focused on making it easier to create value through increased connectivity. Dartmouth professor Geoffrey Parker and his fellow authors in their book Platform Revolution describe platforms as places where “rather than flowing in a straight line from producers to consumers, value may be created, changed, exchanged and consumed in a variety of ways and places, all made possible by the connections that the platform facilitates”.
The number of connections between a group increases much faster the total number of people in the group itself.
Why are connections so important? They are important because of the way they scale. Warning, here comes some math, but its pretty basic, I promise. If there are two people then there is 1 connections between them (2 x (2-1))/2. That is, if you are in the group you can only connect with the group size minus one (you can’t connect with yourself). And we divide by two since you can’t count the connection between you and person A twice. See, told you it was easy.
With this formula you can see that each time the number of people in the group doubles, the number of connections roughly increases fourfold. Thus, the number of connections between a group increases much faster the total number of people in the group itself. That is why cities and platforms are so similar, they are entities that create value in proportion to their ability to maximize connections. In other words, cities are a technology that maximize connections. From our perspective, urbanization offers plenty of lessons that are applicable to the growth of technological platforms.
Lesson One: Platforms, like cities, can’t be entirely planned
We noted that cities are more than just their roads and buildings. Instead, cities are complex adaptive systems that evolve and change over time like an organism. Like any complex entity that changes over time, it is difficult to fully predict its outcome or plan its evolution. We can see evidence of this in the recent attempts at creating massive planned cities to cope with the growing trend of urbanisation. West in his book Scale points out that “most urban development and renewal – and in particular almost all newly created planned cities such as Washington, D.C., Canberra, Brasilia and Islamabad – has not been very successful”.
Urban planning failed when it tried to plan for the highways and buildings and not the people that used them.
Trying to plan a city is difficult since you don’t know which small change might impede the city’s ability to maximize connectivity. The urban writer Jane Jacobs believed that urban planning failed when it tried to plan for the highways and buildings and not the people that used them, “project planners and urban designers assume they can create a promenade simply by mapping one in where they want it, then having it built. But a promenade needs its promenaders”.
Platforms are similar in this sense. You are trying to encourage, foster and grow connections. But it is difficult to fully understand the myriad ways in which people will want to connect and what will make that successful. Why do you use Facebook and not MySpace? Why was WhatsApp successful when there were other similar messaging platforms? Why did Slack conquer the workplace messaging field in the face of so many competitors?
The one thing many of these platforms have in common is that they adapted to their communities. They listened to their users and they tried to use their metrics to understand what worked and what didn’t. The key thing from cities is not that trying to create a city is impossible but that it will take time and you need to ensure you listen to the “promenaders”. This is why planned cities such as Washington D.C., to take just one example, have evolved into more “successful” cities over time. They took note and improved public transport and implemented bike schemes, for instance. Platforms, like cities, need to leave room to evolve and change to the needs of their “promenaders”.
Lesson Two: Platforms, like cities, develop their own gravity
We know that the world is urbanising at a faster rate than ever before. Well over half of the world’s populations currently live in cities and this percentage is expected to rise to over 66% by 2050. The number of cities continues to increase. But the interesting thing is that this does not seem to have occured in the classic bell curve that usually explains everything from exam scores to height distribution. Instead cities seem to be distributed by a “fat tail” distribution. This means that there are more outliers than under a normal distribution which have more in the middle and less at both ends of the spectrum.
These cities develop gravity fields similar to a large planet and pull all resources, people and companies into their orbit.
A UN development report in 2014 noted that there were 28 megacities with over 10 million people whereas in 1990 there were only 10. One reason for this increase is that cities have an inherent drive to get bigger. Like an organism with an innate desire to survive and expand, cities are driven by an urge to grow ever larger. One of the reasons is that the larger a city becomes, the more efficient it is. If a city doubles in size it needs only 85% more petrol stations, 85% more roads and 85% more general infrastructure. That’s a saving of 15% every doubling in size. And as it grows (remember our maths) the number of connections starts to increase exponentially.
As these cities grow larger they become globally connected entities that resemble nation state more than other cities. Think New York, London, Tokyo or San Francisco for example. These cities develop gravity fields similar to a large planet and pull all resources, people and companies into their orbit. The result is a growing inequality between these global megacities and their smaller domestic cousins. As a recent New York Times essay pointed out, smaller cities cannot compete with these behemoths and either stop growing or go into decline.
We can easily imagine a similar fate for platforms. It would be difficult to have multiple Facebooks, Airbnbs or Ubers. The whole point of these platforms is that they have one market or meeting place. If there were lots of Airbnb’s it would be more difficult for both consumers and producers to know how to create value. Similarly with social networks. In a particular area a certain platform will develop its own gravity that will start pulling in resources around it. This will make it more difficult to have multiple platforms within its orbit.
Lesson Three: Platforms, like cities, are about people
We often look for patterns in order to replicate the success we see elsewhere. Companies do the same, copying strategies and policies to engender the same growth or profit. And cities follow this same trend. Planners see cities growing and are blinded by the steel and the concrete and believe this to be the primary manifestation of a city. The more buildings, the more roads, the more infrastructure the more successful the city.
However, this is to miss the point. These physical entities are merely in the service of the people that inhabit that city and not the other ways around. As West notes, “the real essence of a city is its people…this may seem obvious, but the emphasis of those who think about cities, such as planners, architects, economists, politicians, and policy makers, is primarily focused on their physicality rather than on the people who inhabit them and how they interact with one another”.
Unfortunately, like city planners, internet businesses often believe that the goal is efficiency.
If we learn anything from urban theorists such as Jane Jacobs, it is that the goal of a city is to provide the infrastructure to facilitate social interaction, to enhance a feeling of community. In a sense, to make the city feel more personal.
This idea, of a city being about its people, is something that resonates with what we are trying to do at Intercom. The goal of Intercom is to make internet business personal, to make the experience of being on a website feel more like the interaction you would have in your local coffee shop. To realize that goal, we are actively encouraging and fostering connections with other technologies and companies.
Unfortunately, like city planners, internet businesses often believe that the goal is efficiency. It is much more efficient to get your customers to fill in a form rather than to chat to someone. In the same way it is much more efficient to dig up a park and build more offices and apartments.
Jacobs saw the folly of this when she opposed the creation of a four lane highway through Greenwich Village in New York. It was a more efficient design for moving people, certainly, but it destroyed the whole purpose of the city which is to encourage the personal experience of communal meeting places and parks and pedestrian streets. Sure, we need buildings and transportation but if we remove all the places where we can have human and personal interactions, then what is left but cold concrete and steel?
Build platforms like cities
The science of cities continues to show us the secret patterns behind one of our most important inventions. We can learn many lessons from cities, but the most important is that they are, like platforms, about enabling connectivity between people. Everything else – the ideas, the value, the business opportunities and the growth – is created as a result of that connectivity.
There are so many variables involved that you cannot always plan for the growth or the value. You need to focus on the people, your community, and ensure that there is a balance between the personal and physical which enhances connectivity. If you do that, your platform, like your city, will have the best chance of success.
One of the first things that struck me when I started working at Intercom was the culture of transparency and how every team is constantly striving for improvement.
One of Intercom’s core values is that we’re serious about wanting to be the very best. One of the things we can do to implement this value is to be open and honest with each other about our strengths and weaknesses, with a willingness to learn and always keeping in mind that we can do better next time.
The definition of insanity is doing the same thing over and over again, but expecting different results.
That’s why you’ll find us actively seeking feedback on our work every day. Intercomrades are generous with their time and ideas in a genuine effort to help others improve. We share feedback with each other all the time, not just for bi-annual or annual reviews. We want to keep getting better and our feedback loop is a really important part of this.
At the same time, we move fast at Intercom. We’re always focused on the next goal so it can sometimes happen that we don’t take enough time to reflect on the things we’ve done really well and what we haven’t done so well. Retrospectives (retros) are a tool we use to reflect on how we’ve worked together and how we can improve for the future.
There are a few different types of retros at Intercom at different levels of teams and they form an integral part of team planning. Those retros happen weekly within the Product teams and Brand Design and Product Design also hold their own retros.
What I’m focussing on here are project-specific retros. These happen when we have large cross-functional projects involving multiple teams and often multiple office locations in various time zones.
As we grow our company, we’re constantly evolving our processes. Actually, we’re not big on heavy processes at Intercom but we do put frameworks in place to help guide us and we’re always iterating on them. What worked for us three months ago might not work for us now or in the future. Added to that mix are teams located in different time zones and on different continents, so there’s always going to be scope for improvement.
Building software is never a perfect process and that’s okay. Without retros it would be hard to take learnings from what hasn’t gone so well and to figure out ways to work better together next time around. As the saying goes, the definition of insanity is doing the same thing over and over again, but expecting different results. That’s where retros come in.
Running your project retro
The aim of any retro is to learn. You want everyone in the room to feel that they can voice their honest opinions and experiences from the project and by the end of it all, everyone will have an increased insight into what worked, what didn’t work and how things can be done differently next time.
At Intercom, these are some steps we take to ensure we get the most out of our retros.
1. Get the right people in the room
Anyone who worked on the project should be in the room – designers, engineers, product managers. Make sure each function is represented. There’s no point running a retro with only half the voices you need in the room. I always gather a list of key people who I know definitely need to be present and reach out to them to see if there are other people on their teams they’d like to attend as well.
2. Ask for input before you begin
I use FunRetro to gather input in advance and usually ask for three types of input – things that made us Glad, Sad and Mad. This allows you to use the time in the meeting to actually discuss the issues at hand, not for gathering feedback. It also gives everyone visibility into how others are thinking and allows the group to focus on the most important areas. The time when everyone is gathered in the room is both extremely valuable and extremely expensive, you want to get the most out of it.
3. Stick to the point
Lots of things happen in the course of a project and they’re not all related to how teams or groups work together. In other companies, I have seen retros deviate away from what actually happened during the project to more general work-related issues that weren’t specific to the project. This is bad and something I’m very conscious of now in my current role. So as the facilitator, you need to steer things back on topic if you see this happening. The time at the retro is to discuss what happened during the project, how the group worked and how the group can work better together in future.
4. It is a democracy
Everyone’s opinion should be heard in the retro. One thing I have found to be useful is asking people to vote on the issues they want to talk about. Start with the issue that received the most votes and try to discuss at least three more items. If 25 minutes go by and you’re still discussing the first item, try to steer the discussion towards an action or solution and move on.
5. Be open and honest
It’s vital that everyone in attendance at a retro feels that it is a safe space and is comfortable sharing their viewpoints. Everyone should strive to be open and honest but never accusatory. Remember that you’re all in the room because you care about a common goal. You’re all on the same team.
6. Actions and owners
Have an action to take away and an owner for each item discussed. This is a good way to draw a line under an item and it focuses the group on problem solving instead of complaining. Of course, a little bit of complaining is to be expected and that’s fine – just not for the whole retro.
7. Get consensus
Get consensus from the group on actions. If everyone doesn’t agree, I generally go with the the majority. You should always make sure everyone knows that if the action or solution doesn’t work out, it can be reviewed again and changed in the future.
8. Keep to the time limit
Everyone is busy. In my experience, you should try to start wrapping up five minutes before the allotted time is over. I’m not a believer in retros that take half a day, I do mine in an hour. I find it’s hard to keep focus once it goes over the hour and it’s a huge chunk of time to take out of anyone’s day.
After the retro
When the retro is over, I always share the outcomes and lessons learned by email with the rest of Intercom R&D. The mail clearly states who was at the retro, what we discussed and what the action items were. I also include a link to all of the items that were contributed but weren’t discussed.
Sharing the outcomes widely gives everyone visibility.
In my experience a group will often focus on more negative things in the retro because that’s where the opportunities for learnings are. That’s totally fine but it’s important to remember that lots of good things also happen during a project and they should be acknowledged at this point too. Where things haven’t succeeded, it’s important that we learn why so we can change our process for the next time.
Sharing the retro outcomes widely gives everyone visibility into the issues encountered and what has been taken from that. At Intercom, we embed the lessons we’ve learned into our frameworks wherever we can. After all, it’s pointless if you forget about what was learned as soon as you walk out of the retro.
In Sales, timing is everything. You can have the world’s most talented sales team and the greatest product but still lose to a competitor.
A recent HBR study analyzed 1.25 millions sales leads, and found you’re seven times more likely to win a deal if you respond to prospects in less than an hour versus responding in two hours.
The fastest way to respond to a prospect is through live chat on your site. Contact forms still have their place, but there’s a delay between when someone fills out a “request a demo” form to when an SDR follows up. This follow-up process can last days or weeks as SDRs battle to catch the prospect live or get an email response.
Live chat allows you to circumvent this process. But, many companies either fail to make the most of their messenger, or simply use it inefficiently. At Intercom, we’re always experimenting with new ways to deliver a better user experience through live chat and have learned a couple of lessons from more than 20,000 customers using our chat solutions. Here are three simple, tested, but often overlooked live chat time-savers we’ve uncovered:
1. Be selective
Do you email every single lead in your database when you fire off a nurture campaign? Then why would you make live chat available to every lead that visits your site? Doing so can prove to be very costly. Your SDRs should be focused on diagnosing the needs of qualified prospects and providing them with a personalized experience, not having conversations with every person that comes to your site.
Thankfully, it’s now easy to offer live chat only to prospects who match your ideal customer profile. By leveraging tools like Clearbit, you can choose the subset of leads who will see a messenger on your site. Maybe you only sell to B2B SaaS companies under 200 employees. With a couple of clicks you can pick the criteria that makes sense for your business.
Being selective about who you chat with will ensure your SDR team is making real progress towards their goals. It’s also a sustainable way to drive live chat adoption across your sales organization. Your reps will be more motivated to use live chat when they see its ability to deliver a constant flow of high-quality leads.
2. Balance bots with a human touch
Over-automation has tarnished the reputation of Sales and Marketing. We’ve all encountered pesky Robo-Dialers and spammy automated emails. Live chat is the newest frontier, but some marketers are adapting the same ineffective tactics used in the email and phone era to this medium. No one likes to feel like a number. And, nothing annoys prospects more than having a prolonged conversation with a chatbot when they thought they were going to talk to a person.
Modern sales and marketing requires the right balance
of automation and human connection.
Modern sales and marketing requires the right balance of automation and human connection. Our most successful customers use our bot, Operator, to automate the collection of contact information (email, company name and company size), while allowing their SDRs to build valuable relationships with prospects.
Making live chat conversations personal is the most efficient way to making each interaction as human as possible. Prior to having your SDRs jump on live conversations, spend some time determining how you will route chats to individuals or team inboxes. For example, let’s say you service customers in multiple countries and employ multilingual sales professionals. In that case, try routing conversations to your reps based on your visitor’s browser language.
3. Set proper expectations
We’ve been conditioned to expect instant responses when we talk to people on messaging platforms. Whether it’s Slack or iMessage, people tend to grow impatient as they intensely monitor the three animated dots, waiting for a response.
Here are some steps you can take to set proper expectations with your prospects in live chat:
Use a bot to communicate average response times when your reps aren’t available.
Hide the messenger outside of your regular office hours.
By conveying this rudimentary information automatically, your SDRs can more quickly diagnose a lead’s needs or pain points. They can also afford to be more thoughtful in setting your lead’s expectations regarding next steps (i.e. discovery call with an Account Executive) if you automate low-value tasks — using an automated meeting scheduler is a prime example of this.
I’ve heard people attribute success in sales to the three T’s: Talent, Territory and Timing. But it seems people often assume we have little control over timing. That couldn’t be further from the truth. You can gain control over timing by deploying the right live chat solution. By being selective with whom you chat with, you ensure your reps are laser-focused on providing an outstanding user experience to your best leads. By making the live chat experience human and setting the right expectations with your visitors, you drastically decrease the time it takes to convert them to qualified leads.
In sales, timing is everything. And live chat enables you to turn “timing” into a big advantage for your team.
Want more tips for using live chat to capture and convert website traffic? Check out these other live chat resources: