Mind the Gap Between the Product and the Platform

Henrik Kniberg, Greg Bell, Lindsay Silver, Ciara Peter at UXDX Europe. Video: https://www.youtube.com/watch?v=09Qdx0cKVYY

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introductions

[00:00:00] Henrik: I'm Henrik. I'm in Sweden, and I work at Mojang doing Minecraft stuff: gameplay design and development, and also team coaching, to try to help figure out how to work effectively as a group. In the past I've done a lot of organizational coaching at product companies, Lego and Spotify and some other companies. I did a whole virtual meetup yesterday evening, Swedish time, about how we do release management and a bit about how we do design for Minecraft releases.

[00:00:32] Greg: Yup.

[00:00:35] Henrik: What about Greg?

[00:00:35] Greg: Yeah, thanks. Greg Bell. I'm the VP Engineering at Hootsuite. For those of you that don't know, we are a company that builds social media marketing software. We're about a thousand people worldwide, headquartered in Vancouver, Canada. I gave a talk about some of the shifts over the last few years of creating a more data-driven culture within our engineering team. Looking forward to this chat about platforms.

[00:01:12] Rory: Great. Lindsay Silver, over to you.

[00:01:14] Lindsay: Hey, guys. I'm Lindsay Silver. I'm the Head of Platforms at Condé Nast. I've been a data engineer and then an engineering lead for most of my career, and I'm really passionate about how platforms and abstraction layers actually affect businesses. I think at some point I crossed the line into the dark side of the product world, because I was trying to relate engineering and technical concepts to dollars and upside all the time. I'm excited to be here, and I'm really looking forward to talking about platforms.

What is a platform?

[00:01:46] Rory: Great. I'm just going to jump in while we're waiting for Ciara. Hopefully she can join us. The first thing: platform is in the title, and platform can mean a lot of things to a lot of different people. I'd like to just throw it out there: what is your definition of platform? I'll start with Henrik, because I guess with Minecraft it might be a little bit different compared to some of the other answers.

[00:02:15] Henrik: Maybe. When I first saw the topic of this panel, I thought, what is platform? Our product is a platform, it's the same thing. But then when I thought about it more deeply, I realized, actually, no, the term platform does make sense in our context, because we have this game, Minecraft itself, where people are playing. But then the product is also a platform, because people use Minecraft like a game engine to build their own stuff on it, mods and all kinds of community-driven content. Those are in a sense different types of customers for us: the players of the game, and then the people who use the product to build their own things on top.

[00:02:52] Rory: I'll hand over to Ciara after this, but Greg, do you want to give an update on what platform is in your context?

[00:02:58] Greg: We use that word in two major different ways. One is that we consider Hootsuite itself a platform, which means that we have public APIs, we have partners who integrate deeply, and we have an app store where customers can buy apps that run within Hootsuite. That's one aspect of our platform. And then we also have an internal platform, so that's the other way we use the term. We have multiple products all in market, and we developed an underlying technology platform that we utilize to deliver multiple different products. Those are the two different ways that we use that term within Hootsuite.

[00:03:44] Ciara: Thanks everyone, and thanks Greg. Classic case of the computer crashing literally one minute before the presentation, but I'm glad to be back on. And Lindsay, did you have a chance to introduce yourself already?

[00:04:00] Lindsay: I did, yup. On to the platform question: I actually think that Greg and Condé Nast view it very similarly. We have a platform as an offering, a flexible offering, but also as the core underlying technology that powers the portfolio of applications that we have.

When did you decide to become a platform?

[00:04:20] Ciara: On that note, every company wants to be a platform, right? You might start with an initial product, but it's really about how we expand, whether that be a marketplace, building applications, or just some internal platform. I'd love to hear from each of you: did you start as a platform, or at what point did you decide "we're going to be a platform company," and what was the business driver behind that? Lindsay, could I ask you to start on that one?

[00:04:56] Lindsay: Yeah, we had a big shift. At Condé Nast, when we think about our platform, the cornerstone of the platform is our content management system. We're an editorial company. We have a lot of editors creating content, and so the big piece of technology we started with, the product that we started with internally, was building a proprietary content management system. When I started, which was about five years ago, that was the core product. For us, moving into platform thinking was definitely an explicit choice, and it took a lot of change management internally to get people to go from thinking about one product to asking themselves what that core product could do that we weren't already doing with it.

