The Politics of Product Development

Photo by Daria Nepriakhina on Unsplash

Being both a product manager and a critic of the current political climate, in the Western world, produces an interesting intersection of concerns. You find yourself reading literature from both spheres, noticing the obvious similarities. Having done this for quite some time, I’ve reached the conclusion that product development and politics have a lot in common — far more than I initially anticipated.

More than that, some of the best practices evolving in product development are actually applicable as solutions in the political realm. Similarly, the newer movements emerging as political solutions to our troubled global governance can inform how to go about organising product management, design and development. There is a symmetry of mindset available, if you care to cross-pollinate the two fields. There are also some irreconcilable conflicts, which shed light on why product development, as currently practised, so frequently fails to achieve its goals.

Product anarchy

If you drill down into what agile development methods, scrum, jobs-to-be-done and various other modern product development processes or frameworks have in common, it is that they are essentially anarchistic in nature. I don’t mean that they want to cause destruction, lawlessness and mayhem, which is what “anarchy” invariably means in the popular imagination. I mean anarchy with a small “a”, referring to a method of getting things done which is self-organising and anti-hierarchical in nature.

These experimentally-validated development methods eschew big, up-front planning, command and control organisation and linearly scheduled work, using developers as fungible “resources”, in favour of a more realistic approach to how products actually get created successfully. The most successful products are made by people with intrinsic motivation, skill, initiative and a desire to continuously improve what they do for a living. Much of what we once thought was the right way to go about managing product development has been comprehensively discredited by experience. It doesn’t matter how beautiful your theory is, or how smart you are, if it disagrees with experiment, it’s wrong.

This new(ish) radicalism in product development, centred around how to get things done collaboratively, reflects and re-actualises traditional anarchist principles, such as mutual aid, self-management, participatory decision making by consensus and decentralisation. Contemporary product development teams are far more democratic in nature than traditional product development flows permitted (the latter largely being a matter of slavishly realising specifications, handed down from on high).

A clash of cultures

This new way of thinking about how to do the difficult work of product creation is in direct conflict with the way most corporations and product development teams are organised. The conflict arises because it has been grafted onto traditional capitalism, with its top down management hierarchies and quasi-feudal power structures. Today, product development best practice and corporate organisation charts are in open misalignment.

Whereas product developers demand unimpeded creative freedom to do the work as best they see fit, without unnecessary hindrance or interference, this clashes violently with generally accepted, long-established prejudices and notions about the function of management, the corporation, shareholders, the government and the “state”, as it is also called. In other words, what increasingly works in product development is in stark contradiction to the way product developing corporations want to manage. Furthermore, unless you’re in a product development team, it’s difficult to even imagine that work can be done in any other way than through the multi-layered management hierarchy that characterises most of these companies and the society people live in.

We are facing new questions. What happens when the boss is not the authority? How do you recognise relevant skills and expertise respectfully, at different points in the product development life-cycle? If the lunatics are able to run the asylum unaided, what are the various layers of middle management for and what do they do?

An anarchic manifesto

The Agile Manifesto, which outlines the core beliefs and principles of agile development, could be equally well applied, with minor modifications, to organising all human relations, not just product development.

Here is the Agile manifesto, quoted:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

Let’s break the manifesto down and paraphrase it:

It has a preference for humanity and human communications, over mechanistic systems or rigorously defined processes. Implied in the desire to have working software over documentation is a bias toward action over inaction. Another way of saying this is to prefer effectiveness over theoretical correctness, or doing over pontificating. That’s a very pragmatic approach. Collaboration and cooperation are clearly desirable, over domination, subjugation or deception. Contract negotiation is often adversarial, whereas collaboration with a customer tends toward mutuality and consensus. Remaining fleet of foot, in the face of inevitable change, strongly values flexibility over rigidity.

You could reorganise geopolitics, the legal system and the global economy along similar lines, if you come to think about it.

Principle driven policy

The principle of agile development, in all its myriad incarnations, is to expose, de-legitimise and dismantle mechanisms of rule that run counter to achieving the product’s goals. Accepted, orthodox, product development practise is constantly challenged and held up to scrutiny. The quest is for working software, designed in collaboration with customers, with a focus on interactions with individuals, rather than turning the handle on the development method and watching the cranks turn mechanically. You’re encouraged to learn and to change your mind (and the complexion of the product), as you know more. Very little is set in stone.

