Buy pipelines, not products
We’ve all experienced buyer’s remorse: the experience of building up to a big important purchase like a car or a house, thinking hard about all the options, finally taking the plunge . . . and then experiencing the sinking feeling that you’ve made the wrong choice. The cars you chose not to buy seem bigger and shinier, and the houses you rejected seem lighter and roomier.
Psychologists have researched this phenomenon and some suggest that it might be to do with the sudden shift from possibility to reality: when we still making our minds up, we have nothing but possibility ahead of us, and focus on the positive aspects of each of our choices; when have made our decision and made our purchase, we have nothing but reality, and have to deal with all the negatives and compromise of what we have bought.
Buyer’s remorse is particularly strong when buying enterprise software products. Our decision cycle can be long: we often construct detailed evaluation criteria based on our requirements and standards, conduct paper based and technical reviews, run POCs and bake-offs, take reference calls and read research by analysts.
And the period of potential disappointment is even longer: once we have made up our mind, we will probably be living with the product for many years. Moreover, unlike a car or a house, the thing we have bought is rarely ready for use: we need to deploy it and integrate it, we need to configure it and sometimes we need to customize it. We need to do all the hard things that will expose all the problems and compromises. We test the value of our new purchase, the quality of our decision making, and our relationship with the supplier to destruction before we ever see any of the benefits: it’s not surprising that we often feel twinges of buyer’s remorse. Maybe life would be easier if we had gone the other way.
I don’t have a cure for buyer’s remorse. Even for good purchases, it seems to be built into our psychology. But I do have a suggestion for people, particularly technology architects, which may help them make decisions which they don’t regret.
This suggestion stems, like so many changes in our ways of working, from the recognition that tools which were useful in the past are not so useful today. There is an established set of tools in our industry to evaluate purchases, whether these are formal systems or an informal set of techniques and approaches. And I believe that these tools only do part of the job.
The classic software product evaluation approach closely resembles the features of the classic waterfall project delivery lifecycle. We define our business goals, we gather a set of functional requirements and we attempt to define a set of non-functional requirements. We define our commercial parameters: what benefits we are hoping to achieve through our purchase, ad how much we are prepared to spend. And then we build a set of evaluation criteria, we do the analysis, and we make up our minds.
For much of my career this approach has worked. Yes, we sometimes got lost in analysis. Yes, the criteria that were supposed to be objective were not always objectively applied. Yes, we could always get faster and sharper in making decisions (and that’s the topic of a future blog post). But we got there in the end.
But for much of my career, the world of enterprise software moved slowly. Vendors made major releases of their products at most once a year. Sometimes they took several years to take a run up to a major release. Even minor releases and patches followed a slower schedule than today. And clients treated these releases as major events: they planned for them months in advance. Sometimes they chose to skip them and fell years behind the release cycle.
This is not the world we live in today (or at least it is not the world we should aim to live in). Vendors release improvements to their products with increasing frequency. Figuring out how we can apply those changes without breaking everything is part of our jobs. If those products are Cloud hosted, SaaS services or components exposed through good APIs, then this is much easier than it used to be.
This means that we are no longer buying products, we are buying pipelines: we are buying continuous and never ending streams of change. And that means that we need to change the way we evaluate our purchases. Analysing and comparing functional features still has its place, but is less central when we realise that those features will change. Understanding the product roadmap (a question we have always asked) still has its place, but we shouldn’t expect that the details of that roadmap will stay stable over several years (and, of course, they never did anyway). Understanding the technical capability of the vendor is important, but forming a relationship with the team is even more important: these people and the work they are do are going to be an important part of our lives for years to come, and we need to know whether they are people we can work with. And we need to know more about the change cycle than ever before. How will the vendor make releases? How will you test and deploy them? What happens when it goes wrong?
If buyer’s remorse is an inevitable part of human psychology, then maybe we can’t avoid it. But if we think of our purchases as pipelines rather than products, we may soften the blow: we still make the shift from possibility to reality, but we have plenty of possibility left ahead of us.