[00:05:45] I think that fundamentally is one of the big things. When you're thinking about a platform, you start from what you have, but ask yourself what other value can come from it. In our case, the second thing, the impetus for thinking about platforming, was contextual advertising. Our same core content APIs are very editorially driven, with a lot of content that editors had put into our systems. If we added things like NLP to those, then we could build a set of advertising products on top of those as well. Organically, when we started thinking like that, when we started thinking, "Okay, with the same building blocks we can create another product here," it really changed the culture and the thinking.

[00:06:28] I think that's where you have to start. If you approach it the other way and say, "Oh, we want to have a platform," arbitrarily, you get yourself into trouble. I think you see a lot of end-user products that at first are very good and pure, and then all of a sudden they have a marketplace on the side, and all of a sudden they have a community aspect, and all of a sudden they have all these things that aren't the actual purpose of the product. It's just someone saying, "Okay, we have to find other uses for our brand, or other uses for these." That's how we started. It's gone a long way since then, but that is definitely how we started thinking about ourselves as a platform.

[00:07:07] Ciara: That's great. Henrik or Greg, anything you'd like to add on this one?

[00:07:15] Henrik: Well, just from a game perspective, I really agree with that. I can't think of many successful game engines or platforms that were built as an engine from the beginning, and then you add games on top and hope that they're good. It's more like you build a great product, and then you realize, "Oh, wait a sec, we can do all this stuff with this. And oh, wait, other people can do other stuff with this." And then you have this platform, which is battle-tested. I think that's the way it's worked for us with Minecraft, and probably most of the game stuff I've seen as well.

[00:07:44] Greg: Go ahead.

[00:07:44] Ciara: Go ahead, Greg.

[00:07:47] Greg: I was just going to say Hootsuite went through a different but similar journey, which is that we build technology for marketing teams, and marketing teams have a million and one different pieces of software these days that they utilize to get their jobs done every day. The necessity of integrating those tools in a way that they can be useful together was just a clear opportunity for our organization. The other aspect is that Hootsuite builds software on top of all the social networks, and social networks have a really long tail of functionality. There's a long tail of social networks and a long tail of functionality that we may not want to build ourselves, and have chosen not to build ourselves. Our APIs allow independent developers or companies to build that functionality themselves and have it integrated into their day-to-day work. That started happening pretty early on. Hootsuite is a 12-year-old company now, and pretty early on that became a core piece of the strategy.

Planning a roadmap for a platform

[00:09:03] Ciara: It's really interesting, a lot of different inspirations or reasons for building a platform. I've heard, on the core content side, sharing all of the technology that's available in one product; if you have a portfolio of products, enabling them; then thinking about what's a marketplace; and Greg, in your scenario, integrating with all that marketing technology is table stakes. Very interesting. Greg, you not only have to think about the marketing technology, but you also have to think about social media, and these are companies that are doing things... I mean, the marketing companies are as well, but social media companies are doing things completely independently, in their own driver's seat. I would love to hear from everyone, but maybe we can start with you. How do you plan a roadmap for a platform given all this information?

[00:10:14] Greg: I'll try to answer from the two sides. There are two paths: I talked about the internal platform and then the external platform. The internal platform, I think, is fairly challenging, mainly because we are on top of constantly changing APIs from all sorts of different organizations. Some are mature software teams that have great APIs and practices around those APIs, and some are new, fledgling social networks that may or may not care that much about their API. The planning there, I think, is rather challenging, and we look for stability, really. Our internal platform is actually about guarding our downstream internal teams from all the craziness that happens across all the social network APIs.

[00:11:27] Then similarly, having been at Hootsuite for a little over five years, I spent a lot of cycles planning the public APIs that we're going to deliver. I would say it's also fairly challenging for us to create roadmaps against, mainly because I believe it's more challenging to figure out the value that you're providing to organizations via public APIs than via a user interface. We have tons of great relationships with customers who we can just speak to directly: "Hey, do you want this button to do this thing?" We can build prototypes easily, have customers go through them, and learn from usability testing. When we're delivering APIs, all of that is more challenging to iterate on. Typically there are large integrations that these APIs are meant for. They get built, and then inevitably you learn some stuff and you need to make changes, and it's expensive to make those changes, and downstream developers don't want to make changes. I don't have any secret sauce in particular. We're actively trying to figure out how to better plan and product manage our APIs. All I can say is that I think they're pretty challenging.

