Building Inclusive Products

The hard part about the idea of "minimum viable product," for me, is you don't know what "minimum" is, and you don't know what "viable" is.

— Ben Silbermann (co-founder of Pinterest)

In the digital product space, an EPD (Engineering, Product, Design) organization, is often described as a partnership. At work, we even referred to this as the three-legged stool—a metaphor which depicts each leg/department as being an equally important part of the overall product design process.

But, this is an idealized version of reality. More often, the EPD organization is built like a Totem pole; with Product at the top, Design in the middle, and lowly Engineering down at the bottom. This is much less like a partnership and much more like an assembly line.

Caveat: In my career as an engineer, the interplay between Product and Design has always been a bit of a black box. As such, I mostly speak about this process from the engineering perspective. And, I tend to think about Product and Design as being a single unit.

In this model, Engineering is handed a set of specifications (hopefully) in the form of an interactive prototype. Engineering then comes up with an estimate as to how long an implementation might take. Product then argues with the Engineering team, asserting that said estimate is completely absurd and needs to be cut in half. The Engineering team capitulates in an effort to keep the peace (with rationalizations about it only being an estimate). And then, when the Engineering team inevitably fails to meet the estimated due-date, they are reprimanded. And, the Product team becomes increasingly convinced that the Engineering team is the cause of all the company's problems.

If you're not familiar with this story, consider yourself lucky—you are in the minority. These are the trying conditions under which many teams operate.

When reading my account of this process, it's easy to vilify the Product team. But, it's not their fault. Or, I should say, it's not only their fault. As much as the product team might place unfair expectations on the engineers, it's strictly the responsibility of the engineering team to push-back and manage expectations.

But, it's hard for many engineers to do this because they don't actually see themselves as being Design partners. Instead, many engineers view their relationship to the Design and Product teams as being one of subservience. And so, engineers don't feel as if they have the right to push back.

What the engineers forget is that they hold insights that no one else in the organization can see. The engineers understand how long things take to implement; they understand how different implementations affect the maintenance of the application; they understand that different implementations have different cost profiles; they understand that different implementations have different performance characteristics; and, as the ones building the User Interface (UI), engineers always have a unique perspective on the usability of the product.

Engineers don't just have a right to push back—engineers have a responsibility to push back; and, to add depth of understanding to the design. It is the job of the engineers to temper the vision of the EPD organization; and to work collaboratively in an effort to find the best path forward.

Part of the problem is that we have too much reverence for job titles in this industry. People in different roles certainly have different skills and different strengths. But, we're all just doing our best. And, some of the time, our "best" is not that great.

It's helpful to remember that every terrible product that you've ever experienced was implemented by an engineer, envisioned by a designer, and approved by a product manager. None of us is perfect.

But, we all have insights worth sharing. Which is why it's important to include all relevant stakeholders in the product conversation. And, to do so at various stages of product development.

As we discussed in the life-cycle chapter (see Life-Cycle of a Feature Flag), the fidelity of an idea is constantly improving. From concept, to sketch, to prototype, to production, every step in this evolution adds new information about the user experience; and, identifies which aspects of an idea need to be adjusted. Successful products must, therefore, be built iteratively and shared widely in an effort to incorporate this feedback.

Within an ideal organization, this iterative approach to product development is a top-down initiative. But, if not, the product engineering team must step up and become the shepherds of process innovation. Thankfully, feature flags give us the tools to do so.

Feature flags are an engineering tool—an implementation detail. Their use is not predicated on any particular scope of design specification. If the product team uses an iterative workflow, feature flags are a natural fit. However, if the product team chooses to operate within a silo, feature flags can still be used to drive better process.

Remember, success is a shared responsibility. And, if the design team provides a "fully specified" feature, the engineering team is still responsible for deciding how to best implement said feature. Which means, the engineering team can choose to work iteratively even when implementing a fully specified design.

This is especially relevant if the engineering team is trying to bring about cultural change within the EPD organization. Change is always difficult; and, it requires tension. The engineers must be willing to lead the EPD organization on a journey that challenges the status quo.

And, perhaps the most challenging part of this cultural transformation is the inclusion of customers into the conversation.

There's no doubt that the product team reviewed Support tickets and performed some user interviews and perhaps even showed some of the early designs to a select group of customers. But, design feedback and product feedback will be different—period. Which is why we have to put our product in front of our customers, even when it scares us.

Of course, in most companies, engineers don't have much impromptu contact with real customers—such white glove service is normally handled by the product and design teams and other customer facing teams. Which means, in the early days of this cultural transformation, engineers have to treat their product and design teams as "the customer".

This is a transformative first step. Many designers won't connect with the concept of progressive delivery until they see it for themselves. So, by placing the responsibility of inclusion upon the shoulders of the engineers (at least initially), it allows the product and design teams to experience the flexibility of an incremental mindset without having to take a leap of faith on their own. This ends-up creating a lot of psychological safety for the designers.

As much as engineers feel pressure to get it right, at least engineers have control over the implementation. Designers, on the other hand, are another step removed from the final product. They're forced to deal in abstractions and play three-dimensional chess in their heads. And, if they get it wrong, designers know that they're setting the engineering team up for failure.

I believe this creates more pressure than even designers are aware of. And, I believe that this pressure manifests itself in very strange ways; such as going to war over pixel-perfection; and, venturing deep into the rabbit holes of redesign.