Here are some selected agile principles that demonstrate the anarchic (in a positive way) character of this mindset:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. — What is most noteworthy about this declaration is that the highest priority is not to satisfy investors or managers; it’s to satisfy customers. In corporations, by comparison, shareholder profit is mandated, by law, as the highest priority. A principled approach to product development runs counter to that. Also noteworthy is the desire to deliver valuable software, not to destroy value, as often happens in highly financialised organisations.
• Business people and developers must work together daily throughout the project. — In common with twenty-first century anarchy, this principle is anti-hierarchy, flattening the status pyramid into something more egalitarian and collaborative. It removes the deference and precedence that the business managers and money people traditionally expect from developers.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. — In common with anarchic principles, this principle speaks about autonomous self-governance. There are no taskmasters and there ought to be equally little supervision. Let the makers figure out how to make the product. Checking up on their progress or second-guessing what they ought to be capable of producing, per unit time, is anathema. Whereas most companies fixate irrationally on optimising productivity, modern agile product development practice explicitly rejects this as a goal.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. — In common with modern anarchy, this agile principle proposes mesh networks, not a pyramidal hierarchy. Face-to-face implies peer-to-peer. It is not about setting policy at a management level and fanning it out by edict, to those nominally below them in the organisation chart. Conversations imply negotiation and discussion. This principle is all about treating developers as equal partners in a two-way, face-to-face conversation, not simply being told what to do and expecting them to do as they’re told.
• Working software is the primary measure of progress. — Again, what is worthy of note with this principle is that the primary measure of progress is not profit, or shareholder returns; it’s working product. This is in stark contradiction to how most product development organisations measure their own progress. Whereas you can easily find companies with financial balance sheets, you won’t find many that share their working software trend figures at the executive level. This is also not a metric that is ever explicitly reported, formally, to the stock market or the company’s investors.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. — Here, the developers ask that you don’t yank them around capriciously and arbitrarily. In other words, it’s a rejection of traditional command and control management, with its sudden changes in direction, exhortations to work silly amounts of overtime to make a release deadline and other activities that result in eventual burn out.
• The best architectures, requirements, and designs emerge from self-organising teams. — This principle couldn’t be clearer. In common with anarchy, it asserts that there should be no rulers — only self-organisation. Leadership is fine, but it’s temporary and contingent on the fit between specific needs and the skills required to address those needs. It also doesn’t suggest no organisation or disorganisation. There are individual obligations and responsibilities, in a self-organising team.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. — Agile product development is not an ideology or a religion, with rigid beliefs and ceremonies; it’s a theory, subject to learning, modification and change. Compare and contrast this with the usual rules, guidelines, laws and other constraints that corporations (and the entire legal system) are so firmly wedded to. Behaviour is not prescribed; it is refined in response to self-reflection.

The basic principles employed in successful agile product development — mutual aid, voluntary association, egalitarian decision-making — are as old as humanity. They almost read like common sense, as they appeal to what people charged with making products know intuitively. These principles describe a mindset of constant questioning, an effort to identify every compulsory or hierarchical relation (in working and human life), and to challenge them to justify themselves. If they cannot — which usually turns out to be the case — an effort is made to limit their power and thus widen the scope of liberty. These principles hold in both anarchism and agile product development. Progress is made by consensus. They’re birds of a feather.

Core values and mindsets

The analysis above has shown that modern agile shares twenty first century anarchism’s core values of decentralisation, voluntary association, mutual aid, the network organisational model, autonomy, and participative management. Above all, agile product development rejects the idea that the end justifies the means, still a regrettably popular trope in corporate governance. The business of a corporate revolutionary is not to seize management power and then begin imposing one’s vision by coercion and the threat of being fired. It is, instead, an appeal to thinking better thoughts.

Aaron Sachs and Anupam Kundu of Thoughtworks speak of organisational transformation in terms of mindset shifts:

• From profit to purpose
• From hierarchies to networks
• From controlling to empowering
• From planning to experimentation
• From privacy to transparency

It’s not a very large stretch of the imagination to apply these core values and mindset shifts to politics and the economy. People need purpose within both. Networks are more effective ways of governing than hierarchies. Empowerment of citizens or market participants works better than top-down control. Rigid planning fails, where experimentation and learning work. I suggest that opacity and obscurantism is a better fit for what is meant by “privacy” and the mindset shift is moving from strategically hoarding secrets, toward greater transparency between people.

Praxis practicalities

Politics speaks of “praxis”. Praxis can be defined as a free, universal, creative activity with which one creates and changes the world and therefore oneself. It is common to encounter push-back against prescribed agile processes, in product development organisations. The developers claim, “It’s different here. We’re the exception. These problems are unique to us.” Actually, the problems are not unique.

Rather, they are invariably general and universal, but people say these things because they want to hang on to their free, universal, creative activity that they invent themselves, which changes both them and the world. It’s about self-determination and self-realisation. People want to define their own praxis.

This explains the lukewarm reception to formal agile frameworks, while paradoxically desiring many of its goals. The freedom is missing. Pre-packaged systems of product development process and other such frameworks are a hard sell.

Punch down; suck up

Software product development still suffers from the overhang of a bullying culture, thanks to the prevailing ethos in wider society. Developers still compete with each other ruthlessly and put weaker developers down dismissively, yet cravenly appease developers and managers senior to them in the hierarchy of the company. The prevailing mindset is, “Punch down; suck up.”

