Unlocking the 'aha' moment: Developer relations for startups(signalfire.com)
signalfire.com
Unlocking the 'aha' moment: Developer relations for startups
https://www.signalfire.com/blog/devrel-for-startups
10 comments
Do you think developer focused startups are not profitable? Or do you think they aren't profitable without scale? And why?
No, I don't, but I think they're often riskier than a similar sized startup targeting broader B2B customers. The reason for that is that the charging model is often month-to-month or short term contracts (yearly renewal), the products are often something you can do without or can switch to a competitor easily (i.e. there's not much differentiation). It can be very easy for a competitor to come about and knock you off a peg very quickly. In addition, the 'nice to have' dev focused startups are things that can be easily cancelled with not that much of an effect on the bottom line of another business. Many dev-focused startups have their business with other startups primarily, so where there's a recession that might knock some of those out of business it can be fatal to your company if you're reliant on them for revenue.
This is good advice! I would like to propose a corollary:
If your main API function has multiple parameters, in the documentation example you need to use all of them, and absolutely do not shadow the parameter names! “foo foo = foo” might make your demo look slick, but the developer learns nothing. This is a lost opportunity to explain the parameters with the variable name instead of a comment.
I’ll give an example: RevenueCat’s demo for using SyncPurchases [1] returns a tuple of (value, error), and they throw away the error, not even showing the 1 line of how you have to typecast it. This results in much digging needed.
[1] https://www.revenuecat.com/docs/getting-started/quickstart#4...
If your main API function has multiple parameters, in the documentation example you need to use all of them, and absolutely do not shadow the parameter names! “foo foo = foo” might make your demo look slick, but the developer learns nothing. This is a lost opportunity to explain the parameters with the variable name instead of a comment.
I’ll give an example: RevenueCat’s demo for using SyncPurchases [1] returns a tuple of (value, error), and they throw away the error, not even showing the 1 line of how you have to typecast it. This results in much digging needed.
[1] https://www.revenuecat.com/docs/getting-started/quickstart#4...
> foo foo=foo
I hate those. I always make an effort to avoid using the same name for different things, e.g. MyParamName=MyValue indicates clearly that the two concepts are different and can be independently customized.
I hate those. I always make an effort to avoid using the same name for different things, e.g. MyParamName=MyValue indicates clearly that the two concepts are different and can be independently customized.
While we're on the topic of "Terrible "quick start" documentation, checkout the Wix Toolset "Getting Started" docs:
https://wixtoolset.org/docs/intro/
You learn how to install a tool, and then um, check it's installed?
Not a single example of how to run it, how to use it, or how to actually build a installer using WiX.
If you follow the links [1] you end up in reference documentation, the kind where it tells you a hundred different command line flags, none of which mean anything to someone getting started.
Ah, you realise you somehow skipped over "Tools and Concepts" [2]
Nope! That's just an empty header, which takes you to either a FAQ or jumping into "Burn bundles".
Like, all you want to know is, "I have console applications A and B, referencing library projects X, Y, Z, how do I put them in an msi installer?"
And the docs just don't provide that level of help.
By far the worst kind of documentation is this kind of "Technically correct" documentation, half-generated from doc-comments that might work okay as a reference for someone who has worked with the product and needs to remind themselves of a flag, but it's impenetrable otherwise. I don't miss the days when the whole of MSDN was like this.
As a bonus in the case of WiX, there was a huge breaking v3 to v4 change, so half of the guides / stackoverflow questions out there are for the outdated version. And the newer version appears to be maintained by a company that wants to monetise support.
Then mix in the .NET Framework / .Net core migrations on top, as well as installers being kind of old-fashioned compared to containerising everything, and it feels hopeless to try.
[1] https://wixtoolset.org/docs/tools/wixexe/
[2] https://wixtoolset.org/docs/tools/
https://wixtoolset.org/docs/intro/
You learn how to install a tool, and then um, check it's installed?
Not a single example of how to run it, how to use it, or how to actually build a installer using WiX.
If you follow the links [1] you end up in reference documentation, the kind where it tells you a hundred different command line flags, none of which mean anything to someone getting started.
Ah, you realise you somehow skipped over "Tools and Concepts" [2]
Nope! That's just an empty header, which takes you to either a FAQ or jumping into "Burn bundles".
Like, all you want to know is, "I have console applications A and B, referencing library projects X, Y, Z, how do I put them in an msi installer?"
And the docs just don't provide that level of help.
By far the worst kind of documentation is this kind of "Technically correct" documentation, half-generated from doc-comments that might work okay as a reference for someone who has worked with the product and needs to remind themselves of a flag, but it's impenetrable otherwise. I don't miss the days when the whole of MSDN was like this.
As a bonus in the case of WiX, there was a huge breaking v3 to v4 change, so half of the guides / stackoverflow questions out there are for the outdated version. And the newer version appears to be maintained by a company that wants to monetise support.
Then mix in the .NET Framework / .Net core migrations on top, as well as installers being kind of old-fashioned compared to containerising everything, and it feels hopeless to try.
[1] https://wixtoolset.org/docs/tools/wixexe/
[2] https://wixtoolset.org/docs/tools/
I feel your pain. I've been there. There's no dipping your toe into Microsoft developer things often. Footguns abound, but you can make money if you learn them all and then you're the only one who can do relatively simple programming tasks once you've pushed through all the nonsense!
Apple used to have the best developer relationships ever. You would get assigned an “evangelist,” who would act as your factor, within Apple. I think Guy Kawasaki was very involved with that.
The company I used to work for, did a very similar thing, with photographers.
These kinds of programs are really hard to represent as ROI, though, so they are hard to “evangelize,” within the company, so to speak.
The company I used to work for, did a very similar thing, with photographers.
These kinds of programs are really hard to represent as ROI, though, so they are hard to “evangelize,” within the company, so to speak.
Whenever I'd hire someone new into DevRel at DigitalOcean back in the day, they'd always ask to see my demo.
I'd spin up a droplet and ssh in. I never took the full 10 minutes in the demo's for conf's we sponsored. 1.5 minutes and you can go watch someone else more interesting than me.
Get to the aha moment and get onto the next group of potential customers.
I'd spin up a droplet and ssh in. I never took the full 10 minutes in the demo's for conf's we sponsored. 1.5 minutes and you can go watch someone else more interesting than me.
Get to the aha moment and get onto the next group of potential customers.
That's the importance of a good landing page or Readme.md
Tell me why I should care and assume I don't want to.
Tell me why I should care and assume I don't want to.
In the medium term, I expect developer focused startups to become less and less funded. Higher interest rates mean the landscape is very different and profitability is much more important much earlier.