Sep 1, 2022
Interfaces and bundle boundaries
Categorizing design decisions in enterprise product development
It’s an interesting time to be a data practitioner. Never before has capital followed the needs of data teams so closely and intently. At the same time, the growth and evolution of the data infrastructure and tooling market has created grounds for critique, hot takes, and calls for action.
As I go about planning for the short- and long-term functionalities of General Folders, I find it helpful to identify the design decisions that attract and keep the attention of customers. By enumerating these design vectors, my hope is to bring structure to the discussions and also to the exploration of the infinite space of product variations to discover products that sell.
The vectors that I was able to uncover are configurability, functional variety, application universality, and audience universality. Together they help shape the user experience of enterprise products. These vectors are not orthogonal, meaning that moving on the spectrum across a single vector can change where one stands within another. Without further commentary, I present the four design vectors and discuss some of the tradeoffs involved in moving across each vector.
Configurability
1 Definition
Configurability is used to define the degree to which one customer’s version of a product or service can differ from another customer’s version. Configurability is achieved by exposing programmatic or low-code toggles that allow customers to modify the product.
2 Examples and best practices
Box, Dropbox, and GitHub offer very few toggles, whereas Workday, Salesforce, and SAP offer many.
Although larger customers require heavily customized solutions, customization comes at the cost of simplicity in workflows and onboarding. Salesforce has recently launched Salesforce Easy to simplify the onboarding process.
A Dell or HP laptop is more configurable than a MacBook. Yet many companies still choose MacBooks for their employee base. They choose convenience over configurability when configuration does not provide clear benefits for their use cases. It’s nice when you can avoid having to worry about antivirus software or device drivers.
Functional variety
1 Definition
Functional variety refers to the span of distinct functionalities that are bundled into a sellable unit, wherein each functionality can be removed, shipped, and sold as a standalone product.
The functionalities that are included and those that are excluded in the final sellable unit define its bundle boundaries. This choice can expand beyond the product and become the boundaries to which the entire company adheres.
2 Examples and best practices
A product can be built such that it serves a single function very well. Or it can be a Swiss Army knife amalgamation of many functionalities. Consider for example, Databricks. The bundled offering spans data warehousing, data streaming, and ML Ops functionalities. Another bundled service, Notion, packs note-taking, ticketing, and data management functionalities into a single sellable unit. At the other end of the spectrum, there is a lightly bundled Fivetran, which provides SaaS data integration services.
Note that bundling is different from multiple business units delivering services that are sold separately. Atlassian, for example, allows customers to pick and choose. Paying for JIRA does not get you a Confluence membership. Similarly with AWS, paying for Redshift does not get you access to SageMaker. On the other hand, Monday.com and ClickUp bundle all functionalities into a single sellable unit.
The company that is first to bring a product to market has the benefit of defining its bundle boundaries. The category definer is the one that shapes customer expectations. The next entrant has no choice but to implement core functionality as set forth by the category definer. JIRA has come to define what it means to be a ticketing system. GitHub has done the very same for version control; and Workday for HR. For the next JIRA to succeed, GitHub integration is a necessity; for the next Workday, the seamless management of international payroll.
In some markets, the agreed upon bundle boundaries are still under development. BI tools are such a product — the market has yet to figure out the ideal set of functionalities that produce a winner.
Opportunities for bundling occur when an incumbent makes it difficult to buy or integrate their product. Opportunities also arise when an incumbent fails to update their product in response to evolving customer needs. But neither of these scenarios provides a sufficient condition to bundle. If bundling cannot fully replace the need for an existing product, customers still need to buy that product — regardless of its limitations.
When sufficient conditions for bundling are not met, bundling is not a good use of budget. Instead, it is smart to provide integrations with existing products. A look into Snowflake’s list of technology partners, displays the functionalities they choose not to bundle but for which to offer seamless integration.
Ultimately, it’s easiest to sell a product when the bundle boundaries are allowed to be shaped by the market. A product makes sense in the context of adjacent products. It lives in conjunction with all the existing workflows that it does not affect. Bundle boundaries should be shaped by the ecosystem in which the product is to exist. A good example is Square, which aims to address the unmet needs of click and mortar businesses. Study the workflows, then fill in the gaps.
Your place in an ecosystem of tech partners is just as important, if not more so, than the quality of your product itself. —Bob Moore
One final note is about managing teams building bundled products. Attention to the proper allocation of people to each functionality is key. As a company begins to neglect any one of its bundled functionalities, it starts to lose customers as better unbundled services inevitably emerge. A good example is issue tracking in Notion, which is being built anew by companies like Linear.
Application universality
1 Definition
Application universality is a term to describe the degree to which a single product can be applied to varied use cases. A product with high application universality can be considered a horizontal product.
2 Examples and best practices
A great example of a universal product is Excel. And Gmail. You can use Excel for project management, for financial modeling, and for accounting. Gmail can be used for mailing lists and newsletters, for drip marketing campaigns, and for cross-company and internal communications.
Application universality is commonly confused with functional variety. For example, Excel is consistently considered a bundle—just search Google for “the unbundling of Excel”. However, it is more accurate to consider Excel a single product with high application universality, rather than a bundle. A bundle can be broken into parts that can be sold separately. Excel is used as a CRM and for accounting. Yet you can’t remove the CRM functionalities of Excel while leaving the accounting functionalities intact. Consider, also, the kitchen knife. Unlike a Swiss Army knife, the kitchen knife is not a bundle. It has application universality but lacks functional variety.
Products in a horizontal market, i.e., products that don’t target any one particular industry, are likely to have high application universality. For example, AWS S3 is used to store a company’s data regardless of its industry. Naturally, a product with high application universality is able to target a larger market. Having said that, vertical focus doesn’t necessarily reduce a company’s ability to grow. Vertical focus is an opportunity to target a bigger part of a smaller but neglected market. As an example, consider Shopify which serves online retailers.
It is important to note that application universality is not always ideal. In the case of Powerpoint, for example, it can lead to confusing use cases. It’s not clear whether Powerpoint is a way to deliver a report for asynchronous consumption, or if it is a medium to deliver a speech in real time. Similarly, it’s not clear whether Slack is meant to fulfill the role of an email app (asynchronous and high-context workplace communications) or a messaging app (synchronous and low-context workplace communications).
A final example is in the BI tooling space. It isn’t clear whether a BI tool is intended for data analysis or if it is a medium for delivering reports to the rest of the company. Are dashboards an intermediate artifact in a data practitioner’s workflow? Or are dashboards for business users? This lack of consensus leads to confusion and potential misuse, for example, when business users take action in response to noisy data.
Audience universality
1 Definition
Audience universality is used to refer to the the variety of user personas that are able to employ and benefit from a product in the enterprise.
2 Examples and best practices
Google Docs and Gmail have high audience universality whereas AWS has low audience universality. Every employee gets a Gmail account whereas only a subset of engineering team members get an AWS account.
Supporting diverse user personas doesn’t come naturally to all product categories. Enterprise roles vary greatly in their responsibilities, skills, and work processes. This in turn impacts the ideal set of features for a product. For example, BI tools that optimize user experiences for business users tend to underinvest in the features needed by the employees who spend the most time with the tool: the data practitioners. In this particular scenario, and given that data teams are the buyers of BI tools, neglecting their workflows and processes is a not a good sales strategy.
Yet another example where opening a product to more user personas is not straightforward is in enterprise messaging. Consider Slack, for example. Given that Slack invites the entire employee base to contribute to an always-on stream of conversations, it can become a challenge to manage workflows for employees who are on different schedules.
Infrastructure tools take pride in having low audience universality. Consider Terraform, for example. Most employees rarely know if their company is a Hashicorp customer. The same is true for Fivetran or Confluent. These products are designed in such a way so as to minimize the number of employees required to operate the product.
Where a product stands with respect to configurability, functional variety, application universality, and audience universality make it either confusing or useful. Making deliberate choices across these vectors leads to easier-to-sell and easier-to-use products, while ensuring the efficient use of capital.
References and further reading
[1] My $2.6 Billion Ecosystem Fail: an RJMetrics Post Mortem by Bob Moore
[2] Who’s Who in the MDS Ecosystem (Spring 2022) by Jordan Volz
[3] The State of Data Engineering 2022 by Paul Singman
PS Special thanks to Ryan O’Neill, Scott Beru, Abhiram Ramesh, Shane Johnston, Preeya Phadnis, Pedram Navid, and Hassan Jaferi for reviewing this post and providing valuable feedback; and also everyone whose work has provided inspiration for this post.
