Essay

A Playbook for Expressive Products 08.2021

Introduction

Digital goods are the result of the productization of a business solution to a user need, expressed through a variable combination of design and engineering.

Design, code and data converge within a single experience, which becomes the interface that customers use to interact with the product. As the technology industry has evolved, the quality of its products has increased significantly, and expectations of customers have been raised.

Today organizations are not just solving user needs, but they are fighting for customer's attention. To capture people’s minds, they are focusing on creating experiences which are memorable and help people connect with their product.
These experiences are characterized by a tight coupling between brand, design and engineering - to the point that is no longer perceivable when one ends and the other one begins.

Conceptual integrity

Products that achieve such tight connection across their ecosystem are most likely to perform better and to be loved by customers , because they can maintain greater conceptual integrity in the final product.

Conceptual integrity is a fundamental aspect of creating products, and represents the sum of a large number of daily, coherent choices which all are made in support of the same underlying design, concept or principles. These choices can transparent to the users (e.g. the set of features that the product is going to have), or opaque (e.g. as the design of the data infrastructure), but they are originated from a common set of principles: in a conceptually integral product, all parts are ruled by the same order.

In his definition of conceptual integrity, Brooks describes the suggestive figure of a creator (or a set of creators), who is in charge of architecting the project and establishing the fundamental rules of the program .
We have already discussed how separations of concerns can help scaling products through a clear definition of roles and responsibilities, but in the initial phase - when the product doesn’t face scale yet, and concept validation should be as fast as possible - conceptual integrity is best carried out by a small, multi-disciplinary team.

The cross-functional team

Let's imagine that we have a breakthrough idea, which we want to build an MVP for and validate with users. We're in early stage product development, and we want to ensure fast feedback loops in order to generate incremental value as quickly as possible.
Achieving this goal requires a small group of operators who can collaborate on the imprint of the product, by providing a coherent set of guidelines that can be used across multiple concerns.

How should one choose this small group of architects, who will be in charge of the imprint of the program?
There are some key characteristics which a team should have in order to maximize the changes for success. It should be small (3-5 people) and tactical (focused on the specific task of architecting the product) so that it can move with the necessary agility required by the project.

Most importantly, since product making requires the ability to advance the product unilaterally, each individual will have more than one job to accomplish in order to be effective on the team (whether it may be design, product, or engineering). As each contributor is asked to participate in multiple concerns and to understand the entire scope of the product, individuals are required to possess multi-domain expertise in the field.

Problem solving across a number of different surface areas requires a broad domain of knowledge, mental dexterity and lateral thinking . These skills are most commonly found in multi-disciplinary practitioners, who are able to apply first principles and to approach problems from a variety of perspectives.

Building a generalist practice

Generalists are multi-disciplinary operators who are able to contribute to all core aspects of the product: design (research, product, brand, marketing), product (business, strategy, planning), engineering (frontend, backend, data science).

Commonly, a generalist practice is characterized by an innate curiosity, a broad spectrum of interest, and by the ability to navigate ambiguity successfully by adapting prior knowledge to the existing context.

Studies have found that deep expertise in a subject does not positively correlate with accuracy in judgement. As part of his research on forecasting, professor Phillip Tetlock conducted a study with 284 political experts, that generated over 80,000 informed (where the estimate matched the area of expertise of the individual) and uninformed predictions over the course of 20 years. Surprisingly, Tetlock discovered that specialists are less reliable than non-experts, even within their specific area of study. In fact, the study concludes that after a certain point, deepening one's knowledge about a specific topic is affected by the law of diminishing returns and can hinder the ability to accurately predict a certain outcome. The results of the study can be attributed to the fact that subject matter experts are more likely to suffer from confirmation bias and are more likely to feel the pressure associated with reputational damage , both of which can affect their ability to produce accurate predictions.

In Isaiah Berlin's interpretation of Archilochus aphorism, hedgehogs correspond to field experts who tend to be deterministic in their thought process, and foxes are the generalist pratictioners who are less invested in any specific theory, and approach the problem space with the curiosity of a newcomer.

For that, generalists become particularly valuable when looking across product concerns, because they can help a business articulate and quantify the ROI of the product building process earlier in the process, avoiding missteps which can become particularly costly at scale.

As operators that work holistically across the organization, generalists are able to advance the whole ecosystem in unison, reducing the likelihood of chokepoints and working first-hand through any dependency gaps.
The pursuit of decentralized knowledge acts as a tide that lifts all boats as the ability to apply localized learnings across multiple domains of expertise amplifies the impact of each discovery and makes all of the knowledge deeply interconnected.

Creating expressive products

By providing all of the expertise in-house, the generalist practice is able compress the timeline of the product lifecycle. In order to deliver memorable experiences, teams need to tailor their tools and processes to be as iterative as possible.

Most commonly, product-making is determined by dependency reviews and sequencing, which are traditionally linear in nature. With this workflow, each individual (or team of individuals) acts as an expert in a particular aspect of the product, and they are responsible for that specific concern, contributing to the project from a singular perspective.

