Eric Picard is former Chief Product Officer at BARK, an online pet supply company and the parent company of BarkBox. He has over 20 years of experience building product teams and has been a part of 14 acquisitions. Eric has founded four startups and, aside from his most recent role at BARK, has worked in leadership at Microsoft, TRAFFIQ, MediaMath, and Pandora.
In our conversation, Eric shares his experience being on both sides of acquisitions, as well as how storytelling is crucial in getting everyone on board and aligned. He also discusses his learnings from Microsoft — specifically scenario-based planning — and how it establishes value across the organization.
I wrote an article recently about what product management is, and it all comes down to a spectrum of work. It doesn’t quite matter who does the work or how it gets divided up — at the end of the day, it all has to get done.
At a small company, the products that you’re managing tend to be more nascent. There aren’t as many features, but a lot of work is still involved to build the right product well and maintain it over time. As a PM, you’re likely responsible for everything, including knowing which features customers are using, how they’re moving through the product, etc. Heat maps and path analysis are a great way to do this, but a PM only has so much time, especially at a small organization. It requires you to be brutal about prioritizing.
At a large company, work is easier to distill because there are distinct roles that fill all the requirements across the spectrum. There might be 300 people collaborating on one feature or release that’s about to go out the door, and tons of people responsible for the go-to-market, product strategy, writing specifications, and building. There are a lot of moving parts, and you might have four or five different engineering teams all working on that one feature with the different components. That whole spectrum is a very challenging thing to manage.
For example, I used to work on the Microsoft Bing mobile team, and a lot of the things that we were building were local. And when you’re building a local product, you have to go to the market at a very narrow level. If that product has any kind of social features, you have to be down in the weeds within the market, geographically, to win it. How large of a market opportunity is it? A lot of that work needs to be market-driven, and at big companies, these roles are very specific and defined.
I call this the parable of the rocks. When you’re a super product manager in those early days, you have tons of responsibilities. Every one of those features that you’re maintaining or piece of work that you’re doing feels like a rock. It’s heavy, but you put it in your backpack. You’ve got all these rocks that you’re constantly lugging. And as time goes on, your backpack gets heavier and heavier. At a certain point, you’re getting weighed down. It’s too heavy.
This is often the natural time to turn to the sales or marketing team and ask for help with go-to-market work. It’s usually the first point of getting additional resources to help alleviate this weight. However, this is tricky, because it can lead to sales or marketing owning product marketing completely. Instead of giving the product team an additional resource that’s dedicated to that part of the work, suddenly, product marketing becomes a different discipline if you’re not careful.
At an existing company, a lot of market research revolves around talking to current customers and finding the problems they need solved related to what we’re doing. It’s equally important to also talk to people who were customers and left. Why did they leave? Were you not satisfying their needs? Did they just switch to a competitor?
On the product strategy planning side, all of this work is necessary to understand the “why.” What are you building, what area of the market are you going to compete in, and how will you be positioned within it? You might have market requirements that come out of that.
A great market requirement doesn’t have any implementation details — it just states a business problem that needs to be solved. When you move past the market requirement, you’re starting to deal with scenarios, product requirements, and, eventually, specifications. That’s technical product management at its finest. Figuring out what you’re going to build based on what you’ve heard from the market is its own set of skills and it’s an art.
You’ve got to go through the work of defining what that product is going to be. When I was at Bing, I was exposed to the idea of scenario-based planning. A scenario is a group of features that create a complete offering for a customer. It might not be the entire product, but it’s at least a set of features that are related and required to have that whole comprehensive product and fulfill the customer’s needs.
At that point, I fell in love with scenario-based planning, and, to varying degrees of success, implemented that on many of my teams. It’s hard when you’re down in the weeds — especially as a junior product manager — to give in to the requirement of writing a scenario or telling a more complex story. But when you do it, your partners are happier. The sales team understands the comprehensive offering that you’re building — it’s a set of features that are all interlinked and add value.
Apple had what I felt was the best scenario-based advertising that I’d ever seen when they launched the iPhone. They did such a great job of telling the story of what they were building. The ad I’m thinking about was someone walking down the street listening to music on their iPod. All of a sudden, the phone rings. They pull an iPod out of their pocket, look at it, and answer the phone. The music stops playing when they answer, they talk, and then when they hang up, the music resumes.
Well, that’s a whole scenario. What are all the requirements you’d need to pull off that set of features as a scenario? That’s the beauty of scenario-based planning. Especially in consumer-facing products, I believe this model is the best way to approach it.
In a typical, strong engineering-driven culture, there’s a complex build-by-partner analysis. It sounds easy, but it’s actually a very difficult thing to execute well. The first thing to figure out is how much it would cost you to build a specific product offering yourself. How many engineers will it take and approximately how long will you need? What’s the market opportunity? Are you going to miss the business opportunity since other companies are out there now getting market share? You have to make that analysis decision.
Once that’s done and you realize that acquiring another company is your best option, you have to identify your targets. There’s a lot of nuance involved in going through that initial set of decisions around which companies you might want to buy and which will be a good fit, both in terms of offerings and culture.
Then, when you approach these companies, some of them will be strongly against it. When I worked at Microsoft, a lot of companies thought that us acquiring them would be terrible, so they said no. There’s a lot of complexity in that conversation. This is why storytelling is so important in product management — you’ve got to convince these people to join your company and partner with you instead of compete.
It’s very tricky. I’ll talk about a specific example when we were looking to buy a friend of mine’s company when I was at Microsoft. We were having dinner as the deal was getting very close to closing. I said, “I am so glad that we were able to pull this off, but I’m curious — why do you want to sell your company to Microsoft?” He said, “Oh my gosh, the distribution that we’re going to get out of this deal will be amazing. We’re going to be able to sell our products to every company in the world.”
I was confused and said, “Dude, this is an exit. They call it an exit for a reason. The things that you are trying to achieve with your startup are no longer. We had a reason for considering buying you — we’re not going to take your existing product and start distributing it elsewhere.”
Then, for internal reasons that weren’t related to him at all, the deal didn’t happen. It fell apart right at the last minute. When that happened, everyone was disappointed, and I remember telling him how sorry I was that this happened. He said, “You know what? That conversation we had a month ago got my head spun around on this. I actually feel like it would’ve been a bad thing to have been acquired.”
From there, they were very successful. They grew. They didn’t reach the stars, but they grew to a good number and still exist today. It’s the same thing once you’re in the company. You’ve got to get on board quickly with the new imperatives. It’s vital to get over your ego and understand that this is no longer the same company. Now, you have to get up to speed quickly on the metrics and imperatives of your new organization. It’s almost like getting a new job.
It comes back to that ability to inspire people, tell great stories, and get them on board. Specifically with acquisitions, sometimes people forget that they’re not buying a machine, the company is just a group of people. They all have their own aspirations, both at work and in their personal lives, as well as their own vision for what they’re trying to build. They may not align exactly with the vision that led to the acquisition, so as the acquirer, it’s important to make sure that gets squared away early.
When I was at Microsoft, we had a significant investment thesis in online advertising, which led to us acquiring a company called aQuantive. They were generating hundreds of millions in revenue, which, at Microsoft, was considered underwhelming. We needed offerings in the billions to really make an impact. Despite this, we paid a whopping $6 billion for aQuantive, mainly driven by the urgency to compete with Google because they had just acquired DoubleClick.
The leadership at aQuantive felt validated by this acquisition because they believed it endorsed their strategy. They transitioned into leadership roles within Microsoft, but their incremental approach to growth was focused on reducing risk, while our thesis was about disruption, which is inherently risky. This misalignment was painful. We watched Google surge ahead and capitalize on its DoubleClick acquisition. Meanwhile, we spent years debating our strategy and approach.
Even though we grew our advertising business from $800 million in 2004 to $5 billion by 2010, we missed out on the market we aimed for, which was in the tens of billions. Google hit around $90 billion in display advertising alone in 2010, and our reliance on safe, incremental steps meant we were operating on the wrong magnitude.
Of course, there’s a chance that the original thesis wouldn’t have succeeded either, but the goal was to be disruptive. In my experience, sometimes taking a big swing and missing can still land you with significant progress. Playing it safe meant that we were never going to hit the home run. Aligning on the acquisition’s purpose was crucial, and we lost valuable momentum due to differing priorities.
Yes. When my startup, Rare Crowds, was acquired by MediaMath, we faced a significant challenge. As ex-Microsoft employees, we had been given access to free Azure cloud services for several years and decided to build our solutions on that platform. This was a misstep and became a major issue when MediaMath acquired us. Their business team was enthusiastic about what our approach could mean to their business, but the engineering team was not interested in our code. They used a completely different tech stack and had no experience with .NET or C#.
Since my product manager had accepted a job at Google and my engineers had accepted jobs elsewhere, I was the only person to join MediaMath from Rare Crowds. I had to persuade the MediaMath engineering team to rebuild our core concepts using their technology. This required me to leverage my skills in storytelling — I had to inspire the team and provide data-driven arguments to overcome skepticism from tech leadership.
When we were all done with that effort, we built a tool at MediaMath called Curated Marketplace. Although I left MediaMath before it gained traction, it eventually became their fastest growing product. I believe that if I had taken a different, forceful approach, or didn’t take the time to build consensus and alignment, it might not have succeeded. But by taking the core idea and storytelling through the lens that MediaMath viewed the world, we got it built and it ended up being a big winner for the company.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Learn how AI can help PMs plan and run workshops that drive results from preparing agendas to facilitating discussions and summarizing work.
Learn how to prepare and launch internal products effectively with real PM examples, readiness pillars, and a practical launch checklist.
Learn how to balance confidence and collaboration as a product leader while building trust, authenticity, and high-performing teams.
Data shows you what users do, not why. Learn how blending qualitative and quantitative insights fuels real product innovation.
Learn more →