[00:12:47] Ciara: Got it. Henrik, how about you? How do you and the team plan a roadmap for the platform, in alignment with all the products?

[00:13:01] Henrik: I would say there are a few driving factors. We're generally quite flexible with roadmaps. We don't generally set up a five-year plan and then measure how we follow it, but we do have high-level goals that we try to align towards. They're driven quite a lot by the community, because we work quite closely with our player community and creator community. When we see things that they really need, that make their life better, that influences our priorities quite a lot. That's one aspect: what are creators asking for, what do they need?

[00:13:36] But it's also balanced, because every time we build something, we don't want to break stuff for people. It's the same platform. We change something, and somebody, somewhere, has built something that depends on the thing we changed, and now it's broken. So it's always a trade-off. The community drives it, but then there's our own pet peeves: "Oh, if we improve this in the platform, it'll make our life easier. If we make this change, it'll be easier to add new entities or new creatures in Minecraft, for example. Maybe we should invest in that." Depending on what we're planning in the future, we might prioritize enabling technology for those features. Things that make our life easier would of course influence things.

[00:14:11] And the third thing is just, what is the theme of our next updates? For example, just a few days ago we announced that the next theme for Minecraft is going to be mountains and caves. We're going to build grand mountains and huge cave systems. Of course that will influence the priorities of our platform. We need to do some things to it to enable that to happen.

[00:14:32] Ciara: That's cool. I'm sure it would be very interesting, just thinking as a designer, what it would be like to be the cave designer. Lindsay, would love to hear from you. How do you and your teams plan roadmaps?

Incremental change versus fundamental change

[00:14:43] Lindsay: I mean, it's hard, for the reasons that both Greg and Henrik mentioned. What we always start with is a really big, obvious problem. With platforms it's nice, because when you have a new big, obvious problem, you've got a place to start, but then those really quickly fractalize. As we build roadmaps, usually the first quarter or first six months of our roadmap are very easy to map out. But as we start building a user base, as the problems start to get smaller, the upside gets smaller and the number of problems gets bigger. It becomes hard.

[00:15:24] I think what Henrik said is really important, which is that you're always looking for incremental change. We're even building teams that are focused on incremental change. We'll have a team that will basically just be improving UIs, working towards the next iteration or the next version of the software. But we always need to be questioning: is there a breaking change, or a fundamental change to the APIs or to the UI of our products, that will actually solve the problem better in a foundational way?

[00:15:56] I think people get into one mindset or the other. You have teams that are very focused on how can we disrupt, how can we change, and usually those are the ones that walk away from a product the minute they've released the first version, and then it gets to die. And then you have the incremental change people. I shouldn't actually say people; there's a mindset that's incremental change. Incremental change is easy once you get it, but there's decreasing marginal value to those changes. After about a year or two in a product, you're optimizing such minute things that unless you're Google, unless you're seeing a billion clicks per day or something like that, you're not having a huge impact.

[00:16:36] Henrik: You might even be wasting your time, because maybe you're just incrementally moving towards a local optimum, instead of saying, "Wait a sec, I should be getting off this hill and up on that mountain instead."

[00:16:44] Lindsay: And breaking that culture. I think that good management, good leaders, will always be pushing their teams to pivot to one side or the other, and that's a lot of the guidance I give my teams. "Look, if you're thinking incrementally, if you're doing a great job thinking incrementally, step back for a second and look for that thing that might fundamentally change your product. Should we rewrite it? Should we do something? Is there something there?" And vice versa: if I see someone running hard, going out into left field, coming up with big ideas, I'll often push them to say, "Okay, well, what is your three-month roadmap? What is your near term? What is going to incrementally improve your product?" That's hard. That's something you learn as an engineer after years of doing it. I learned that, and I'm sure you guys, both Greg and Henrik, do too. You always have to step back, and you always have to balance those two things in your head.

Who are the stakeholders of a platform?

