ai architecture artificial-intelligence blog blogging Book Review business career Compliance Content Corporate Life Customer Support cybersecurity data data-science DevOps education entropy fitness garmin leadership Licensing life marketing microservices Monitoring music Observability Operations Partnership philosophy Product Management Products saas Sales Security software-development technology User Experience wordpress writing

When to Build Reliability

Published by

on

Harold Lloyd hangs from a clock hand above a busy street in a scene from Safety Last

Features win sales. Lack of sales kills the company. Everyone in leadership can be focused on that as the wolf currently at the door. Most developers and product managers can agree as well; obviously we have to sell the bits to pay the people. What surprises us is that the features don’t have to be very good to win the sales. They just have to be better at solving a single aspect of the customer’s problem than status quo. If you want to win a sale, first you need a demo. Then you need a proof of concept (also known as proof of value). You do not need a great deal of quality or reliability. You barely even need a 1.0 version.

Reliability does not immediately win sales. Reliability wins renewals. Enterprise requirements like complicated identity access management and role based access control win renewals. Scale wins renewals, but only rarely helps with sales (a POC might be large, but it won’t be production scale). These are very important to build because without renewals your company will be toast. Churn kills the company, even if it’s default alive instead of default dead. If you want to keep your customers, you’ll need to make quality product they can rely on. Support for your reliability work is best gained by seeking protection against this second wolf.

There is a large complication to this model: the sales can only happen if you’re at the table, and you won’t be at the table unless there is some level of reputation you can rely on. Why should the prospect believe what you say when you promise you can solve their problem? Fortunately or unfortunately, reliability does not play into that reputational load for some time. Initial sales meetings come from borrowed reputations: the founders were at a company, the engineers went to a school, the company is funded by a venture capitalist. Over time, product reliability can burnish or tarnish that reputation and affect the ability to make new sales. The best time to plant a tree was thirty years ago, as they say, and building your product with some thought to quality is never bad. What is bad is holding it back from the real world until it’s perfect.

A related complication is that you’re only able to get to the table within your own network. It may feel large, but your total addressable market (TAM) is the people who will listen to your borrowed reputation. Ever notice how every little startup’s page is able to name some major companies as customers, while those same major companies have procurement departments with vendor managers and RFP processes and a thousand other gatekeepers designed to stop that from happening? That’s individuals spending their political capital to introduce people and product from their networks. Growing the TAM by organically growing the network is certainly beneficial, but eventually you’ll need to address a market of people who don’t know or care about your background and relationships. Entering the front door with those customers means addressing all the gates: compliance, customer references, identity access management, analyst mentions, role based access control, and proven reliability.

Support for reliability work looks like getting things done. First, you have to get agreement from leadership that this is the time to make the investment. Whether that’s founders or e-staff or PM and EM leaders, they’ll need to see a cogent argument with strong data. That data needs to explain why the problem is a critical problem to solve now, because solving it is going to displace something important. You will need data, and a disturbing amount of that data is going to be in the form of quotes from important customers and their sales teams. If your enterprise software sales team is excellent or at least well above competent, they’re probably able to sell renewals past all sorts of objections. Your proposal for product change might make their jobs easier, but it is unlikely to land in time to affect the deals they’re thinking of. It can also be difficult to distinguish between normal complaining that the job is hard and actual reports that the job is approaching impossible. After the renewal is lost is far too late for action, but acting too early can be nearly as bad by blocking investment into features that will sell. You simply break down and prioritize the requirements for reliability, scoped the work to be done, and propose a schedule for the most critical blockers. And that’s why product management is an important task in even the smallest of teams.


Discover more from Monkeynoodle.Org

Subscribe to get the latest posts sent to your email.