In the presence of a substantial hierarchy above them, developers are also prone to despondency and becoming apathetic to change, resigned to their role within the organisation as an immutable given, with all its associated creative limitations. They behave as if their hands are tied and lose all hope of improving anything. Punch down; suck up results in learned helplessness.

People, in general and software developers in particular simultaneously behave like bullies to those below them and as acquiescent, submissive cowards to those above, as a result of long term trauma and mistreatment in the work place and in their lives. From cradle to grave, people are propagandised into not sharing common cause, not helping each other, not investing in each other, never admitting to weakness or uncertainty and vanquishing and dominating people they perceive to be conquerable. It’s encouraged from childhood, while compassion, mutual cooperation and empathy are punished. Product managers must deal with the fallout of the distortions and dysfunctions that result from this virtual PTSD almost daily.

Agile product development seeks to defuse this predatory tendency by insisting on collaboration, equality, respect, diversity and getting things done, rather than jockeying for position in the pecking order. It is, however, a formidable battle. People do not discard bad behaviours overnight, especially when they are reinforced and rewarded so extensively in the world outside the development team.

Once again, it doesn’t take an Einstein to realise how beneficial the anarchic agile product development mindset would be, when applied to other spheres of human activity, such as the law, the economy and politics, not to mention the school playground. If punching down and sucking up worked, it would be a product development best practice. The fact that it isn’t represents a consensus from experience that it just doesn’t work as effectively as cooperation and a flat, meshed organisation. There’s an important lesson in that.

Square pegs; round holes

Product managers are caught in the crossfire between the anarchic nature of agile product development and the feudal nature of traditional corporate org charts. Even matrixed organisations are simply overlays on the so-called “line management” pyramidal hierarchy. They try hopelessly to reconcile the fundamentally irreconcilable.

Hapless Product Managers struggle to square this circle, trying to bridge the yawning chasm between being effective inventors of the future, beneficial to all of humanity, and the dead hand of financialised, private, for-profit corporations. The clash is inevitably regressive and careers have been destroyed on the altar of maintaining top-down control. Corporate lords and barons dislike losing control of their product development serfdom.

This clash of mindsets is what kills innovation and the reason why so much product development is badly misdirected, relative to more urgent, pressing, human needs. The conflict between control and empowerment explains, in large part, why the big problems, which technical solutions might help, remain unaddressed. There is, today, limitless investment in surveillance capitalism because it reinforces control over the population, but precious little on tools for human agency and empowerment. Even less is invested in environmental sustainability.

You can have effective, agile product development or you can have a (largely sub-optimal) command and control hierarchy, but you can’t have both. Deference to authority kills initiative, spontaneous good ideas and psychological safety. It subverts and frustrates group consensus decision-making and shows everyone that you care more about power and status than the product or customer outcomes. A fixation on profit dilutes shared purpose. The command and control mindset demonstrates a lack of trust in the people charged with making the product in a highly confrontational way. A willingness to insert unnecessary supervision over every task assigned, disempowers the workforce. If you allow experimentation only to the extent that it doesn’t impact the authorised, official plan, you’re stifling learning, discovery, validation and serendipity. To summarise, adhering doggedly to a feudal corporate structure crushes morale.

Trying to fit the square peg of agile product development into the round hole of traditional corporate hierarchies is never going to work satisfactorily, yet millions of dollars continue to be wasted trying to do so, resulting in sub-standard products and needless stress and friction within the company.

A failure to learn

The solution, of course, ought to be obvious. Corporations and the wider economy need to be organised more like agile product development teams and less like the military. In fact, even the military should be less like the military. Anarchy, with a small “a”, represents tried and tested, effective ways to organise human affairs and make progress. Wielding power within a hierarchy is a wasteful, miserable and inefficient way to make things and have a working life. It also negates the benefits of agile teams. We ignore what we’ve learnt at out peril.

We have a collective failure of will and imagination, if we can’t spread what works demonstrably well in software product development to corporate organisational structures and governance, and beyond that to wider societal and political spheres of concern. The patterns and methods are proven. They work. Why do they stop at the border of the product design and development team?

Ironically, the more software eats the world, the more opportunities there are for this anarchistic mindset (i.e. no rulers) to become the de facto way the world operates. We already have promising decentralised technologies, like Blockchain, peer-to-peer overlay networks and the Internet itself. They work. They have hitherto unknown properties and benefits. We know all that. Common sense anarchy is a good fit for the kind of world we wish to create, both embodied in software that serves us and in human relations. Agile product development offers us proof. We just have to want to change.

About the author

Michael Topic is a freelance Product Manager with over thirty years experience delivering products that didn’t exist before. He welcomes contract enquiries to define new, competitive products, design them and deliver them. His speciality is software-based products.

Disclaimer

The opinions offered in this article are intended to describe common scenarios that sometimes occur in general product management practice. They are in no way intended to be read as referring to any particular employer, past or present.