This is the second of three posts on David Graeber’s notion of the ‘bullshit job’: pointless work that becomes psychologically destructive in cultures that associate work with self-worth. Bullshit jobs can introduce wasteful work on a massive scale, thereby allocating scarce resources and manpower to work that generates little (or even negative) impact. In the first post, I explored the kinds of bullshit jobs Graeber identifies and to what extent consultants have such jobs. In this post, I explain why I beg to differ: working as a consultant for me involves getting rid of bullshit, not adding more to the pile. How does this work?
Bullshit filters
As indicated in the first post in this series, consultancy can be a gateway drug to bullshit. Consultants, masquerading as benign helpers, may not always act in accordance with the best interest of their clients.
Here’s what a ‘non-bullshit’ product management consultant should be doing in my book: building adaptive organizations by using the following 5 ‘bullshit filters’.
Bullshit filter 1: Build bridges between high-level strategies and the day to day challenges of product development to create a sense of purpose and ownership
Many organizations suffer from a lack of alignment on longer-term goals and how to reach them. Organizations usually have some vision, but it doesn’t feature prominently in the work being done because it isn’t really lived. Many symptoms emerge from this. For example, ‘business’ and ‘IT’ have a dichotomous relationship, and there’s a great deal of inefficient handovers between these silos. As a result, ‘management’ has no clear idea how the daily activities of product development contribute to their longer-term goals. In a desperate attempt to leverage control and manage stakeholders (“when will it be done?”), organizations may seek salvation by adopting a project mindset focused on fixing scope, budget, and deadlines. The expectation is that this mindset will allow them to predict the success of product development. As a result, development teams are stuck in the trenches, trying to meet the deadlines imposed upon them from above, mourning silently in remembrance of an inspirational leadership session at the beginning of the year that set such beautiful big hairy audacious goals.
Sounds familiar? Perhaps you can find some solace in the fact that you’re not the only one stuck in the gap between company vision and daily work, better known as the ‘product management vacuum’ (ominous music intensifies).
Bullshit filter 1 is all about traversing the product management vacuum. To do so, the company and product vision are made actionable by translating them into concrete steps (e.g. roadmaps, epics, and product backlog items such as ‘user stories’). Subsequently, these actionable steps need to be revised persistently and relentlessly, for example by collaborating closely with end users (see bullshit filter 3). Having a measurable and concrete idea of outcomes (see bullshit filter 4) can be extremely beneficial here.
Once the product management vacuum is bridged, those working on a product develop a sense of ownership and purpose, since they know where they’re going, as well as the steps involved in getting there. As a result, teams can become more effective, efficient, and innovative. I’ve seen teams become highly aligned, since they know where to go, but also highly autonomous, since they know what problems need fixing and can dedicate themselves fully to figuring out how to best solve these problems. Product managers that used to micromanage these teams now more time to do the things that really make a difference: stakeholder management, market exploration, etc.
Bridges crossing the product management vacuum are only helpful if they are validated through regular feedback loops that are integrated into the organization’s way of working. Process trumps truth, since the latter is not known beforehand in complex environments. Delivering a full-fledged product after a relatively long time is risky, since the product delivered by then could be at odds with the rapidly changing demands of the marketplace. Instead, organizations are better off ensuring they deliver early and often to customers. Subsequently, the insights from each delivery can be incorporated into the next development cycle. Build, measure, learn – and start over, again and again.
Bullshit filter 2: Facilitate collaboration across organizational silos
When failing to align on the basis of shared goals, a common tendency for organizations is to organize on the basis of disciplines. The resulting organizational silos cause ineffective and inefficient communication between different departments. For example, sales departments are the commercial tip of the spear, but lack a clear idea of what ‘the factory’ is building. In turn, IT departments lament the lack of interest from their peers with a more commercial focus, and may react by focusing on building the thing right rather than building the right thing. The resulting patterns may become habitual and over time become as self-explanatory as the law of gravity.
Having actionable steps towards a clearly identified goal helps to align different departments. Based on these goals and the steps that emerge from them, organizations may aspire to reorganize into so-called ‘end-to-end teams’. Such multi-disciplinary and cross-silo teams contain all the expertise required to build a full increment of a product that can be delivered to the market. When teams are able to deliver a complete increment of a product without depending on other teams, the ability of organizations to learn from end users, stakeholders, and the market increases dramatically. Speed of delivery is optimized through efficient communication across former silos, and releasing early and often fosters the ability to pivot to more fruitful pursuits.
Bullshit filter 3: Involve end-users
The only way for product teams to really ensure they’re making something valuable is by releasing something to the market, and thereby open the door to feedback. An even more effective way to ensure you’re building the right thing, is to involve end users in figuring out what you need to work on. The Agile Manifesto favors customer collaboration over contract negotiation for a reason: building something in collaboration with end users and/or customers greatly increases an organization’s ability to learn from user demands, and decreases the risk of the product running out of sync with the demands of an increasingly demanding user base. Rather than a big bang release after an extensive period of planning, coding, and testing, releasing early and often creates a fast build, measure, learn loop (see bullshit filter 1).
The amount of product teams that have no to little contact with end users never ceases to amaze me. “We can’t just walk up to the user and take up their precious time, can we?” Sure you can. You’d be amazed how many people like to express their worries and ideas. Just think of all the precious time you can save and how much additional value you can create. Those using your product will thank you for it.
Bullshit filter 4: Measure the impact of products
Knowing how your product is being used pays off, since it shows where users encounter problems, what functionalities could be improved to create an even more valuable product, and what features may have little to no value. Talking with users (see bullshit filter 3) is an obvious way to find out more about the impact your products actually have, but there’s also a great deal of technical platforms that enable the collection of large quantities of data about the use of digital products.
More generally, measuring the impact of products is important in building a product-oriented mindset, which can be highly advantageous for organizations. In a project mindset, discussions are primarily ‘inside-out’ and tend to focus on deadlines, scope, and budget. A product focus is ‘outside-in’ and focuses more on evidence-based ideas of value: how is the product used? What do users have to say about it? How can ideas we have developed internally be validated by delivering early versions of the product to the market?
Organizations that shift towards a product focus operate in a different paradigm in comparison with output-oriented organizations. Ultimately, output doesn’t necessarily create impact. Output can lead to impact, but in itself isn’t a reliable indicator of impact. For example, an organization that produces a product with numerous features that end up having impact can pride itself on making that impact on the basis of the large number of features produced. What if an organization’s competitive edge is based on a subset of those features? What if the organization fails to see this, and thereby fails to prioritize properly? And what if all that output doesn’t generate any impact? Shouldn’t an organization decide to pursue different goals on the basis of these insights?
In the world of product development, studying the impact of products leads to a more elaborate understanding of success. Evidence-based frameworks to measure product impact can guide organizations along the way. Take for example Pirate Metrics, which measures acquisition, activation, retention, referral, and revenue, but also the Evidence-Based Management Guide developed by Scrum.org.
Bullshit filter 5: Training and coaching
Applying bullshit filters is no small feat. Together, they can add up to a profoundly different way of working. Insights from a product-oriented mindset are easy to understand, but difficult to implement and master in practice. A crucial part of my work for clients involves setting up workshops and training sessions that increase familiarity with product management-related topics. Subsequently, I often stay on board to ensure the adoption of principles, to see whether concepts and methods are applied correctly, and to address problems that will surface along the way. After an initial honeymoon period, it’s highly likely severe issues come to the surface. That’s fine – these issues were there to begin with anyway. There’s no way to identify all of these risks beforehand. In complex work, it’s better to just start and see where you end up.
Conclusion
Applying these bullshit filters helps to validate assumptions persistently and rigorously, and thereby trim the fat. In fact, a consultant may render herself redundant if the principles above are successfully integrated in an organization’s way of working. Bullshit filters should enable organizations to have less bullshit, not add more to the pile.
As much as the 5 bullshit filters above contribute to de-bullshitification, you may be tempted to think “that all sounds just fine, but why should I act in this manner?” Well, dear reader, a lot is at stake. Stay tuned for part 3 in this series on ‘Consultancy as Bullshit Job’, the last post in this series.