[00:17:37] Ciara: Thanks, Lindsay. Yeah, it's very interesting, because as a product manager you're often thinking about the roadmap a quarter ahead, two, three quarters ahead. The theme that I've heard across this conversation is a lot of incremental, a lot of feedback from the community. I want to talk about stakeholders for a minute. Who do you consider the main stakeholders in the platform? Do you do UX research on a platform, and have you ever gotten negative feedback? I know that this is a lot of questions, but I'm curious what a day in the life is like in the world of these platforms' stakeholders. Anyone?

[00:18:30] Greg: I can talk about our internal platform. Like many organizations, we have a platform engineering team, and its management ranks have people who operate as technical product managers. I wouldn't say that we do quite as rigorous a job; I know we don't do nearly as good a job as our proper UX research team. However, the version of UX research that we're doing for that is actually with all the other engineering teams. I think we have three platform engineering teams, whose customers are the 27 other scrum teams at Hootsuite. We haven't tried to reinvent what product management means, and what customer discovery means, and what it means to understand what your customers need. We've taken a lot of those practices and just pointed them at that. The problem is more about: are our engineering teams effective, are our engineering teams moving at the pace they can? And if not, then let's look for pieces or tools or processes or technology that can actually enable most of the teams. That's from an internal perspective.

[00:19:50] Ciara: Any other inputs from the panel?

[00:19:58] Henrik: I guess I can mention who our stakeholders would be. I wrote down players, developers and creators, but I realize that players, people playing the game, are maybe not the primary customer for the platform stuff. We wouldn't change stuff in the platform for them primarily. We will build features for them. When we do stuff in the platform, it is to make life easier for the developers and designers, like me, so we can work more effectively and get stuff done. And then of course, features that would make creators happy, people who build stuff on top of the game.

[00:20:34] One thing I think is really important when people work with platform stuff, and very easy to forget, and I want to put it up as a banner on the wall, is: don't forget who you're building this thing for, whatever it is. Because it's so easy to forget, especially when you're in the platform. It's so easy to fall into this theoretical world where you're like, "Oh yeah, we've got to make this new structure for our database." But why? Who is it for? And is that person, team, function or customer segment involved in the development, giving you feedback? How do you know if you've succeeded with this? Because we tend to build so much junk, fancy things that nobody's going to need, which does cause entropy in the system. We need every single thing we do in a platform to be accompanied by who needs this and why.

[00:21:09] Ciara: Lindsay, anything you want to add?

[00:21:15] Lindsay: No, I totally agree with that. I agree with both, but I think it is interesting. For me, the hardest thing was to learn to actually love the products myself, so that I was actually my own stakeholder. And honestly, when one of your products is Vogue, vogue.com, it takes a little bit of learning to love it yourself. But I'll tell you, the best products are ones where the engineers and the product people love being users of them. I think that's something for our teams: you find people that love your product, and you cut out a layer, and that's really good. That's why I love platforms, because I can nerd out on it.

[00:21:56] Henrik: It can be dangerous, because the engineer writing that feature might love it, but are they the ones who are going to use it? If they're not, then they might build it unnecessarily.

[00:22:07] Lindsay: Totally. Well, that's the difference, and I think that's really true. I know this as an engineer, because I've spent months and years writing hobby projects and things over and over again, and trying to tune them. There's a difference between loving the code and loving the thing that you're creating, and then also loving being a user of it. I agree, and that's an easy trap to fall into. People will say, "I love this model because I've created it myself," and next thing we know, it's six months later.

[00:22:37] Henrik: "The users don't like it, but they're stupid. They don't get it."

[00:22:40] Lindsay: "They don't understand it." That's right. That's always what we hear.

Can you build an MVP of a platform?

[00:22:45] Ciara: Thank you guys for sharing that insight. I want to send a quick note to the audience, because I think we have about five minutes left. Please send us your questions right now; we'll start to collect them and get them ready. Henrik, you are famous for the MVP approach. Is it possible to do an MVP on a platform, and what does that look like?

[00:23:12] Henrik: First of all, I didn't come up with the term MVP. I don't know who did, but I also don't like the term. I don't use it. A term I like better is MLP, minimum lovable, and also minimum testable. I tend to use those instead, because I find them more concrete. Minimum testable: not lovable at all, but you can ship it to somebody and get feedback, and that's great. And then you have this other stage, minimum lovable, as in, I would actually ship this and be proud of it. I could still improve it forever, but it's in a good enough state. We use those in pretty much all the companies I work with; I've tried to introduce those concepts. Sorry, what was the actual question?

