tldr
Tobi Lütke sits down with Vanessa Lee — Shopify's highest-ranking product person — for an episode of "Context," Shopify's internal podcast now made public. The conversation centers on a single thesis: the best product work comes from understanding your domain so deeply that you have a "Neo-in-the-matrix moment" where the entire problem becomes code you can bend. They trace Vanessa's arc from metafields (an API-only abstraction nobody used) to leading Shopify's entire product org, and use that journey to unpack how Shopify thinks about Platform Building, domain modeling, developer ecosystems, intuition in product decisions, and the editor-vs-writer dynamic in product leadership.
Key Takeaways
- Domain modeling is the job. Not feature shipping, not sprint velocity — the core craft is modeling your problem domain so durably that the solution lasts years and doesn't break APIs. Implementing a feature is easy. Getting the model right is hard — and worth 6-12 months of upfront investment.
- "Gushing Neck-Wound" products. Shopify's platform thesis: you can only build a real platform if you start by solving a pain so acute that customers come to you despite everything else. Then the ecosystem builds around that gravity. You can't build a platform first and hope people come.
- Developer Experience can't win, but can lose. You win the developer ecosystem by solving a real problem. But you lose developers — permanently — through bad DX: breaking APIs, poor documentation, insane technical contracts. Every developer who walks away is a killer app that never got built.
- Intuition is a trained system. Tobi draws on The Inner Game of Tennis to argue that intuition isn't a mystical thing — it's a visual, pattern-matching system trained by deep domain experience. The key: learn to trust it, even before you can articulate why something feels wrong.
- The courage to trust your gut. Your ability to sense something is wrong will always outrun your ability to explain it. Product leaders need the courage to say "this doesn't feel right" even when they can't immediately justify it — then backfill the reasoning.
- Editors vs. writers. Product reviews at Shopify follow the editor-writer model: leadership (editors) shapes direction and catches systemic issues, but the name on the book belongs to the designers and engineers (writers) who do the building. Editors don't write the code.
- Naming shapes industries. Shopify accidentally named "variants" for the entire retail industry (Tobi didn't know the proper term "SKU" in 2004). They intentionally pushed "composable" over "headless." The words you choose become the industry's vocabulary.
- Stakeholder reviews aren't presentation theater. Tobi actively breaks the "presenting to the CEO" dynamic — he wants to be brought in when things aren't working, not when they're polished. The meeting dynamics matter: making it safe to surface problems is more productive than reviewing solutions.
Timestamps
| Time | Topic |
|---|---|
| 0:00 | Cold open — "You have to understand your domain really, really well" |
| 0:40 | Context podcast intro — Shopify's internal podcast goes public |
| 1:00 | Who is Vanessa Lee? Brand new to Shopify (joke — she's VP Product) |
| 1:30 | Metafields and metaobjects — the most abstract of the abstract |
| 2:30 | Vanessa's early days at Shopify (2017-2019) — bringing metafields from API-only to platform backbone |
| 3:30 | Vanessa's rise to highest-ranking Product person at Shopify |
| 4:30 | Joining Shopify without knowing what Shopify was |
| 5:00 | Platform evolution — budding, mature, and now AI-driven |
| 5:30 | Y Combinator demo-day lists as a signal for what problems people want to solve |
| 6:00 | "You can build a platform, but it has to start with a gushing neck-wound" |
| 7:00 | Why developers come to Shopify — solving unmet merchant needs |
| 7:30 | Platform gravity: "Come for the tool, stay for the network" |
| 8:00 | Implementing features is easy — modeling the domain is hard |
| 9:00 | The unacknowledged craft of designing primitives and relationships |
| 9:30 | Checkout modeling — what they got wrong early and had to rethink |
| 10:00 | Getting the model right takes 6-12 months but lasts years |
| 10:30 | "Don't break the API" — invisible damage from broken contracts |
| 11:00 | Developers code for many purposes — Shopify must earn their time |
| 11:30 | Developer ergonomics: can't win with it, can quickly lose without it |
| 12:30 | The killer apps that never got built because a developer walked away |
| 13:00 | API horror story — HTTP remote calls on include, breaking every contract |
| 14:00 | How Shopify learns what the problem-domain actually is |
| 14:30 | The "Neo-in-the-matrix moment" — seeing the entire problem as code |
| 15:00 | When solutions are so elegant they need extensive explanation |
| 16:30 | Flow/automation example — orders triggering custom workflows |
| 17:00 | Locations: from vertical feature to horizontal primitive |
| 18:00 | Locations as a platform — events, metafields, extensibility |
| 18:30 | Not copying what others call experimentation — digging one level deeper |
| 19:30 | "Variants" — Tobi accidentally named them for the entire retail industry |
| 20:00 | "Handles" — URL slugs named from Ruby on Rails conventions |
| 20:30 | "Composable" over "headless" — intentionally reshaping industry language |
| 21:00 | Unearthing more-truthful representations of the problem domain |
| 22:00 | "The Inner Game of Tennis" — intuition as a trained visual system |
| 23:00 | System 1 vs System 2 — let the body learn, don't over-verbalize |
| 24:00 | Why pictures and feelings communicate better than words for complex problems |
| 25:00 | Intuition in product: "I just knew there was nothing in this direction" |
| 26:00 | Sensing adjacent opportunities that don't require breaking the API |
| 26:30 | The courage to trust a "niggling feeling" before you can explain it |
| 27:30 | Your ability to sense wrongness will outrun your ability to explain it |
| 28:00 | Cultivating intuition and the courage to trust it |
| 29:00 | The high of intuition-driven decisions changing trajectories |
| 29:30 | "Please bring me in when something ISN'T working" |
| 30:00 | Meeting dynamics — millions of intangible ways to change decision quality |
| 31:00 | Breaking the "presenting to the CEO" dynamic — make it safe to be imperfect |
| 32:00 | Product reviews and stakeholder roles |
| 33:00 | Editors vs. writers — the writer's name goes on the book |
| 34:00 | Choosing between solutions: ten ways to solve any problem at Shopify |
| 35:00 | How you solve the problem matters more than whether you solve it |
| 35:30 | Local decisions with system-wide consequences — "Shopify ten years from now" |
| 36:00 | There's never a perfect solution, only the best set of trade-offs |
| 37:00 | Career craft: the ceiling of your product IS the ceiling of your career |
| 38:00 | Wrap — "A+, but how do you get to A++?" |
Relevance to SupportWire & FeatureOS
- "Gushing neck-wound" test for SupportWire. Tobi's thesis is that platforms only work when they start by solving an acute pain. SupportWire needs to be so good at one thing — AI-native customer support — that teams come despite missing features. Build the gravity first, platform second.
- Domain modeling applies to feedback systems. FeatureOS models feedback, votes, roadmaps, and changelogs. Are these the right primitives? Or are we using someone else's vocabulary (Canny's, Productboard's) instead of discovering what the problem actually is? Tobi's "Neo moment" challenge: can you see the entire feedback-to-product loop as code?
- "Don't break the API" is a FeatureOS imperative. FeatureOS has an API and integrations. Every breaking change is a developer who walks away and a killer integration that never gets built. Invest in durable modeling upfront — it's cheaper than the invisible damage of broken contracts.
- Intuition in product reviews. The "Inner Game of Tennis" lesson applies to design reviews at FeatureOS: when something feels wrong about a UI or interaction, trust that feeling and investigate it rather than rationalizing it away. Cultivate that instinct.
- Editor-not-writer posture for CEO feedback. When reviewing the team's work, adopt Tobi's editor posture: shape direction, catch systemic issues, but don't rewrite. Make it safe to bring problems early. The name on the book belongs to the people who built it.
Notable Quotes
"You actually have to just understand your domain really, really well. And model it very, very durably."
"I don't want to call it 'eureka', but it feels like a Neo-in-the-matrix moment where you just sort of see the entire problem for what it is. It's all code, and you can bend physics."
"You can't win it by developer ergonomics alone, but you can very quickly lose it if you don't pay attention to that."
"Implementing a feature straight up is really not that hard, especially if you care only a little about UX and you care only a little about scalability. But understanding how the thing works with everything else — that's massively harder."
"Your ability to know that something is wrong will be speedrunning your ability to explain why you think that. And that is an uncomfortable position to be in. It requires courage."
"In the end, it's the writer's name on a book. It's not the editors on a book."
"Shopify ten years from now will have consequences from decisions we make today that only look like minor changes in the local context."
One Thing to Act On
Run the "gushing neck-wound" test on SupportWire. Tobi's platform thesis is clear: you can't build a platform and then find users — you need a pain so acute that customers come despite everything else. Before building SupportWire's platform layer (APIs, integrations, extensibility), pressure-test whether the core product solves a "gushing neck-wound" for a specific segment. If you can't name 10 teams who'd switch tomorrow because nothing else solves their pain, the platform play is premature.
#shopify #domain-modeling #platform-building #developer-experience #intuition #product-craft #tobi-lutke #internal-tools #api-design
Raw Transcript
Auto-captions from YouTube. Folded by default — expand if you need to grep the source or pull an exact quote.
0:02 You actually have to just understand 0:04 your domain really really well. Okay. 0:07 And model it very very durably. 0:10 >> I I don't want to call it eureka but it 0:12 feels like a neo in a matrix moment 0:14 where you just sort of see the entire 0:17 problem for what it is right like it's 0:18 like suddenly it's all code. 0:19 >> You can't win it by developer ergonomics 0:22 alone and you can very quickly lose it 0:24 if you don't pay attention to that. when 0:26 people say, "Oh, we can build it this 0:29 way. It works." But something about that 0:32 is feels wrong. 0:34 >> No. Uh, 0:34 >> it doesn't fit into all. 0:36 >> And now we're trying to come back from 0:37 gushing neck wound. Um, 0:40 >> context has been Shopify's internal 0:42 podcast for over 10 years, and now we're 0:45 bringing it to you. It's where leaders 0:47 across our business talk about what 0:48 they're building, why it matters for 0:50 commerce, and how it helps merchants, 0:51 partners, and the ecosystem. 0:57 Hey everyone, welcome to Context. I'm 0:59 here with Vanessa who is um where's 1:02 Vanessa? 1:02 >> Brand new to Shopify. 1:04 >> First day. Hello everyone. 1:06 >> This is the onboarding. 1:06 >> Yeah, for sure. 1:08 >> In fact uh uh very much not so. And um 1:10 we even have done a previous context 1:12 episode together. So thank you for 1:14 coming back. 1:15 >> Very different. 1:16 >> I've been waiting for you to message me 1:18 to come back for four years. 1:20 >> Okay. So like already um I've 1:22 disappointed. Perfect. This this took no 1:25 time. 1:25 >> I I I aspire to be the Asian mom that is 1:28 missing in your life. 1:29 >> You said it. 1:31 >> Perfect. Um okay. So last time we 1:33 chatted, we chatted about meta fields. 1:34 Uh we chatted about um meta objects and 1:37 uh these kind of things. the most 1:38 abstract of our abstract uh 1:40 conversations we got ourselves in 1:41 because we've been working for a very 1:43 long time on product together 1:45 >> and um 1:46 >> so last time then it's because we 1:49 finally built the thing that we 1:51 discussed and wanted and you know 1:52 product is wonderful in all these ways 1:55 because you get to imagine things that 1:56 don't exist yet and then event like some 1:58 of them even um real yeah which is like 2:00 incredible right 2:01 >> the most magical thing it's why we do 2:03 what we do 2:03 >> exactly and um you go through trials and 2:06 tribulations and everything that truly 2:07 evokes ends up being someone's uh 2:09 passion project and someone fought for 2:11 it and uh you you learned that pretty 2:12 quickly as a builder. Well, funny story. 2:14 I I remember with metap fields, meta 2:16 objects, actually like the two major 2:18 features in my early chapter here were 2:21 like versioning and metap fields and 2:22 meta objects. 2:23 >> And I remember both of them being very 2:25 under the radar at least what I thought 2:28 was under the radar for you because I 2:29 was like you didn't mention versioning 2:31 at all. you had not and this is like the 2:32 first 20 2017 2017 2018 2019 and I 2:35 remember like looking at those features 2:37 like metap fields in particular finding 2:38 it in the API and being like this is 2:41 >> this is the most underleveraged thing in 2:43 Shopify I was like why don't we have it 2:46 in the admin and so like it went from 2:48 this place of like I had built a lot of 2:51 systems with Postgress back in the day I 2:52 was like this is essentially the 2:54 flexibility that you get with Postgress 2:56 because you have the JSON column type 2:57 right and like it was the only database 2:59 at the time doing that I was like why 3:00 aren't we doing this for Shopify. And so 3:02 like we brought that from essentially 3:04 just API only and no one using it to now 3:06 it backing 3:07 >> so much of Shopify's data platform which 3:10 was it's been just the funnest thing to 3:12 see. 3:12 >> Yeah. No, it's major fields are I mean 3:14 we have an entire episode on this which 3:16 people can produce 3:16 >> a throwback. 3:17 >> Um but like they are log bearing for 3:20 Shopify because 3:20 >> they are the most pure extensibility 3:22 component in Shopify. the the atomic 3:24 building block of how apps communicate, 3:26 how how you know state which is 3:28 important for software such as ours. 3:30 That was four years ago. Uh since then 3:32 you are now part of my team highest 3:34 ranking product person in the company. 3:36 So that's pretty cool. So nice nice work 3:37 on that. It's 3:38 >> it's been it's been fun to see all 3:40 levels. I joined as a as a senior PM. I 3:43 think not a lot of people know that, but 3:44 like 3:44 >> that's a good scope. 3:45 >> I've seen it all and it's been fun at 3:47 every stage, but very different at every 3:49 stage. I I bet you like lots of your 3:52 friends at the time would probably not 3:54 even be surprised like like that but 3:55 that but you made it through the all the 3:56 levels. I I just have that opinion of 3:58 you. It felt inevitable that like um 4:01 you're going to like I don't know ascend 4:02 this place. 4:03 >> I don't know. I kind of joined I don't 4:05 think you know this. So this is like 4:08 truly our 101 now out there. But I I I 4:11 joined Shopify because I needed a break 4:13 from running my previous startup. 4:15 >> Y 4:16 >> and so I thought I was like oh commerce 4:18 is fun. There's nothing more fun than 4:19 commerce. I like to shop. How hard could 4:20 this be? It must be better than 4:22 healthcare, right? It must be easier 4:23 than healthcare. Uh and so I was only I 4:26 was like, "Oh, I'll join for a few 4:27 years." And that was like nine years 4:29 ago. So yeah, I I don't know. I don't 4:31 know what people think um having known 4:33 me from before, but but it's been fun. 4:35 Let's talk about some of the stuff that 4:36 we've also got a chance to work on cuz I 4:38 feel like I've seen so many chapters of 4:41 Shopify. When we when I first joined, I 4:44 was like the technical PM. 4:46 >> Yeah. who joined to build our platform 4:49 with JML at the time and a bunch of 4:51 other folks. And since then, we are now 4:55 not only like a platform, but we're 4:56 moving into like yet another chapter of 4:58 Shopify. 4:58 >> Y 4:59 >> I feel like I feel like it's changed. We 5:01 were like, oh, budding platform, mature 5:04 platform, and then now to uh something 5:08 new. And I think AI has driven that in 5:11 the last I'd say like two and a half 5:13 years especially. And so like why don't 5:16 we talk about that a little bit because 5:17 building product looks so different from 5:19 when I joined till now. 5:21 >> Yeah. Yeah. I think the topic of 5:22 platform is exactly the right one 5:23 because um you know everyone wants to 5:26 build a platform actually in the AI age 5:28 like I I spend time looking at what 5:30 everyone's building basically like a Y 5:32 cominator demo day kind of lists and so 5:34 on because this gives me an appreciation 5:36 for like what people identify as 5:38 problems worth solving problems of that 5:40 are they think there's value in a 5:41 business model there and also very often 5:44 there's like lots of different um 5:46 companies looking coming at the same 5:47 thing lots of internal competition in 5:49 these cohorts um I think you Y community 5:52 at some point, right? Like so I find 5:54 that always an interesting uh case study 5:56 of how people try to solve a different 5:58 problem from different directions and uh 6:00 you always learn something along the 6:01 way. Right now everyone is always trying 6:04 to build platforms like it just like 6:05 it's funny because I don't think that 6:07 works. I think you can build a platform 6:11 but you have to build something else 6:12 first. I think you can eventually turn 6:14 something into a platform but you have 6:16 to 6:16 >> you have people come for the utility 6:18 value. people have a as Terry Matthews 6:20 always calls it like like a gushing neck 6:22 wound. I can never get this stupid term 6:24 out of my mind because he always talks 6:25 about it and um uh then they uh clearly 6:29 need to stench the flow and uh they do 6:31 this I suppose if the nature of a 6:33 gushing neck wound is e-commerce they 6:34 come to Shopify so 6:37 >> I not actually quote 6:39 >> no doesn't fit into now we're trying to 6:42 come back from gushing neck wound um but 6:45 like I I remember saying this too like 6:47 the the platform and the way we grow it 6:49 we really stumbled on something magical 6:52 but it was because there was this need, 6:54 this underlying need. And developers 6:56 don't just come here because they like 6:57 spending time coding versus living their 7:00 lives. They like it because, hey, 7:01 there's a bunch of other unmet needs 7:04 that they can fill with merchants for 7:06 merchants, all of the merchants that are 7:07 on Shopify, and that they they go where 7:10 they are needed, right? And I think that 7:12 like that's the thing that is so magical 7:14 about um about having a platform at this 7:17 moment is it is really hard to build 7:19 because at the first and foremost you 7:20 have to build a great product. 7:22 >> Then you can think about how do I extend 7:26 this to invite others to come and build 7:28 on top of it for the all the humans that 7:31 have come and collected across my 7:33 original product. Right. 7:34 >> Right. And that's actually really hard 7:36 to do. 7:36 >> Absolutely. And so it's you you come for 7:39 the utility, you stay for the uh 7:41 platform and uh to and the benefits of 7:44 being on a platform acrew to all the 7:47 users and um a platform can only emerge 7:50 though where um the pieces uh of a 7:53 system can be put together in novel 7:55 ways. I mean it's extraordinarily hard 7:57 to to to make a good platform, right? 7:59 Because you have to figure out how to 8:01 get the things that you wanted. like 8:03 that implementing a feature straight up 8:05 is really not that hard, especially if 8:08 you care only a little about UX and you 8:10 care about uh uh only a little about 8:12 scalability, which is easy to do if 8:14 you're building like bespoke software 8:16 for instance, and uh you do not care 8:19 about um it being addressable by other 8:21 people in novel ways on the platform. It 8:23 the amount of code you have to write is 8:25 just reduced by 100x or something like 8:27 this. and the amount of um thinking you 8:29 have to put into how how the thing works 8:31 and how it works with everything else is 8:33 also like just massively reduced. So um 8:35 we do the opposite. We do sort of the 8:37 hardest thing of everything. We like we 8:40 want to deliver a new feature that's 8:42 immediately approachable by absolutely 8:44 like millions of different and very 8:45 diverse businesses in uh hundred of 8:48 different countries speaking like 30 8:51 different languages and uh we want to 8:53 expose a set of APIs that uh then other 8:56 people can use to do completely novel 8:57 things and for these these things have 8:59 to be components um and each part of 9:02 this has to be designed and this is a 9:03 very under acknowledged part of building 9:05 Shopify specifically but something we 9:08 have been doing we have a lot of reps on 9:10 we have taken a we have broken um a lot 9:13 of very monolithic things into 9:15 components that then made the platform 9:18 better 9:18 >> yeah like like a good example is if you 9:21 look at something like checkout right 9:23 and I I didn't get a chance to work on 9:25 the checkout during C1 but now that I 9:27 get to work closely with the team I 9:28 think you see so many examples of this 9:30 checkout was like one thing I was like 9:32 it was checkout we didn't model very 9:35 much to be honest with checkout we at 9:37 that point we model such things as 9:39 upsells, extensions, subscriptions. 9:41 Think about all the things that happen 9:42 in the contract between a buyer, which 9:45 you don't get to see, and then the 9:46 merchants's business, which is really 9:48 what Checkout is, is that contract 9:49 happening a million times over, right? 9:52 And so that contract, we then decided, 9:54 okay, let's let's take that and more 9:56 firmly create pieces, things like, okay, 9:59 here's a product, here's a subscription, 10:00 here's a price, here's tax. Okay. And by 10:04 modeling it more firmly and I think 10:05 that's that's a very important piece is 10:08 getting that model right and building a 10:09 bespoke platform for a particular 10:13 vertical which is very very powerful 10:15 right and so I think that's that's what 10:17 you see with checkout and with building 10:18 platforms is you actually have to just 10:21 understand your domain really really 10:24 well okay and model it very very durably 10:27 so that it lasts for beyond just the 10:30 next you know 6 to 12 months but it 10:32 lasts for years to come. We all know 10:33 that every time you break the API, don't 10:35 break the API. Um, you you cause a bunch 10:38 of invisible work to happen that you 10:40 don't see and causes a ton of pain for a 10:43 lot of people having sat on the other 10:44 side as an independent indie developer 10:47 uh using many platforms. You feel that 10:49 pain. So, it's it's actually it's very 10:51 hard to build a develop like you almost 10:53 I always say that your platform lives 10:56 and breathes by a use case. You had to 10:58 have a purpose for why people are coming 11:00 and then they want to participate with 11:02 you in this mission. Okay? Because at 11:04 the end of the day, developers can code 11:06 for many purposes. You can build 11:07 software for anything. But you choosing 11:10 to build to invite people to come and 11:12 build for this purpose, right? Which is 11:14 amazing. But once you've gained that, 11:17 you can lose it by okay, well, let's not 11:20 invest in the way that developer 11:22 ergonomics is designed. Let's in let's 11:24 break the API over and over again. So 11:26 like you can very quickly lose it. You 11:28 can't win it by developer ergonomics 11:30 alone and you can very quickly lose it 11:32 if you don't pay attention to that once 11:34 you have that community. 11:35 >> That's very true. The developer tools, 11:38 the tooling, the experience of 11:39 installing it um to invoking it to um 11:43 creating a template to then invoking the 11:44 template um to writing code against the 11:47 APIs, figuring out what APIs exist and 11:49 and and how this all works is also UX. 11:53 It's UX uh delivered to uh developers 11:56 who are very busy people and um they 11:59 want their uh tooling to be just so 12:02 because this is an invitation you know 12:04 they they can spend their time on 12:06 everything um and if they chose to spend 12:08 their time on Shopify we should really 12:11 not lose their attention because of 12:13 unforced errors very similar to how we 12:16 don't want people to abandon their 12:18 interest in Shopify because of some UI 12:20 confusion during onboarding right like 12:22 and Um this is a really really important 12:24 point. The net amount of busy work we 12:27 are pumping into the ecosystem will not 12:29 really come back at us uh directly. It 12:32 will come back at us in the absence of 12:35 killer applications that never got 12:36 developed because someone just like 12:38 walked away. You know there was various 12:39 points of time where I think our 12:41 developer tools were probably un like a 12:42 good deal under the level of quality um 12:45 that we wanted. I there's a famous case 12:47 of uh there definitely was a Toby 12:49 tornado. Um uh these things are 12:51 >> I do love when Toby talks about Toby 12:53 tornado. 12:54 >> Yeah. Yeah. Yeah. Like I mean I might as 12:55 well probably like this this was 12:57 definitely one because I think our 12:58 Python bindings were doing uh HTTP 13:01 remote course upon including the file 13:04 which is like just like broke literally 13:06 every sane contract any or assumption 13:08 anyone ever had on how how an API uh 13:11 behaves and what how a library behaves. 13:13 you know there was just like real like 13:16 exposed skills issues um coming from our 13:19 like we communicate for code too right 13:21 so so then you're like okay 13:23 >> if we are the types of company that 13:25 ships libraries at that state like let's 13:27 look at everything top to bottom and see 13:29 what else are we um what other insane 13:31 things are we doing and turns out yeah 13:33 obviously there's lots of areas which 13:34 were doing well but like some weren't 13:36 and and and and actually the unevenness 13:38 of the entire experience is actually a 13:40 problem too so all to Um this has all 13:44 been cleaned up uh by you know you know 13:47 Eton and the teams and u 13:49 >> after a lot of hard work 13:50 >> lots of hard work and 13:52 >> so that's good we have like we can talk 13:54 about online stores and online store 13:56 editors and but I think the more 13:58 important thing is just with how Shopify 14:00 Shopifies is to really learn deeply 14:04 about how a problem domain works. 14:06 Sometimes we have to you know we talk 14:08 with our customers we build something 14:09 that is our best rendition of it and 14:11 then iterate from there like this is the 14:12 loop I always talk about and then at 14:15 some point 14:17 ascending this loop something happens 14:19 which is like this some people would 14:21 describe it as penny drop moment but 14:23 that's usually used too early in the 14:25 thing there is like a I don't want to 14:27 call it eureka but it feels like a neo 14:29 in a matrix moment where you just sort 14:31 of see the entire problem for what it is 14:33 right like it's like suddenly it's all 14:35 code and uh you can bend physics 14:37 >> like there's just like a level where at 14:39 some point teams get into 14:42 >> I understand 14:44 what set of problems can be solved all 14:47 with the same primitive and then we go 14:50 and put this all together in such a way 14:52 that um that that uh you know like it it 14:54 solves 14:55 >> not just problem now but actually in the 14:57 future it actually itself spawns an 15:00 entire new area of like the app store or 15:02 like like yeah it like I I I know you 15:05 know what I'm talking about. 15:06 >> Yes. Okay. I'm trying to find like the 15:08 best example because I know that moment 15:10 like time and time again. 15:12 >> I think functions is one. 15:13 >> Functions. Functions is a good one that 15:16 has grown. 15:16 >> I think uh niparis is one. Um um I I 15:21 think even the shop web components is is 15:24 is is one like I mean maybe they're not 15:26 the ideal examples for this like 15:28 functions unfortunately is so abstract 15:30 that we would have to spend a lot of 15:31 time explaining it to to for people to 15:33 appreciate 15:35 >> why they are so such a um incredibly uh 15:39 inspired solution for the problem set. 15:41 >> Yeah. But the the practice really is 15:43 easy to explain, right? You go into a 15:45 particular problem and I think this is 15:47 the thing that sometimes I I struggle to 15:49 articulate to PMs who haven't um who 15:53 aren't technical, right? And to be 15:54 honest, like our like our PM team now is 15:57 probably one of the most technical PM 15:58 teams. I was the first technical PM. Um 16:01 although there were other technical PMs. 16:02 I don't know why people gave me that um 16:05 thing. Well, are you a PM or an engineer 16:07 back then? I mean, I don't know. Anyway, 16:09 >> I mean I think back then we had earned 16:12 our stripes to be like our weird PM 16:13 selves. But um but now um like one of 16:19 the patterns where you see this happen a 16:21 lot is like someone goes in and says hey 16:23 for orders like this is how functions 16:25 came about too and flow was like they 16:28 were looking at particular use cases 16:30 right let's say like when an order comes 16:32 in from Toby I want it to mark like send 16:34 a special note or um you know make a 16:38 joke about gushing neck wounds and then 16:40 um and then and then and then put that 16:43 in have that run every single time, 16:45 right? So like you'll pick enough of 16:47 those use cases up where you realize, 16:50 okay, well, how are we going to design? 16:52 So you design it very vertically. You 16:53 say, okay, we're just going to solve 16:54 this problem and then you figure out, 16:56 okay, hey, in this actually which part 16:59 of this is actually applicable 17:01 horizontally and you just like you have 17:03 this all the time with light bubbles 17:05 like even locations. Okay, that's maybe 17:06 one that's a good example because I 17:07 dived into that recently. Yeah. Um so 17:10 locations we initially came up with this 17:12 for multilocation for storing inventory 17:15 in two different places like I was 17:17 really involved in that when the team 17:18 did that hard work we worked on that 17:20 heart surgery originally it was really 17:22 just about like there's two locations at 17:24 which you are storing inventory your 17:26 warehouse and your retail location and 17:28 we want to model that so that we we end 17:30 up uh shipping from the right place okay 17:32 and we and we charge the right shipping 17:34 cost so it's a very vertical thing now 17:37 locations very recently has started to 17:39 evolve into. Okay. Well, what other 17:41 thing does a location model beyond just 17:44 for the purpose of inventory? 17:45 >> Yeah, you might sell from it 17:46 >> and you might sell from it, you might 17:48 not. Right? So, we have locations that 17:50 represent things like there's a retail 17:52 location um and we sell from it, but 17:54 there's also like capabilities we're now 17:56 adding on locations that give us more 17:59 utility there. So, like which locations 18:02 might have in the future events tied to 18:04 them? Are there meta fields that we can 18:06 attach to a location to solve more use 18:08 cases? So the the the single model of 18:11 locations starts off with a very 18:13 particular use case and then extends to 18:16 fill more and more as long as you've 18:17 modeled the domain correctly which I I 18:19 think you you do see over and over again 18:21 as long as you look hard enough but that 18:22 that was one that came up to mind. 18:23 >> I I think very often what happens is um 18:26 you find a lower level commonality 18:28 between behind a lot of different 18:30 things. We didn't just say, hey, the 18:32 industry, this other pack of human 18:34 beings have told us that this is what 18:37 experimentation should mean. Instead, 18:39 it's digging one level deeper and then 18:41 continuing to dig and dig and dig. And 18:43 then we have this infamous thing of like 18:44 always modeling stuff. And the thing 18:46 that actually has been so fascinating to 18:49 watch, I remember when we joined, we 18:51 were such a a small fish in 2017 18:54 compared to now. And we had set some 18:57 like new terminology cuz whenever you go 19:00 deeper like that you end up setting new 19:02 patterns right that don't look like what 19:05 other people are doing right um like we 19:08 set terminology out there around okay we 19:10 are going to model um like multicurrency 19:14 in in a particular way present at the 19:16 time we called it like presentation 19:17 currency we've changed that since then 19:19 but like these terms that we have over 19:22 time used now become the de facto 19:26 industry standard which has been such a 19:28 fascinating place for us to be. 19:30 >> Um best example of this is variance. Um 19:32 like variance the retail industry at 19:35 large is calling um variance variance 19:38 because I in 2004 didn't know the term 19:40 skus 19:42 >> literally the reason actually there's 19:44 even even handles are like this um I I 19:48 called them handles. The industry term 19:49 was um actually from slugs. 19:52 >> Slugs. Yeah. I just didn't know the term 19:53 like slug or I feel like I may have 19:56 actually I may have actually looked it 19:58 up and was like what the hell 20:00 >> that's a very ugly name. 20:01 >> It's an ugly name for an thing. Um so 20:03 anyway so um handles and varants are 20:06 really very very clear examples of um 20:10 the funny side effects of success 20:12 because it creates a little bit of a um 20:15 you know weather system of its own and 20:17 sucks everyone else in. And now um um 20:19 yeah all software even random open 20:22 source GitHub e-commerce packages that 20:25 some I look 20:26 >> oh composable commerce is another one 20:29 like we we like kudos to Ilia and some 20:31 of the we were like headless sucks like 20:34 we don't like that name let's do 20:35 composable and now everyone says 20:36 composable 20:38 >> or headless is pretty good when you have 20:39 a gushing neck wound I suppose because 20:40 like it's 20:41 >> yeah because then that is your that's 20:42 your whole head 20:44 >> um 20:44 >> um the um markets 20:47 >> markets 20:48 That's another one. Yeah. If it hasn't 20:50 taken off broadly yet, it will in the 20:52 next year. I think every single time 20:54 that we redefine something and when you 20:57 like this is what when I when I talk to 20:59 teams, I was like this is actually the 21:00 only way to build the best product. 21:03 >> Okay. Because as you uh unearth these 21:07 like more uh truthful representations to 21:10 be honest of what you're trying to build 21:12 and what the user is trying to look for 21:14 then you set you set new heights on okay 21:17 well how could it work right and so like 21:19 that's the thing that is often I think 21:21 tough for a lot of folks coming into 21:22 Shopify that's a really hard culture to 21:25 drive and because it's it takes a lot of 21:28 judiciousness to be like okay now keep 21:31 digging keep digging keep that curiosity 21:33 going. You have to love it because for 21:37 sure there are easier places to build 21:39 product where learning from others and 21:42 just being like okay well that the 21:43 industry does that so that's that's 21:45 enough. The breed of product here is 21:47 like um really lends itself to people 21:51 who are just so obsessed that just the 21:55 act of like if it doesn't fit in the 21:57 system in your brain you are not 21:59 satisfied. You need to use this actually 22:01 as a signal like like feelings like 22:04 that. There's a wonderful book uh called 22:07 um uh the inner game of tennis which I 22:10 really love. 22:10 >> Oh yes. 22:11 >> Um yeah, you know 22:12 >> I play tennis. So I've read it. 22:14 >> It's a it's a great great book. It's 22:16 accidentally like don't think too hard. 22:18 >> It's accidentally an amazing book on um 22:21 how to think better and uh how to learn 22:23 things much more quickly. And basically 22:25 the the big premise of the book um by 22:28 the way this is the least academic book 22:30 you will read because it's written by 22:31 like some 22:32 >> as a sports person as a coach 22:33 >> like yeah as a coach basically um um who 22:36 is like somehow written one of the 22:38 greatest books um and um um the premise 22:41 is that uh you know like again this is 22:43 something you see from people like um um 22:46 Danny Connean and Atlas Straki as well 22:49 that there's like multiple systems in 22:51 the brain. Um he he frames it slightly 22:53 differently. But what he says is like 22:55 you have um uh what one part of your 22:58 brain is uh um the part that you are 23:00 trying to uh you know you you do you do 23:03 your swings. It'll learn it's it's going 23:05 to learn the muscle memory and 23:08 it's it's part of a visual system and 23:11 the key to it is it doesn't understand 23:13 language. It's like he he makes this 23:15 wonderful analogy of like if you're 23:17 trying to um uh uh you take a swing or 23:21 something, do a surf, and and you just 23:23 don't get it right, and then afterwards 23:25 you're just like beating yourself up 23:27 over it. It's sort of like um 23:30 >> uh being on vacation and being uh yelled 23:32 at by some uh you know, Italian 23:34 grandmother. like it's entirely 23:37 entertaining and uh but you don't 23:40 understand the word unless you speak 23:41 Italian because it's just like these are 23:44 >> your brain doesn't understand 23:45 >> your brain doesn't talk it talks in 23:46 pictures 23:48 >> if you want your reasoning brain just 23:50 chiding the the rest of your body with 23:53 language you're not speaking the right 23:54 language you need to actually visualize 23:56 what it looks like to do the surf and 23:57 then do the surf and that now you're 23:59 communicating 24:00 >> so I worry that people don't appreciate 24:03 this enough because the other direction 24:05 go is exists as well. The only way these 24:09 two systems um can talk to each other is 24:12 pictures or feelings. That's the other 24:14 direction. So when people say, "Oh, we 24:18 can build it this way. It works." But 24:20 something about that 24:22 >> feels wrong. you're using we we fall 24:25 back for a lack of better terminology 24:27 onto the language of aesthetics and 24:29 feelings because we are sort of uneasy 24:32 with like they're being a really large 24:35 part of our brain that we have trained 24:36 to um with intuition on something that's 24:40 very important for us in our lives to uh 24:42 chime in um and tell us that there's a 24:45 problem. If you talk with um like 24:48 grandmaster chess players, they 24:50 acknowledge this much more. They talk 24:52 about language of beauty all the time. 24:53 It's like they they like you're talking 24:55 with like the computers evaluate tens of 24:58 th millions of positions. The 24:59 grandmasters do don't. They they just 25:02 only like this looked appealing. So I 25:04 calculate the line. This is I I I just 25:07 knew there was nothing in this direction 25:09 because it no line in this direction 25:12 would be beautiful. like they actually 25:14 use this they have learned to uh push 25:17 their uh neurovvisual cortex into being 25:20 a parallel computer calculating for them 25:24 moves of the board but the only way it 25:27 can send anything back is through 25:30 aesthetics and so I think um it's 25:32 incredibly important to actually uh 25:35 understand that like intuition what we 25:37 call intuition sometimes communicated by 25:39 aesthetics and feelings um is uh our 25:42 entire life's experience rolled out for 25:45 us in the moment uh coming to bear to uh 25:48 help us um um making uh a decision. 25:51 Often if you then go back and really 25:53 think through or calculate the line uh 25:55 in other words, you'll figure out why it 25:57 would have been bad to do it. It's 25:59 usually you're missing a trade-off of 26:00 some kind or there's just like an 26:03 adjacent uh thing you could do that 26:05 helps with the next and the next and the 26:07 next project or doesn't require you 26:09 break the API or you know any of these 26:11 kind of things. Yeah, there's really two 26:13 things also because intuition is is one 26:15 thing but it requires two things to be 26:18 super good at it. One is the courage to 26:20 follow it. Okay, that actually isn't 26:23 said enough is it actually does take 26:25 tremendous courage to say it's right 26:28 before this thing is supposed to ship. 26:29 Everyone's telling me to ship it. It 26:31 doesn't feel right. So the the courage 26:33 to be able to like actually admit that 26:36 there is a niggling feeling that 26:39 something isn't correct even when it's 26:41 uncomfortable and then two the ability 26:44 to unear and decode your intuition. And 26:48 both of these things we are never 26:50 taught. 26:51 >> Yes, that's right. Well, because it it 26:54 doesn't make sense to teach people 26:56 especially like I think the worst case 26:57 you can do is teach a young person to 26:59 trust the iteration because the 27:00 intuition sucks 27:01 >> when they're teenagers just like 27:02 >> your world model is completely 27:04 incorrect, right? Like um I mean all you 27:07 just see 27:08 >> I should jump off this car and 27:10 >> Yeah. Yeah. No, I mean you can see lots 27:11 of confirmation by what people protest 27:13 for, right? Like it's they're all going 27:14 to be embarrassed by that whatever it is 27:16 um in the future. So um the world is 27:18 much more nuanced um and complex than 27:20 everyone's pretending. So the um um yeah 27:24 like but at some point you can be on the 27:26 other side like if you have put in the 27:28 reps and then you should trust your 27:29 intuition but you have to discover it 27:31 yourself is true and it requires courage 27:33 because very often your ability to know 27:35 that something is wrong will be 27:37 speedrunning your ability to explain why 27:40 you think that. 27:40 >> Yes. 27:41 >> And that is um very very um much coded 27:45 in minds of most people as arbitrariness 27:48 when it really isn't. um um it's 27:51 actually an enormous accelerant for 27:53 making good decisions as long as it's 27:56 actually an area that you have built the 27:57 correct intuition for. So a lot of I 28:00 think building a great career is about 28:02 cultivating this kind of intuition and 28:04 then the developing the courage um to uh 28:08 trust these uh judgments and then going 28:11 back and back filling if if if pushed. 28:14 >> Yeah. Yeah. It's something that I've 28:16 learned over and over again is like 28:19 nothing matters. The satisfaction that 28:21 you get when you either follow an 28:24 intuition and gain more information and 28:26 rectify whatever f whatever feeling that 28:28 you had or you saw it through and it 28:31 turned out that your intuition changed 28:35 the trajectory of something for the 28:36 better is and that high that you get 28:38 from that that's there will be no other 28:42 feeling. 28:42 >> Yeah, I agree. It's um 28:46 um yeah, I mean it's so satisfying to um 28:51 make significant contributions to a 28:53 thing that like is impossible for a 28:55 single person to create, right? Like 28:57 it's it's like things that only teams 28:59 can build and then coordinating and uh 29:02 you know being part of that is just like 29:04 I think it's the greatest. Um it's it's 29:06 so hard to do but we're getting pretty 29:08 good at it. We pretty good at this 29:10 coordination which I'm really really 29:11 proud of. Yeah. 29:12 >> Well, yeah. I I I have to I so often my 29:15 job is like your job is probably like 29:16 this too. It's like we we tend to be 29:18 called in when something isn't working. 29:19 It's really easy to make get get the 29:21 wrong read from this. This is why I like 29:23 the the product reviews because you have 29:25 to we look at everything and there's so 29:27 much that's actually going well. Um and 29:29 like yeah 29:30 >> I actually feel like half the time I 29:32 have to really tell teams as like please 29:35 bring me in when something isn't 29:36 working. 29:38 >> They want to bring things to me when 29:39 things are working. 29:40 >> Yeah. Um, 29:41 >> Shopify itself is actually has very much 29:44 an Asian parent mentality. Like it's 29:46 like it's like what happened to the like 29:48 98% what happened to the last 2%. 29:51 >> We're never satisfied. Never satisfied. 29:53 Um, but I think that there's also like 29:56 as as I teach PMs this a lot. Um, 29:59 especially folks who have other more 30:01 junior PMs underneath them is like there 30:04 are millions of intangible ways that you 30:07 can change the dynamic of a particular 30:09 meeting. And this sounds so tactical 30:11 because like meetings like oh my god 30:13 like who cares but like if you're a PM 30:16 and you got you got your team together 30:17 for a meeting that meeting is valuable 30:20 because it's it's expensive so let's 30:23 make the most use out of it. the like 30:24 little tactics like, okay, how do you 30:26 shift into collaboration mode so that 30:29 those who have a lower um courage bar 30:32 for bringing up when something isn't 30:34 working 30:35 >> is welcome to say it because I I think 30:37 that that's that's a really tough place 30:39 to be. Most organizations don't pay 30:41 enough attention to this and therefore 30:43 they don't leverage all the humans in 30:45 the organization uh to their full 30:47 potential. But like I'll do little 30:49 things like I'm famous for like all 30:51 right like I see you have the Figma. Uh 30:53 give me the link. I will present back to 30:55 you what your Figma is and you'll watch 30:57 me struggle through it. And it just 30:59 shifts the dynamic of the of the room a 31:01 little bit so that it's like no you're 31:03 not presenting to me. This is not meant 31:05 to be perfect 31:05 >> because otherwise you're you're like 31:07 obviously the people who made with Figma 31:09 will know exactly how it works, right? 31:10 Like it's all all we establishing is 31:12 that experts can use it which is never 31:14 the goal of any thing we're building. 31:16 >> No. And and it also invites a ton more 31:18 collaboration. Right now it becomes you 31:20 are not presenting to me. This is now a 31:24 collaborative effort where I'm actually 31:25 like let's all just talk about what's 31:27 wrong with this thing. Right? How do we 31:29 make this better? Um and all of those 31:31 tiny little I don't know I call them 31:33 like tiny little tricks makes for more 31:36 productive decision- making for PMs. 31:39 >> Very good. I I like that a lot. I mean, 31:42 it's also just like 31:44 anytime you can um like like fresh eyes 31:48 is like really powerful, right? Like 31:49 it's just like seeing something for the 31:51 first time is um it's nothing much more 31:54 more valuable than having someone 31:55 narrate um a first experience about 31:57 anything. And like um you will never 32:00 learn as much about the thing you're 32:02 trying to build as in both cases. Um 32:04 >> well actually this is like something 32:06 that me and you've talked about and I've 32:07 talked about it in smaller forums but 32:09 it's like building a product requires 32:12 editors and writers. Okay. And no one 32:15 talks about this because the equivalent 32:17 of an editor and a writer is is not in 32:20 today's organizations is not a mutual 32:23 respect but when you're writing a book 32:24 it is a mutual respect for each role. 32:27 Usually editors in organizations are 32:29 folks like Toby, sometimes myself, 32:31 sometimes you know ex people who are 32:34 seen as uh stakeholders but they're they 32:37 play a very necessary role right and so 32:40 like as stakeholders we have to 32:42 appreciate the blank how difficult it is 32:44 to be a writer in the room and to have a 32:46 blank page 32:48 >> but also as the writer you have to 32:50 appreciate and welcome the feedback from 32:52 the editors. Right. And only great 32:55 products come when those two roles 32:57 exist. 32:58 >> 100%. Completely agree with us. And I I 33:01 think um I think it's important to say 33:03 like in the end it's the writer's name 33:05 on a book, right? Like it's not the 33:07 editors on a book. And I think this is 33:09 like I think the the medium of books is 33:12 as good as it is due to this 33:13 arrangement, right? Like there is a um 33:16 like it's important. This is what the 33:19 entire um like the the our mastery 33:22 system is about like it's the craft 33:24 people are the ones who um get their 33:26 name in the line light right now and are 33:28 doing frankly they're doing most of the 33:30 work and it's right like this. So many 33:32 in in tech a lot of times this is wrong. 33:35 This is not going the right direction in 33:37 my mind. However, the writers, the 33:40 programs, the designers, um um some of 33:43 the PMs on the projects really also just 33:46 need to like there needs to be 33:49 appreciation for the editing because 33:52 there is just a perspective like it's 33:53 it's really like every problem is 33:55 solvable locally, but you might gum up 33:57 the entire system very very quickly if 33:59 you solve every problem locally. Um 34:02 Shopify is a big system and they often 34:04 we need to say well yes this a valid 34:07 solution but um there are 10 different 34:11 ways like we had we were in a review 34:12 today which was uh where we discussed 34:15 >> um uh new way by which orders can uh be 34:20 created 34:21 uh 34:23 facilitated through something like a 34:24 sales channel. Well, are we going to 34:27 give statistics for um how many orders 34:30 were facilitated in the sales channel 34:32 app or are we going to, you know, insert 34:34 those things as orders into into 34:36 Shopify? And then when the answer to 34:38 that is no, uh that's not the plan right 34:41 now. Why not? And it turns out like at 34:45 least we don't know yet. this was today. 34:46 But very likely that means there's 34:48 something about orders that like that is 34:51 like 34:52 >> there's a new hill to climb on orders 34:54 >> harder than it should be. And so 34:57 >> solving the problem, it's not about 35:00 solving a problem. It's about how are 35:02 you solving the problem because the 35:04 decision of how to do this has 35:05 unbelievable consequences like um uh 35:08 that we don't need to go in go into but 35:11 like this is not a small decision where 35:13 one of them is uh actually it is it 35:16 feels from the team's perspect as a 35:18 small decision where one of the two 35:19 solutions is um significantly more 35:22 annoying because now you have to like 35:24 commit code to core or liaison with a 35:27 checkout or order team um which is just 35:29 more toil. However, only from the 35:32 perspective of a team working on the 35:34 problem right now in the local context 35:35 does this look like a minor change. Um, 35:38 Shopify 10 years from now is a 35:39 completely different product because of 35:41 this this decision, right? Like utly 35:42 utterly different um because of uh 35:45 >> and this 10 degree difference. 35:46 >> Yeah. Yeah. Yeah. Yeah. Exactly. So um 35:50 this editing can only be done um like 35:54 for people who are specifically have to 35:57 spend their time roaming across the 35:58 entire problem space of Shopify and 36:00 understand all the all the piece and all 36:02 the trade-offs because there's never a 36:03 perfect solution for anything. There's 36:04 only the best set of trade-offs which we 36:06 are trying to find. 36:08 >> Yeah. Yeah. And I think that like when I 36:09 when I coach um folks who are now coming 36:12 into more senior PM positions, even for 36:15 PMs on the team, you are playing a local 36:18 editor, 36:18 >> right? You can see the millions of 36:20 decisions that your engineering team is 36:21 making, that your UX team is making. And 36:24 because you have fresh eyes and you 36:25 aren't down that rabbit hole, you can 36:27 play that role at that even that micro 36:29 level and that just gets bigger and 36:30 bigger and bigger. But I think that that 36:33 is also something that we have to teach 36:35 more of as folks come into Shopify is 36:37 that like these um in life society 36:41 teaches us a lot that to build a product 36:43 to have these reviews for example that's 36:45 a pass or fail. 36:47 >> So they prepare they prepare so much and 36:50 they want to make sure they like nail it 36:51 and they're like looking for I don't 36:53 know that like oh amazing work I didn't 36:56 think about that. 36:58 um like go forth and and and and then 37:01 you know maybe you'll become uh I don't 37:04 know like a a a VP like I don't know 37:06 whatever external title whatever society 37:07 has told you you want to do the 37:09 challenging thing is actually unlearning 37:11 that and then being like no no the 37:13 editor's role is to provide you 37:17 information to make better decisions and 37:18 when you rethink like of your 37:21 stakeholder meetings or whatever ex 37:22 meetings that way you change the 37:25 trajectory of how your team anticipates 37:28 um feedback how how what whatever like 37:31 what's the ceiling that you can you can 37:32 actually achieve in terms of your 37:34 product and it just changes the whole 37:36 dynamic of being a PM. 37:37 >> Yeah, totally completely agree. I think 37:40 that's a great place to uh wrap it. I 37:43 think perfect 37:46 ending 10 of 10. 37:47 >> Amazing. 37:50 >> We need a different ending. 37:51 >> Could be better. 37:51 >> We could Yeah, 37:52 >> could be better. 37:52 >> One out of 10. Maybe like uh I give it a 37:56 6 out of 10. Let's improve. 37:58 >> Yes. Yes. Clearly, we need to loop be 38:00 loopy here and um find some rapid 38:02 improvement loops. 38:03 >> A+ but but how did you get A++? 38:06 >> Yeah. Yeah. Exactly. 38:07 >> Well, Vanessa, thanks for joining and um 38:10 uh that's context for you.