Status: Speculative / assertions. Based on secondary sources, putting myself in the shoes for the user.

High level principles

• Developers have a job to be done. Any tool has to be primarily in service of the job. Other concerns (elegance, mindshare / goodwill) are secondary. Most often the tool will be evaluated with respect to fit for job.
• Jobs have remarkable variance across instances. This variance will likely not lie in the elevator pitch but in the deployment.
• Developers are smart and used to solving problems along multiple dimensions. With well designed and documented degrees of freedom they can achieve their ends.
  • The best tools unlock new creativity beyond what the creators imagined. Good tools are used exactly as the creators intended. Poor tools are not used or are used suboptimally.
  • Good tool design is roughly 1) fit with existing mental models and patterns where they exist, and 2) elegant patterns of use for novel scenarios (or scenarios where existing patterns can be improved 10x)
• Developers want to try, discover, and learn new things. New ways of thinking or new capabilities can appeal to their curiosity.
  • Corollary of point 1 and 4: Letting developers try must be as frictionless as possible while still adding value and doing the job.
• The sales funnel to developers is longer. Demos or marketing can at best convince developers to try - where the tried product (in restricted time and/or feature set) should be convincing enough for a sale.
  • If a product needs significant developer investment to try or to deliver real value, relying on novelty and promise is unlikely to work. Costs of trying may have to be borne by the seller (sales engineers etc)

Try before buy

Common models for trials → either time bound (2 weeks) or feature bound (no storage / less compute / no support).

Trials are tricky to get right since it's a balance where real + demonstrable value should be delivered (net the cost to try it) without giving away too much of the value such that there are no paying customers.

The more investment is required to try, the more generous the trial value should be to convince developers to put in the effort to try as well as commit to pay

• Counterargument → the IKEA effect and sunk cost of initial trying could potentially make 'hard to try' tools sticky but this does not seem sticky in the long term. For example, when the decision maker to continue the subscription is no longer the same person who did the trial, these biases will not hold.

Delivering real value

• The most obvious way of adding value is saving developers time. This is a particular instance of cost reduction.
  • Given developer salary is ~$40 per hour, this is straightforward to compute.
  • Fixed costs → Cost of your tool (dev hours + sale cost) vs cost of BATNA (competitor or in-house)
  • Ongoing costs → Recurring costs of your tool (dev hours + recurring dollar cost) vs cost of BATNA (competitor or in-house maintenance / additional feature work)
  • An even more particular instance is a shift of fixed costs from in-house developer time to cash, which is generally more fungible. (Developers are hard to train etc). This seems especially risky since in a successful company, developer time may become less scarce than equivalent cash.
  • Examples of such startups → most cloud services / pure software tools
  • Strategies of cost reduction
    • Amortise marginal cost over multiple clients (standard cloud economics)
    • Capture rare knowledge so that internal marginal cost is cheaper than external marginal cost
      • Stripe (financial integrations), regtech (GDPR / HIPAA compliance)
• The other way of delivering value is to unlock revenue. It is arguable whether this should be considered purely a developer tool, as some other function (sales, marketing, product) would also need to be using this.
  • Examples of such startups → analytics (Segment, Mixpanel), A/B testing (optimizely)
  • Question: How did such startups sell? Did the sale story evolve from focus on developer to focus on business decision maker

Risks

• A flipside of developer appeal of novelty → there is an element of fashion / trends in developer preferences.
• Narrowly, developers see value clearest in making an existing workflow easier. They need to 'have the job' to seek or be sold a better tool for that job.
• If single-cloud shops and stacks proliferate, barrier to entry for 3P solutions will increase. The likelier outcome on success will be for cloud companies to build out a competitive offering.