How Shopify builds product

VP of Product Glen Coates on how Shopify plans around yearly themes, organizes around jobs to be done, tracks using a homegrown tool, why they shifted away from a GM structure, and much more

👋 Hey, I’m Lenny and welcome to a 🔒 subscriber-only edition 🔒 of my weekly newsletter. Each week I tackle reader questions about building product, driving growth, and accelerating your career.

---

Shopify has always done things a bit differently. They’ve been remote-friendly long before Covid, recently canceled all of their recurring meetings (and now even show how much each meeting is costing attendees!), and famously are on a mission to “arm the rebels.”

The business has been an unprecedented success story, too. Shopify now powers over 10% of all U.S. e-commerce, hosts a large swath of the world’s biggest e-commerce businesses, including Supreme, Glossier, Mattel, Vuori, Gymshark, and Allbirds, has processed over half a trillion dollars of GMV, and generates nearly $6B (!) of revenue per year. Shopify is also 17 years old, with almost 10,000 employees, but continues to execute like a startup and launch innovative products like Sidekick (an AI business partner), immersive product description pages, and the world’s highest-converting checkout platform, Shop Pay.

To learn from Shopify’s experience scaling and optimizing their product org, I sat down with Glen Coates, VP of Product, responsible for the core Shopify product—the largest product team within the company.

Here’s what stood out to me most about Shopify’s approach to product:

1. Their CEO Tobi’s yearly themes, and how they inform every team’s planning

2. Their aversion to OKRs

3. Their homegrown task tracking system, called GSD—Get Shit Done

4. Their shift away from a GM structure, and their move from 10 business units down to two

5. Teams being structured around jobs to be done

6. Their AAA framework for handling stakeholders—Aiming, Assembling, and Achieving

7. Their recursive internal mantra that ends with “The third priority is never to reverse priorities one and two”

Glen is also going to be announcing a swath of product updates to the Shopify platform tomorrow morning as part of the Shopify Editions Summer ’23 launch. For more from Glen, follow him on LinkedIn and Twitter. For more stories of how the best product teams operate, don’t miss my interviews with Figma, Coda, Duolingo, Miro, Ramp, Notion, and Snowflake.

---

How Shopify builds product

Glen Coates, VP of Product

1. How far out do you plan in detail, and how has that evolved over the years?

Until very recently, Shopify had an annual planning process where we’d present plans to the CEO and Finance in August or September. We’d write these long docs, but unsurprisingly, they’d usually get torn up by about March. So planning became this charade of we’re going to do this insane planning thing, but we know it’s all just going to go sideways in three months. We all know how crazy it’s been out there; things are changing so fast all the time. People who think they can see a year out are mostly kidding themselves.

Instead now, once a year, Tobi [Shopify’s founder and CEO] sets themes for the year. This year there were six that reflect top-level priorities. They’re always written from the point of view of the merchant. We try to imagine a Shopify merchant writing an email to a friend where they say, “Here’s why I love Shopify, and here’s why I’m going to keep using it for my business.”

One of the themes that Tobi added this year was “Shopify keeps me on the cutting edge.” Which is an amorphous thing, “the cutting edge”—what does that mean? Is it developer tooling? Is it AI? Is it evolving regulations like ATT? Is it how I optimize my checkout for conversion? It could be any of that, which is the idea. We want merchants to focus on their business. We want them to think, “Hey, I’m just a guy trying to sell candles. Do I really want to have to learn everything about checkout conversion optimization? Do I really want to have to read white papers coming out of OpenAI, or can I trust that Shopify’s got me and I can just focus on my candles?” This year, especially with AI, that theme was such a focusing lens for us. We have to be on the bleeding edge so merchants don’t have to be.

Once we have Tobi’s themes, one level lower within each top-level team (e.g. Core), we think about the ways we could measure our impact against those themes. We come up with what would end up being called an objective or something that smells a bit like an OKR (though we would never say that here).

That turns into a rough six-month roadmap. This aligns with our twice-yearly releases, Shopify Editions, which are our big releases with hundreds of improvements, features, and products.

