Mind the Gap Between the Product and the Platform

Knowledge / Inspiration

Mind the Gap Between the Product and the Platform

UXDX Europe 2020

Everybody wants to have a platform; but what does it actually mean. How do you design the boundaries around the platform, and how do you design your teams around that. Who are the users of the platform? What are the pitfalls? What are the decisions people have to make when separating out from a product? What is the product/UX of the platform?
Moderated by Ciara Peter, join the conversation, share your insights and probe the speakers on the elements of their talks that left you wanting more.

Henrik Kniberg: I'm Henrik. I'm in Sweden. And I work at Mojang doing Minecraft stuff. So, a gameplay design and development, and also a team coaching to try to help figure out how to work effectively as a group and 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 meet that I taught yesterday evening, Swedish time about how we do Release Management and a bit about how we do design for Minecraft releases.
Greg Bell: Yup.
Henrik Kniberg: What about Greg?
Greg Bell: 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 and headquartered in Vancouver, Canada. Give a talk about some of those shifts over the last few years of creating a more data-driven culture within our engineering team. Looking forward to this chat about platforms.
Rory Madden: Great. Lindsay? Lindsay Silver over to you.
Lindsay Silver: Hey, guys. I'm Lindsay Silver. I'm the Head of Platforms at Conde Nast. Basically, I've been a Data Engineer and then an engineering lead for most my career and really passionate about how platforms and abstraction layers actually affect businesses. And I think at some point I crossed the line into the dark side of the product world because I was trying to talk and relate engineering and technical concepts to dollars all the time and upside. I'm excited to be here and I'm really looking forward to talking about platforms.
Rory Madden: Great. I'm just going to jump in while we're waiting for Ciara. Hopefully, she can join us but the first thing, just in relation to this. Platform is in the title. For platform can mean a lot of things to a lot of different people. So, I'd like to just throw it out there. What is your definition of platform? And I'll start with Henrik, because I guess with Minecraft, it might be a little bit different compared to some of the other answers.
Henrik Kniberg: Maybe. When I first saw the talk of this panel of like what is platform? Our product is platform. It's the same the 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, right? Minecraft itself where people are playing. But then the product is also a platform because people use Minecraft like a game mentioned to build their own stuff on it, mods and all kinds of community driven content. So, those are in a sense of different types of customers for us, that the players of the game and then the people who use the product to build their own things on top.
Rory Madden: I'll handover to Ciara now after this but Greg, do you want to give an update on what platform is in your context?
Greg Bell: We use that word to in two major different ways. One is Hootsuite itself we consider a platform which means that we have with public ideas. We have partners who integrate deeply and we have an app store where customers can buy apps that run within Hootsuite and so that's one aspect of our platform. And then we also have an internal platform so that's the other way we use that. The term which we have multiple products all in market. We developed an underlying platform technology platform that we utilize to deliver multiple different products. So, those are the two different ways that within Hootsuite, we use that term.
Ciara Peter: 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 Lindsey, did you have a chance to introduce yourself already?
Lindsay Silver: I did, yup. Onto the platform question and I actually think that Greg and Conde Nast view a very similar that we have a platform as an offering, as a flexible offering but also as the core underlying technology that powers the portfolio of applications that we have.
Ciara Peter: On that note, thinking about every company wants to be a platform, right? Like you might start with an initial product but it it's really about how do 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 say decide we're going to be a platform company and what was like the business driver behind that? Maybe Lindsay, could I ask you to start on that one?
Lindsay Silver: Yeah, I think that we, I mean, we had a big shift. So, Conde Nast's when we think about our platform, that the cornerstone to the platform is our content management system. So, we're an editorial company. We have a lot of editors creating content and so the big piece of technology that we started with the product that we started with internally was our content. It was building a proprietary content management system and when I started, which was about five years ago, that was the core product. For us, it was creating change and moving into platform thinking was definitely an explicit choice. And it took a lot it was change management internally to get people to go from thinking about one product to asking themselves what could that core product do that we weren't already doing with it and I think that that fundamentally is one of the big things. When you're thinking about a platform is starting from what you have but asking yourself what other values coming and, in our case, the second thing that the impetus for thinking platforming and how we thought was contextual advertising. And so, our same core content API is that then we're very editorially driven where a lot of content that editors had put into our systems, if we added things like NLP to those at that point then we could build an advertising, a set of advertising products on top of those as well. And so, organically when we started thinking like that, when we started thinking, "Okay, this can now but the same building blocks, we can create another product here." It really changed the culture and the thinking. And I think that's where you have to start, I think if you approach it the other way and say, "Oh, we want to have a platform arbitrarily. You get yourself into trouble and I think you see a lot of end user products that at first, they're very good and pure. And then all of a sudden have a marketplace on the side and all of a sudden, they have a community aspect and all of a sudden have all these things that aren't the actual purpose of the product, or just someone saying, "Okay, we have to find other uses for our brand or other uses for these. That's how we started now it's gone a long way since the but that is definitely how we started our thinking about ourselves as a platform.
Ciara Peter: That's great. Henrik or Greg? Anything you'd like to add on this one?
Henrik Kniberg: Well, I guess just from a game perspective, I really agree with the thing 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 a 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 so 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.
Greg Bell: Go ahead.
Ciara Peter: Go ahead, Greg.
Greg Bell: I was just going to say Hootsuite went through, I guess, a different but similar journey which is that we build technology for our marketing teams and marketing teams have 1,000,001 different pieces of software this day and age that they utilize to get their jobs done every day. And so, I've a necessity integrating those tools in a way that they can be useful together was just a clear opportunity for our organization. I mean, I guess, the other aspect is Hootsuite builds software on top of all the social networks, social networks have a really long tail of functionality. There's a long tail of social networks and a long tail of a functionality that we may not want to build ourselves. And we 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. And that has started happening pretty early on with it. As you know, Hootsuite is a 12-year-old company now. And so, pretty early on that became a core piece of the strategy.
Ciara Peter: It's really interesting. A lot of different inspirations or reasons for building a platform. I've heard on the core content side like sharing all of the technology that's available in one product. If you have a portfolio of products enabled like them then thinking about what's a marketplace and Greg in your scenario thinking about the marketing technology is table stakes to be able to integrate with all that. 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 and in their own driver's seat would love to hear, actually everyone, but maybe we can start with you. How do you plan a roadmap for platform given all this information?
Greg Bell: I'll try to answer that the two sides. There are two paths. I mean, 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 a constantly changing API with all sorts of different organizations that maybe are some are mature software teams that have great APIs and practices around those APIs and somewhere new fledgling social networks that may or may not care that much about their API. So, there's 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 KPIs and then similarly having been at Hootsuite for a little over five years spent a lot of cycles planning the public APIs that we're going to deliver. I would say also fairly challenging for us to create Roadmaps against mainly I believe it's more challenging to figure out the value that you're providing to organizations via public KPIs then then making it a user interface. We have tons of great relationships with customers who we can just speak to directly about, "Hey, you want this button to do this thing? We can build prototypes easily." Have customers go through it. We can learn from these ability testing when we're delivering API is all of that is more challenging to iterate on typically they're 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 they're expensive to make those changes and downstream developers don't want to make changes. So, I don't think there's any, I don't have any secret sauce in particular. I think 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.
Ciara Peter: Got it. Henrik, how about you? How do you and the team plan a roadmap for platform and alignment with all the products?
Henrik Kniberg: I would say there are a few driving factors. We're generally quite flexible with roadmaps. We don't generally set up like a five-year plan then it's measuring how we follow up but we do have high level goals though that we try to align towards and they're driven quite a lot by community because we work quite closely with our player community and creator community. And when we see things that they really need that makes their life better than that influences our priorities quite a lot. That's one aspect. What are creators are asking for is what do they need? But it's also balanced because every time we build something, we want to break stuff for people. Right? It's the same platform. So, we changed something. Well, somebody, someone, somewhere has built something that depends on the thing we changed and now broke. So, it's always a tradeoff, the community drives it, but then there's our own pet peeves like, "Oh, if we improve this in the platform, it'll make it or life easier. If you make this change, it'll be easier to add new entities or add new creatures and Minecraft, for example, then maybe we should invest in that." So, depending on what we're planning in the future, we might prioritize enabling technology for those features. So, things that make our life easier would of course influenced things and the third thing is just, what is the theme of our next updates? So, for example, just a few days ago, we announced the next theme for Minecraft is going to be mountains and caves. So, we're going to build grand mountains and huge cave systems. So, of course, then that will influence the priorities of our platform like we need to do some things to it to enable that to happen.
Ciara Peter: That's cool. I'm sure it would be very interesting. Just thinking as a designer, like 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?
Lindsay Silver: I mean, it's hard. I mean, for the reasons that that both Greg and Henrik mentioned that when we build something, I mean, what we always start with is this really big, obvious problem and with platforms, it's nice because when you to have a new big obvious problem that you can tie in or you can start building. You've got a place to start but then those really quickly factualize. And so, as we build roadmaps usually the first say quarter or first six months of our roadmap are very easy to me map out, but as we start getting, building a user base as the problem start to get smaller, the upside gets smaller and the number of problems gets bigger. It becomes hard and I think what Hendrick said is really important which is that you always are both looking for incremental change. And we were even building teams that are focused on incremental change. So, we'll have a change team that will just be basically 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 is there a fundamental change to the APIs or to the UI of our products that actually will solve the problem better in a foundational way. And I think people get into one or the other mindset and you have teams that are very focused on how can we disrupt? How can we change? And usually those people are the ones that walk away from a product the minute they've released the first version, then you get to die. And then you have people who are incremental change people. I shouldn't actually say people that there's a mindset that's incremental change and incremental change is easy once you get it, but it's a decreasing marginal value to those changes. After about a year or two and a product, you're optimizing such my new 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 on it.
Henrik Kniberg: 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 as hill and up on that mountain instead.
Lindsay Silver: And breaking that culture, I mean, that's what I think that good management, good leaders will always be pushing their teams to pivot one to one side or the other and that's what a lot of the guidance I give my teams is, "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 someone, I see someone running hard and going toward going out into left field, coming up with big ideas, I'll often not push them to say, "Okay. Well, what is your three-month roadmap? What is your near term? What is going to just basically improve your product or incrementally improve it?" That's hard. I mean, 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, you always have to step back and you always have to balance those two things in your head.
Ciara Peter: Thanks, Lindsay. Yeah, it's very interesting because as a product manager, often you're always thinking about what's the roadmap a quarter ahead, two, three quarters ahead. And 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 guys consider the main stakeholders in the platform? And 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, like what is the day in the life in the world with these platforms’ stakeholders? Anyone can?
Greg Bell: I can talk about probably our internal platform like many organizations have a platform engineering team and the platform engineering team actually has its management ranks have people who operate as a technical product manager and I wouldn't say that we do quite as rigorous of a job. I know we don't do nearly going to have a job as our proper UX research team. However, the version of a UX research that we're doing for that is actually all the other engineering teams. I think we have three platform engineering teams of which their customers are the 27 other scrum teams at Hootsuite and so following very similar, 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. So, we've taken a lot of those practices and just pointed to that, the problem is more about, well, our engineering teams being effective or 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. So, it's from an internal perspective.
Ciara Peter: Any other inputs from the panel?
Henrik Kniberg: 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 they're not maybe the primary customer for the platform stuff. We wouldn't change stuff in the platform for them primarily. We will build features for them. Right? 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. Well, one thing I think is really important when people work with platform stuff and very easy to forget. I want to put it up as a banner on the wall. Right? Which 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 we'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, customer segment are they involved in the development of giving you feedback? How do you know if you've succeeded with this? Because we tend to build so much junk, right? 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 with who needs this and why.
Ciara Peter: Lindsey, anything you want to add?
Lindsay Silver: No, I totally agree with that. I mean, 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 and it takes a little bit of like learning to love it yourself but I'll tell you the best products are ones that the engineers and the product people love being users of them. I think that's something that 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.
Henrik Kniberg: 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.
Lindsay Silver: Totally. Well, that's the difference. And I think that's a really true, I mean, 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 and trying to make 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.
Henrik Kniberg: The users don't like it but they're stupid. They don't get it.
Lindsay Silver: They don't understand it. That's right. That's always what we hear.
Ciara Peter: Thank you guys for sharing that insight. I want to just 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 like?
Henrik Kniberg: 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 but a term I like better is MLP, minimum lovable. I would like to try minimum testable. So, I tend to use those instead because I find them more concrete that's product committee, minimally 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 it's 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. So, that's why we use those in pretty much all companies that work with. I've tried to introduce those concepts. Sorry, what was actual question?
Ciara Peter: Is it possible to build an M blank P for a platform?
Henrik Kniberg: Definitely. Definitely. Yes. 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? We'll 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. So, maybe the team is like, "Yeah, this is viable." And then someone else is like, "Yeah, this is shippable. But wait a sec, the customers hate it but it's just the minimum viable and it gets really confusing." So, whatever terms you use, try to make it clear what they actually mean.
Ciara Peter: Got it.
Greg Bell: But that wasn't necessary that I would just throw in which is if you're building, being a platform for other teams to integrate to building that first integration as a part of the design process is a total necessary. I've just seen too many times the 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, the it guys don't actually support the integration."
Henrik Kniberg: Yeah. I'll probably use the term minimum integratable product in that case. Like what is that tiniest little thing we can do chip to somebody even if it's just a "Hello world" call to our API. But it's something to check that it works.
Lindsay Silver: I mean, I think that's the hardest thing we faced for sure. Is that minimum, whatever you call it, product often means go off and build it yourself in a silo to test it and what we end up with, I mean, almost every time and we've had some spectacular disasters that have come out of like, "Let's get really lean and let's build this, but let's not think about the API design. Let's not take it. 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 out if you want to stub in API end points. If you want to create a version of this, that's separate just for time's sake. That's fine. But you better have a plan for how it is integrated.
Henrik Kniberg: That's actually another empty pattern I've noticed when using this MLP, MVP, whatever incremental thinking. Is that, "Yes, we should be shipping a small step and not building it all in 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 integrate towards it.
Ciara Peter: 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, which is when does an organization meaning a company or part of the engineering and product division, when did they decide to call themselves platform versus a single product? Maybe you guys have some anecdotes.
Greg Bell: 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, "Okay, 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? And those are the only two definitions that I find myself trying to try to steer everybody towards.
Henrik Kniberg: I tend to avoid the word because it's on its own doesn't mean very much. So, instead try to talk about we are actually talking about instead of doing this vague catch-all word.
Lindsay Silver: It's such a weird, I think when Greg was describing earlier that he both is building a platform, sits above a bunch of platforms, right? In terms of what he's doing and probably having hacked Hootsuite’s APIs a few times myself. I know that people are building platforms on top of say, you sit in this weird world where you're always in the middle of things. And so, everything is a platform and nothing is a platform. I think at that point and it's a handy thing 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 build, 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.
Ciara Peter: 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.