As Chief Product Officer, Tamar is responsible for product strategy and development, design, research, and customer experience. With tens of millions of Slack users worldwide–and a product that is a business critical backbone of modern work–it takes a special leader to steer the business. And Tamar, who was previously a VP at Google (overseeing products like Search, Identity and Privacy) and VP at Amazon, is that special leader.

In our wide-ranging private Guild discussion, we covered countless interesting lessons and frameworks that she applies in her work. Here are some of our favorites.

‍

There’s no perfect org design… but your org may need single-threaded leaders

We explored how Tamar has structured her organization at Slack, which today includes multiple VP-level Product leads assigned to priorities like Platform, Foundations, New Products, and Enterprise, as well as leaders for functions like Design and Customer Experience. This gave the opportunity to pose an evergreen question for Product leaders: “How should scaling organizations think about segmenting Product into discrete swimlanes for VP/Director-level leaders?”. Tamar’s response was thought-provoking.

“There is no perfect organization. You have to play to the strengths of the people who are on your team. Draw the lines by giving people the things that they’re good at. When it’s not working, then change things up… but I don’t believe there is one way of organizing things. It will change all the time. Instead I would say, figure out what’s the most broken in your product and make sure you have a single-threaded leader fixing it.”

To illustrate this principle, Tamar shared the story of a feature that had been in the works for several years. It was easily one of the most commonly requested features from customers. That feature also aligned with the company’s long-term strategic roadmap, as it unlocked a large number of new platform use cases. The wrinkle? The project was being managed by a junior PM several layers deep on the Core product team, and progress was halting for several years.

The solution? Leadership asked the VP of the Core team to take a secondment, shedding all of their direct reports and shifting to become a single-threaded product leader fully focused on bringing the feature to life. The end result was that progress accelerated dramatically; and ultimately, after about two years ownership of the feature was transitioned back into the main Product org. But the point is, the feature may never have seen the light of day without a single-threaded leader.

The tool for leaders here is a simple one, and rhymes with the common adage of putting your best people against your biggest problems (or opportunities). But single-threaded leadership takes this a step further, enabling great leaders to bring things to life through the clarifying power of focus.

‍

You don’t need a perfect strategy, you need to make customers successful

Later in our conversation, we explored why one of Slack’s Product teams was very deliberately named the “Expansion” team–a team that in most companies would be called the “Growth” team. The simple answer: the name was meant to serve as a constant reminder of the most important outcome the team was driving toward.

The deliberate re-naming of organizations is a concept I first encountered many years ago, with the then-Chief Marketing Officer of Shopify. In his first few months in the role, he would ask his team, “what are you responsible for?” And individuals would respond with, “I’m an Events Manager. My job is to organize customer events.” One of the first changes he made as a new leader was to change titles across the org to include “Growth”. The reason? To make it abundantly clear that each team member’s job was to drive growth–and that organizing customer events was simply a means to that end.

Tamar is a believer in the notion that Product teams’ fundamental role is simple: to make customers successful. Anything else is simply a means to the end of customers succeeding. Yet far too many teams become distracted by other things–and perhaps chief among those are metrics. At their best, metrics are a powerful tool, in particular when they act as a near-perfect proxy for your desired end (i.e., making customers successful). At their worst, they actually lead Product to do things that may be short- or medium-term productive, but are not fundamentally aligned to your more important long term mission.

All of this ladders up to one framework that the best teams embrace: seeking the global maximum outcome, rather than the local maximum. In this specific example, Growth teams can very easily get distracted in efforts that find the local maximum. A ruthless focus on optimizing every piece of copy, every landing page, and every step in a funnel does lead to higher-converting pages and therefore productive outcomes. But it can also lead you to lose sight of your customer.

Slack’s Expansion Team implemented several simple ways to beat back the temptation to focus on the local maximum. The first was simple: focus on helping customers understand the value of Slack and how teams become successful by using Slack, not on optimizing the funnel. Then, rather than fixating on how customers moved from one step of the funnel to the next, the team began to focus on how well customers understood what each step was trying to communicate. The team also redefined their North Star metric to the best possible proxy for what a customer succeeding looked like, along the lines of “more than X people sending Y messages per week”.

A final gem that Tamar shared in this discussion is a call to action for Product leaders–one that not only will help you find the global maximum, but also casts the role of Product leadership in delightful simplicity… and removes the undue pressure that many Product leaders feel to be a strategic visionary.

“Your job is not to sit in a room and come up with a strategy. It’s to talk to a lot of people. Talk to a lot of customers. Talk to other Product Managers, Engineers, Executives. Then assimilate all of that information and come up with something that is compelling. But you have to also have an opinion.”

‍

To be the best Product leader, you need to understand how the product is built

A final area we touched on was the relationship between Product and Engineering. One of the top things that Tamar suggests for Product to become the best partner to Engineering is to learn how hard it is to build things. Whether that means learning to code, building a side project, or going really deep on how a spec will come to life within an existing product ecosystem, understanding how things are built will pay lasting dividends.

On one hand, Product leaders will better appreciate what it takes to bring products and features to life, creating a more empathetic and productive relationship. To illustrate the opposite of what this looks like, Tamar shared the story of a Product leader in a former life that was described by Engineering as, “somebody who sees a spec and a press release… and nothing in between.”

A second benefit of going deep in understanding how to build is that Product leaders will be able to sense if engineering teams are being overly cautious or aggressive in providing project estimates. This is invaluable in the (relatively rare) situations where Engineering teams feel strongly about whether a feature should be built or not; and use high or low estimates as a tool to influence whether the feature is built.

‍