We want to have very high confidence in what’s going to be shipping in the next Edition, and some idea of what will go in the one after that, but we don’t try to think too much further than that. Then every six weeks, teams come together and do their sprint-level detailed planning of what they are doing right now. 

So that’s kind of the lay of the land in terms of planning. Themes once a year, which gets translated into a six-month plan, and then there are four six-week cycles inside each half.

But again, things are changing so much right now. The world economy just went upside down last year, and that changed things. The world of AI appeared earlier this year, and that changed things. So I think we’ve learned the hard way that the world doesn’t seem to be slowing down, and being able to react and not being married to the plan is actually the most important thing.

2. You said you never use the word “OKR,” but let me ask you anyway—have you used OKRs in some form, and how has that changed over the years?

I’m not aware of us ever using OKRs formally at Shopify, but people end up using things that smell like them all the time. If I had to say why there is an aversion to them, I think it’s really two things. One, it’s part of the culture—there’s a bit of an affinity for chaos and change that doesn’t embrace structured systems. In a sense, that’s just who Tobi is. Tobi is very truth-seeking in the sense of whatever the truth is, he just wants to go there, and systems and structures that stop him going to the truth are bad in and of themselves.

If you look at companies like Google, Facebook—things that are very aggregatory, very funnelly, very at-scale consumer products—they’re often very metrics-oriented. A team owns a number, and the goal is to do whatever they have to do to make that number go up. I think Tobi just does not agree with that philosophy of product development and thinks that you end up with a lot of micro-optimizations of local maxima that may say you drove that number up, but the product just doesn’t feel good anymore. The product doesn’t fit well together, and it feels like one part is pushing me in one direction and the other part in another. You can’t really explain why that is until you find out that there were two teams inside the company who had different metrics they were optimizing for. That’s when you realize why the product is so weird and incohesive.

On the other hand, there are some parts of Shopify where we do care a lot about metrics. A good example would be the Checkout team, who cares a lot about checkout conversion rate because there’s a one-to-one relationship between that and the money that our merchants make. We’re extremely focused on metrics when it comes to performance.

We care a lot about the speed and quality of the product itself, but we’re not the kind of company that would deem something a failure or not approve something to go ahead just because you can’t put a metric on it. As an example, right now we’re working to significantly change the look and feel of the Shopify Admin [the seller dashboard] for no reason other than it’ll look better and we think it’s the right thing to do. There’s zero metrics attached to it. The only thing that matters is that we come out the other side, look at it, and think: That’s rad. I’m psyched. Merchants are psyched. That’s it.

Shopify Admin

3. How do product/design review meetings work?

Shopify has an internal system called GSD, which is a bit like Jira or a task management app, except it’s not really a task management app. It’s a project stakeholder reviewing tool. It stands for “Get Shit Done.” Every project that any team does goes in GSD, which has five phases of review:

1. Proposal

2. Prototype

3. Build

4. Release

5. Results

Here’s what this looks like in an actual screenshot of GSD:

We have a system called OK1 and OK2, and for any particular team there’s a front line of reviewers. On OK1s, it’s usually the directors from product, UX, engineering, and sometimes data who all have to sign off. And then it comes up to the senior leadership team (SLT), which we call OK2, which includes, again, product, UX, engineering, and data, who all have to sign off on it as well.

It’s actually been really good practice for the PM team, because most of these reviews come with a short video from the PM explaining what the product or project is. I think it’s great practice for PMs to have to say, very concisely, “What is this thing? Why is it valuable? How does it work?” So they get a lot of practice storytelling in tight videos.

Usually we do these reviews async and we trade comments. Sometimes, though, we set a meeting to talk synchronously when we know the topic will be super-controversial or it’s a big deal. We also have an office-hours rotation where if you need to get in for a 30-minute review for quick feedback on not very much notice, there’s a lever to pull.