[00:23:48] Ciara: Is it possible to build an M-blank-P for a platform?

[00:23:57] Henrik: Definitely, yes. And I would boil it down to the same thing. If I'm building a platform for something, what is the minimum I can do to be able to test this? Build that first and ship it, because otherwise you don't know if your platform is solving any problem. And then of course at a later stage you might get to a lovable state, and you can have a hundred releases in between, but I find it's useful to have these clear milestones. The reason why I avoid the term MVP is because I've noticed that the term "viable" means so many different things to people, so it can get very confusing. Maybe the team says, "Yeah, this is viable," and then someone else says, "Yeah, this is shippable," but wait a sec, the customers hate it, but it's the minimum viable. It gets really confusing. So whatever terms you use, try to make it clear what they actually mean.

[00:24:40] Ciara: Got it.

[00:24:40] Greg: There's one thing I would just throw in, which is that if you're building a platform for other teams to integrate with, building that first integration as a part of the design process is a total necessity. I've just seen too many times people building something with this abstract notion that there's going to be an integration to it, and then when you finally get down to saying, "Okay, we're going to tie these two business systems together," oh, it doesn't actually support the integration.

[00:25:13] Henrik: Yeah, I'd probably use the term minimum integratable product in that case. What is the tiniest little thing we can ship to somebody, even if it's just a "Hello world" call to our API? But it's something to check that it works.

[00:25:26] Lindsay: I think that's the hardest thing we faced, for sure: that minimum-whatever-you-call-it product often means go off and build it yourself in a silo to test it. What we end up with, almost every time, and we've had some spectacular disasters that have come out of it, is "Let's get really lean and let's build this, but let's not think about the API design. It's going to be slower if we try to integrate it into our core at the start." We've learned a lot about architecture by having to say, "No, go back first and map out how this integrates with the platform that you've already created. And then you can go off; if you want to stub in API endpoints, if you want to create a version of this that's separate just for time's sake, that's fine. But you'd better have a plan for how it is integrated."

[00:26:12] Henrik: That's actually another anti-pattern I've noticed when using this MLP, MVP, whatever, incremental thinking. Yes, we should be shipping small steps and not building it all and shipping at the end, but we should also have a high-level vision, a goal, and not just ship blindly incrementally. Sometimes people get over-enthusiastic about agile, for example, and they're like, "Yeah, we're agile, we ship in small increments." But you know what? You also need an architecture. You also need a high-level, long-term goal. It can be high level, it can change, but it needs to be there so you can iterate towards it.

Q&A

[00:26:39] Ciara: Thanks, guys. We have about a minute left. I do want to get to one question from the audience, which is an extension of something we talked about earlier: when does an organization, meaning a company or part of the engineering and product division, decide to call themselves a platform versus a single product? Maybe you have some anecdotes.

[00:27:04] Greg: Stumped. I use those two definitions. I think every startup in the world right now is calling themselves a platform, so I think it's highly overused. However, in my world we try to use it to mean: are we building a platform which is going to have an ecosystem of integrations or developers around it that are going to build on top of it, or are we building our internal platform? Those are the only two definitions that I find myself trying to steer everybody towards.

[00:27:44] Henrik: I tend to avoid the word, because on its own it doesn't mean very much. Instead, I try to talk about what we are actually talking about, instead of using this vague catch-all word.

[00:27:53] Lindsay: It's such a weird... I think when Greg was describing earlier that he is both building a platform and sits above a bunch of platforms, in terms of what he's doing, and having probably hacked Hootsuite's APIs a few times myself, I know that people are building platforms on top of you. You sit in this weird world where you're always in the middle of things. So everything is a platform and nothing is a platform, I think, at that point. It's a handy word for us when we're describing a system, a factory for other systems. I think that's the biggest thing that I would say. We refer to things as platforms if you can hang something else off of them, or if they're built to be built upon. But I totally agree with Henrik, it's a useless word in itself. Anything could be a platform.

[00:28:38] Ciara: Well, I think we're at time. This has been a great conversation, and apologies again for the rocky start, but thank you Greg, Lindsay, Henrik and the UXDX family for having us on today.