{"id":1832,"date":"2024-04-29T07:36:51","date_gmt":"2024-04-29T07:36:51","guid":{"rendered":"https:\/\/janbosch.com\/blog\/?p=1832"},"modified":"2024-04-29T07:36:52","modified_gmt":"2024-04-29T07:36:52","slug":"from-agile-to-radical-triaging-external-forces","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2024\/04\/29\/from-agile-to-radical-triaging-external-forces\/","title":{"rendered":"From Agile to Radical: triaging external forces"},"content":{"rendered":"\n
\"Image
Image by Gerd Altmann from Pixabay<\/figcaption><\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Interestingly, this doesn\u2019t 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\u2019t have much of a strategy but instead, constantly seek to respond to feedback from customers and others.<\/p>\n\n\n\n

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\u2019re responding to what customers are asking of us. In, of course, the most agile fashion.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

First, although customers will ask for things and consider their asks really important at the time they express these wishes, in many cases there\u2019s 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

The more important consequence is that if we wait until customers can express their needs, we\u2019ve opened ourselves up for disruption from companies that operate more strategically. In the timeline of new features, there\u2019s a point where a new feature becomes relevant for customers, but they\u2019re 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.<\/p>\n\n\n\n

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\u2019re 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.<\/p>\n\n\n\n

In the previous post<\/a>, we raised the importance of having a clear and precisely defined strategy. However, we\u2019ll 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.<\/p>\n\n\n\n

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\u2019t in our strategy and that, for all we know at this point in time, won\u2019t be relevant for other customers. In those cases, we should really decline \u2013 which brings us to the second strategy.<\/p>\n\n\n\n

Whenever we\u2019ve 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\u2019s being received. It also allows us to reiterate the strategy we\u2019re pursuing and reinforce the buy-in from the customer on that vision.<\/p>\n\n\n\n

Finally, if the customer isn\u2019t receptive and the strategy doesn\u2019t align with the customer, we could consider firing the customer. This doesn\u2019t 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.<\/p>\n\n\n\n

In startups as well as companies in general, there\u2019s 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\u2019ve seen my fair share of startups being reduced to glorified consulting companies that have one or a few customers for exactly this reason.<\/p>\n\n\n\n

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\u2019t is explained what we seek to do and if it turns out that there isn\u2019t 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.<\/p>\n\n\n\n

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: \u201cIdeas are easy. Execution is everything.\u201d<\/p>\n\n\n\n

Want to read more like this? Sign up for my newsletter at\u00a0jan@janbosch.com<\/a>\u00a0or follow me on\u00a0janbosch.com\/blog<\/a>, LinkedIn (linkedin.com\/in\/janbosch<\/a>) or\u00a0Twitter (@JanBosch<\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

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 … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"generate_page_header":"","footnotes":""},"categories":[8,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1832"}],"collection":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1832"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1832\/revisions"}],"predecessor-version":[{"id":1833,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1832\/revisions\/1833"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1832"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1832"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1832"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}