At every stage workers generate an artifact, which is then passed onto another team member, who continues the build process separately. As these artifacts are translated from person to person through the lens of their unique skillsets, they are prone to translation errors which can affect the conceptual integrity of the experience.

Generalist teams are able to bypass some of the challenges of this traditional workflow by eliminating the need for a formal hand-off process, and by evaluating all of the aspects of the product from the beginning of its lifecycle and by putting the emphasis on showing what the experience should feel like as opposed to telling . This procedure limits the amount of artifacts generated to a minimum, and the outcome is always a complete end to end experience, which is refined incrementally until the desired level of polish is reached.

Building functional experiences helps product owners to identify where the team should focus their attention next. By reviewing the experience as a whole, additional efficiencies and opportunities emerge which would not have been apparent by evaluating artifacts alone.

Designing in code

We define the process of building experiences incrementally as incremental prototyping. Prototyping offers the expressiveness required to evaluate an experience holistically and to measure its conceptual integrity.

While there are many prototyping tools available on the market, most require to be combined with other solutions to be truly functional. Programming is the ideal medium for functional prototyping because it’s the only aspect which is able to express presentation, logic and data at the same time.

There are numerous studies which highlight the benefits of prototyping in product development: most notably, software prototyping is at the core of Barry Boehm's Incremental Commitment Spiral Model . In contrast to the waterfall process, Boehm's model is highly iterative and is diagrammatically represented as a nautilus, with every concentric circle representing a discrete product iteration, which starts with goal setting and utilizes prototyping to inform risk assessment and validation phases. Each concentric iteration removes a layer of ambiguity and evaluates the remaining level of uncertainty until the program is completely de-risked. In Boehm's studies, the inclusion of rapid prototyping as part of the product lifecycle can dramatically help with risk mitigation, and has shown to increase the efficiency of the team members by 40%.

As we anchor prototyping in programming, we also aspouse a new process, in which code acts as the source of truth and as the sandbox for product creation. By fully embracing this practice, we are short cutting the traditional product-making workflow and we are designing the product directly in code. This shift in how we think about building products has a series of measurable benefits.

• It is a technology first approach: by removing the opportunity for translation errors, designing in code helps the team evaluate tradeoffs objectively. It also exposes the capabilities of the platform the product is being built on, and it helps product owners to be more economical in their choices (e.g.: when to use a custom component vs. the platform native APIs) and reduce technical risk.
• It fosters experimentation: code is parametric and highly malleable.Functions and styles can be defined in a single location and their updates propagate across the entirety of the product. Functional prototypes can be used for user research and forked for multivariate testing at a low cost.
• It’s semantically coherent : functional prototyping offers a single, shared language around which the team can rally on, which helps maintain a high degree of conceptual integrity throughout the experience.
• It provides a foundation to build upon: while production code might have different standards than rapid prototyping, concepts and architecture are easily transferable, offering an helpful jump off point when the product is ready to graduate into a more mature stage.

Graduating to production

There are different kinds of functional prototyping which provide a wide spectrum of outcomes. Rapid prototyping is optimized for fast iteration cycles and is aimed at validating ideas quickly. This approach favors simple solutions over enforcing strict engineering standards or dedicating time to infrastructural investments. Because of the lightweight nature of the programming used, rapid prototyping can be extremely valuable for concept value testing, but it usually results in code which will not be used in the final product.

On the contrary, evolutionary prototyping aims to build out the experience as the product matures by evaluating technical feasibility and by focusing how the codebase can scale as new requirements are uncovered. In iterative product-building, evolutionary prototyping naturally graduates into becoming the first version of the product and continues to evolve until a major infrastructural refactoring is required.

The opportunity to build the production codebase incrementally makes of prototyping a long term investment which delivers continuous value both to product owners and to customers.
It also contributes to establishing an experience-centric culture in the organization, which that can help optimize resources by reducing the amount of artifacts generated and by focusing instead on building functional experiences directly in code.

References

1. McKinsey Quarterly, The business value of design, October 25, 2018. ↩︎
2. The Mythical Man-Month: Essays on Software Engineering, Fred Brooks, 1975. ↩︎
3. Magur.no, Separation of Concerns in Systematic Design, Separation of Concerns. ↩︎
4. Magur.no, A playbook for Expressive Products, Learning Organizations. ↩︎
5. Wikipedia, Lateral thinking. ↩︎
6. Tech Tello, First Principles Thinking: The Most Powerful Way To Think. ↩︎
7. The New Yorker, Everybody’s an Expert, Louis Menand, December 5, 2005. ↩︎
8. Harvard Business Review, Making Dumb Groups Smarter, Cass R. Sunstein and Reid Hastie, December, 2014. ↩︎
9. A List Apart, Sketching in Code: the Magic of Prototyping, David Verba, June 17, 2008. ↩︎
10. Semantic Scholar, Rapid software prototyping, Luqi Luqi, R. Steigerwald, 1992. ↩︎
11. Michigan State University, A Spiral Model of Software Development and Enhancement [PDF], Barry W. Boehm, 1992. ↩︎
12. Magur.no, Semiotic Constructs in a Design System, Creating a System. ↩︎