Sellability

<< Previous - ROI | Table of Contents | Next >> - Agility

Sellability relates to the ability (and effectiveness) to sell a product to prospective customers. Many variants can affect Sellability; some controllable (e.g. Brand Reputation), others less so (e.g. varying customer expectations, subjective reasoning, or even a general Bias).

"USEFUL" PRODUCTS

To be sellable, a product should solve some useful problem, that customers will pay for, and do so at the right time.

Much of a successful sales process is established through listening, and building trust. Although a competitive pricing model is important, being transparent, reliable, and agile are also highly valued. Of course, it’s easier to build trust upon strong and highly respected products and branding (later).

SALES PHASES

There’s typically two final phases prior to a sale, and project initiation:

1. The initial workshop(s), where everyone views the proposition from a business perspective (e.g. functional affiliation).
2. A technical workshop(s).

Either phase can fail (e.g. "it doesn’t do 50% of what we require of it"; "show me evidence of that it scales and is resilient in these circumstances"; "we expect all medium bugs to be fixed in one day"), so it's important to balance functional and non-functional needs.

COMPETITIVENESS

Competitiveness takes many forms, including:

• Pricing - the proposed pricing model is agreeable to both parties.
• Features - e.g. the product has all required features, or can be easily modified to support them.
• Non-Functional - e.g. it scales to customer needs, data is well protected, and it is highly available.
• Agility - e.g. we can easily switch direction as the market/customers dictate.
• Quality - e.g. the product has gained a strong position due to its proven high quality.

TECHNICAL QUALITIES AFFECTED

The figure below shows some of the technical qualities affected by (or affecting) Sellability.

They are:

• Flexibility & Extensibility.
• Costs.
• Reuse.
• Scalability.
• Reliability.
• Security.
• Portability.
• Productivity.
• Releasability.
• Testability.
• Maintainability.
• Availability.
• Usability & Integrability.

FLEXIBILITY & EXTENSIBILITY

Systems that support the Flexibility and/or Extensibility needs of prospective customers promote Sellability. Negotiations are much easier if the solution easily demonstrates efficient support for the customer’s needs. However, this does not suggest the employment of these tactics across a system’s entirety (a form of Overprocessing).

Portability is just a specialised form of Flexibility, aimed at the vendor or platform level.

COSTS

A competitive pricing model is a very important aspect of Sellability, and (from a systems-impact level) may include:

• The cost (including delivery effort) of each functional change.
• The solution’s Operational Expenditure (OpEx) - e.g. the monthly operational costs to run the platform. Is this charged directly to the customer?
• The cost to scale the platform to meet an increased capacity. This is a common problem in event-based systems (such as sports events). A solution might be cost-effective on the Business-As-Usual (BAU) infrastructure, but entirely unacceptable at the desired "event scale".
• Pricing Model (e.g. x cents on each subscription, monthly SAAS payments, daily rate); e.g. does the business charge by the day (i.e. a service), spread the costs through a SAAS offering, or through a percentage of each subscription? The chosen pricing model may determine what (or how) you build a solution.

SCALABILITY

Scalability can affect Sellability in two ways:

1. The customer has heard (or has experience) of the product’s scaling issues (damage to Brand Reputation) and won’t enter into a sales discussion.
2. The prospective customer enters into a sales discussion, but requests (unavailable) evidence of the system's scaling capabilities. It’s feasible to get far along the sales process (investing significant time and money), only to fail in the technical discussions.

SCALING AND COSTS

Scalability also affects Costs (and thus Sellability). So what if a system meets you capacity demands, if it costs $10 million a year to operate...?

REUSE

