The Platform Story: Part 6
Previously on…
Is this thing still on? Excellent. Sorry about the layoff for the last couple weeks. It turns out it’s been pretty difficult to choose where to go next with this story, and that’s led to a bit of paralysis.
That paralysis then resulted in a series of false start articles (false starticles?), each just marginally less boring than the last.
Dear reader, please know: if this still ends up being boring, it wasn’t for any lack of worse ideas.
The usual disclaimer
As always, it’s important to keep in mind: this is one company’s journey from one person’s perspective. A lot of it has been seat-of-the-pants, and a lot of it has been driven by constraints of time, industry, roadmap, and headcount.
This issue’s big lesson
This time around, there are really two big takeaways: don’t forget to step back and look at the whole picture, and always bias toward impact.
For example, if you’re constantly thinking one sprint ahead, you might neglect something that’s going to take a month of lead-time until it’s two weeks out in front of you…
…but if you haven’t mapped out what impact you were hoping to get out whatever thing you might have missed, taking a step back won’t matter in the first place.
And that’s all fine as an abstraction, but below, I’ll try to unpack it into a handful of mini-lessons sourced from our actual platform launch. If you’re short on time, it’s all collected at the bottom of the article in a nice handy “tl;dr.”
Anyway…
We’ve built a fully functional ecosystem 🎉
After roughly a year of platform development since first opening our API, Frame.io has:
- A developer portal
- A partner marketing site section
- A docs hub
- A native Zapier app
- A Spectrum community forum
- A growing presence on Glitch
That’s a lot of stuff to keep track of. At first, you’ll want to do what you can to stay on top of everything. Then you’ll burn out. Then a couple things will drop off (see: Whale of Mediocrity). Then your team will grow, and you’ll rebalance; lather, rinse, repeat.
What’s difficult is remembering to poke your head up, look at the full battlefield, and make sure everything is fitting together in a way that’s both scalable, and coherent.
The developer portal + v1 marketing site
Before we had a fully designed, lovely, useful, standalone site, we had a scrappy, function-over-form panel shoehorned into our main app’s admin area.
Pros: it worked, it was good enough for early adopters, and it kept us moving.
Cons: it looked like hot butt. Seriously, look at this v1 wireframe:
But it was enough for us to get to a soft-launch at IBC in 2018, which was a serious statement of intent as we started to engage our first real partnerships a build momentum toward a big go-live the following April.
The v1 marketing site
This was good and pretty, but not very functional — basically an email capture that prompted us to put potential users on a hand-maintained mailing list.
The big go-live
When we did finally go big with our “official” API launch at NAB in April — 6 months after our soft launch, and 10 months after opening our first endpoints — the reception was awesome. We did a blog post and a marketing video. We had a special “API Bar” at our booth. We had speaker sessions highlighting integrated workflows with some of our partners. We won an award.
The actual work here involved going through a full site design process, and for lack of a better phrase, taking things seriously.
Takeaways
I’d make the same opening move here ten times out of ten. By finding a sort-of-hidden surface (admin pages) and low-key stuffing things in there, we were able to skirt almost all of the non-essential parts of our SDLC, diverting all of our attention to security and functionality. In other words, we quickly built a stable foundation… knowing full well we’d have to rebuild all of it.
Tl;dr: in your early days, bias toward impact at the expense of debt.
Marketing site
Fun fact: if no one knows about it, it doesn’t matter. As a bonus, when the work you’re doing is heavily technical, workflow-based, and not immediately obvious in the core ecosystem of your product, marketing is a crucial piece of the puzzle.
In my case, I feel extremely lucky to have gone through this whole launch cycle with an organization who understood that implicitly, because I didn’t really at the time; but certainly do now.
From launch to relaunch
Step one of the marketing puzzle was a grid of launch partners sitting just below the fold on our developer portal. Hover state, links out, but all hard-coded and no real landing pages.
Step two was latching onto a marketing site relaunch, and ensuring our partners had dedicated landing pages.
Takeaways
I really wish I’d made time to tackle this stuff a little earlier. By the time we started taking partner marketing seriously, we were massively short on resources to manage it, and instrumentation to justify the resource needs. While not impossible to navigate, that’s a tough combination.
Tl;dr: start thinking about partner marketing on day one.
The docs hub
When you’re opening up a platform, every scrap of impact backs out to usage, and (nearly) every scrap of usage backs out to someone reading your documentation.
We started with one provider, and after about a month of work, chose to cut everything over to another. Skipping a few details, the cutover ultimately led to the research and subsequent development of Rolodex, an OpenAPI generator for Elixir’s Phoenix framework.
Pros: writing workflow guides is a great way to learn your own world while building developer empathy, and Rolodex was a critical step in democratizing documentation completeness and quality in our backend org.
Cons: writing docs is really time-consuming, and the effort of Rolodex — while important — locked down some pretty important engineering resources while we were in the middle of a fairly scrappy phase.
But hey, we’ve ended up in a pretty good place! Below is a guide written by our first dedicated Developer Relations hire, which includes links out to code samples, a usable app, and other related guides.
Takeaways
I don’t love any of the common SaaS solutions for API documentation and guides, but I’m glad we pivoted as quickly as we did, and I’m reasonably happy with where we are now. But I do wish we’d been able to get a head start on Developer Relations a bit earlier — now that we have dedicated lane for it, we’re seeing how (in some ways) we’ve created a jagged developer experience, and we’re scrambling a bit to catch up with ourselves.
This story plays out in our traffic metrics, too. Marketing will give you spikes, but a comprehensive content plan backed with solid developer advocacy gives you traction, and through it, sustained growth.
Tl;dr: remember that your docs ecosystem is its own little universe, and create a dedicated lane for developer relations as early as you reasonably can.
All the other stuff
Native Zapier App
I’m just gonna get this out of the way right now: I’m a huge Zapier fanboy.
For the uninitiated, Zapier is a webhook mediation service that facilitates shunting event-driven data around over 1,300 common (and not-so-common) software products. In short, Zapier makes is easy to extract integrated value from a variety of different solutions without writing code.
In our case, we started working on a native Zapier app for Frame.io in late 2018, built up a solid beta audience, and went public ~4 months later.
We’ve invested quite a bit in our app, but Zapier makes it pretty easy to stage your work so your effort is always justified by measurable results. In other words, as a platform developer, it’s a gold standard strategic platform.
Tl;dr: If Zapier seems like a good idea, just do it. It’s a small starting commitment, and the value could end up being huge.
Spectrum.chat forum
Spectrum is neat! It’s a forum site that focuses on new and emerging technologies or startups, and developer-to-developer communication. It was an obvious enough need and good enough solution that they were acquired by Github practically before they were able to get off the ground, so…there’s that.
We fired our forum up right around our soft launch, and now that we actually have a solid on-the-ground developer advocate (read: not me), it’s growing in users, engagement, and quality.
Tl;dr: give your community a place to chat! But also don’t forget to post there yourself.
Glitch
Glitch.com is a little hosted app harness that we’ve been using for reference apps. It’s pretty solid, but we’re not quite sure yet if there’s a clear line between our work there, and external developer success. It follows that there should be value, as it’s basically code samples on steroids; and my gut is that without Glitch, we’d be looking at a clunkier version of the same solution with more dependencies, and a higher technical lift for the end-developer.
The lesson: stay on top of new sites and tools in the wider developer community. There’s fun stuff out there!
Tying it all together
Tl;dr wrapup
For convenience, here are all the little “tl;dr” wrapups from the article above:
- In the early days, bias toward impact
- Think about partner marketing on day one
- Remember that your docs ecosystem is its own little universe
- Create a dedicated lane for developer relations as early as you reasonably can.
- If Zapier seems like a good idea, just do it. It’s a small starting commitment, and the value could end up being huge.
- Give your community a place to chat! But also don’t forget to post there yourself.
- Stay on top of new sites and tools in the wider developer community. There’s fun stuff out there!
And finally…
You’re creating an ecosystem — don’t forget to look at it!
As you start flying into a multitude of surface areas, you’re going to have to work extra hard to stay on top of what everything is, and why you’re doing it.
I’ve found it helpful to actually grab some flowcharting software and map it out. For example, it wasn’t until I mapped out our universe that I could clearly articulate that developer enablement is the bridge that turns customer demand into customer success.
More on that next time.
As always, thanks for reading, and happy platforming.
Previously:
- Part 1: Orientation, and the problem statement.
- Part 2: Background and goals.
- Part 3: Expectations.
- Part 4: Risk and measurement.
- Part 5: Choices, mistakes, and lessons.
Coming up:
- Part 7: Your tiny universe.
- Part 8: The partner pivot.
- Part 9: Keep your head in the game.
- Part 10: TBD…
