The Grouparoo Blog
When I was in charge of Product/Engineering at TaskRabbit, it was always challenging to prioritize integrations being requested by our Marketing, Sales, and Customer Success teams.
First and foremost, most engineers just hate working on these kinds of integrations. Often, this preference alone is the deciding factor in organizations for what gets prioritized or not. The work that gets prioritized and done is the work that energizes people, and no engineer was excited to brainstorm how we could most effectively sync data to Marketo.
What engineers want to work on is the core product. That is why they joined the company and critically, they know how to be successful there. The requirements for the Intercom integration are much fuzzier. It is hard to know what success looks like. This ambiguity prevents the momentum often necessary to get the work started, much less to the finish line.
The engineering team had ambitious goals: there were features to build, bugs to fix, metrics to move. When combined with other factors, the integrations were at the bottom of the list despite the outsized opportunity to impact the business.
One practice we had at TaskRabbit was periodically shadowing coworkers on other teams. It is enlightening and helps build the empathy that makes the business much stronger. If you have ever done this, particularly with a customer success representative, you will know what I am talking about when I say that it is very difficult to watch.
The primary job is working tickets in a tool like Zendesk. As an engineer, the problems themselves made me sad because they were often bugs or fundamental misunderstandings on how the product worked. However, I had much more anxiety over the process of solving the ticket itself. Specifically, the data to help close those tickets is everywhere. Each ticket leads to opening multiple tabs just to get the right context and opening a few more to solve the problem.
When this data inefficiency is multiplied for all the customers and all the tickets and all the coworkers, it is a huge waste of time that negatively affects everyone: the customer, the coworker, the business.
The key concept of integrations is leverage.
A data integration makes it possible to route the tickets better and surface key data right there in Zendesk. I've seen this change result in a 10x efficiency increase which has a huge impact on customer and coworker satisfaction, leading to a much stronger business.
The leverage here is tremendous because of the volume of tickets, scale across the business, and how painful and manual processes were to begin with.
In Product organizations, we think in product terms. What can we build that will attract more users? What feature will make them stay around longer? However, it often turns out that's the wrong solution space altogether.
After the minimum viable product stage, the difference in many businesses is channels.
Let's agree that if nobody knows about the product, it doesn't matter what features you have. The solve for that isn't always a better landing page. It might be a Facebook ads integration to allow the Marketing team to create lookalike audiences.
If someone has signed up or used the product, what's going to bring them back? Not your social proof on the funnel. And probably not the generic newsletter each month. The most effective tool here is personalized communication about their needs where they are in the journey, accomplished by syncing their data to tools like Mailchimp and leveraging that to be more relevant.
B2B cases are all about timing. How can you reach the right people at the right time with the right message? It's not going to be a feature and it's not going to be blindly emailing all of your accounts. Instead, if Salesforce knows about your accounts' recent activity in the product, you can use that data to trigger the right communication to better qualified leads.
Even with these strong business cases, integrations were always still hard to prioritize because of the unfamiliarity for the engineers. Eventually, they had to happen for the company to scale. At that company and the 100 more I've spoken with, this integration work was always done later than it should have been.
The cause of this delay is the lack of a common language between engineers and operational teams. When looking to solve this organizational problem, we set out to fill this gap with Grouparoo. By defining patterns through an open source framework, both sides can engage on consistent footing. This approach makes data enablement easier and adds confidence, the core challenges for the engineers.
I don't have any illusions about how exciting we can make data sync. It's unlikely product engineers will wake up in the morning thinking about Marketo's rate limits. My bar is pretty low.
I just want to make it possible for an engineer to respond with "Oh yeah, what do they need?" instead of "No, thanks." to an integration ask.
This response is a signal that integration work is on an equal footing with other feature developemtn. At that point, everyone starts to realize the leverage and power of these integrations. They are low-hanging fruit that make a huge difference. Then, they get done, the tools get smarter, everyone has a better experience, and the whole business wins.
Tagged in Engineering Product
See all of Brian Leonard's posts.
Brian is the CEO and co-founder of Grouparoo, an open source data framework that easily connects your data to business tools. Brian is a leader and technologist who enjoys hanging out with his family, traveling, learning new things, and building software that makes people's lives easier.
Learn more about Brian @ https://www.linkedin.com/in/brianl429