Closely related to Productivity and Releasability (e.g. it’s easier to release something you're already familiar with) is Reuse. Reusing solutions in different contexts is a good sales enabler, because (a) it suggests good TTM/turnaround time, (b) the solution is “proven” (i.e. Stakeholder Confidence) and believable, and (c) it enhances the sales team confidence that the solution meets the customer’s needs, and they can leverage this information to increase the likelihood of the sale.

RELIABILITY

Generating sales off the back of a notoriously unreliable product is always going to be challenging (see Brand Reputation). Any technical due diligence undertaken by the prospective customer should uncover those Reliability issues, resulting in either (a) a difficult sales process, or (b) the disintegration of that sale.

Reliability also falls into the realms of Releasability; failing to deliver on a promise (due to poor delivery mechanisms, or too much work), may cause your business (rather than your product) to be perceived (Perception) as unreliable.

LOCUS OF CONTROL

One (relatively nascent) idea that is gaining traction is our perception of control of complex systems (whether they be economic, technical, political, or something else); i.e. our locus of control. This is an extremely interesting area of study and is already having consequences on how we design our systems of the future. [1]

The premise of Locus of Control revolves around the chimeric notion that we are being able to control a Complex System. Whilst we invest heavily into preventative recourse, applying layer after layer of controls, in order to supposedly control a complex system, what we’re doing is exacerbating any future problem through more rigid coupling to the point that when a problem does (eventually) occur (we can’t control every eventuality), it is far worse than it might have been.

Whilst we must should always have table-stakes in place (e.g. testability), it's sometimes prudent to allow a problem to occur rather than introduce further controls, and demonstrate Resilience through swift resolution.

SECURITY

I could invest a great time of time detailing how poor security practices affect Brand Reputation (although I suspect you already know this...). As a consequence, poor Security can also affect sales.

Typical questions a prospective customer may ask includes:

• Where is the data stored (particularly when using a public cloud)? e.g. some European customers are concerned with sensitive data held outwith Europe.
• What data do you encrypt? Are you best placed to manage that data or does it require specialist skills? This often flows into the realms of regulatory compliance such as PCI and GDPR.
• Have any previous occurrences of security mismanagement been reported?
• What technologies (and versions of those technologies) are used and how regularly are they patched? Support dwindles for old technologies, thus the need for regular migrations and upgrades.
• Software lifecycle processes - how is the software built to ensure it is secure? This may involve demonstrating adherence to techniques such as the OWASP guidelines.
• Have/are regular penetration tests undertaken, and what remedial action is taken? Can the reports be shared? Can the customer undertake their own tests?

PORTABILITY

I've attended a number of customer workshops and seen their eyes light up at the prospect of providing them with a portable solution, enabling them to choose: (a) whether it’s hosted in the public cloud or on-prem, (b) what cloud provider they select (some customers have existing commercial agreements with certain vendors or have a Vendor Bias), and (c) the data storage technologies.

Conversely, if not carefully controlled, Portability can also harm TTM/ROI (through increased complexity), and thus Sellability; some customers are ambivalent to underlying platform intricacies, and care only that it meets their desired capabilities.

VENDOR BIAS

Beware of Vendor Bias; customers should have reasonable reasons for an affinity with a specific vendor that also fits into your business needs. Don’t say yes until you’ve identified both the immediate effort and the long-term impact of that decision.

PRODUCTIVITY

Productivity may have a bearing upon Sellability. For instance, some customers have expectations in how they want value delivered (as I write this I’m about to attend a meeting to describe our delivery process to a prospective customer). If productivity is poor (e.g. poor communications, team structures, insufficient detail, antiquated tools and technologies), then that may reduce your perceived value (Perception) to the customer. Some customers buy into an ethos, not just a product.

RELEASABILITY

An increasingly important aspect of Sellability is how easy (and often) value is released to the customer. Most of the major players use “continuous” practices, and Agile/DevOps methodologies to enable them (in part) to drive more sales, sooner. Consider how valuable the proposition becomes if you can present a newly released feature/proof-of-concept to a prospective customer in the time it takes to undertake a customer workshop.

TESTABILITY

Often overlooked, Testability improves the quality of software, potentially increasing your perceived value (Perception) to a customer. Testable software also promotes (medium-to-long term) Productivity and Releasability (change occurs more rapidly), and thus supports sales.

Testable and releasable software also makes provisioning environments a breeze. The sales benefit is fast, reliable provisioning of demo systems that the customer is able to play around with.

It all comes back to Stakeholder Confidence. The sales team are confident that the product is of high quality (it's been robustly tested), whilst the customer perceives the quality (and gains confidence) by engaging with it, and the sales team.

MAINTAINABILITY

This quality is related to Productivity (at the code level), and thus can support sales. Let me elaborate.

Bugs are an inevitability in even in the most robust of software. Customers will (at some stage) come into close contact with one. Whilst disconcerting, it need not be injurious. Modern customers are (in the main) more technically astute than previous generations; and whilst that may make them tougher in some areas of negotiation, they're also more pragmatic about the realities of stamping out all bugs.

Now, whilst this approach doesn’t excuse sloppy workmanship or insufficient testing, it can (under the right conditions) support sales. Customers may be more appreciative of your ability to respond to failure (i.e. your business resilience), than if they had never suffered any hardship.

AVAILABILITY

Closely related to Reliability (how stakeholders perceive your business and systems), is Availability. It is key for many organisations.

Let's say you’ve built out a live video-event streaming service, with the intent of selling sports events content to customers. You market the service successfully, and a large number of customers purchase it. However, during the stream of the live content, you find your system unable to service the demand (causing a Self-Inflicted Denial-of-Service), forcing all customers out mid-event (this is poor availability, caused by a scalability issue).

This scenario terrifies prospective customers in this domain (it affects their reputation, and profit margin), thus, they will take a keen interest in Availability (normally through SLAs), typically near the beginning of the sales process (RFIs/RFPs).

USABILITY & INTEGRABILITY

Humans are visual and tactile creatures, and grow affinities with aesthetically-pleasing products they can see and touch (Apple has done rather well on aesthetics). Consider the plethora of Unqualified Critics who’ll line up to provide their feedback on a new user interface, in contrast to the focus a new API or back-end solution receives. User interfaces a far more accessible (Lowest Common Denominator), to a broader range of stakeholders, so they naturally receive more attention (even though they’re often not the most important).

AESTHETICS CAN HIDE REALITY

One potential problem I’ve witnessed with beautiful user interfaces (UIs), is what lurks below that shiny new interface (Aesthetic Condescension). To the uninitiated, an aesthetically-pleasing interface may successfully hide (at least initially) deeper inherent system issues (e.g. it’s still a Monolith under the hood; or the UI interacts directly with the database, hampering scalability, evolvability, and reuse).

The best metaphor I can think of is the elegant swan moving gracefully across the surface of the water, whilst (hidden from view) underwater, the little duck’s legs paddle furiously to propel it.

An aesthetically-pleasing UI can be a big sales enabler. However, well-versed investors will apply caution, and apply a metrics-driven decision-making process as part of their due diligence.

Most businesses/customers involve a range of stakeholders before making big decisions. Some of those stakeholders are technical. If that customer is required to integrate (e.g. you provide APIs that they consume through an external website), then Integrability (the ease with which an integrator can successfully integrate) could be important. To elaborate; simply providing an acceptable level of functionality is not (and never should be) a sufficient end game. Those features should also be accessible in a (convenient and consistent) manner to support sales.

CHAPTER SUMMARY

The key points of Sellability are:

• Whilst feature support is extremely important, most customers also have strong non-functional expectations.
• It's unlikely you’ll be able to (or should) cater to all customers needs. The more distinct each customer’s requirements, the more complex the system, and the harder it is to control.
• The strength of the brand affects the sales process. A poor reputation may prevent any form of sales discussions.