I'm really excited to be here.
Thanks, everyone, for coming.
My name is Cole Krumbholz.
I'm the product and engineering lead
for the developer platform at Squarespace.
I was also the founder of a Heavybit company
called Brace.io a couple years back.
Today I'm going to be talking about
developer product design and, more specifically,
some lessons that I learned from shipping
almost a dozen developer-focused products
over the last few years.
I'll just jump right in.
This is a list of some of the developer-focused products
that I worked on over the last few years.
It's really a wide range of APIs, command line tools,
services for developers, and a lot of different verticals
from physical mail to email, A/B testing, static site deployment, really a wide range of things.
I think, in the course of shipping those products,
I learned a lot.
But there are a few things that
I wish that I had known going in.
Some things that I think would have really helped me
save some time and really focus on
what was important up front.
Developer Product Design
These are the top four questions
that I would have liked to have answered for me
and that I wish that I had been thinking at
at the beginning of pretty much
every product that I worked on.
Does my value prop make sense to developers? I'll spend most of the first half of the talk
talking about this.
We're going to dig in here and talk about: Is your product is a developer product? Or, potentially, what would it be like
if it was a consumer product?
Do developers have influence
in the market that you're trying to target?
Does my value prop resonate with those developers? Finally, will developers in the developer community
trust me and trust the product?
I'll focus on that for the first half and then we'll invite up the panel
and we'll dig in to some of these other questions.
Who is my customer really?
Try to get a high resolution image
of what your customer is.
How do I learn from my customer?
And finally, how do I know if I'm succeeding or not?
Let's go ahead and get started.
Know Your Users
If you are a developer working on a developer product,
I think that you've got a bit of
a double-edged sword to contend with.
On the one hand, you have the power.
You understand developers,
and you have the ability to create products for developers. You really can get started right away.
But I also think that, as a developer
working on developer products,
you have some biases that you have to contend with. For one thing, even though you're a developer,
you're actually just one kind of developer.
And the developer, especially the developer community today,
it's very diverse. The term "developer" is somewhat vague.
As a startup founder or
a developer working on a startup company,
you're actually pretty different
from the majority of developers out there
who may be working at bigger companies.
In addition, as a developer
we all love to use the products that we create.
Our tools always have that special
sort of emotional attachment. But at the same time,
the people that we're developing products for
have the same thing going.
They also love the things that they create,
which don't happen to be the things
that you're creating, necessarily.
And so you have to overcome that "not invented here" bias.
If you don't necessarily know your developers
as well as you think,
and the developers that you're creating for
are less inclined to want to use
your software than you expect,
then you have to really be careful to ensure
that the product you're creating creates
real value for developers.
How do you do that? The product-development gospel is
that you have to get out of the building,
you have to go talk to users.
And it's absolutely true.
You have to go out there.
You have to meet them and you have to find out
what their story is, what their context is.
But I think that talking to users, especially developers,
can be a bit confusing.
Developers may have some ulterior motives that you may not expect for signing up for your product.
Maybe they love the technology that you're working with.
Maybe they're just curious about what you're doing
and how you're doing it.
Maybe they're competitors.
I think there are a lot of different reasons why
developers out there may sign up for your product
that might not have to do with what you care about,
which is that they have a problem
that you're trying to test.
As a result, you can launch your product
and if you market it well,
you may have several thousand developers sign up for it.
And you may feel like
you have market validation because of that.
But it could also possibly just be part of
the Silicon Valley echo chamber.
Developer vs. Consumer Product
Even before you start talking to customers,
I think there are a few questions
that you can ask to ensure that your value prop
really makes sense to developers.
The first one is whether your product is a developer product.
Have you considered what it would look like
as consumer product?
Here's a list of companies we're pretty familiar with.
On the left side you've got developer-focused products,
and on the right side you have
the corresponding consumer products.
And these are the mail industry,
telephony and payments.
If you look at the two different columns,
the thing that differentiates them on the left side,
you're really looking at companies that
at the end of the day are targeting
enterprise customers or bigger companies.
Even though these tools are available
and any developer can come and use them,
oftentimes they're making their money
off of those bigger customers,
not hobby projects or smaller startups.
If you look at Twilio, for example,
one of the first customers that they promoted
were Sony Live Music and also Tumblr.
Those are some pretty big customers.
On the other hand, on the right side,
you've got companies that are targeting
much smaller companies or small businesses,
and they tend to have a lot of customers.
For example, Paypal, some of the first customers
that they were successful with were eBay entrepreneurs,
and they didn't have a developer platform
for, I think, five years,
is roughly how long that took.
In short, if you're building developer products,
I think you should be really thinking about
bigger customers or enterprise customers.
That can mean prioritizing features
that aren't necessarily that intuitive
to developers just trying to scratch their own itch,
things like team features or permissions.
On the other hand, if you are just scratching your own itch
and you're focusing on small businesses or startups,
it's worth asking whether a consumer product
might have broader appeal, actually,
and if you're holding back or limiting
some of your initial customers
because you're focusing on developers.
Developers as Influencers
Let's assume that we're past that.
You're focusing on devs
and you're interested in enterprise at the end of the day,
the next question is, "Are developers influential
in the product-making decision in your market?"
I think typically this is pretty obvious.
Things like payments, dev ops, transactional emails,
these are all things that developers care about
and they're influential on the decision making process.
But sometimes developers can get excited about something
and nobody else is listening.
I think this is the case when
developers aren't the end user of a product.
For example, let's consider something like print on demand.
We're talking about postcards, fliers, maybe invoices.
Today, the major players in this space
are still consumer-focused,
things like Vistaprint.
And I don't think that's for lack of trying
by developer-focused companies.
There've been a lot of startups, actually,
that have tried to tackle this print-on-demand industry.
Companies like MailFinch, Chirply, my own
Sendspree, Sincerely, and recently, Lob,
which I think is doing a great job.
But it's a difficult market, and it's taken a lot
to try and tackle it. I think that's because, traditionally speaking,
developers are not the ones responsible
for sending the emails.
At the end of the day, it's often office managers
that have to send this mail.
And so those office managers,
their needs are the ones that tend to drive
the purchasing decisions.
Another industry is A/B testing.
I think that may be similar.
Developers may care about this
and may have to help set up an A/B testing suite.
But it's the analysts or the strategy team
that oftentimes end up running the experiments.
And so it's their preferences and needs
that ultimately drive the purchasing decisions.
I think one goal you can have
to help sidestep that potential problem
is to make your product part of the customer's core product.
Or as a corollary, if it's not a problem that has to do
with the customer's product,
then perhaps dev tools aren't the right solution.
I think developers have the most influence
over core product decisions
and less influence over other parts of the business.
Making Your Value Prop Resonate
All right, so, you're making an enterprise product. Developers are influential in your market.
The next question is, "Does your value proposition
resonate with those developers?" I think, in order to answer this
you have to ask what service your product provides.
Not necessarily what you are making,
but what service are you providing?
And I think the answer shouldn't be
that we reduce the amount of code
that developers have to write,
because developers love to write code. It's their job.
Instead, I think you have to be able to articulate
your value prop using a sentence like this:
"Developers want to do X.
But they don't want to do Y, so we do it.
All they have to do is Z." The more specific and evidence-based
this madlib is, the better.
Also, when it comes to what they don't want to do,
I think that should be a non-programming task
and preferably something that's a continuing pain,
not a one-time thing.
Just for fun, let's try this out with a few companies.
Twilio, for example:
developers want to use SMS and telephony
but they don't want to figure out
how to integrate with multiple phone carriers and
keep track of several different APIs
or sign contracts with those providers.
So we do it. All they have to do is script the calls
using an HTML-like language.
Let's talk about SendGrid.
Developers want to send emails
but they don't want to worry about deliverability,
authentication protocols or bounced emails. So we do it.
All they have to do is use our JSON API.
Here's an example that doesn't work quite as well.
I don't know if you guys remember Google Chart server, but it was a tool that they deprecated a few years back.
You might say for them,
developers want to embed charts and graphs
to render charts and graphs. So we do it.
All they have to do is pass the chart data
through query params and an image URL.
In this case you're essentially trading
one kind of programming task
for a different kind of programming task.
That's one way to think about it.
Another way to know if your value prop resonates
is to think about trying to provide
problem-solving tools instead of solutions.
Any time your service can breakdown the problem,
offer helpful metaphors
or provide a new way to approach a problem,
you're off to a good start.
Alternatively, if you're creating end-to-end solutions
such as telling developers what to do,
making choices for developers
that aren't related to the core problem
that you're trying to solve,
that's much more difficult.
This is actually something that happened to me.
One of the products that I worked on
was an end-to-end solution
for building and deploying single-paged apps.
It was called Backlift.
And we had it all.
We had data APIs, deployment tools, templating language
and, at the end of the day,
devs just didn't get what we were doing.
It didn't fit into their mental model
of how to deploy sites.
I think we were much more successful
when later we took some of the core elements of that
and broke them out into parts
that work together but didn't depend on each other.
We ended up rolling out separately
deployment tool for static sites,
APIs for charts and data as separate, a la carte options,
and that was a much better strategy.
Finally, I think you shouldn't be thinking about
how to make dev's lives easier.
This may be a bit controversial,
but I think,
instead of trying to make their lives easier, you should try and give them super powers
or help them do something that's almost impossible.
I think that's somewhat a relative term, right?
Like, what I think is almost impossible
may be relatively tractable for somebody
who is more experienced in a particular area.
But generally speaking, that's your customer,
the person that thinks that this is almost impossible. I think if a problem sounds too difficult for you,
that's a great idea.
That's a great reason to try and tackle it,
because it sounds like there's an opportunity there.
All right, so you're focusing on enterprise,
developers are influencers,
your value prop resonates with developers.
Next question is how do you establish trust?
I think trust is very important
because developer platforms require an investment.
I think a killer feature for any dev product
is its trustworthiness.
There are a few strategies I think you can employ
to try and do this.
One is to try and minimize the developer footprint
or the shadow that your product casts,
or the surface area.
Those are tons of different ways
that you can think about this.
But at the end of the day,
you're just trying to avoid requiring
a large commitment up front.
I think the bigger your developer footprint,
the larger the barrier to adoption there is.
If you can manage to create smaller, sharp tools
that developers can try out on side projects
or for temporary campaigns,
I think that's a great strategy. What it does is it allows developers
to build up trust over time.
Another way to think about it is
to try and be a barnacle.
Try and attach your product onto the side
of their product somewhere
and then grow from there, start to multiply.
Another essential part of establishing trust
I believe documentation is really essential
to having a great developer product.
I think it's a core part of your product's user experience.
Some products like Stripe have actually created
I think also Facebook, they have a whole sandbox
for trying out their APIs.
I think this is a great way to
not only engage developers,
but also to learn about your developers.
I think there's a ton of interesting
opportunities within docs to learn about
what your developers are interested in
and to find out what's confusing to them.
And we're going to talk about this a little bit more later.
I think it even makes sense to consider
writing your docs first, before you work on the product.
I think that writing documentation
often exposes complexity,
clarifies what you're actually doing and the value you're providing.
It encourages you to simplify.
All right, so, you've got good answers
for the previous questions.
You're on the right track.
If you have those answers down,
I think you're on the right track
for articulating a value prop
that makes sense for developers.
Validating a Paid Product
I think the last step is to validate that
the developer community is willing to pay something
to have your problem solved.
This is sort of like the Maslow's hierarchy of needs.
I call this the Krumbholz hierarchy of customer investment.
It's almost as catchy.
At the bottom here we've got email.
These are basically things
that you can ask your customer to give you,
either direct payments at the top,
or something in lieu of payment
that really allows them to signal that
they are invested in what you're doing.
You can ask them for an email address.
You can ask them to share publicly.
You can ask them for time
by asking them to fill out a survey
so you can get more information or perhaps watch a sales pitch or something.
You can ask them to pay a token amount
to reserve a user name or a seat.
Then of course, if you can get them to pay for a month
or a year in advance, then you definitely win.
But I think if you get them to invest like that,
that's a great way to ensure that
not only is this value prop resonating
and makes sense to your developer market,
but it's something that they value
and are willing to pay for.
The counter-question to that is,
"What about freemium?"
Honestly, I know that this
doesn't apply to everybody,
but I think if you can avoid freemium,
I think that's good.
I think there are very few scenarios
where it makes sense.
One example is something like npm.
Npm is a product that was really attached to Node,
and as Node grew and took over,
npm was right there alongside.
And once they were in a position
where they were sort of established
as the main package management solution,
then they could start to translate that into a business.
Which was a little bit of a tricky thing for them as well,
but that worked really well for them.
If you're not counting on this meteoric rise of
a particular technology that you can come along with,
I think it makes sense to
try and get users to pay something up front.
I think paying customers not only help you validate
that your idea makes sense,
but they're also awesome.
They write thorough bug reports,
they're respectful of your time,
and they make fewer spurious support requests.
And even if you intend to go freemium eventually,
I think it can make sense to ask for some money
at some point early.
You can always make it free later
when you validated the product
or make a part of it free later.
Those were basically some things
that you can think about
to try and validate your value prop
and make sure that it makes sense for developers.
The next couple of questions
we're going to open up to a panel discussion.