Adobe Brand Visibility is a GEO software that helps companies improve their AI visibility, citations, and share of voice. You can preview the new product here.
Connect with Meryll on LinkedIn.
Congratulations to user patti_jane, who won a Stellar Question badge for asking Setting PATH environment variable in macOS permanently.
TRANSCRIPT
[intro music]
Ryan Donovan: Hello, everyone, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I am your host, Ryan Donovan, and today we are talking about a merger acquisition that happened in the news lately, Adobe bought SEMrush. But instead of doing the normal, you know, big engineering task to integrate everything, they decided to have an internal hackathon. And we'll be talking about that with Meryll Blanchet, who is the Director of Engineering for Adobe Brand Visibility. So welcome to the show, Meryll.
Meryll Blanchet: Thank you so much, Ryan, for having me. A real pleasure and nice to be here and talk in front of your audience.
RD: Glad to have you. So before we get into the hackathon portion, let's get to know you. Tell us a little bit about how you got into software and technology.
MB: Teenager, got a computer at home, started playing with it. Very interested in understanding host software, working actually, spent time debugging and trying to patch existing software before daring building my own, built a few video games as usual, learned several languages on my own, went through regular computer science, and started in the industry 20 years ago. I started on the field actually working very closely to customers because I wanted to become an architect and therefore I thought I need to know as many use cases and situations as possible. I ended up then within Adobe Engineering and had the privilege to launch a few products over the last years, latest being Adobe Brand Visibility, for which we'll talk today.
RD: My experience of previous roles of doing a big acquisition, there is a lot of stuff to integrate, right? I remember we wrote blog posts just about the sort of user data integration and how difficult that was. So tell me a little bit about why for at least part of it, you decided to approach this with an internal hackathon.
MB: We had a very concrete goal, which was, and it's still the case, we want to build the best geo product in the industry with other big brand visibility. And when you have two teams like this, which have significant experience, but coming from different perspectives and need to know each other and to be very effective together. As every good engineer knows, there is no better event than the hackathon to bring the people together and start dealing with the real problems, right? So this is with this mindset that we came into the hackathon with the goal also to achieve something by the end of that week, which was quite short, actually. It was only three days. And not only get to know each other, but actually work together on concrete problems again.
RD: With the hackathon, was anything off limits? Was there like, we are definitely moving database type A to database type B, that sort of thing?
MB: I do not know how much you know about what we had done on the Adobe side prior to the acquisition to the hackathon and what SEMrush did. But we have actually two products prior to the acquisition on SEMrush side, SEMrush AIO Enterprise, which is a brand visibility product really focusing and strong on the data, on the LLM visibility data for big brands. And on our side,
we had built and launched with my team, Adobe LLM Optimizer, last October. And we approached it quite differently because we come from the enterprise CMS world with Adobe Experience Manager. So we approached it from the content and from the own signals perspective for a brand, like CDN logs, on-site telemetry, etc. As a result, we have two products which are complementary. They are not competing in terms of functionalities. Before talking about complex infrastructure integrations, which take, to your point, longer time, right? It's something that you cannot trust like this because there are many implications. Rather looking at: what value do we want to unlock out of these two great products for the enterprises that are going to use the product underneath? And again, on one hand, how do we combine the signals that SEMrush provides to their customers with the on-site signals that we got through CDN logs for the websites that are hosted on our CMS, for example, but also analytics data that we get through Adobe Analytics or Customer Journey Analytics? And how do we then leverage these signals into actionability for marketeers to potentially create content or react to some off-site visibility opportunities. You probably know that, for example, social media like Reddit or YouTube are likely to be cited by specific LLMs. So the focus was really on the customer value. First, and what features do we want to extract within the version that we GA this week? Secondly, we had also a very specific goal, because you can come in and hackathon like this, and okay, let's explore, let's see what's working or not, and then we will eventually roadmap and plan. At the end of the week, the goal was clear. Our customer zero, adobe.com, which is already actually using both products, is on Adobe brand visibility and is able to use it.
RD: Wow, that is a big goal for a week of a hackathon, right? So at the beginning of the week, what was the barriers? Did you identify barriers beforehand or was that part of the hackathon too?
MB: We had post-acquisition and before Hackathon a couple of weeks to actually connect and get to know each other, either from the product perspective but also from the engineering practices perspective. We have seen a lot of similarities in how we approach, first of all, customer centricity, how we are aiming to validate product features against data and making sure that the data is relevant for the end users or for customers, how we are actually operating as engineering teams. But to your point, yes, you're still coming with different setups. And we have been mitigating those setups during the week. For example, a typical one, okay, where does the code go, right? You have two sets of repositories. And of course, in some cases, code needs to go on one side, in the others, in the other. Since we were building customer-facing capabilities, we decided to reuse the existing LLM optimizer UI shell and infrastructure for the customer-facing features. Because it's already generally available to Adobe customers under the Adobe requirements. So it simplified everything. And it was easy for us to onboard also SEMrush engineers to those repositories and make them part of our CICD. And that's a good example. Then in terms of other challenges, what I'm thinking of, two others. One is around integration patterns, of course. You have data on one hand, you have UI surface on the others, and you have a variety of possibilities to integrate with pros and cons on the short term, on the long term. I think one key to be successful in this kind of exercise is to not close the door to any option because you may regret it. You may rush for the immediate success, and actually you may regret down the road that the solution doesn't scale, doesn't surface, external customer use cases because we focus too much on customer zero, et cetera. So here we make plans, we look at options, we keep optionality. What's the best approach? Is it micro front-end? Is it API? Is it anything else like infrastructure level, data migration, et cetera? And we plan for it. What's the best for the short-term and actually with minimal risk for our customers and our users? And where do we want to go long-term in terms of product vision and unified stack for AI visibility? Finally, the third one, it's a different set of integration concerns that companies doing this kind of exercise may face. It's about data model. So on one hand, you may have taken decisions to store and to define data in one way, and on the other, some completely different paths, both for very good reasons, but ultimately, same thing. How does it fit together? Do we have means to make these models fit together? And how do we want them to evolve as a unified model on the long run? To give you an example, a quick example, SEMrush coming from the SEO perspective is defining everything around domains, right? Like a brand domain, like adobe.com. On our side, since we had the opportunity to start from fresh, with LLM Optimizer, we iterated on this domain, and we thought, ultimately, we would like to rather define everything around a brand, which can be surfaced across multiple domains, whether it is owned, earned, social, accounts, et cetera, but that all deserve to be monitored for the sake of finding opportunities to improve the visibility of the brand on these domains. And so we made, actually, the two work together, preserving both approaches, but also making sure that in Adobe brand visibility, it all falls back into the brand-centric model.
RD: Right. That is a good point that there is any integration. There are, I think, like you said, the three big culture operational, there's tech stack and data model. I want to sort of start with the culture operational, if there are any sort of frictions, because like you acquire a company, you acquire the team too, and you acquire their ways of working, whatever their ticketing process is or CICD, right? Their norms. Were there any sort of like, hard difficulties in getting the SEMrush team to work with Adobe?
MB: To be fair, I can say only the opposite. During the hackathon, the very first PR, which was
actually leading to enabling the first feature for Adobe.com, was sent by a SEMrush engineer in one of the Adobe repositories. Got reviewed, approved, and published. So this is a fantastic success story. I remember at the end of the hackathon when we have the demo session, of course, and the recap, Vitaliy Obishenko with the chief product officer of SEMrush and I, we were co-organizing. We called out this person very strongly as the reference. Look, guys, first PR on the first day sent by a SEMrush engineer into the Adobe repositories. That was fantastic.
RD: Nice. For the tech stack. Is it one of those that's easy if it's like all broken into microservices that you could just change pathways, put APIs, or is there a larger chunk that's harder to manage?
MB: The way SEMrush built the product, it is very data-centric, as you can imagine. So, of course, people who go into the enterprise product have profiles like enterprise SEO analysts or geo-analysts. They like to go through dashboards to slice and dice the data, etc. But what they like also is extract the data and extract it to store it in different systems, internal systems, very often for the sake of reporting here and there, maybe to the C-level decision-makers level, maybe to share further for further application building inside the company, etc. So they have an API-first approach by default, right? Everything that you see in the product is actually reachable from an API, which made it quite trivial to integrate from this standpoint because we were doing nothing else than using most of the APIs that are already available to third-party developers, with the exception of one, which is internal, that we use, because looking at the scale of data we need to exchange between the products, it was actually more ready for this kind of integration. So we have access also to SEMrush technical API in that sense. On the main challenges, of course, identity is a topic. We have our own enterprise identity management within Adobe. And you have to expect that when SEMrush comes in, they have also their own enterprise management. So we had one dedicated work stream for putting SEMrush on Adobe Enterprise in the sense of identity management. Of course, to get started with this product integration as a driving use case, imagine that the effort is much larger. But we brought not only engineers from my team and from the SEMrush AIO or SEO teams, we also brought engineers from the Adobe Unified Platform team, which are taking care of many internal two-picks, identity being one of them, to unlock the situation as fast as possible. Another key two-pick is brand. So all the products on the Adobe side have the same look and feel. They look and feel like Adobe. This is a styling system that we call Spectrum. It's fully open source. It's available on the internet for people who are interested into looking into it. Of course, SEMrush has its own identity as well. So here, there is also a work that is ongoing and to accommodate the micro-frontends we are integrating into the Adobe look and feel. And as of today, we have already external customers that are benefiting from this integration in a product that looks generally like Adobe while integrating pieces of SEMrush UI.
RD: I imagine, like you pointed out, Adobe is already a company that has a large suite of differentiated products with a sort of central operating feel. And I'm sure there's technology overlap too, right? So that must have been an easier approach for you guys to just integrate something new.
MB: The challenges I mentioned are somewhat no-brainer. I mean, I'm sure you would have anticipated them and then people listening to us may recognize themselves into some integration patterns. But also one thing that makes it easy again is because we have a clear separation of concerns between the SEMrush part and the part on which we really rely the WLLM optimizer infrastructure, which is more in regards with actionability. So once you have the signals, how do you use these signals to identify opportunities to improve the brand visibility, how do you suggest changes, whether these changes will be on site, which you can actually even auto-optimize, right? Versus what will be changes that need to go through briefs for a larger digital marketing team, including teams such as PR or social community management, et cetera, for real intermediate work where human still needs to be in the middle. And by the way, even for optimizations, man remains in the middle because we still want humans to review content before publishing it. We have this part of the stack and SEMrush have the part of the data science and the large data stack, which makes it very easy to integrate together.
RD: So this was a fairly directed hackathon, right? It wasn't like, here's your fantasy wishlist stuff. When you started, what was the, you know, besides the SEMrush guys getting the PR first, what were the sort of surprising things you found?
MB: At the end of the hackathon or even during the hackathon, because we had like five work streams in total. And I was rotating across the work streams. You had the feeling that the engineers had worked together for much longer. And this is one of the key sentences that came out also from our feedback, whether this was Vitaly on SEMrush side, on the Adobe side, we had the feeling we have been working longer than one week together. I don't know by which magic, if you want, but the mindset was very positive. The instructions, the goals were clear. There were a lot of overhead taken away from the engineers in the sense of, okay, this is what we want to achieve. You have the customer zero, and it's up to you to make it happen. We had also side events, of course, like in every good hackathon. So we had various zinners. We also had the chance for SEMrush people. I think this is very important to present to us what they have been doing so far. Imagine you're getting acquired by a company like Adobe. Of course, you have a lot of things to discover within Adobe. But we want to know also, what did you guys do? And please explain to us how it's working. And this was, to me, one of the best parts of the hackathon as well, to see that they were super happy to present us, to explain us, and spending all the time required to tell us, okay, this is how this part of the product is working. This is the science behind, et cetera, et cetera. So these are the main call-outs I want to say about bringing the people together. As of today, because we are almost two months after the hackathon now, people still work in the same dynamic, but remotely. And we are planning a follow-up hackathon for NetNew2Pix by the end of August. And this time it will be in the SEMRUS office, right?
RD: That SEMRUS presentation, were there things that they presented there that you realized you had to sort of change your approach or change some ways you worked at the Adobe brand visibility side?
MB: So first of all, what we realized from the presentation, but also from the product is, of course, the big expertise of the team into the Tupic. It's not only being thought leaders, it's having accumulated years of expertise in data, understanding data, and presenting data in the right manner, etc. So it was quite obvious that actually this is an operation. And yes, this is an additional strength into the product. At the same time, we also see that the SEMrush team are very interested into what can we do with this data? And by the way, how can we augment the data with the data that you guys have in return? Which led into subsequent streams that are post-GEA two-peaks on which both teams are already working together, really combining the data together in order to identify new insights and deliver new powerful features in the product.
RD: In the hackathon, we had this specific goal. Were there things that came out of that development, that hackathon, that you didn't expect?
MB: There was one feature that we really wanted to have, and it came earlier than what we would have expected. The main initial problem for a brand when it comes to brand visibility is to understand what's my current brand visibility, right? And for that, you need to be able to identify the two picks and the prompts which may actually be relevant for your brand. And SEMrush is coming with a fantastic collection of prompts and topics that help practitioners to do so. It's still a very tedious task if you're not a seasoned geoanalyst to go through this data, to analyze it, and to say, okay, these are actually the opportunities for me to keep measuring my visibility and take action upon that. And what we always wanted to achieve was what some people in my team are doing. I have, as part of my engineering team, a team of domain experts. These domain experts are not regular engineers. They are very seasoned SEO or GEO experts. This was actually an idea we had that having done so much progress with AI development, we could also add people who bring net new value to the engineering team and net new knowledge. And as we work a lot with customers directly to get them through the product, understand their problems and improve the product in return, one of the tasks that was delivered all the time was setting up the right prompting strategy for a brand in a market. Imagine, we have now the data, we have now our first-party data, and we have the domain expertise knowledge. And the result of this is we have been able to build quite fast, and it's part of the GA features, prompt strategy agent on top of that, which is analyzing a variety of signals from market signals to on-site signals, and delivers recommendations about which are the prompts to track for a brand and why. So it's accelerating the work that the customer would have to spend in the product even further by telling them, look, these are the hot topics. And this is actually what you need to track if you want to optimize your visibility further.
RD: My experience with the internal hackathon is there's always deep wish list stuff that is just not feasible for whatever roadmap, right?
MB: Yes, totally. I've been doing a lot of hackathons in the past. And yes, you tend to load the boat until the boat cannot anymore. So we were really focusing on the strict minimum here. The main pillars, one of them was integrating the AI visibility capabilities from SEMrush into the product done and delivered to Adobe.com. The second one was, actually, do we have capacity on top to start working on this prompting strategy that I was mentioning before? Second to pick. The third one was prompt tracking of the customers once they have selected their prompting strategy. And then the fourth one was dedicated, as I said before, to the SEMrush on Adobe Infrastructure and Adobe Requirements Workstream. We have brought PMs, product managers, and product marketing managers as well, and they had their dedicated workstream. The goal of this workstream was exactly align on key topics, key maps of interest that we want to keep working on after the hackathon, validating, of course, with early access customers and customer zero before productizing fully, and also everything related to the GA, GA planning and so on. So we were really focusing on the important part, arguing this is not the right time to look at what's happening in one year from now, arguing that it's not the right time to bring complexity. And yes, we want to do more, but actually these two peaks need to be broken down into multiple months of work and validation with customers, really focusing on the immediate actionable content and then planning for the rest of time.
RD: The way you sort of talk about the hackathon, it almost sounds like very specific sprint with a directed goal, but kind of like a free-for-all contribution process, right?
MB: It was really a set of high-level two-peaks where we know the impact will be maximum for both having SEMrush closer to Adobe infrastructure and second, maximizing the impact as per Adobe Brand Visibility GA. We keep this kind of more long-running two-peak for after and for subsequent hackathons, of course, because engineer creativity is still what is, to my eyes, very dear in how a software can evolve and how a software can get better. We do that. But again, it's a matter of being focused at one time versus being more creative after.
RD: Right. And there's always that conflict between the sort of long-term roadmap and getting the work done that needs to get done with enabling that creativity.
MB: Yes. And we have a challenge, an additional challenge in this space. It's a very fast-moving space, the brand visibility in the AI search nowadays. If you look at industry level, we have more than a hand of LLMs which share the market, right? And I don't even speak about market-specific LLMs like we may have in Europe or in Asia, but we're really focusing on the main ones which are distributed worldwide. Each of them shares similarities but differences. Each of them is competing with the other. And we have also to be very reactive about what's happening. Does it impact anything we have in the product, but also does it impact anything we want it to do? And do we have to change plans? And one key for that, of course, we need to be at the frontier. We need to keep observing what's happening and making hypotheses. But really one crucial point here is that from the ground, from the time we built LLM Optimizer last year, we have been doing this in partnership with internal customers, but also external customers who had early access. There is nothing that goes in the product where we cannot say this feature has moved a needle towards a specific metric. And because of the high speeds at which this industry is moving, we must also allow ourselves to remove a feature to deprecate something anytime if it's not valuable anymore. So it's a very, very challenging space in which we operate here.
RD: Not only does the market move fast, but coding agents let the engineers move fast too. Is there part of this sort of like hackathon mentality that you think you can bring to the sort of everyday engineering life?
MB: First of all, being goal-oriented is always good to me. Even to our earlier point in the discussion, engineer creativity is good. But if you are not able to bind this creativity to some outcome, of course, outcome for customers is the best, but it could be also outcome for your team, for the team velocity, for solving an internal challenge, etc. I think you're wasting time nowadays because everyone who is a bit entrepreneur with AI can actually solve problems much easier than before. And people who are actually not necessarily traditional engineers, of course, they don't have everything required to productize and to end a solution, right? But they can bring innovative ideas because they know this is a business problem that the company may have, and this is the approach to solve it. So that's one key element. I think it's important for engineers to be entrepreneurs, to feel empathy for the customers. In my case, we speak about large enterprises with professional users, right? But it's the same if you build a B2C product in the end. If you don't have empathy for the end user, if you don't understand what problem they want to solve using your product, then I don't think you can make a good product out of that. And again, validating as early as possible, getting feedback, whether it's good or constructive, and iterate upon the feedback, understanding how this is going to move, again, a needle on specific metric, for example, or solve a specific problem. I think this is key to being successful in an hackathon or when building a product on the long run.
RD: Yeah. And in terms of building that empathy, how much dogfooding does your team do? Is everybody an SEO expert out there?
MB: Before I started hiring SEO NGO and actually paid media experts in my team, we have been feeling the pain ourselves. We have been working with our Adobe Experience Manager customers, so customers on our enterprise CMS, because we wanted them to realize beyond having their content served by AEM, having actually value out of it. And when you build a website, the value you can get is various. You can get more traffic acquisition, right? And this goes through SEO normally. You can get better engagement because the page loads faster than before. And eventually leading even to better conversions, whatever the conversion is. We've been working for one year and a half as engineers with customers. And I have to tell you, we did not know much about SEO beyond the SEO principles that I think everyone in the web may be aware of. We've been working closely with customers, moving their websites to the latest and greatest version of our CMS, and then understanding what is required to actually see this traffic trend increasing with successes, but also failures and learnings. And this is how we started. And then with AI development increasing and growing so fast, it became logical to have crossed the bridge and to say, let's bring the knowledge and let's actually have these people working with us in a new way of building software. Not so long ago, you had maybe backend and frontend engineers, right? And then you had full stackers. I believe today you may have people who are more like into the harness and people into the AI orchestration, bringing very specific knowledge on how to actually tell these models what to do. And you will end up having also these kind of new full stackers who can do both. But I think it's an interesting mix and it appears to be successful.
RD: I think I've seen some folks talk about the full stack domain is kind of growing to increase to like product and user understanding. So that's interesting.
MB: I think it's not specific to SEO, GEO, paid media or whatsoever. It's just a domain, right? You could have the same for engineers working in a completely different vertical, whether this would be, for example, digital assets management, commerce specific, performance marketing, etc.
RD: So for the upcoming August hackathon, are you going to have another sort of goal to direct or are you going to take the leash off and let the dogs run?
MB: The goal is, we know where we want to go with the product. Again, there are two aspects. There is the aspect of where the industry is going, what are the nouns right now, and we know we have to be there. And then what are the noun and nouns on which we want to double down? Because if we manage to learn about them and to make them happen, then we will have additional value for the customers who go on the product. This is clear. At the same time, I think these two picks are broad enough so that engineers can tell us what to do. It's not like we have, by the end of the week, to deliver this ABC feature set. It's more like a big chunk of capabilities where we will know that we have to follow up a plan after in the following weeks to productize fully.
[music]
RD: Thank you all for listening. It's that time of the show where we shout out somebody who came onto Stack Overflow, dropped some knowledge, shared some curiosity, earned themselves a badge. Today, we're shouting out a stellar question badge. Somebody came on and asked a question that was so good it was saved by 100 users. So congrats to Patty Jane for asking, setting path environment valuable in macOS permanently? I'm sure that's a popular question to ask. I am Ryan Donovan. I am the host of the podcast, editor of the blog here at Stack Overflow. If you want to reach out to me with questions, comments, topics, et cetera. Email me at podcast@stackoverflow.com. And if you want to contact me directly, you can find me on LinkedIn.
MB: Thank you so much for having me, Ryan. It was a big pleasure. Similarly, if you want to reach out to me, you can find me on LinkedIn. And if you want to have a preview of the product with GA, go to https.play.bv.now. Thank you for having me.
RD: Our pleasure. Thank you for listening, everyone. And we'll talk to you next time.
[outro music]