The Natural Tendency to Ship Mediocre Products & The Importance of Unreasonably High Expectations

As consumers, we all understand intuitively that details matter. All of us have experienced products that are hard to use, apps that feel carelessly constructed, slow, buggy, and lack the features we expect to see. We have all felt the frustration of trying out app after app and cursing quietly (or loudly) wondering why obvious issues are present and why teams that built them could not have done a better job. We wonder about their judgment, taste, and skill. Our negative and positive product impressions transfer to the companies that built them, making them forgettable footnotes or burnishing their reputations as trustworthy brands.

As consumers, we all understand this intuitively, and all of the builders inside of companies do too. So why is it that so many poor products exist? Why is it that so few companies get the details right? Why is it that app stores are littered with poorly rated apps when clearly their creators aspired to build smash hits? It turns out that the way product building organizations, particularly digital product building organizations, make day-to-day decisions both at the macro and micro levels, have a natural tendency to negatively impact product quality. This may sound counterintuitive but it’s true. If you work in the industry of digital product building, like I have over a career spanning more than two decades, then you know all too well that day to day decisions chip away at the intended quality that all teams start out with. No matter the starting aspiration, there are a number of endemic forces that pressure teams to deliver something subpar. These forces emerge from practices with positive intent and positive impact, but they come with downsides that systematically and dependably erode product quality. Some of the major ones:

1. The ability to remotely update digital products makes it easy to cut features and quality in favor of getting a product out faster (because you can always add things in later).
2. The ability to measure usage data (known as metrics) at microscopic albeit still crude levels allows teams to take a wait-and-see approach before investing more into a product or feature area.
3. Metrics-based decision making is easier to scale across an organization and defend against stakeholder scrutiny than instinctual, subjective, judgment-based decision making.
4. Federated development structures, leveraging multiple feature teams (or scrum teams), to collectively deliver a product encourages teams to play it safe rather than to take risks.

Together, these forces inject rationale into the day-to-day decisions at the micro and macro levels that repeatedly call for the narrowing of investment into a product and full featured-ness. Day-to-day, these forces show up in the interactions that are part and parcel of every product building organization. Questions such as the following are instantly relatable to all builders across our industry:

• “How do we know this will move our key metrics?”?—?an ask to provide defensible data (and, to a lesser extent, logic) to justify the investment of resources (time, people, money).
• “How will this move the needle?”?—?coded language for a metric that resonates with leadership and the board
• “What’s the ROI of this effort?”?—?an ask to provide an estimated return on investment
• ”What’s the MVP version of this product?”?—?an ask to bring back the minimum version that we can launch.

Each of these questions and the many like them, place builders into the position of defending their investment choices. Builder teams know these questions are coming and so they naturally ask these questions on their own. Business operators are rewarded for cheaper and faster and that thinking trickles down to builders. Faster and cheaper is rewarded at every stage of planning and building, so the small details that are hard to envision ‘moving the needle’ get cut. It’s simply easier for builder teams to gain alignment by cutting features and launching earlier than proposing a later or more expensive launch. It’s simply easier to take shortcuts with less optional UX than propose a more costly build.?

The actual hard?question

If you’re still reading (thank you), you might be thinking, ‘oh here goes another creative griping about business realities.’ On the contrary. As someone who works in a leadership capacity I know that these forces and questions arise naturally in the course of business. Even if we are not explicitly articulating them out loud, they are considerations any leader must keep in mind. I have long accepted these forces and consider the skill to manage them effectively a crucial part of development in design teams and individuals. These forces exist because the modern product development practices from which they emerge also create tremendous upsides.

1. The ability to remotely update an app enables a previously unparalleled level of experimentation and resource optimization, allowing teams to get products to market earlier and invest where they see the most traction.
2. The ability to make decisions using usage data (i.e. which screen/states users spent them most time on, which links/buttons they tapped on) brings an unparalleled level of richness to the decision making inputs.
3. Making decisions based on data vs opinions is simply easier (full stop). You don’t have to convince people that you’re right if the data does it for you.
4. Splitting the work required to build a complete product into multiple teams helps organizations move faster.

