Building Products @Socialbakers

At Socialbakers, we were one of the first to build enterprise solutions for the previously non-existent field of social marketing. We started back in 2008 with social media solutions but we’ve evolved rapidly, hand-in-hand with the industry. My role is to oversee development of the Socialbakers platform, so I have the privilege of cooperating with all of our awesome teams, but also being able to shape the future of Socialbakers, and to have a deep and positive impact on our clients’ marketing strategies.

I’m often asked “What does Socialbakers actually do?” Engineers, developers, scrum masters, product managers — they all want to know. And I can talk for hours on this subject. That’s why I’m going to write a definitive answer to that question here and now so that I have something to share with people who ask — because I believe that WHAT we’re building and HOW we’re building it is pretty incredible. Another goal is to impart to you our amazing culture, so if you like what you read, get in touch with me or simply sign up for an interview straightaway.

So What Is It That Socialbakers Does?

We’re building a constantly evolving SaaS platform that helps enterprises around the world make their digital marketing smart. If you’re a marketer, you know what a huge, and hugely appreciated, job that is.

Even the best products need advertising, and customers (yes, you!) quickly got used to instant communication with brands over social media. From groceries to cars, the number of people shopping online rises each year as does the number of communication channels, platforms and technologies — all increasing at a rapid pace.

Imagine you’re a marketing manager for an automotive company and you want to launch a campaign for a new car that will “be a hit”. To do that, you need to ask yourself some questions. Here are a few:

• Who is your target audience for this campaign?
• Which content will be the most relevant and bring you the most conversions?
• Which channels are the best ones to use? What will be the optimal channel budget split?
• When’s the best time to post content to each channel?
• Which content to promote? (pay to increase reach, so that more people can see it)
• Should you use influencers to promote the product? If so, which ones?
• What are the key metrics to measure?
• How will you track conversions to sales/sign ups/leads?
• Will you utilize email marketing to prospects/past customers?
• What kind of past email content converted well for each customer segment?

You get it. It’s not just 1 + 1 = 2. There are many considerations. To make it even more complex you’re usually collaborating with multiple teams, and across multiple locations if your company is multinational. Your work probably involves approvals, campaign briefs, analysis of results and the constant pressure to optimize and increase efficiency. It’s like juggling 20 balls while standing on a running machine — the ground is moving very fast under your feet and the challenges you face change daily in step with the industry.

That’s why at Socialbakers, we take such pride in building a unified digital marketing platform that helps solve all these problems — the problems of 3000+ enterprise customers around the world. We currently employ more than 400 people but to support further growth and help our customers as fully as we can…

Anyway …

How are the product/DEV teams structured?

Rome wasn’t built in a day and neither was our Socialbakers platform. The structure of the company has changed dramatically over the first ten years of our existence as we’ve grown…but let’s talk about the current situation — we’ll start with the the product.

Product

The first thing, obviously, is to make sure we’re building the “right” product. Product has its own seat in Socialbakers leadership and is engineering-independent. I have the privilege of running this amazing ten-strong team (product managers and product owners).

The rate of our development means we decided to split product roles into PM and PO to enable easy scaling while remaining focused. Some people excel at client communication and market research while others prefer to build the product in collaboration with developers. We all have one common goal, though: to deliver the best possible value to our customers in the shortest possible time using agile methods. In other words, we don’t try to build spaceships when a scooter would do the job perfectly. And we also try to deliver “Minimal Valuable Product” as fast as we can to test the original hypothesis and solve customer’s problem.

Product Managers work on early prototypes with our design team. They also come up with ideas, measure platform usage (Mixpanel, Google analytics, Fullstory), have regular calls with customers, undertake market research and customer validation. This is to ensure we have a strong understanding of market potential and feasibility of every feature idea. Once the feature is launched, PMs are also responsible for release notes, feature beta process, and for educating our product marketing team in how to communicate the feature benefits to other internal teams, customers, and to prepare in-product marketing campaigns.

Product Owners, on the other hand, collaborate mainly with development teams. It’s their responsibility to make sure the development teams have all user stories prepared several sprints ahead so there’s enough time for feature grooming and that all priorities are clear. POs are the magicians, beside the development and design teams, that plan and solve any possible edge case that may occur (e.g. What should a user see when they don’t have permissions? Why does this search yield zero results?)

Even though development teams participate on feature prep. from the beginning (together with Platform Architects) the user stories created for them by POs usually contain the final design, marketing copy, usage measurement specs (Mixpanel events) and everything else they need to groom the feature. If more is needed, they discuss with other teams (facilitated by the Scrum Master of that particular dev. team).

We use SCRUM methodology and two-week long sprints. Given our B2B model, we don’t release features to production until the minimal-viable-product (MVP) is prepared. The readiness (value) of the features is always evaluated from the point of view of our enterprise clients. This usually takes between four to six sprints (two to three months) — enough time to add more platform value, prepare automated tests, educational content, feature measurement and everything else the client needs to start using the feature from day one. Thanks to the number of product development teams we have available, our customers can enjoy new valuable features every two weeks as the releases tend to spread throughout the whole year quite nicely.

The concept of our sprints and feature releases obviously has high impact on how our development teams work to set and communicate deadlines across the company. The product team communicates the feature release date based on prior agreement with the developers. As we approach release date, estimations become more precise. In the ideation phase we speak of deadlines approximately (H1, Q3, etc) but soon harden to a particular day (e.g. 15/10/2019)

There are many things that need to happen before a new feature is launched to production and this work is divided between product, development, product marketing, marketing, sales and support teams. That’s a lot of teams! The release process even has a name: “Ready to sell/ready to deliver” or in short, RTS/RTD.

It can be complex, so we hold weekly sync meetings with all relevant parties about the release of important features. Deliverables include:

• Feature value proposition and positioning for sales colleagues
• Update of product training
• Targeted marketing campaign (both in-product and external) to promote the launch
• Feature toggles in the product to ensure only specific packages include the feature
• Updates of website/packaging/pricing
• Release notes/PR announcements where applicable
• Training for support/education/presales/sales teams
• SalesForce adjustments (new fields/reports)
• In-product feature landing pages with value explanation
• Integration of the product with Mixpanel to measure usage
• Integration of the product with Salesforce to capture customer’s interest/intent
• Update of support documentation
• Public webinars

That’s enough for the first article, don’t you think? Next, we’ll discuss details of how our engineering and development works. If you have any comments or questions, use the comment section below or contact me directly via email or on your preferred social channel.

Let me know, in the comment section below, what’s the structure of your product team and how does it differ to ours.

And don’t forget we’re hiring! I guarantee that building a fantastic product is even more fun than reading about it.