Developer-centric Startups for Critical Applications

Most DevOps centric startups are focusing on the Dev, not the Ops. Many tools and startups start in Test & Dev (versus “production” or “in-revenue” applications). But really hard problems in DevOps are often connected to in-revenue, critical applications. These applications have real-time and high-availability requirements and “exactly-once” execution of commands.

I have the privilege to meet awesome founders all the time. The first thing they do is to solve the hard problems in a prototype. That’s a good start. But soon they find out that no one wants to touch their in-revenue applications, definitely not with a prototype of a 10-person startup. PoCs take forever. Sales cycles start creeping towards 9-12 months.

Start with a non-critical time saver or value driver.

Awesome entrepreneurs should have the confidence that they will solve the hard problem eventually. And they should have the confidence that the problem is an acute pain and not a chronic pain. By creating a time saver for a non-critical subset of the problem you allow developers to tinker around with your software without starting a full-blown PoC, without starting the full-blown due diligence process, without setting the slow mills of enterprise security and procurement into motion. You can build confidence with developers, learning more about their needs and their processes, and maybe even find out about timing and budgets.

I’ve seen only very, very few startups with very, very experienced leadership where a developer-centric solution for critical applications was able to scale directly within critical applications at a pace that their VCs felt comfortable with. You have to have an extremely strong Rolodex and reputation to scale — and keep scaling! — directly in critical applications.

Build “reasons-to-believe” versus “solutions for VCs”.

At some point, you want to raise venture capital (again). As VCs, we not only see pitches, we also see portfolio companies as well as our fellow VCs’ portfolio companies. Depending on how much “beta” the investor has, as well as what her past experience with other companies was, she will ask you for certain KPIs because it either will make fund-raising easier or let you achieve a valuation where dilution gets minimized (or a down-round prevented).

Keep in mind that your actual sales mode and product are fitting current budget, while VC metrics are targeting future development. Sometimes there is a disconnect between these two. A mistake I see is when entrepreneurs build “solutions for VCs” — and great VCs will actually realize that and help you avoid it. When a great VC says “we need to flip this to a recurring revenue model” she does not mean that you try and wrestle your prospects into a different ownership or billing model (and probably lose half of them on the way), but rather build a product and have first “reasons-to-believe” — success stories, case studies, first customers — that create a line of sight that when the market is ready, you will be ready to flip your revenue model as well.

Don’t forget product instrumentation – and keep measuring.

That means you (a) have to build some early product versions that can demonstrate a shift in strategy; (b) add instrumentation to your product as well as your marketing and sales efforts to track market readiness and success factors; and (c) find some early friendly customers who are willing to try out your new strategy so that you can gather some lessons-learned.

Build your story and demonstrate nuanced insights.

Depending on your ACV and sales velocity, you might need a good six months of data for most enterprise software to demonstrate trends, product iterations, and strategy adjustments. The best outcome is always when you can demonstrate to future investors the nuances of current future strategies, KPIs, sales modes, customer behavior, or market readiness: “Yes, you are right. And this is how it works for our product / industry. And here is where we are different and why. There are two reasons for that. We are waiting for these two things to happen which would clearly signal to us to shift our resources to the new strategy. In the meanwhile, we can demonstrate early traction with two early adopters and continue to prepare the market and customers but otherwise sell what’s on the shelf.”

Thoughts? Opinions? Comments? Corrections?