35 min
It’s hard to find a hotter trend in Silicon Valley than the idea of turning your product into a platform. And it’s not without good reason: nearly all software products with dominant market share started as apps but grew to the point where third-party developers began building valuable integrations on top of what these companies had already created. Turning your product into a platform that developers can build on is a great way to tap into new audiences and expand your market share. But that doesn’t necessarily mean you should take the leap blindly, simply because it’s popular at the moment.
Over the past year, we’ve had great conversations with some of the top minds in platform development, and these talks have had an enormous influence on the way we think about extending the Intercom platform and building out our App Store. In today’s episode, we’re featuring the best parts from those chats. You’ll hear from:
- Slack’s Director of Platform Marketing, Ceci Stallsmith, on defining a platform and measuring success.
- Box’s Chief Product Officer and Chief Strategy Officer, Jeetu Patel, discusses migrating to the platform mindset.
- New Relic’s General Manager, Mark Weitzel, weighs in on how you can support your developers.
- Former Head of Marketing at MadKudu, Liam Boogar-Azoulay, on ensuring you value customers and partners.
- VP of Facebook Workplace, Julien Codorniou, explains why they want to be the ‘Switzerland’ of IT departments.
To hear each of these conversations in full, check out episodes of our podcast. You can also subscribe to the show on iTunes, follow us on Spotify or grab the RSS feed in your player of choice. What follows is a lightly edited transcript of the episode.
Ceci Stallsmith on how to define a platform
What is a platform, anyway? With any hot topic in the startup world, it’s helpful to start by establishing terms. In this case, Ceci Stallsmith likes Bill Gates’s – a platform occurs when the value of the stuff built on top of your product surpasses the value of your product by itself. If you can create a scenario where others are building on top of your product – and therefore evolving it in ways you may not have the resources to do yourself – your offering suddenly becomes even more valuable to your customers. Here, Ceci unpacks her thinking for Intercom’s Group Product Marketing Manager, Jasmine Jaume.
Jasmine Jaume: Obviously Box and Slack are both strong platforms. And platforms are kind of a hot topic, right? Everyone wants to be a platform at the moment. What makes companies like Box and Slack real platforms versus just products that have kind of great extensibility, and why do you think it’s important to their business strategy to actually become a platform?
Ceci Stallsmith: This is one of my favorite topics. I think everyone likes to call themselves a platform, but I think “platform” is one of the most overused words. It almost loses its meaning. You’ve been working in platform too, and at a certain point it’s like if everyone’s using this, does it mean anything anymore? I think it’s important to figure out what the heck platform means, and what is a platform and what is not. When I was in Venture, you’d meet with at least 20 founders every week and talk about their products, if you weren’t actively doing a single deal. You’d meet with these tiny companies, and they’d be like, “We’re more of a platform.” And we’d be thinking, “No one knows you and who you are. How are you a platform yet?” So that is something I care about a lot.
“Bill Gates actually defined a platform as the point when the value of the stuff built on top of your platform surpasses the value of your product by itself”
I think it’s tricky. Not everyone can be a platform if the nature of platforms existing means that some products have to be built as extensions of the platform itself. I also have a theory that platforms beget platforms. One of the good ways to identify what is a platform versus what isn’t is to think about what really is one. Windows: that was a massive platform. Still is. iOS, Facebook, Salesforce: those are true platforms.
Bill Gates actually defined a platform – and this is a pretty high bar; I don’t think many people have met it – as the point when the value of the stuff built on top of your platform surpasses the value of your product by itself. That’s quite a high bar, but it’s what I like to strive for. The litmus test is if you’ve created a marketplace: are people actually building on your product because there’s value that you’ve created, or is it just a nifty integration? For instance, you build an iOS because you know you’re going to get users through it. Same for the other big ones that I talked about.
But there is this other area of developer tools: the Twilios and the Stripes of the world. Those are big amazing companies. But are they platforms? Stripe definitely has a marketplace, but I also know that Stripe is just a really useful product that I want to plug into my own product that I’m building to help transact money. Twilio, I need it for text messages. So those are developer tools for sure. Are they platforms? I’m not sure. And then how you know you’re not a platform comes down to if there’s any value in integrating with your product, or do you need to be doing all the integrations so that your customers get value versus having partners and developers wanting to come and build with you? That’s how I look at it a little bit.
“When people build more stuff on top of your product, then your product is more useful to your customers all of a sudden. And that just gives you more product-market fit and helps you grow faster”
Jasmine: Should companies all be trying to become platforms, even? It’s fashionable, but do you think there are times where it makes sense to actually start trying to build that value and times where it just simply doesn’t, and you should just stay as a product?
Ceci: It’s tricky because the answer should be yes. The reason why you’d want to pursue being a platform is because it makes your value as a company – as a product – that much greater. The upside of having this big two-sided marketplace and extending your product into tons of different products with an API is quite large. It increases your products company’s multiple, in terms of valuation, quite a bit. Having a platform makes you more useful. I have this thing I’ll be putting out soon about the platform flywheel, and one of the reasons why platform is so useful is because when people build more stuff on top of your product, then your product is more useful to your customers all of a sudden. And that just gives you more product-market fit and helps you grow faster.
If there’s the opportunity to be a platform, great. On the flip side, developer time and mind share are precious. It is not worth trying to go pursue building a developer community if there’s not actually value there for them. You can kind of fake it for a couple of years, I think. It’s very doable to figure out how you can win some developer interest over by trading good things in return. But at the end of the day they’re going to see through whether or not you’re adding real value to them. Marketing can only go so far, basically. And getting paid to develop something can only go so far. So, I do think a big part of figuring out whether this is not a strategy for your business is asking, “Do I actually have something of value to give to developers?”
That is what matters to me. That’s why, when I saw the Slack opportunity, I just had to go. It was just too cool, because there was such value being added to developers from early days, and there was so much developer demand before we had an actual platform for third party developers to build on. That’s why I thought, “Oh, this is going to be a true platform instead of something that people think will be a platform someday.” It’s fine not to be a platform, too, but obviously it’s lucrative to be able to develop one.
Everyone wants to be the center of the wheel. And the truth is, I think in each generation, in cycle of technology, you only get a couple major ones that have a significant, lasting impact on the industry. And that’s why, when I list off Windows, iOS, Facebook, those are some of the biggest names. They shaped the industry because they figured out how to build a platform. And it’s interesting with iOS, Steve Jobs didn’t even want to build a platform, but that turned out to be a great thing.
Jeetu Patel on migrating into a platform mindset
In the summer of 2015, Box co-founder Aaron Levie recruited Jeetu Patel to create an open platform where developers could build Box content management into their own products. Box Platform, which now includes more than 175 partners, has exponentially grown the company’s addressable market. But how – and when – did they decide it was time to move into a platform mentality? As Jeetu explains to Adam Risman, it was about finding new ways to create value for users on top of what had already been built.
Adam Risman: When you’re a product builder who’s first beginning to open up your platform, as it was the case for you when you got to Box, how does the mindset of the product team have to change? What type of transition did y’all have to make to become a platform company?
Jeetu Patel: That’s a really good question. When you’re an apps company and you start thinking about building a product for a particular audience, you tend to have a tremendous amount of clarity on the use cases that you’re going to serve. You typically tend to curate a very thoughtfully built experience for those use cases for that particular audience, and then you direct people to use your product in that way.
“A majority of the innovations that we’ve seen our customers build, we had never imagined when we were building the platform”
With that model of taking an apps business and importing it over to your platform, the biggest cognitive dissonance that happens is, you don’t start out with a very predefined, prescribed set of use cases. You start with a baseline infrastructure and framework that people build on top of. That is the biggest mind shift you have to make, because a majority of the innovations that we’ve seen our customers build, we had never imagined when we were building the platform.
Adam: Box was quite large at the time it made this transition, but for a smaller startup, looking around the corner, how do they know that they’re both a good fit, and ready for a platform play? What boxes do they need to check to set them up for success?
Jeetu: As you’re building a startup, the thing you think about is this: any category-dominant leader that’s built a disproportionate value and market share compared to their competitors has not just built an apps business. They’ve also built a platform business. What I mean by a platform business is you’ve got data in your system that other developers are using to create additional value on top of what you’ve provided to them. And that creates a discontinuous leverage effect within the ecosystem. You’re no longer bound by the innovation velocity that you might be able to deliver to the market; you’re actually compounding that value because everyone else can go out and build on top of the data that you have.
“Over time companies that want to dominate certain categories will need to think about building a platform”
Over time a lot of companies that want to dominate certain categories or have a category leadership position will need to think about building a platform. But the way that you do it is in multiple stages. So for example, if you look at our journey at Box, we started out as an app that had some pretty basic capabilities – how do I take a file, put it in the cloud, and share it with people both inside and outside my organization? From there we actually built some enterprise capabilities that customers wanted around governance and compliance. Very quickly we found that we should make sure that we give people the ability to work with Box content regardless of the application they’re working in.
“Make sure you have the discipline of being an API-first company”
The first thing we did to become a platform company was back in 2008, when we said, let’s open up our APIs to third-parties to integrate with us. And in fact, phase 0 was we had built out a pretty robust set of APIs. All of our capabilities that we had built ourselves were built on top of APIs, rather than being built directly with calls onto our core engine.
So we had abstracted with a set of APIs and RESTful services, and we then opened up those APIs for developers to integrate with us. Over time what you started seeing was that customers, as they were deploying Box, wanted to do some scripting and make sure that they can do some customization. They wanted to use Box in a certain way, or they wanted to go out and do broad based deployment and user provisioning, and they wanted to dry write a quick script as an admin. So our APIs started getting used for that. And then, very quickly, customers started coming to the conclusion of, “Hey, I love what Box brings to the table, and there’s a bunch of apps that I’m building, which I also want to have the same level of rich content capability embedded in, with the same level of compliance and security. And I don’t want to refigure that out every single time I build an app. Would you folks be able to white label the app, or white label your product with a set of APIs and have the right identity models, so people don’t have friction.”
We started with something very basic, but we were true to the principle that we have to build a company that’s API first. You might be an apps company today, but make sure you have the discipline of being an API-first company, because you never know when, for your business model, it will actually make a lot of sense to create leverage by building a platform, and building a set of APIs that people can build on. If you do plan on building a multi-billion-dollar company, chances are you’re going to want to make sure that you deliver ways that the data you have can be compounded and valued by what other people do on top of the data. And that requires having a platform mindset.
Ceci Stallsmith on how to build a platform and measure success
To establish Slack as a true platform, Ceci Stallsmith’s team took a threefold approach by creating the Slack Fund to invest in developers, creating a launch strategy and story, and driving adoption by making life as easy for developers as possible. Then, there’s the issue of measuring success – which is hardly straightforward. Ceci sees adoption as the top metric to look at, followed by overall developer activity and app quality. Here, Ceci gives Intercom’s Group Product Marketing Manager, Jasmine Jaume, a few things to look for when judging triumph or failure.
Jasmine Jaume: When you joined Slack, what were the other things you did to start getting the platform off the ground?
Ceci Stallsmith: I got to go through a really fun platform journey. When I first joined, we actually didn’t have APIs that worked for third party developers very well. So we had to essentially take the API and turn it inside out like it was a sweater. But it’s a technical sweater, so that took awhile. I joined, and then we did this big event figuring out how to set the APIs up so that third parties could use them and got those out, one by one. Then we created the marketplace where people could have their app listed, thinking, “Oh, that could be a valuable place to be found as a developer or to find apps as a customer.”
One thing was that we actually created the Slack Fund. The focus was investing in this ecosystem that we thought would be really successful. It’s gone really well, and we’ve made a lot of investments. We have someone full-time who actually does the job of making investments from the Slack Fund, which shows a lot of commitment to that. A lot of companies say, “We have a fund,” but no one manages it, and they do two investments to start, and then they never pay attention to it ever again. But we really have one, and we invest out of it, which is really cool.
Another thing, when I first started, was to create a launch strategy and to create the story of our platform while we have it. Some of those pieces we did early on are still some of my favorite work I’ve done at Slack outside of hiring the team that I’ve hired (because I love them, and they’re the best people ever). But creating that story was really fun. I actually got to put out this blog post about that Bill Gates quote I mentioned. He said: “If you all win, then we win. So we’re here to help you win.” And it was cool to see that resonate in the community. From there, it was driving adoption like I mentioned: making life easier for developers, figuring out how to make our APIs more usable, creating different things that would scaffold these APIs so that people could use them. And then on the product marketing side, what was fun was thinking about how to market APIs, how to market developer products. You do this a good bit, too; usually you’re thinking about how to get a customer to adopt something and click a button now more often.
“Adoption of the apps that are built on your platform is the top measure for success. It’s also the hardest one to get to”
It’s really fun to product market something where you’re like, “Here’s all this stuff you could build with this.” And so since I joined, we’ve been just opening up different parts of our UI and different parts of our product to give developers access. For example, when you hover over a message in Slack, there’s a three-dot button where there are more options to take an action on a message, which means if I want to send a message to Jira, I can do that. There are all these different things we’ve been exposing in our product to give developers more access to our customers and to make their products more useful for our shared customers. It’s been really fun figuring out how to market those things really simply.
Like for enterprise marketing, you have to think, “What does the CIO care about? What is the itch they need to scratch?” Often, it’s about security and fear. But with developer marketing, it’s, “How do I sound the least like a marketer as possible?” I’ve never really seen myself as a marketer, so that’s what’s been fun in this role and working with the team that we’ve built to do this. We’re kind of like marketers who love being marketers but don’t want to sound at all “marketingy.” So I’ve worked to create a style that we use that’s straightforward, to the point, but kind as well and has a little bit of Slack’s playfulness. That’s been really fun.
And then the last thing – if I were going to bucket all the stuff we’ve done – is figuring out which big partners to go to market with and how. We’ve had a lot of fortune in terms of landing really big partnerships for Slack. But the way I always look at this is kind of like this huge school of fish. There are some fish that are really, really big. And then some fish are really small. And you’re sort of a middle fish. And when you partner with one of the big ones, you need to figure out, “When I come up with a really big partner, what is that going to communicate to the market?” Because they have a very significant brand, and they have an audience. And when you partner with that brand and that audience, it rubs off on you. What are they trying to get from our brand when we do this partnership, from a marketing point of view?
This actually does impact your platform. The smaller fish or smaller partners will see the big partnerships that you’re doing and react to them in different ways. For instance, if there’s a partner that does the same thing as some of your up-and-coming partners, you need to figure out: “How do we not step on toes? How do we create separate swim lanes? And then how do we get what we want for the company from a marketing point of view?” That’s especially relevant around the PR that comes out and the blogs that you’re going to write. It’s hard, it’s nuanced. It’s more like a comms job. Again, that’s what makes this role so fun, because there are so many different elements, and you have to really grab onto the brand pieces and be like: “Okay, this company plays really well on these channels. We’re going to go hang out in those channels with them. Or we need to watch out for these pieces because that will not reflect well.”
Jasmine: We’ve talked about your partners’ success and your success, but how do you actually measure it? This is something we’ve struggled with Intercom, and other people I’ve worked on platforms at different companies also find it difficult. How do you actually measure the platform?
Ceci: I’ll just start with the anti-answer: not tokens. Because so many companies say, “We’ve had 1 million developer tokens generated.” That means nothing! It’s meaningless metric. I could go click “Generate token” all day long and generate 300. I’m pretty passionate about figuring out success metrics. They were also hard. At Box, they were a lot easier in many ways, because with Box you store files, share, comment – but there were fewer pieces to the puzzle, I guess. Slack is a more complex product in that there are so many things you can do with it.
I’m going to get to what the actual metrics are, but I’m going to tell stories first. For instance, there are a number of apps that just send information into Slack. They’re called notification apps. For instance, there’s one for Twitter that just sends you a tweet in Slack if you subscribe to someone’s tweets. That’s a really basic integration. Is using that integration valuable to customers? Yes and no. There are certain channels that were set up a long time ago, and someone set up a notification from some product into that channel and that channel is just a dead channel that gets random pings all day. There are other channels where you set up an integration with any product that can give you an update on a project status, and it’s actually super valuable. Watching your competitors’ tweets – that’s actually valuable. You don’t always click the tweets or to click the notifications coming in, you just read them.
It’s tricky to know how to measure success, exactly. All that said, as I’ve been banging this drum I’ll just keep banging it. Adoption of the apps that are built on your platform is the top measure for success. It’s also the hardest one to get to. It requires completing the platform flywheel, and it’s difficult. It’s usually also something that happens after you’ve really started to spin the whole thing up because you have to win the developers and partners over, you have to get them to build with you or build the integration for them. You have to then do the marketing to launch those things and then you have to watch, and try to get that adoption to happen. So it’s a slower metric to track.
Mark Weitzel on how to support your developers
New Relic believes that every developer is created equal. That’s why they’re striving to be a more open company that’s contributing to open source, consuming open source and engaging in open standards. To get there, they’ve developed a set of ethics to guide their culture. Here, Mark Weitzel runs Intercom’s Head of Platform Partnerships, Jeff Gardner, through those values.
Mark Weitzel: At New Relic, we try to establish a set of guiding principles, because so many people – so many teams – interact with our customers. The first one we laid out was this notion of all developers being equal. All developers are created equal. That’s the idea that you create a platform, and whether you’re a New Relic employee or a customer or a developer at a partner, you’re using the same tools. You’re using the same APIs. There’s this notion of equality across the platform.
Jeff Gardner: So you guys advocate really for having your internal teams dogfooding, using those APIs to build everything they build for your own internal product.
Mark: Yeah, absolutely. That’s our goal. This is a guiding principle, and let’s be honest with each other: sometimes these are tough to adhere to. Making software isn’t always pretty. But if you establish that principle, it starts to establish a discipline of separating out the platform, which gives you the ability to adhere to API contracts, which gives you the ability to evolve and move faster. The more you are self-consuming, dogfooding, drinking your own champagne or whichever euphemism we want to use, the stronger your platform ends up becoming.
Another guiding principle for us is that we’re striving to be a more open company that’s contributing to open source, consuming open source and engaging in open standards. We joined CNCF about a year or so ago. We did that so we had a way to engage the community at a different level, bring some of our thought leadership and learn from other companies that are there. So we’re working to be more open, and we favor working openly where we can. That doesn’t mean we’re going to open source everything, obviously. But it does mean we’re going to try to engage more openly.
The last one – and this is one that’s really, for me, the most important one – is that working with New Relic must be joyful. You have to have that sense of accomplishment. Think about the first 20 minutes when you think, “Oh, I want to go try something,” and all of a sudden it works. You’re like: “Wow, I did that! That was awesome. What’s next?” You get that excitement, and you feel like you’re being productive and driving value to the business in a new and unique way. That’s a joyful experience. That’s the energy and excitement I want New Relic’s developer program to instill in every person that touches our API.
“We’re here because we all have this love affair with software. We’re all passionate developers, so making that a joyful, exciting experience was a no brainer”
Jeff: Ceci Stallsmith mentioned something similar in the sense that you’re trying to make the process simple and easy and effortless for the users of the platform. But you also are there to instill some of your brand and your personality into the relationship. It sounds like that’s exactly what some of these principles are driving towards.
Mark: That’s exactly what those principles are driving towards.
Jeff: Great. You guys obviously have a strong set of principles here to start with. But how hard was it to get to those? Was there a ton of internal debate? Was it an exec-level thing? Was it at ground level with the team deciding that amongst themselves? How did that play out internally?
Mark: It’s really interesting. There was really no debate about that last one. We’re here because we all have this love affair with software. We’re all passionate developers, so making that a joyful, exciting experience was a no brainer. It’s almost like stating the obvious. Like we talked about, building software’s hard. Deciding, for example, if we should open up an API that we use proprietarily – those are hard decisions.
Jeff: They’re hard calls.
Mark: Yeah, building software isn’t always the prettiest thing. So there was a lot of debate about that. What does it mean to have everybody created equal? And what does it mean to consume our own platform? We had a lot of discussions about that at multiple levels of the organization.
Jeff: And in the end, you guys came to a common understanding of what “created equal” means, and what openness looks like and that sort of thing?
Mark: We did. And this is part of our journey as a maturing developer platform, as engaging our community more. These are guiding principles, and we strive for those principles. We’re not always perfect, but this is what we’re striving for.
Liam Boogar-Azoulay on valuing your customers and partners first
Businesses exist to make money. But you can kiss success goodbye if you’re putting yourself before your customers and partners. That’s why it’s essential to determine whether your product is ready to be a platform at all. As Liam Boogar-Azoulay tells it to Intercom’s Director of Content, John Collins, some products should think about integrating with existing platforms and growing their reach that way instead.
John Collins: What is your advice for other product teams or startups that are trying to build integrations and trying to get this off the ground really quickly? When should you think about integration and who to choose to integrate with early on?
Liam Boogar-Azoulay: That’s a really good question. I think you have to think about a lot of things. Over the past nine moths or so, we’ve been building a lot of relationships with different platforms that we felt like had complementary aspects, and we felt like we could both benefit from working together.
“For us, in the world of customer intelligence, Intercom plus MadKudu makes a lot of sense”
We learned that you have to think about a few different things. One, you have to think about the use cases you’re trying to solve for. And less is more, in this case. Where are you trying to add value, and what are the tools people are using to do that today? And are you augmenting, or are you replacing that tool? For the most part, you should be augmenting, because the foundations that work are our foundations for a reason, and instead of ripping up the foundation, it’s better to build something on top of it. Build a better roof, a better floor. Things like that. And the other side of that is you have to think about, “Who is using that use case?” For us, we’re very mid-market and enterprise. We’re not a self-serve, go-to-market company. And so, for products that are solely self-serve (and solely SMB or very small business), it can make less sense for us to go after it, right? You have to weigh the pros and the cons of who is actually going after it and who that target audience is. And the last thing is just thinking: “What is the vision that you are driving for? And in your vision of the future, where your product is ubiquitous, what are the roles of other platforms? And how can you demonstrate and create evidence of that vision through integration?”
For us, in the world of customer intelligence, Intercom plus MadKudu makes a lot of sense. We see very much how customer engagement and customer data is going to live somewhere together and customer intelligence is going to augment that value. We see how we can be pulling data from outside of Intercom, because we know people use multiple tools across their marketing and sales tech stack and the whole go-to-market stack. We see how we can take that customer data from your Redshift database, from Segment, from wherever – and we can bring that right back into where your marketing, your sales and your customer success teams are working. And you don’t have to bring it in the form of piping in the raw data and the raw fields; we can just pipe it in with a “thumbs up, thumbs down” or “very good, very bad.”
When you’re building integrations and thinking about the ecosystem you want to play with, you really want to ask, “How does this communicate the vision that we’re trying to bring to the world?”
Julien Codorniou on creating a seamless platform experience
Being a platform does you no good if the user experience is clunky and convoluted. As Julien Codorniou explains to Intercom’s Director of Content, John Collins, that’s why the Facebook Workplace team wants to be the “Switzerland of IT departments”: the plug-and-play destination that connects flawlessly to the other apps you’re already using and helps you discover new ways of working efficiently.
John Collins: One of Facebook’s strengths as a company is its platform, which allows third party developers to come in and create their own applications and services that access Facebook data. You worked on the platform team – was that the vision in the early days?
Julien: It was the vision of Facebook, but the vision for Workplace is actually very, very different. We do have integrations with some apps. We have a marketplace today with 50 applications, but the truth is that we want Workplace to be the app that will be connected to every other app you’re already using. Usually these apps are Office 365, G Suite, Box, OKTA, Netskope, Salesforce, etc.
We want to be the app that will be like the Switzerland of IT departments, making every other app work better together in a way that is integrated and mobile friendly, while Workplace becomes the place of discovery and distribution of what’s happening in other applications. For example, at Facebook, we use Quip, which Salesforce acquired. When I wake up in the morning, I don’t open Quip.com or the Quip app on my phone – but I do open Workplace, and in a group with my team someone will have shared a document in Quip (or a link from quip). So we’ll have a nice preview of that document in Workplace, and we click on it, it will take me to Quip.
“We don’t want to be on that journey alone; we want to build an ecosystem and foster and stimulate a very vibrant Workplace economy and a Workplace ecosystem”
I think that’s the type of partnership and user experience we want to give to our employees and clients. It has to be so easy, so simple, so integrated that you don’t even feel you’re going from one app to another, and I think the News Feed on Workplace does a very good job of driving the discovery and the distribution of other applications. My goal is to make sure that if I look at the top 100 SaaS, all of them are natively integrated with Workplace. It’s not an open marketplace for everybody; it’s a closed highly curated marketplace where you will find the most respected SaaS companies and the most used SaaS applications in the world. It’s very different from what we did with Facebook.
What’s similar, though, is the ambition to build an ecosystem – to build a Workplace economy – of service integrators, of resellers, of ISVs, of independent developers building apps for their colleagues, employees or customers. But that’s what we’re heavily investing in, and we have a big partnerships team now working from PWC to companies like Revevol in France, Enablo in Australia and Paychex and Slalom Consulting in the U.S. We don’t want to be on that journey alone; we want to build an ecosystem and foster and stimulate a very vibrant Workplace economy and a Workplace ecosystem. That’s very similar to Facebook’s core principles.
Happy platforming!
Original artwork by Kyle Smart.