The problem isn’t that we launch iteratively, measure usage, make data based decisions or federate development. The problem is that we don’t consistently recognize the downsides of these practices and work to counteract them. I’m referring to companies, not individuals. In order to build a quality product, organizations have the organizational know-how to prioritize the activities and craft that deliver the extra features, small details, and quality that would otherwise get cut by the naturally emerging forces of modern product development practices. While many confuse the questions I posed above as being the hard questions, the truly hard questions are how to counteract the downsides of these very natural and obvious questions.

Where to?start

Building quality products all starts with appreciation of the afore-described dynamic at the very top of the company. Leadership teams have to understand the natural dynamics that’ve described above, and counteract them by making room for subjective, instinctual decisions in the name of quality. When they don’t, there is no hope. At the very least you need two influential individuals who hold this belief dear. One is the CEO. This individual sanctions and models the behavior that informs all the teams that affect a product’s quality because they all ultimately roll up to them. It can also be the CPO if they have an aligned CTO and have broad latitude to define and drive their investment levels. The second person is the CDO or top design executive who marshals the craftspersons that will define the user experience and thus has the most direct ability to influence the craft and elegance of the product interface. It’s certainly helpful to have more members of the leadership team understand the dynamic but these two are the minimum. You can’t have less. Without a supporting CEO, a CDO has limited ability to impact quality because they don’t control the development or product management resources. Without a CDO, a CEO or CPO will have limited ability to drive the craft through the design organization. Arguably you could start with just the CEO who then hires or elevates a CDO to deliver a shared vision of craft (see Jobs and Ive). In very very few organizations, these two persons are the same person (see Brian Chesky). In very large organizations you might also have a GM and with broad latitude that doesn’t have the CEO title but even then the GM will borrow from the practices and ethos laid down by the CEO. If the CEO does not have an understanding of these forces, it’s unlikely the GM will have the latitude to operate in a way that counteracts them.

Once you have these two minimum roles in place, they must then create space for those subjective, intuitive decisions that allow the small details impacting product quality to thrive. And there are many levels to this. Crudely:

1. Level One, is to lead by example, to consistently make judgment based decisions that prioritize quality and communicate that details matter, and why (more on that later).
2. Level Two is to introduce working frameworks that counteract the negative forces. A few examples include product principles that direct builders not to cut the details, adding qualitative research that allows builders to regularly observe and listen to users experiencing their products, and adding benchmark metrics like NPS or CSAT. Many teams do have these functions and metrics but they are often largely performative. Just having them is not enough, teams have to be given the directive and the space to really use them well.
3. Level Three is building a commitment to quality into the way the company hires, fires, rates employee performance and gives feedback. This third level takes surface level principles and builds quality into the so-called DNA of a company.

In practice, making room for subjective quality decisions, means that leaders have to be willing to exhibit seemingly unreasonably high expectations. In order to push a team to counteract the negative forces that lower product quality, leaders have to express points of view that will seem to quizzically defy the accepted ways of doing business. These high expectations will flummox and inflame many and perhaps even drive some people out, but the truly passionate product builders will stay and acquire new ways of thinking and doing, and teach those ways to others. I’m not talking about overworking teams to the bone but rather about countering the natural tendency to build something mediocre. In his 2012 article, The Real Leadership Lessons of Steve Jobs, Harvard Business Review, 2012, Isaacson W. , biographer Walter Isaacson, wrote posthumously about Steve Jobs’ push for perfection, his prioritization of products over profits, and his “(in)famous ability to push people to do the impossible.” In one particular example Isaacson writes,