When engineers use feature flags to incrementally build and share a product internally, it gives designers the opportunity to experience their own designs as they come to life. This feedback loop removes the burden of perfection; and, provides the psychological safety in which to adjust designs early in the implementation process—before the cost of change is prohibitively expensive.

It turns out that engineers are uniquely positioned to bring the entire EPD organization to the table. By gathering feedback through iterative development, engineers have the ability to break down team barriers and instill a sense of co-ownership over the product. Not only does this lead to better product outcomes, it creates an environment in which people feel more connected to each other and to the work.

As the teams begin to internalize the value of iteration and inclusion, feature flags will slowly become a mandated part of the development process. And, eventually, a culture of shipping and sharing will become an expectation across the organization.

This is already a massive improvement over the status quo. And, if you stop there, you'll have radically changed the EPD organization. But, there's still more value to be had if you start including product customers in this culture of shipping and sharing.

It seems like it should be an obvious step to talk to customers about the product that you're building for them. But, customers tend to be an underutilized resource; especially once a project moves past the design phase.

Some of this comes from insecurity about sharing an incomplete feature. But, some of this comes from a misguided belief that customer feedback will lead to a less innovative, less compelling product.

It's important to remember that you're building products in order to solve problems for customers. And, the best way to know if a product is making a difference is to ask; both about what is working and what isn't working.

When you include customers in the conversation—and demonstrate that their feedback is being heard—the customers feel seen. And, they feel invested. In the same way that a culture of shipping brings the EPD organization to the table, progressive delivery brings the customer to the table; and, allows them to have that same sense of connection and co-ownership.

But, including the customer isn't just about instilling a sense of connection—getting customer feedback early and often is hugely beneficial for the product itself. The sooner a customer can try a feature, the sooner the EPD organization can get a sense of whether or not said feature is solving the right problem.

The truth is, until a feature is being used, it's all just guesswork. It might be educated guesswork based on prior evidence; but, until a feature is in the wild, the EPD organization really has no sense of how a feature will land.

In the worst case scenario, a large feature is deployed all at once and fails to gain traction. At that point, it's hard to know which aspects of the feature are problematic. Is it a small issue that's causing a big problem? Or, is the feature itself failing to connect with the customer needs?

It's always better to start small and gather evidence along the way. And, when a product team works iteratively and inclusively, it has the opportunity to fail fast. Meaning, it can identify—and address—issues early in the process when change is less expensive. This helps to ensure that the final product actually matches the customer expectations.

Building products that people love doesn't happen by accident. And, it doesn't happen all at once. The key to success is building iteratively and working collaboratively. This requires trust and love and generosity. And, it is made possible with feature flags.

#The Necessity of Qualitative Data

Quantitative data is numerical information that can be measured and counted. It deals with quantities and amounts, making it more objective and suitable for statistical analysis. Qualitative data, on the other hand, is non-numerical information that describes qualities or characteristics. It is often subjective and deals with qualities that cannot be easily measured.

When a team operates within a siloed workflow, quantitative data is the guiding light because it is often the only light. Metrics drive all decisions and provide all feedback. Customers are merely an abstracted concept—a source of measured input.

But, when you include your customers in the conversation—and bring them into the product development life-cycle—you open yourself up to qualitative data. This keeps you connected to the people that use your product. Qualitative data provides a visceral dimension to their pain; and, surfaces problems that cannot be seen in the data.

Mother Teresa understood the problem with quantitative data. She was known for saying:

If I look at the mass, I will never act. If I look at the one, I will.

— Mother Teresa

She understood some fundamental truths about the human psyche: that human reasoning is not well equipped to consume statistics; and, that human emotion is a critical part of the decision-making process.

When people examine a situation from a statistical standpoint, they become numb and detached from the underlying information. Which makes it hard for people to use numbers as a means to motivate. This creates a counter-intuitive situation in which it actually becomes harder for people act as the evidence of pain and suffering becomes more abundant.

Mother Teresa circumvented these limitations by dealing with individuals. She used human connection to charge her emotions and hack her own psychology.

We can do the same; and, we must do the same. Maintaining an intimate connection with the people who use our product is—sometimes—the only way that we can reliably stay focused and motivate ourselves to act on behalf of the customer.

Qualitative data also helps to counteract the curse of knowledge. That is, by talking to customers about the product evolution, it helps the EPD organization understand the beginner's mindset and experience the product through the customer's eyes.

When we use feature flags to share new concepts and to work iteratively and collaboratively with our customers, we immunize ourselves against the negative impact of hubris. We accept that we don't know everything; and, we embrace the generative power of human connection and open conversation.

#Incremental vs. Innovative

One common objection that people have to incremental / iterative work is that it orients the team toward small changes. This is true from an implementation standpoint; but, it has nothing to do with the overall vision of the product. The team can still make large, innovative changes—it just needs to make them using small, incremental steps.

When thinking about innovation, the only meaningful difference might be how early the customer is brought into the conversation. If the team is working on something truly revolutionary, getting customer feedback too early may create more distraction than it's worth. This, however, has nothing to do with how often feedback is gathered internally to the EPD organization. Which means that using feature flags and working incrementally is not in opposition to innovation.

That said, I do believe that organizations often over-index on innovation. Yes, innovation is important; and creates product differentiation. But, most of the time, we should be meeting our customers where they are. Which means removing small frictions and adding small improvements. This is an act of love and generosity; and, if we do this often enough, we will end up creating a lovable product.

Have questions? Let's discuss this chapter: https://bennadel.com/go/4560