In terms of who makes the calls in product reviews, I generally think of it like this: product makes the call on should we do this at all, Engineering and UX essentially has the veto power on how we do it, and then at the end of the day, the PM has to put their body on the line for is this ready to ship. If they say yes and the thing’s garbage, then the PM has to wear it. That’s generally how that works.

4. Are product and design part of the same org? And who do PMs ultimately report to? Has this changed over the years?

Tobi is the head of R&D (and also CEO) at Shopify, and there are two people who report to him, who all the PMs report to. One of them is me and the other is Kaz. About half the PMs report to each of us.

In my org, product, UX, marketing, ops, and partnerships all report up into me, and engineering and data have their own functional orgs separately. Under me, the reporting lines go functional. So the head of UX reports to me, and all of UX reports to her. I have a head of product marketing, and all of product marketing reports to her.

In 2018 we had a GM structure, with about 10 GMs at Shopify, each of whom had all the functions for their business unit reporting to them. Then, about two and a half years ago, Tobi reorged the company from 10 divisions to two.

The two divisions are:

1. Core: What I run product for, which is what’s in the box when you buy Shopify—all the included features, the online store, checkout, and Admin.

2. Merchant services: Think of it as the optional add-ons for Shopify, the point of sale, the payment processing, and the shipping labels. This also includes Shop—the buyer-facing brand, the wallet, the package tracker, the shopping.

There were many reasons for our move away from the GM structure, but one of the biggest reasons was because as the company grew and our product became wider, with lots of capabilities, the advantage we have versus your competitors is the breadth of the feature set—the one-stop-shopness of your product. That value really starts to fall apart if the parts of the product don’t work well together and don’t seem like they were crafted from a single vision.

This is the challenge that all big tech companies need to overcome. Can you tell how our org structure works by looking at the product? Can you see where the breaks are in the product or not? The best companies figure out how to make sure you can’t see the org chart through the product.

This org structure that we’re in right now, it has downsides to it (e.g. very large teams that require a lot of centralized coordination), but the big upside is that the org chart and the actual product are very close to the same thing (e.g. we are respecting Conway’s law). This helps us deliver on what our merchants want: products that work well together and are all aimed in a single, consistent direction.

5. Do you structure your teams around products, user types, user journey, outcomes, or something in between? Has this changed over the years?

We’re structured essentially around jobs to be done. Within Core, we have 11 teams, and they are oriented around the main merchant jobs to be done. There are some that are obviously semi-standalone bits of the product, like the online store and the checkout. Once you get into the back end, we have a team called Merchandising, and the job to be done there is all about how to set up and sell products. There’s a team called Engage, which mainly focuses on marketing and customer engagement. There’s a team called Build, which manages the developer platform. There’s a team that manages the app ecosystem and all the dynamics around that.

Part of the reason we focus teams around jobs to be done is to honor a promise Shopify tries to make and keep to its merchants. We never want merchants to bump into the ceiling that says, I love this product, but it’s not scaling to meet my needs. Now I have to go do the really painful thing of moving my entire business onto some other platform.

We want teams to think about the whole spectrum. Everyone from my mom, if she wants to get started selling pottery tomorrow, all the way up to big brands like Supreme. We don’t want there to be any rough edges on that curve. As a merchant’s business gets bigger, we don’t want there to be a weird moment where Shopify flips into enterprise mode, where suddenly everything’s different. We want that to be a smooth curve all the way up, and we just need every team to care about that, so there is no “Enterprise Team” or “Small Business Team”; each team needs to think about “hello world through to IPO” for their features.

In terms of jobs to be done, we don’t use the hardcore, capital JTBD framework or anything like that. There are gray areas around the edges of some of these things. There’s also a very big variance in the maturity between different jobs to be done within the company. Shopify is a world leader in checkout, for example. I think the next company to us in the world, in the landscape of checkouts on the internet, isn’t even close. We’re world leaders by a big margin. But then you take our Engage team, which builds the marketing tools and customer segmentation—that’s really like a challenger, an upstart, versus a Salesforce Marketing Cloud or things that are much more steeped in those categories.

6. What’s in your product team’s tool stack?