“The initial design [of the iPhone] had the glass screen set into an aluminum case. One Monday morning Jobs went over to see Ive. “I didn’t sleep last night,” he said, “because I realized that I just don’t love it.” Ive, to his dismay, instantly saw that Jobs was right. “I remember feeling absolutely embarrassed that he had to make the observation,” he says. The problem was that the iPhone should have been all about the display, but in its current design the case competed with the display instead of getting out of the way. The whole device felt too masculine, task-driven, efficient.”

In the very last sentence Isaacson captures Jobs’ and Ive’s willingness to tap into something they feel instinctively vs something that can be measured. He then goes on to share how Jobs scrapped 9 months of hard work to start again and his team agreed! Jobs not only excelled at tapping into his product instinct but also had the willingness to have unreasonably high expectations on execution, and the ability to build this willingness into Apple’s DNA.?

Pragmatism is kryptonite

While this is a rather dramatic example, there are dozens to hundreds (and sometimes thousands) of product decisions made throughout the development journey, each individual decision testing contributing teams and the organization’s willingness and commitment to achieving its vision. Along the way there will be countless reasons given for why you ought to not do the hard thing. There will be countless reasons given for why you ought to not throw away existing work, spend more money, spend more time, risk pissing off your investors, your partners, and your team, etc. etc. At each decision point there will be pragmatic voices calling for the sensible, reasonable, conservative approach. The vast majority of businesses are filled with pragmatic voices because pragmatism is generally regarded as a virtue. But pragmatism is kryptonite when it comes to product building. The pragmatist is risk averse, the pragmatist does not go the extra mile, the pragmatist sets the bar at average. Average expectations lead to mediocre products. That is why it is so important to have the willingness and courage to be unreasonable.

Chances are, you already have these unreasonable voices in your company. But they have been trained to let the pragmatist voices lead. It’s hard to operate on feelings, it’s hard to understand why something isn’t sitting right and then extract the underlying principle leading to a higher level of understanding. It’s worlds easier to just a/b test something and let a crude metric decide. It’s worlds easier to cut features and launch on time than explain a delay. It’s worlds easier to be pragmatic and reasonable than stick your neck out for something you believe and feel but is hard to articulate.

To tap into unreasonable voices, leaders need to embrace being unreasonable, reward the unreasonably high bar, and evolve their organizations to expect it. Without that willingness, you are destined for average.

Anchoring your?‘why’

Pushing beyond accepted norms is not easy… in fact, it’s crazy hard. Leaders face tremendous pressure to deliver measurable results and manage organizations well. To succeed it’s critical to have a shared thesis as to why product quality matters for the business. I would argue that product quality matters for every business but there are levels and variations. A leadership team may use product quality as a way to catch up to a competitor or create distance between it and the competition. It might see a strong product quality track record as a brand differentiator and organizational capability that opens up the ability to compete in new spaces and expands the business. It may see commitment to quality as part of their heritage, sacred to protect and continue to burnish. Whatever you (company leadership) choose to be your clarion call for quality, I advise that you pick one and anchor your decision-making repeatedly and dependably to it, such that your board, your leadership, your middle management, and your entire organization is aware of why quality matters and buys in. That way you pass the thinking and logic up, across, and down into the org such that they can affect the day to day decisions from macro all the way down into the micro levels.

Recognizing the work of?many

There are, of course, many other functions that contribute positively to product quality and I would be remiss if I did not recognize the importance of quality engineering, quality control, planning and project management, rituals, etc. all of these functions and their leaders contribute to quality. All of these pieces are crucial ingredients. But without leadership buy-in and a willingness to have, not just entertain but heed unreasonably high expectations, all other well-intentioned and highly capable entities have limited ability to improve quality up to the extent that meets the organization’s potential. A single engineer might be able to independently deliver a superlatively performing piece of software but that does not result in a widespread commitment to quality without top level buy-in.

About the?Author

Calvin Nguyen has designed and built products in the digital space for over two decades, spanning consumer, b2b, digital pure play and multi-modal services and products. He has led design and research teams that have brought some of the most well known and disruptive products to life. His work has been used by 100s of millions of users worldwide.