One of the hardest things for us as human beings is to adequately balance focus on our own goals and drivers and the needs, requests and influences of others. We all know people who sail their own course no matter what others ask of them and we know people who are so responsive to others that they have no direction for themselves whatsoever. We tend to like the latter group better but wish they would bring more to the conversation.
In psychology, this is mapped out on the disagreeable versus agreeable axis. Although we all sit on a bell curve, some of us are far out on the disagreeable end, which is associated with some of the very successful entrepreneurs (as well as criminal behavior). Those on the other extreme tend to be more likable, have more friends and have more of a support system around them but also tend to suffer more heavily from anxiety and other mental afflictions.
Interestingly, this doesn’t only apply to individuals but also to companies. Some companies have defined a vision for themselves and are executing on a strategy that they wholeheartedly believe in and no input from customers, partners or suppliers will cause them to deviate from that course. Companies at the other end of the spectrum don’t have much of a strategy but instead, constantly seek to respond to feedback from customers and others.
In my experience, Agile is, at heart, more toward the passive side of the spectrum. The backlog is shaped and prioritized by the requests and input from the various customers. Of course, in larger organizations, these requests are processed and managed by product management activities, but in essence, we’re responding to what customers are asking of us. In, of course, the most agile fashion.
Most companies I work with claim to be customer-focused. Many interpret this as seeking to respond to every whim of any customer. Although this does result in periodic positive responses from customers, the organization tends to become overworked as there are always more requests than we can handle, no matter how many people we hire. More seriously, it tends to lead to commoditization of the offering and decreasing competitiveness.
How can it be that as we do everything we can to react to customers, we still end up in a bad place from a competitiveness perspective? There are at least three reasons: irrelevant additions, inconsistent products and being too late.
First, although customers will ask for things and consider their asks really important at the time they express these wishes, in many cases there’s little relevance to them and the product over time. The consequence is the addition of many small and not very relevant features and functions to the product at the expense of more important functionality.
Second, the result of these small additions is that the product tends to get bloated, complex and inconsistent. As different customers have different preferences on how to solve certain use cases, the consistency of the product tends to decrease and, as a consequence, more complexity is introduced into the product. There are so many things that users could do, but so few that they need or want to do that most of the features are useless to them, as a result of which they experience the product as bloated and complex.
Third, and this could be viewed as the most serious concern, is that we tend to add important and differentiating functionality too late. Of course, an overflowing backlog tends to push the more strategic functionality to the back as teams simply are too busy to take on large challenges, no matter how important.
The more important consequence is that if we wait until customers can express their needs, we’ve opened ourselves up for disruption from companies that operate more strategically. In the timeline of new features, there’s a point where a new feature becomes relevant for customers, but they’re not yet aware of this need nor are they able to express it. At a later point in time, customers become more consciously aware of their needs and can express them and request them from us.
The time between these two points is where we get disrupted. During that period, new entrants that have a deep customer understanding and are executing on a strategy to meet important, but unexpressed, needs may be able to convince our customers that they’re better served by switching to the competing offering. This is one of the key reasons why waiting for customers to ask for new functionality and features is so dangerous.
In the previous post, we raised the importance of having a clear and precisely defined strategy. However, we’ll be influenced by others as we start to execute on it. The challenge is to know when to be responsive and when to ignore. This requires us to triage the inputs we receive into those we incorporate, those we ignore and those we morph into something that gives a partial response. In my experience, there are at least three important tactics to consider here: customer-first versus customer-unique, offering something better and firing the customer.
First, we distinguish between customer-first feature requests and customer-unique ones. If a customer requests something that aligns with our strategy but would require us to change the order and timing of building that functionality, it may well be worth doing. We seek to be responsive to our customers and building something that we plan to incorporate anyway is a good way to achieve that. Customer-unique feature requests are those that aren’t in our strategy and that, for all we know at this point in time, won’t be relevant for other customers. In those cases, we should really decline – which brings us to the second strategy.
Whenever we’ve decided to say no to a customer request, we should seek to present this in such a way that the customer is promised something else that we do intend to build anyway. In that way, we can manage the situation and achieve an outcome where the customer feels good about the value that’s being received. It also allows us to reiterate the strategy we’re pursuing and reinforce the buy-in from the customer on that vision.
Finally, if the customer isn’t receptive and the strategy doesn’t align with the customer, we could consider firing the customer. This doesn’t necessarily mean cutting the customer off from the offering, but rather deprioritizing the customer and reducing or removing account management, support and other activities our highest-priority customers get.
In startups as well as companies in general, there’s an important distinction between making customers happy and making happy customers. In the first case, we seek to satisfy the needs of anyone who happens to be our customer and many of the problems discussed in this post originate from that approach. I’ve seen my fair share of startups being reduced to glorified consulting companies that have one or a few customers for exactly this reason.
In the second case, we have a very clear idea of the ideal customer we want to serve. Any customer matching that profile gets preferential treatment. Any customer that doesn’t is explained what we seek to do and if it turns out that there isn’t enough of a match, we should say goodbye to this potential customer. That allows us to focus all our energy on making the customers that do match our strategy really happy.
The Agile paradigm is, at heart, a reactive and passive approach. This results in all kinds of challenges including an overworked organization, bloat and complexity in the product, reduced competitiveness and increased risk for disruption. Instead, we need to be responsive while maintaining the execution of our strategy. Being responsive means carefully triaging the external influences and forces and intentionally deciding on which ones to incorporate, which ones to morph and which ones to ignore. To end with a quote from John Doerr: “Ideas are easy. Execution is everything.”
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).
