Junk Change and Pastiche Product Management

There is a malaise affecting Change Management and Product Management 

Junk - Photo by Jessica Palomo on Unsplash

Junk [creativity] : Worthless writing, talk, or ideas

Pastiche : An artistic work in a style that imitates that of another work, artist, or period

I have a problem with the way that modern software development methodologies are being exercised by a significant proportion of the practitioners in the industry.

So much value has been placed on performing the mechanics of Agile or DevOps processes that the value of those processes is being lost under a sea of buzzwords and procedural nonsense.

This is not about "Is Agile Dead?" or "DevOps doesn't work!", I don't want to get involved with that sophistry. What I want to do is point out an increasing trend towards the belief that just doing Agile or DevOps will bring the benefits. The benefits stem from the good engineering practices that these methodologies promote, through a degree of formality, language and organisation. Without recognising and cherishing the engineering behind the methodology, too many teams are burning the trust of their investors and business managers.

So what is Junk Change [Management]?

• being unable to say why a change is required;
• making changes that have no associated metric;
• making changes that are mainly aesthetic;
• making changes that have no relation to end-user/Persona activity;
• refactoring without a reward;
• making changes that test/affirm no hypothesis about your users;
• using non-experts to approve changes;
• making non-testable changes.

And what is Pastiche Product Management?

Pastiche Development - Photo by Jesse Roberts on Unsplash

• having a product vision that never gets evolved or referenced;
• having Personas divorced from the product plan;
• Planning things that don't need planning;
• Estimating things that can't be estimated;
• Grooming a backlog with opinions rather than teeth;
• having "statement only" Stand-up meetings;
• having sprint tasks for BAU activities;
• doing retrospectives that change nothing;
• allowing unchallenged slow cadence/velocity;
• condoning rubber stamp PR code reviews and release approvals;
• writing unremarkable release notes;
• having no method for user feedback;
• ignoring "difficult" bugs.

Knowing "Why"

Knowing why you are making a change and why that change is important is the single most influential factor in promoting productivity and healthy product development. Ask yourself "why am I changing the colour of this button?" and then continue to ask why all the way back to the point where you reach the raison d'être for the business. If there is no realistic chain of connections then you don't have a valid reason for making that change.

The same goes for the mechanics of a methodology, knowing why you have stand-ups and why you do code reviews is very important for the success of those steps in the process. And everyone needs to know the reasons so they can hold the management team to account when a retrospective changes nothing or there are too many cards on the Kanban board.
Collectively knowing "why" is the basis of a shared purpose.

Understanding Users and Business Models

Large consumer goods companies such as P&G and Unilever spend a lot of money researching their consumers in many ways including H&P (habits and practices) studies, trying to understand them. Senior executives sometimes even visit the homes of tame consumers to try and gain a degree of empathy for their lives and see first hand how they use the product. The more successful technology companies also have a very strong customer focus, for example Jeff Bezos said:

"Focusing on what customers want or need has driven many of Amazon's most profitable business moves."

Linking all changes to a vision that chases down a series of consumers' needs and wants is key to good product management. They may not know they need it or want it yet, but being able to strategically address those needs at some point in the product roadmap is something that needs to be clear. A good example comes from looking at Google's dominance of the mapping space, analysis shows that the product decisions were made many years ago with some big investments as Justin O’Beirne's recent blog post unravelled; the whole roadmap is aimed at providing a superior user experience eventually (7 years later). Perhaps Google Maps is just a stepping stone in a greater product vision.
The team need to understand the user and their needs, there are a number of viable mechanisms for doing this but the one that I find works best for software solution is the Persona and macro level Use-case documentation. The team also need to be aware of the corporate mission and where that intersects the users lives, as well as a high level view of how the company plans to turn that point of intersection into a formal business model. A lot of developers and developer focused product managers fail to see the connection between good user modelling (Personas and Use-cases) and feature development. Without an accurate internal representation of how the users and customers the majority of product decisions are simply guesswork.
The user model defines the way in which you can ascribe value to features and hence prioritise, groom and make key decisions about the product and its roadmap.

Feedback, Metrics, Releases & Product Testing

"It's About Feedback and Change" is the title of an Agile Software Development paper by Williams and Cockburn (from 2003); it was written at a time when Agile was not yet the dominant methodology for software development, and while the acceptance of Agile has matured the key pillars of the agile manifesto seem to still be missing from the daily lives of too many of its practitioners. Feedback is a valuable element of the information required to make meaningful changes to both the software and the process of creating that software.
Direct user feedback is great, but it comes with a cost - either the cost of soliciting it or the cost of processing the un-moderated stream. Metrics provide a way of interpreting user behaviour and ascribing the value associated with those behaviours, either from changes in user retention, user engagement or more direct positive outcomes (up-sell or social vitality). Retrospectives and team meetings also have a cost and so productivity metrics are also a part of the development information required for a healthy agile team (when used positively).
Feature flags and A/B testing are common ways teams release change; and this works well from a process decoupling point of view, where the act of completing the development and the exposure to the end users are not tied to the same release step. But these tools are designed to allow the developers to finish and move on to the next task, and allow the product owners to work out the impact of the changes.

Hard Problems, Big Bad Bugs & Feature Leader Marketing

Commercial advantage comes from delivering products and services that either give your users a feature advantage, facilitate a cost reduction or provide any other significant differentiating factor (e.g. GDPR compliance). The source of these advantages for a tech company usually comes from solving a hard problem, for example the audio fingerprinting algorithm that Avery Li-Chun Wang created to launch Shazam. If you are not solving hard problems and constantly moving the dial in any significant way, and your competitors are, then you will rapidly lose your marketability and commercial leverage. Writing the paper is only step 1 of the product development, you need to get the functionality developed and put it in the hands of users, learn from how they use it and iterate to create the commercial gain.
Sometimes the hard problem is not visible to the user, perhaps it is security or issues of scale, perhaps it is a nasty bug that creates the operational problem to solve; I call these "nice problems to have" because you only get them if you are doing most things right, and so shying away from these problems is commercial suicide - you need to tackle them head on!
It doesn't matter if you are operating in a new or mature market (e.g. mobile phones) the only difference is that the more mature the market the more well known the critical features are, but you still need to be addressing both the known and the unknown/unexplored features; the product only needs to be one step ahead on each one to be market leading from a feature point of view. In other words, the product doesn't need to be years ahead in one area, it needs to be slightly ahead in all areas. Incremental improvement of features will only take you to the point where it starts to get hard, by focusing on the hard problems then you give your product that extra feature step at each iteration.

Branding and Aesthetics

There is a valid place for the importance of branding and aesthetic changes in product management. But the investment in those areas needs to be proportional to the value it brings. Branding can be very subjective and often a personal statement, but its value is found in the generation of familiarity, trust and making your brand synonymous with the qualities of the product you want to promote.

Summary

Think:

• Is the methodology actually working?
• Do the changes matter?
• Does everyone know why?
• What features make the difference?