.svg)
What do the Twillio’s, Stripe’s, Auth0’s, and Plaid’s of the world have in common?
Apart from their incredible valuations, all these companies have gotten one thing spectacularly right. Despite being fairly complex offerings, the time taken before a user starts to see value from using the solution is incredibly low.
And this (in no small measure) is because of the fantastic developer-friendly repertoire they have on offer. From well-architected microsites to splendidly put-together software development kits (SDKs) — these product owners and founders knew how important developers would be to their deployment and usage ecosystem and brought them along for the ride, from Day 1.
To do justice (and out of fear of our product teams) to the topic, we’ll focus this particular post on the role a dev microsite can play in your product-led growth strategy, how to get it right, and how our teams have cracked the code to building some of the most well-used dev microsites. We’ll cover SDKs in the next post.
Dev microsites are also called developer documentation, developer resources, documentation and resources, and so many other terms. But dev microsite just seems more suitable - no?
The truth: the fundamentals of running a lean operation means having to pick favorites, prioritizing ruthlessly, and sometimes putting certain things on the back burner. Let us tell you, and we learned this from some of the most successful serial entrepreneurs of our time: your developer microsite can't be one of the things you put on the back burner. So, at the risk of wasting precious digital real estate on something you already know, here’s a quick run-down of the benefits:
● When done right, a dev microsite is the chameleon of your product-led strategy: your sales collateral, your how-to-guide, your investor pitch expansion, and so much more.
● It reduces time to realization of value, by facilitating self-service and pre-emptively overcoming objections and roadblocks.
● When used well, it can shorten feedback cycles, and evolution cycles for the product itself.
● It drives up usage, exploration, and encourages expanding applications.
● It gives you a single, verified, straight-from-the-horse’s mouth point of truth to refer to at all times, removing unnecessary frustrations involved in long wait times, superfluous assumptions, and wasteful interpretations.
If you still aren’t convinced, here’s the rest of the article.
By nature, a dev microsite’s role in your product marketing journey is evolutionary. In early-early stages, it articulates value most comprehensively to investors and early adopters. In the early adoption stage, it shortens feedback lifecycles and convinces the skeptics. In the growth stage, it is a crucial cog in the brand manager’s playbook, an essential vehicle to drive retention, and a critical driver of product-led growth. In the later expansion and traction stage, it’s what recaps familiarity for the little guys, creates belongingness for the newcomers, and becomes the bedrock for your developer community, allowing and creating an organic space to naturally discover the next big thing for your product.
There’s a story that we often hear in the marketing world: about allowing user-led change to take its course. This one is about LEGO®, and anyone who’s been to any school for a marketing degree has probably heard the myth. As legend has it, in the early hyper-popularity phase of LEGO®’s life, some enthusiasts started using LEGO® blocks to go off the scripted path. Instead of building what’s on the box, they started getting really creative and building all kinds of new, never-been-done-before things. They posted videos of this on YouTube and those became viral.
This story is not unlike the Coke case study, it has been retold so many times, nobody quite remembers what really happened, but everyone agrees on this.
As LEGO® users got more and more creative with the building blocks, LEGO® had a couple of ways forward. They could “Cease and Desist”, claim the LEGO® trademark, and stop. Or, they could do what they did and build a whole co-creation community around this offshoot, productize it, and transform it into an experience by itself. Evidently, the latter path was taken.
What happened organically for LEGO® and was a strategic masterstroke in hindsight is yours to build proactively with your developer microsite, opening a communication gateway to iterative brilliance and shared experiences.
Absolutely not!
But do take the word of serial entrepreneurs who have had Andreessen Horowitz invest in them, who went from $0 to $26 million in valuation in under a year, or who raised over $70 million in the course of two years. Apart from having a product that nailed the problem-solution, they all prioritized the ease-of-deployment experience. Even when the products were incredibly complex, finding the right thing to do to get to a value always seemed simple.
We worked on their dev microsites through its various evolutionary cycles, and at different times, the microsites were a part of the user, deployer, and buyer journeys. We built these websites in parallel to the product and used different strategies based on how complex the actual exercise of deploying the product would be.
For a fairly complex Data SecurityTech product, our dev microsite came equipped with a sandbox for developers to experiment with the solution and get a feel for it. For a simpler-to-implement solution, it became a how-to-guide to get the most out of various integrations and capabilities of the solution. For a HealthTech client, it was built with reusable components to make it as close to the actual product experience, focusing on the simplicity of use and deployment.
● Build it parallelly to the product so that you have everything documented, pre-set, and already on a self-sustaining model from the first day. An example of someone who’s done this better than anyone else: Google’s API/SDK reference documentation. It’s set up so that they can deprecate/add new interfaces parallelly. The Google Android docs keep changing, and is one of our favorites to go to for inspiration.
● Pay attention and build your dev microsite architecture to mirror your product architecture: modular, scalable, and containerized. For this one too, we go back to Google’s clarity in doc setups. They're incredibly large, complicated, but are easy to scale and we can't imagine their developers waiting for their turn to release updates to these as they simultaneously work on so many, many things.
● Take the DevOps lessons to your microsite: ensure that developers are able to create, and move updates to deployment quickly, at which point, you have a pre-set auto-check and auto-publish protocol in place to ensure easy roll-outs. (Don’t forget to build provisions for roll-backs.)
One of our favorites here, Skyflow’s developer documentation. They are growing super fast, rolling out new capabilities at epic speeds to keep up with their speed of scale, and have independent teams who’re working on various aspects of their solution. And their dev microsite doesn’t miss a thing: because they use a tried-and-tested protocol that empowers individual dev functional units to push out their docs alongside their features.
● In the early stages, custom building isn't essential, so minimalist build solutions from Redocly, Changelog.md will work just fine. However, as your solution increases in complexity, being able to customize and use multi-media formats is going to be key to keeping the microsite relevant and current. Transition to a customizable, built from scratch system then to remove roadblocks.
We’ve learned this one the hard way so that you don’t have to: the branding requisitions around developer documentation is low in the early stages, and taking away resources from product build to custom build a developer microsite on a budget is unnecessary. However, as the product grows, sticking to that low-lift microsite and not evolving it can be detrimental and lead to longer buy cycles because, believe it or not, your developer microsite is a part of that buyer journey.
● Work with partners who can speed up build and deployment for these. For example, depending on product lifecycle stage and complexity, Zemoso has their own pre-built templates that we can easily customize, white label, and deploy for our customers.
More specifically, we have a microsite template with in-built mdx and API docs support. Any new customer can have their developer documentation up and running in three weeks with a sufficient amount of white labeling saving precious go-to-market time.
● Show, don’t tell where possible. Infographics, flow-charts, and intuitive symbolization are amazing and your developers will thank you for them. Ensure that visual representations match across your microsite and product user experience.
The best example for this one is, of course, Stripe. They offer an amazing developer experience with their sample apps for workflows and checkouts. This link shows a sample user interface (UI) with respective platform code within the docs, making dev life super easy.
● Don’t assume knowledge of niche tech terminology. A one-phrase explanation with a hyperlink hurts no one. A clear articulation of use case is your best friend. Leading with what a developer might want to accomplish and jobs to be done, as opposed to: how to do something will be transformational. And even companies as large as Visa, follow this rule. They have so many different fintech terminologies in their docs and they hyperlink each one of them to allow easy exploration, supremely helpful for developers, even if they’ve been in the space for ages.
At Zemoso Labs, we've made developer microsites and documentation a part of our engineering offering. Schedule a conversation with us today to learn more.
.png)
.png)
.svg)
.svg)
.png)
.png)
.png)
%20(2).svg)
.svg)
.jpg)
.svg)
What do the Twillio’s, Stripe’s, Auth0’s, and Plaid’s of the world have in common?
Apart from their incredible valuations, all these companies have gotten one thing spectacularly right. Despite being fairly complex offerings, the time taken before a user starts to see value from using the solution is incredibly low.
And this (in no small measure) is because of the fantastic developer-friendly repertoire they have on offer. From well-architected microsites to splendidly put-together software development kits (SDKs) — these product owners and founders knew how important developers would be to their deployment and usage ecosystem and brought them along for the ride, from Day 1.
To do justice (and out of fear of our product teams) to the topic, we’ll focus this particular post on the role a dev microsite can play in your product-led growth strategy, how to get it right, and how our teams have cracked the code to building some of the most well-used dev microsites. We’ll cover SDKs in the next post.
Dev microsites are also called developer documentation, developer resources, documentation and resources, and so many other terms. But dev microsite just seems more suitable - no?
The truth: the fundamentals of running a lean operation means having to pick favorites, prioritizing ruthlessly, and sometimes putting certain things on the back burner. Let us tell you, and we learned this from some of the most successful serial entrepreneurs of our time: your developer microsite can't be one of the things you put on the back burner. So, at the risk of wasting precious digital real estate on something you already know, here’s a quick run-down of the benefits:
● When done right, a dev microsite is the chameleon of your product-led strategy: your sales collateral, your how-to-guide, your investor pitch expansion, and so much more.
● It reduces time to realization of value, by facilitating self-service and pre-emptively overcoming objections and roadblocks.
● When used well, it can shorten feedback cycles, and evolution cycles for the product itself.
● It drives up usage, exploration, and encourages expanding applications.
● It gives you a single, verified, straight-from-the-horse’s mouth point of truth to refer to at all times, removing unnecessary frustrations involved in long wait times, superfluous assumptions, and wasteful interpretations.
If you still aren’t convinced, here’s the rest of the article.
By nature, a dev microsite’s role in your product marketing journey is evolutionary. In early-early stages, it articulates value most comprehensively to investors and early adopters. In the early adoption stage, it shortens feedback lifecycles and convinces the skeptics. In the growth stage, it is a crucial cog in the brand manager’s playbook, an essential vehicle to drive retention, and a critical driver of product-led growth. In the later expansion and traction stage, it’s what recaps familiarity for the little guys, creates belongingness for the newcomers, and becomes the bedrock for your developer community, allowing and creating an organic space to naturally discover the next big thing for your product.
There’s a story that we often hear in the marketing world: about allowing user-led change to take its course. This one is about LEGO®, and anyone who’s been to any school for a marketing degree has probably heard the myth. As legend has it, in the early hyper-popularity phase of LEGO®’s life, some enthusiasts started using LEGO® blocks to go off the scripted path. Instead of building what’s on the box, they started getting really creative and building all kinds of new, never-been-done-before things. They posted videos of this on YouTube and those became viral.
This story is not unlike the Coke case study, it has been retold so many times, nobody quite remembers what really happened, but everyone agrees on this.
As LEGO® users got more and more creative with the building blocks, LEGO® had a couple of ways forward. They could “Cease and Desist”, claim the LEGO® trademark, and stop. Or, they could do what they did and build a whole co-creation community around this offshoot, productize it, and transform it into an experience by itself. Evidently, the latter path was taken.
What happened organically for LEGO® and was a strategic masterstroke in hindsight is yours to build proactively with your developer microsite, opening a communication gateway to iterative brilliance and shared experiences.
Absolutely not!
But do take the word of serial entrepreneurs who have had Andreessen Horowitz invest in them, who went from $0 to $26 million in valuation in under a year, or who raised over $70 million in the course of two years. Apart from having a product that nailed the problem-solution, they all prioritized the ease-of-deployment experience. Even when the products were incredibly complex, finding the right thing to do to get to a value always seemed simple.
We worked on their dev microsites through its various evolutionary cycles, and at different times, the microsites were a part of the user, deployer, and buyer journeys. We built these websites in parallel to the product and used different strategies based on how complex the actual exercise of deploying the product would be.
For a fairly complex Data SecurityTech product, our dev microsite came equipped with a sandbox for developers to experiment with the solution and get a feel for it. For a simpler-to-implement solution, it became a how-to-guide to get the most out of various integrations and capabilities of the solution. For a HealthTech client, it was built with reusable components to make it as close to the actual product experience, focusing on the simplicity of use and deployment.
● Build it parallelly to the product so that you have everything documented, pre-set, and already on a self-sustaining model from the first day. An example of someone who’s done this better than anyone else: Google’s API/SDK reference documentation. It’s set up so that they can deprecate/add new interfaces parallelly. The Google Android docs keep changing, and is one of our favorites to go to for inspiration.
● Pay attention and build your dev microsite architecture to mirror your product architecture: modular, scalable, and containerized. For this one too, we go back to Google’s clarity in doc setups. They're incredibly large, complicated, but are easy to scale and we can't imagine their developers waiting for their turn to release updates to these as they simultaneously work on so many, many things.
● Take the DevOps lessons to your microsite: ensure that developers are able to create, and move updates to deployment quickly, at which point, you have a pre-set auto-check and auto-publish protocol in place to ensure easy roll-outs. (Don’t forget to build provisions for roll-backs.)
One of our favorites here, Skyflow’s developer documentation. They are growing super fast, rolling out new capabilities at epic speeds to keep up with their speed of scale, and have independent teams who’re working on various aspects of their solution. And their dev microsite doesn’t miss a thing: because they use a tried-and-tested protocol that empowers individual dev functional units to push out their docs alongside their features.
● In the early stages, custom building isn't essential, so minimalist build solutions from Redocly, Changelog.md will work just fine. However, as your solution increases in complexity, being able to customize and use multi-media formats is going to be key to keeping the microsite relevant and current. Transition to a customizable, built from scratch system then to remove roadblocks.
We’ve learned this one the hard way so that you don’t have to: the branding requisitions around developer documentation is low in the early stages, and taking away resources from product build to custom build a developer microsite on a budget is unnecessary. However, as the product grows, sticking to that low-lift microsite and not evolving it can be detrimental and lead to longer buy cycles because, believe it or not, your developer microsite is a part of that buyer journey.
● Work with partners who can speed up build and deployment for these. For example, depending on product lifecycle stage and complexity, Zemoso has their own pre-built templates that we can easily customize, white label, and deploy for our customers.
More specifically, we have a microsite template with in-built mdx and API docs support. Any new customer can have their developer documentation up and running in three weeks with a sufficient amount of white labeling saving precious go-to-market time.
● Show, don’t tell where possible. Infographics, flow-charts, and intuitive symbolization are amazing and your developers will thank you for them. Ensure that visual representations match across your microsite and product user experience.
The best example for this one is, of course, Stripe. They offer an amazing developer experience with their sample apps for workflows and checkouts. This link shows a sample user interface (UI) with respective platform code within the docs, making dev life super easy.
● Don’t assume knowledge of niche tech terminology. A one-phrase explanation with a hyperlink hurts no one. A clear articulation of use case is your best friend. Leading with what a developer might want to accomplish and jobs to be done, as opposed to: how to do something will be transformational. And even companies as large as Visa, follow this rule. They have so many different fintech terminologies in their docs and they hyperlink each one of them to allow easy exploration, supremely helpful for developers, even if they’ve been in the space for ages.
At Zemoso Labs, we've made developer microsites and documentation a part of our engineering offering. Schedule a conversation with us today to learn more.
What do the Twillio’s, Stripe’s, Auth0’s, and Plaid’s of the world have in common?
Apart from their incredible valuations, all these companies have gotten one thing spectacularly right. Despite being fairly complex offerings, the time taken before a user starts to see value from using the solution is incredibly low.
And this (in no small measure) is because of the fantastic developer-friendly repertoire they have on offer. From well-architected microsites to splendidly put-together software development kits (SDKs) — these product owners and founders knew how important developers would be to their deployment and usage ecosystem and brought them along for the ride, from Day 1.
To do justice (and out of fear of our product teams) to the topic, we’ll focus this particular post on the role a dev microsite can play in your product-led growth strategy, how to get it right, and how our teams have cracked the code to building some of the most well-used dev microsites. We’ll cover SDKs in the next post.
Dev microsites are also called developer documentation, developer resources, documentation and resources, and so many other terms. But dev microsite just seems more suitable - no?
The truth: the fundamentals of running a lean operation means having to pick favorites, prioritizing ruthlessly, and sometimes putting certain things on the back burner. Let us tell you, and we learned this from some of the most successful serial entrepreneurs of our time: your developer microsite can't be one of the things you put on the back burner. So, at the risk of wasting precious digital real estate on something you already know, here’s a quick run-down of the benefits:
● When done right, a dev microsite is the chameleon of your product-led strategy: your sales collateral, your how-to-guide, your investor pitch expansion, and so much more.
● It reduces time to realization of value, by facilitating self-service and pre-emptively overcoming objections and roadblocks.
● When used well, it can shorten feedback cycles, and evolution cycles for the product itself.
● It drives up usage, exploration, and encourages expanding applications.
● It gives you a single, verified, straight-from-the-horse’s mouth point of truth to refer to at all times, removing unnecessary frustrations involved in long wait times, superfluous assumptions, and wasteful interpretations.
If you still aren’t convinced, here’s the rest of the article.
By nature, a dev microsite’s role in your product marketing journey is evolutionary. In early-early stages, it articulates value most comprehensively to investors and early adopters. In the early adoption stage, it shortens feedback lifecycles and convinces the skeptics. In the growth stage, it is a crucial cog in the brand manager’s playbook, an essential vehicle to drive retention, and a critical driver of product-led growth. In the later expansion and traction stage, it’s what recaps familiarity for the little guys, creates belongingness for the newcomers, and becomes the bedrock for your developer community, allowing and creating an organic space to naturally discover the next big thing for your product.
There’s a story that we often hear in the marketing world: about allowing user-led change to take its course. This one is about LEGO®, and anyone who’s been to any school for a marketing degree has probably heard the myth. As legend has it, in the early hyper-popularity phase of LEGO®’s life, some enthusiasts started using LEGO® blocks to go off the scripted path. Instead of building what’s on the box, they started getting really creative and building all kinds of new, never-been-done-before things. They posted videos of this on YouTube and those became viral.
This story is not unlike the Coke case study, it has been retold so many times, nobody quite remembers what really happened, but everyone agrees on this.
As LEGO® users got more and more creative with the building blocks, LEGO® had a couple of ways forward. They could “Cease and Desist”, claim the LEGO® trademark, and stop. Or, they could do what they did and build a whole co-creation community around this offshoot, productize it, and transform it into an experience by itself. Evidently, the latter path was taken.
What happened organically for LEGO® and was a strategic masterstroke in hindsight is yours to build proactively with your developer microsite, opening a communication gateway to iterative brilliance and shared experiences.
Absolutely not!
But do take the word of serial entrepreneurs who have had Andreessen Horowitz invest in them, who went from $0 to $26 million in valuation in under a year, or who raised over $70 million in the course of two years. Apart from having a product that nailed the problem-solution, they all prioritized the ease-of-deployment experience. Even when the products were incredibly complex, finding the right thing to do to get to a value always seemed simple.
We worked on their dev microsites through its various evolutionary cycles, and at different times, the microsites were a part of the user, deployer, and buyer journeys. We built these websites in parallel to the product and used different strategies based on how complex the actual exercise of deploying the product would be.
For a fairly complex Data SecurityTech product, our dev microsite came equipped with a sandbox for developers to experiment with the solution and get a feel for it. For a simpler-to-implement solution, it became a how-to-guide to get the most out of various integrations and capabilities of the solution. For a HealthTech client, it was built with reusable components to make it as close to the actual product experience, focusing on the simplicity of use and deployment.
● Build it parallelly to the product so that you have everything documented, pre-set, and already on a self-sustaining model from the first day. An example of someone who’s done this better than anyone else: Google’s API/SDK reference documentation. It’s set up so that they can deprecate/add new interfaces parallelly. The Google Android docs keep changing, and is one of our favorites to go to for inspiration.
● Pay attention and build your dev microsite architecture to mirror your product architecture: modular, scalable, and containerized. For this one too, we go back to Google’s clarity in doc setups. They're incredibly large, complicated, but are easy to scale and we can't imagine their developers waiting for their turn to release updates to these as they simultaneously work on so many, many things.
● Take the DevOps lessons to your microsite: ensure that developers are able to create, and move updates to deployment quickly, at which point, you have a pre-set auto-check and auto-publish protocol in place to ensure easy roll-outs. (Don’t forget to build provisions for roll-backs.)
One of our favorites here, Skyflow’s developer documentation. They are growing super fast, rolling out new capabilities at epic speeds to keep up with their speed of scale, and have independent teams who’re working on various aspects of their solution. And their dev microsite doesn’t miss a thing: because they use a tried-and-tested protocol that empowers individual dev functional units to push out their docs alongside their features.
● In the early stages, custom building isn't essential, so minimalist build solutions from Redocly, Changelog.md will work just fine. However, as your solution increases in complexity, being able to customize and use multi-media formats is going to be key to keeping the microsite relevant and current. Transition to a customizable, built from scratch system then to remove roadblocks.
We’ve learned this one the hard way so that you don’t have to: the branding requisitions around developer documentation is low in the early stages, and taking away resources from product build to custom build a developer microsite on a budget is unnecessary. However, as the product grows, sticking to that low-lift microsite and not evolving it can be detrimental and lead to longer buy cycles because, believe it or not, your developer microsite is a part of that buyer journey.
● Work with partners who can speed up build and deployment for these. For example, depending on product lifecycle stage and complexity, Zemoso has their own pre-built templates that we can easily customize, white label, and deploy for our customers.
More specifically, we have a microsite template with in-built mdx and API docs support. Any new customer can have their developer documentation up and running in three weeks with a sufficient amount of white labeling saving precious go-to-market time.
● Show, don’t tell where possible. Infographics, flow-charts, and intuitive symbolization are amazing and your developers will thank you for them. Ensure that visual representations match across your microsite and product user experience.
The best example for this one is, of course, Stripe. They offer an amazing developer experience with their sample apps for workflows and checkouts. This link shows a sample user interface (UI) with respective platform code within the docs, making dev life super easy.
● Don’t assume knowledge of niche tech terminology. A one-phrase explanation with a hyperlink hurts no one. A clear articulation of use case is your best friend. Leading with what a developer might want to accomplish and jobs to be done, as opposed to: how to do something will be transformational. And even companies as large as Visa, follow this rule. They have so many different fintech terminologies in their docs and they hyperlink each one of them to allow easy exploration, supremely helpful for developers, even if they’ve been in the space for ages.
At Zemoso Labs, we've made developer microsites and documentation a part of our engineering offering. Schedule a conversation with us today to learn more.
.svg)
.svg){kind=small}
.png){kind=small}
