May 10, 2016
Capital Efficiency: Lessons From the Financial Crisis
Javier Soltero discusses the challenges and lessons learned during the boom and bust period of his career. With past examples, Soltero cover...
Hello, 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.
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.
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.
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.
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.
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. Sounds good.
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.
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 is documentation. 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 interactive documentation. 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.
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.