- Sar's Scatter Brain
- Posts
- Demystifying the world of developer platforms
Demystifying the world of developer platforms
My chat with Ceci Stallsmith, Cofounder of Calyx
Today’s Scatter Brain is brought to you by Secureframe
Secureframe helps companies achieve SOC 2, ISO 27001, PCI, HIPAA, NIST, and GDPR compliance, fast. With their guided workflows and one-click integrations, Secureframe automates the compliance process so you can focus on your customers, closing deals, and growing revenue.
Secureframe helps organizations respond to RFPs and security questionnaires quickly with AI. Get compliant in weeks, not months. Thousands of companies like AngelList, Fabric, Doodle, Dooly, Lob, Slab, and Stream trust Secureframe for automated security and privacy compliance.
Click here to chat with the Secureframe team. Mention “Sar” during your demo to get 20% off your first year of Secureframe. Promotion available through December 31st, 2022.
Everyone thinks what they are working on is a platform! The word platform is used in many ways by different people. Many sell whatever they do as a platform because that sounds great and feels more fundable. Many use it to refer to their product or service. Many use it to counterposition against marketplaces. Many seem to believe you can just have a platform from day one if you just keep calling your product a platform. Many think that having APIs makes you a platform. Many think simply having more than one product makes you a platform.
To better understand the platform world, I reached out to Ceci, the cofounder of Calyx, a consulting firm that helps companies like Stripe, Zoom, WorkOS, Airtable, and Soucegraph build platforms. Ceci and her cofounder Paige Paquette helped build Slack’s platform.
In this conversation, Ceci and I talked about :
Her take on marketing versus communications
An actionable framework for what platform is and isn’t
Playbook to test the platform potential of a product
Organizational design to support platform strategy
Third-party development versus customer-driven customizations
Platform’s versus developers’ business interests
Enabling monetization for developers
Misconceptions and pitfalls in building platforms
Building a consulting firm
Ceci’s vantage point of having been an insider and now as a consultant made this chat quite clinical. In the end, Paige joins to answer a few questions!
Sar: Before discussing platforms, I want to touch on marketing and communications. You told me marketing is the weirdest function, and comms is the most unsung function at companies. Can you say more? Let’s stick to garden variety platform-less software companies for now.
Ceci: This is a conversation I keep having with founders! Look at all the other main functions at a company - sales, engineering, support - there is variation within those roles, but everyone generally gets what people are doing. Marketing, though, is all over the place. A product marketer, a growth marketer, and a brand marketer are three very different individuals! When you’re building a company - who do you hire first? A CMO won’t be able to roll up their sleeves and do the work you needed yesterday. You need PMM to help with positioning, but you need someone focused on demand generation because growth is the most crucial gap product marketing isn’t addressing. You also want to hire a content marketer, but now we’re talking about three full-time marketing hires, and that is too many people if you’re early stage! Marketing is a true hodgepodge - you have to be strategic about where to start and how to grow. I’ll add that many companies can succeed with very tiny (or even non-existent) marketing teams. The other tricky thing about marketing is that it can be super high leverage and an amazing function. Still, many successful companies don’t have marketing in their DNA, which isn’t a big problem.
Comms…oh comms. Comms people are the puppeteers behind the curtains. A comms person has strategically engineered everything you read about companies larger than 50 people. The amazing founder stories are groomed, prepped, and perfected by a comms genius. The narrative arc about how the software is entering the market at the perfect time, with strategic tailwinds, making all of our lives better - that is the work of comms (or specifically, this is the work of Ashley Mayer, making enterprise software sexy). And, for the most part, comms people are unknown. Except for a couple we follow on Twitter, you don’t hear from them much because they are making other people sound and look great. I felt this most acutely around Slack’s IPO - many teams worked tirelessly to make the event go well. We all praised finance, program managers, and execs. But very few paused to give comms a round of applause. That team probably spent weeks sweating every last word and detail, but they don’t often get thanked publicly. Also, if a grouchy reporter decides to have a spicey take, it’s the comms’ fault (even if it isn’t). Winning looks like the executive team doing an awesome job; failing looks like the comms team flopping. Their success is visible in the headlines, which is probably satisfying, but I am here to give them props.
Sar: I recently talked to Cristin, VP of Communications at Notarize. And she had a similar perspective on how the communications function is misunderstood and underappreciated. I see your point about marketing being a hodgepodge. Given how it can be a catch-all function, have you landed on a way of thinking about who your first few marketing hires should be?
Ceci: I chat with seed and series A companies about this a lot. I think it truly depends on your needs as a business. Look at your customer funnel, determine the biggest gap, and hire to solve that problem. I am *most* in favor of trying to hire a whip-smart, mid-level individual who can wear many hats (PMM one day, content the next, etc.) and isn’t too senior actually to do the work. This person is a diamond in the rough, so hire quickly if and when you find them!
On the flip side, as I mentioned, many companies can get very far with very little marketing because many marketing functions can be hired as consultants or freelancers. Once you evaluate costs, you can determine where a full-time hire is strategic versus freelancers & consultants to produce content, drive growth, or do comms work.
Sar: Let’s switch to your favorite topic now. “Platform” feels like something everyone wants to be, but most people can’t define it, and only a few understand. What is a simple, actionable definition of a platform? I sense you build a thing that people use, and then you enable other developers outside of your company to build new things on your thing and help them acquire customers and make money. We don’t want to be platform police and say it is this very narrow thing for a specific audience, but we are talking about successful developer platforms here.
Ceci: Yes, platform is an extremely overused word. One of my first investments was in a company called Readme.io; the CEO/founder is a delightful human and made a t-shirt with a toaster saying, “I’m not a toaster, I’m a platform!”. There are different types of platforms. I break them down into two buckets.
Platform = ecosystem. You build a thing people use; your platform gives developers, and partners access to those users (via APIs+ and an App Store. APIs+ means APIs, webhooks, etc.).
Platform = very useful tool, or suite of tools, that enables developers to build. The word tool can sound diminutive, but let’s be real, we all understand what it means, and it’s okay for something very ubiquitous to be a tool. Stripe or Twilio are great examples here. They have developer ecosystems, too, but their main offerings are APIs that enable developers to build superior products. I think the word platform here is in question, but many people use it, so let’s let them continue.
What isn’t a platform? I have a hard time calling stand-alone software that isn’t easy to integrate with other products a platform. I usually work on ecosystem work in platform-land - opening a product up so that it can become a platform others build on. And yes, everyone calls themselves a platform because everyone has a little set of APIs, even if hardly any developers use them. Every company wants to be the center of the wheel, with all the other software existing as a spoke, but not everyone can be the center. At a certain point, the market will tell you whether you’re the platform everyone builds on or the company with APIs that builds integrations with the other platforms to acquire users. It’s okay to be the latter! This is also a strategy for growth!
Sar: I like to think of all of this in terms of the extensibility of the software and where that manifests. If you take software and add APIs to extend its utility in someone else’s software, that’s just partnership work. A good example is ATS integrations with HRIS systems. How you define platforms is using APIs to extend the utility of the core product within itself by third-party developers. What do you think?
Ceci: Love it. Nailed it. Yes.
Sar: I wonder if it is realistic or practical to have serious platform thinking from the earliest days. Is it even possible to do that when you barely have a product or have a good product but not a lot of adoption yet? When do you think companies should start considering whether they have platform potential? I’m sure it’s an art, but can you share your rubric for thinking through the optimal signs to look for?
Ceci: I love this question because the answer is…it depends! Slack is my favorite example. Slack built the first 50+ integrations that our customers used. The company was “built as a platform” from day 0 because the people building it were developers, and they wanted Slack (the product they were using all day) to be integrated with the other products they used all day (developer tools, the google suite, and a couple of other apps). Integrations were native to the Slack experience because the founders built the product for themselves and wanted it integrated.
Platform ecosystems are flywheels. This is kind of my favorite thing to talk about. Building a platform grows the company if you have a good product-market fit and there’s a need/opportunity for integrations with other products.
How early should companies start thinking about their potential platform? I would argue that it’s useful to think about how you open up APIs from the early days.
It will make your product more scalable even internally as you build it as a team - this is obvious, but it’s faster not to API-everything. But, if you grow, you’ll likely get to a point where life would be easier if you had built APIs for the various functions of your product.
If you wait too long to build an ecosystem, you often miss out on growth and get entrenched in your primary product function. I have seen a lot of companies that want to build or improve their platform offering, but the effort is consistently deprioritized. As a result, they miss out on making that flywheel spin. When it’s not spinning, it’s hard to justify the platform effort.
Developers aren’t dying to build with you, and if you want to win them over, you have to show them, over time, that you are worth their effort. When you’re unproven, and this hasn’t been a focus for your company, you have to win developer trust, which is hard and takes time.
So, not everyone can be a platform, but it’s not dumb to build APIs for your product, and there are many ways to open them up safely. You’ll also be surprised by how your users want to leverage your APIs (even more than 3rd party developers) and can find strong customer growth by enabling customization through a “platform” (aka, having APIs and webhooks).
Sar: Ah, you suggest a crawl, walk, run approach. It’s beneficial to have internal APIs driven architecture from the early days because that’s a better way to scale for the internal teams. That creates the option of opening up some APIs to your users to start testing the waters and seeing how your users can get creative. And then, you can take the last and final step of becoming a platform by attracting third-party developers who might want to reach and build for the platform customers. So it’s a gradual approach with learnings at every step.
Ceci: Yes - exactly. Ecosystems are named after the ecosystems that occur in nature. They should grow organically, as any ecosystem in nature does. So, build what you think users want (ask your users what they want, then build that), and if it thrives, continue! I think this is the most organic approach and safest play.
Our consultancy is named Calyx to evoke the concept of nature being core to ecosystem work! (A calyx is a term for whorl outside a flower before it blooms. It turns out that this is also a popular name in the rapidly growing cannabis industry. : shrug:)
Sar: Ha, I meant to ask you the backstory behind your firm’s name! Anyways, I'm curious about how teams should be structured after the decision to make a long-term investment in platform efforts. Is it a standalone cross-functional team? Is it all spread out across functions of the core product? How should we think about the trade-offs?
Ceci: I have seen it both ways at different companies! They all can work (a lot depends on the culture and power dynamics!).I personally like the GM model most - have a GM of the platform and bucket product, design, partnerships, marketing, developer relations, and engineering under them - or some subset of that group so that critical mass all reports to one person who holds the vision and has executive sway. That said, the platform team spread across an org can work as long as the CEO/leadership believes that the platform is strategic and critical to growth. If you don’t have CEO-level buy-in, this effort will get shunted quarter after quarter, and you won’t see much progress.
Sar: What are your thoughts on how to make the business case for leadership buy-in? Who typically makes the case and owns it? What are the common pitfalls?
Ceci: One of the fun things about consulting, and working with many growth stage companies on platform work, is that I get to see this play out across various companies.
The strongest case for a platform is usually made by the product team, with business development’s strong buy-in. The most winning approach always includes an executive who wants to hang their hat on the platform’s success and will budget resources and headcount towards the effort.
Common pitfalls: I have mostly worked with companies where leadership believes in the platform vision - so I might not know the answer here! It often doesn’t work out when there isn’t an executive accountable for the platform result if the platform effort is a rag-tag team without executive representation. Sometimes the person who sparks the platform initiative is an IC, and their willingness to let the platform be “owned” by an executive with a team can make or break the success of that platform.
Sar: I feel like not having executive buy-in on an ambitious project is a mistake everyone should make at least once early in their careers. It is one of those fundamental experiences that inform your worldview on how to pursue new ideas internally!
It is tempting to treat developers working on your platform as a monolithic group. Talking to you helped me understand the importance of distinguishing customers using a platform to build customizations for themselves versus third-party developers building apps for a platform’s app store or marketplace. Can you expand your thinking on that?
Ceci: When you get third-party developers/partners to build for an App Store, you get lots of useful but often not customizable apps that your customers can go and install to enhance their experience of your product. This is excellent; more value for customers, and developers get more users. But there can be downsides. These are
If the developer is not well known, some customers may not have enough trust or validation to believe that the app is safe. This can block larger or security-conscious customers from using smaller-brand apps.
Some customers have specific needs, and the out-of-the-box integration may not work for them. This particularly applies to integrations with highly custom and usually data-heavy systems. Out-of-the-box integrations with Salesforce or data tools are often not well adopted because every company uses Salesforce in its special way. One size cannot fit all.
Your customers can use your APIs to build their own integrations (or whatever they want to build, sometimes just workflows on your own product!) This is a huge win. Why?
Customers building custom integrations == extremely sticky customers. It is much harder to churn when they’ve built to your product. They are invested.
This grows your developer ecosystem in a new, powerful way. The more developers know your APIs and get involved, the better. Someday the developers who built the custom apps will change companies, and if they had a good experience, they would suggest doing it all again.
Worth noting 2nd party developers are also a thing. This is when you get consultancies, system integrators, etc., to build integrations for your customers. Lots of fun upside to this motion, as well. Consultants make $$$ building for your customers, and your customers get a more bespoke experience of your product, making it stickier.
Sar: How do you recommend considering the trade-offs in the platform’s and developers’ business interests?
Ceci: Honestly, I think this is very simple. When building an ecosystem, all that matters is adding value to the customer. This sounds kind of developer un-friendly, but it is true. If you make way for developers to acquire customers on your platform, they will often deal with sub-par developer experiences to access those customers. Creating a best-of-breed experience for customers will make your platform effective. I don’t know if you can decouple the “platform” and the “customers” - if you don’t open up useful parts of your product, then customers won’t find your platform valuable. So those two go hand in hand.
Sar: Right. Are you implying that effective platforms err on customers’ side when taking popular third-party offerings and making them first-party, native features if they believe it’s a better customer experience? This is a dynamic that all platforms eventually run into. Slack had to make these calls as well. Developers don’t love that, of course.
Ceci: This is the catch with building for a platform. The most recent interesting platform drama in this category has been around Shopify. It is naive, as a developer, to build on a platform and not expect the platform to compete with your offering to some degree. This is inevitable. The job of the developer is to be nimble. The platform is big and slow. The developer has to get ahead of it, understand what’s coming, and adapt strategy before the platform gobbles them up.
If they want to do business with extra integrity, the platform’s job is to warn developers when their features will be duplicated. This allows the developer to respond, trying to create more/new value before their integration becomes obsolete because the platform now offers it natively. Inevitably some apps get crushed. RIP iOS flashlight apps.
Sar: Talk about how to think about monetization and how to help developers make money building on a platform. If we look at the social media world, YouTube got so right early on that they understood the importance of enabling creators to make money and figured out a scaleable business model. Are there similar learnings for the developer-centric platforms?
Ceci: Ooo, hot topic.
Your developers must see a path to making money on your platform. If they don’t, they will leave, and you won’t have a platform.
The path to monetization can be direct - e.g., your platform facilitates a transaction - or through enough user growth that developers can monetize on their own.
When you offer native monetization, your platform will generate your business revenue so that you can prove the value of the platform internally. This is excellent and very obvious, but many platforms do not offer monetization and spend a lot of time and effort trying to prove the platform’s value (e.g., it reduces user churn, drives expansion, etc.). Measuring both direct revenue from platform efforts and these less-directly-causal impacts is critical. Especially in enterprises, the latter can have huge customer benefits and grow your active usage significantly.
Native monetization comes with a lot of developer nitpicking and is an ongoing strategic conversation. Just look at the iOS App Store tax conversation. Developers don’t like paying the platform tax, especially once your platform is huge and making a lot of money.
This is a high level. We could do an entire deep dive on this topic alone.
Sar: What are the most common misconceptions about building platforms?
Ceci: The first is that partners will want to build your API. When it comes to larger partners, they likely won’t want to build the app or maintain it. This takes heavy BD work. The second is that platform work will automatically grow the business. You must work hard to make customers aware of and happily use apps/integrations. You can kill your platform accidentally if you don’t do this work. A lot of people ignore this step; it’s critical.
Sar: Let’s go back to the marketing function. How does marketing for core products differ from marketing for the platform? How does all of this vibe with developer relations and communication functions?
Ceci: This is a tricky question because it’s up to the individual company to decide how to differentiate platform versus core product marketing! However you set up your organizational structure, your app store is practically secondary to your core product. Whoever markets your platform has to work with all the other marketers to ensure that platform messaging is woven throughout, and the app discovery is part of each key user journey.
Platform Marketing and Developer Relations should work in lockstep. I often think of Platform Marketing as air cover, brand, messaging, and Developer Relations as boots on the ground, practical implementation, and the voice of the customer. I have found that Comms works to help convey the platform message - but I see less challenge here, as the comms team works across all of the GTM functions.
Sar: Let’s switch gears and discuss what you are working on now. How’s the consulting experience been so far? I haven’t ever seen someone specialize in consulting on platform work for companies before. What were the early days like? Do you miss being focused on just one platform at a time? How do you absorb the organizational context needed to have an informed perspective?
I adore consulting. We are unique in our offering - there aren’t a lot of platform strategy & marketing people in the world yet - which means we are a rare commodity, so we’ve gotten to be very choosy, which is fortunate. I don’t know how, but when we decided to start Calyx, we immediately landed Twitter and Airtable as clients, so this just took off from day one. I honestly love the variety of consulting work. I have some clients I’ve worked with for years, so long-term relationships are in place, but working on new problem sets at different organizations is fun and refreshing. I love working with companies at every growth stage - you don’t get to do this when you’re at one company full time.
I got accredited as a coach at Slack, so I think picking up the organizational state is something I learned through that process. It’s also something I groove on, trying to figure out what dynamics are working well and where there are challenges and gaps. When you’re an outsider, it’s often a little easier to see the cracks, and people are more willing to share openly. Usually, the downside of consulting is that you don’t have a consistent team, but my business partner is one of my favorite people and a total joy to work with, so we do a lot of our work together.
Sar: Any advice for people who are considering consulting?
Ceci: I’d say try to book your first client before you even really know that you want to consult! Try it on! That’s the fun of consulting; it’s a very light commitment. You can do a short project with a client just to see if it’s a good fit for you - you don’t need a website, special credentials, or anything - you just need time and the skills to deliver what you sign up to do. I guess this is similar to my platform advice - see if there is some product market fit, try to find a client or two, and if there is, let it grow!
Sar: Is there anything you are closely following that you don’t think is making progress fast enough? It doesn’t have to do with anything we have talked about,
Ceci: The community category is interesting. Huge bets have been placed in this space. I help companies grow developer communities, so I believe community is a real unlock for growing a business. I think the software being built here is good, but I have many questions about how it is differentiated from CRM. If I were building in this space, I’d pivot hard into becoming a modern CRM with community elements layered on effectively for different parts of the business to leverage. This space should have evolved more rapidly, given the dominance of Discord, Slack, etc. I also feel like this is similar to the “everyone wants to be a platform” dilemma - everyone wants to have a community, but individuals cannot spend all of their time in online communities - a lot of success is figuring out whether or not you’re the going to host the community or market into other pre-existing ones.
Editor’s note: Ceci’s cofounder Paige joins us to answer the next set of questions.
Sar: You run the consulting firm along with Ceci. I’m curious about what digital tools you use and how you think about the operations of running the business.
Paige: Our business is simple, and so is our operating model. We’re not an agency. We conduct our services in person or via Zoom and use standard SaaS accounting software. I also use Calendly, Slack (shared channels for each client are game changers), Webflow, Docusign, Miro for collaborative client sessions, and Substack as our blog/newsletter. A simple CRM through Coda. 1Password for everything. It’s as simple as that!
Sar: Have you had moments where you felt like your time at Slack is hurting your ability to think a certain way or adjust your advice for clients? Slack is an outlier story, and I think it’s easy to overfit or over-index on things that are not replicable.
Paige: Every startup is different - even the same startup looks like an entirely different company every six months when things are moving quickly.
While frameworks or rules of thumb from previous experience can be helpful starting points, it’s important to take a first principles approach to new problems. When thinking about a GTM approach, you need to deeply understand (and talk to!) the users – their pain points, jobs to be done, worries, motivations – to nail down what they desire from a product or how to reach them with marketing. This deep understanding of the user is the foundation for all the next product and marketing decisions. And that deep understanding, in my experience, needs to come from actual conversations, not assumptions or rote Google searches.
Sar: Outside of the world of platforms, what else are you closely following these days?
Paige: I’m most interested in companies trying to solve real-world tangible problems. Climate tech is big. Healthcare is a huge one – specifically, I’m curious about startups addressing issues like mental health, women’s health and fertility (i.e., Oath), and elder care/family caregiving support (i.e., Carol)
Recent conversations :
Click here to chat with Secureframe team. Mention “Sar” during your demo to get 20% off your first year of Secureframe. Promotion available through December 31st, 2022.