Here at JumpRock, we are proud to continue our support for Crookham Rovers Pythons for a further year.
Taking inspriration from the tenacity and spirit of a small band of 12 year olds. It is fantastic to see them reflect JumpRock every weekend, 

Navigating Vendor Selection
 
Tips from the coal face, delivering vendor selection.
 
If it’s time for a change, the platforms that support your marketing are burning, too costly to maintain or upgrade, your business process is out of sync with your tooling, or the purpose and presentation of your web presences no longer match what your business currently does, read on. 
Marketing tooling on average is replaced every 3-5 years, this may simply be down to a lack of maintenance sometimes a  project over a product mentality will have left a behemoth that is presenting a business risk of patched and loosely coupled technologies. It’s time to press ahead and realise the benefits of a replatforming. With all the upheaval that will entail
 
For a number of years, we have been working with organisations large and small to identify platform architectures that deliver against need but also provide the business uplift required to make our customers the hero. Increasingly we are seeing the acquisition of platforms decoupled from the implementation partner relationship. With so much at stake you need to assess the market and land on a path that will suit your organisation for several years. It is not enough to know that your support partner has access to lots of engineers, there is a lot at stake if you make the wrong choice. 
Research shows that the average SAAS or PAAS platform remains in use for 3-5 years. But if you are looking for a complex platform or will be looking to invest in a platform that will support a number of different processes, supported by a product development plan you may be looking for a lifespan of up to a decade. 
 
We are seeing RFP’s where platform selection is being carried out in parallel with an implementation partner selection or, in a lot of cases a package of work to unpack the business need and define not only a platform but a larger architecture and implementation roadmap alongside phased investment thresholds. 
 
I have drafted this article to pass on some of the key tips for organisations embarking on a vendor selection.  It is not exhaustive if you want more detail. Do shout. 
The challenge is that a business platform decision will impact multiple teams within your business. The implementation could cost 3-5 times the software costs in the first 12 months so confidence in your underlying platforms is imperative. 
 
In order to create confidence. Not only for you but also for your colleagues and stakeholders we recommend the following steps
 

• Get your priorities right – Unpack exactly what your business need are. It is probably not just be a replacement of new for old. Tec changes and you can guarantee that if your last change was five years ago. The landscape will be different. Analyst reports can help you get a top line on trends in the market. 

 

• Unpack the interdependencies – Understand who and what impacts your platform. And where these interactions could be improved. Make sure you understand what goes on under the hood and who is feeding in. 

 

• Dig out the details – Make sure you are clear on any processes or integrations that will need to be implemented or migrated. Are you pulling a value from a legacy system or serving an international market with specific data considerations.

 

• Understand your full technology lifecycle – you can only understand the total cost of ownership when you understand what your platform will be doing and for how long. Implementation cost is only part of the picture, what are your total costs annualised and are you benefitting from other technology in a way that could not be replicated in a new platform. 

 
Let’s unpack this a little more. 
 
 
Understand the priorities. What gap are you seeking to fill
 
Make sure you have an adequate mechanism for logging and prioritising your business requirements. The primary driver of the initiative may be a single imperative such as your current platform is approaching end of life. However, replacing like for like is potentially not the right thing to do. 
 
Timelines may be deceptive a key requirement in one part of the business may not be compatible with the quantity or quality of change needed in another. The way to navigate this is to understand and document the priorities. What is needed now and what is needed in the future. I have additionally seen platform decisions upended and revisited when a small but prescient point that has not been surfaced, becomes apparent.  Having clarity on the priorities ensuring they are tracked, shared and commonly understood will ensure you are going in with your eyes open. 
 
Modern composable technologies can help as you are often not compelled to use one platform for all. A competent implementor will certainly be able to help you stage a delivery plan. 
 
Lets also look at the Interdependencies.
 
Do you have teams or business units with key skills that need to be considered (coding preferences)? 
Do you have data that needs to be shared managed or handled at different parts of the process? Equally, timelines do you need one technology in place before you can implement others. Having a high-level picture of this will help you create your architecture over time. 
 
Staffing, Business processes 
 
Ensure you have looked at your staffing requirements. Content or ecommerce technology has huge impacts on business teams. Your content supply chain. Your merchandising capability, stock and facilitation.  Changes in technologies at one point in the digital diaspora can have knock on effects up or down stream. Make sure you have these implications logged. 
 
Thiswill give you a strong sense of the shape your platforms will need to fill within your organisation. 
 
With the context in mind, it is time to focus on the solutions. 
 
Getting a sense of what is out there 
 
Draw up a clear requirement and take that to the market. 
Starting with market landscape view, it is worth understanding quickly which vendors can bring something to your requirement. As vendors grow through acquisition and consolidation. It is worth having an up-to-date understanding of your vendors perspectives. Don’t just look for historic leaders. Look at who is investing and who has strong roadmap plans that align with your requirements. 
 
I like to have initial conversations with vendors without divulging the name of my client. You can clearly align your needs against the functionality you need and look at company size and industry experience so you can assess a match with the vendors available. I also like to look at vendor stability. Look for a measure of stability that suits your need but ownership, backing, client mix and pending mergers can give you a clear understanding of potential partnership contenders. 
 
Once you are clear that there is a solution fit across a shortlist of vendors It is time to start talking cost. 
 
Ensure you have a clear understanding of the total cost of ownership (TCO). 
Are there any subsidiary costs, is this PAAS or SAAS, and what are the implications fo hosting, maintenance and upgrade paths. 
Ease of access to resources. Quite often responsibility for development will be split between vendors and implementation partners. Make sure you gave a strong ecosystem of partners in case a change may be needed at some point. 
 
 Also do what you can to project costs over a full-term. Software implementations often have a 5-10 year lifespan. Understand cost impacts across that timeframe.  Initial implementation of course is important, but your business will change. What will be the long term costs to adapt your platform.  What is the mix of Ongoing (fixed licences) short term costs (implementation and decommissioning, and any third party, plugins’ s updates or additional licences. A platform that looks cost effective on paper can look different when you assess support, hosting and any functional add-ons’ or connectors you will need to pay for on an annual basis. 
 
Having looked at this a number of times the first-year cost is rarely reflective of ongoing costs. So make sure you have a view over a period relevant to your business. Certainly, more than one budget cycle.  Also factor in the cost and cadence of upgrades and deployments. What weight will this place on your business. Long slow deployment processes can be crippling for efficiency. 
 
If your platform requires the development of add-ons, tools or widgets.  Are these native to your platform or can you develop them in a way where they can move forward into any new platform, using for instance headless or UI technologies that can exist beyond the current use case without costly reengineering. It can be worth thinking in this way a few years prior to any potential replatform to retain as much of the investment you have made in specific user tools, as you can. 
 
Test before you commit.
Firstly, don’t take the standard demo. You can guarantee that is not real and has been rehearsed many times. Look by all means but once you have a small group of potential vendors left ask for a detailed demo. One that closely matches your business requirements or needs. Remember vendors are commercial entities and sales guys time is precious so save this detailed step for the final few. It will help you understand the user experience your staff will be going through. You can unpack how well suited the technology will be for your teams. 
 
Many vendors will let you spike an API to be sure that its delivering, but if you are doing spikes save this as a final step and only put vendors you are very interested in through it. Hopefully your vendors require an NDA in place for this but if you have been sharing business information throughout your negotiation it’s a wise precaution. 
 
As an overriding principle a vendor selection process is a funnel. Your initial interactions need to cover easy to ascertain information. Business size, reputation, status, broad technical fit etc are easy to acquire.
 
Detailed functional details are harder and will require some interaction between you and the vendor that you will both have to invest in. 
 
Detailed demo’s or Technical spikes take time to create and resource, both for you and the vendor. Save these interactions for Vendors that you are really interested in. Keep demos to an hour or so and don’t pack too many into a day. You will not remember anything clearly. However  Do invite you team into Demo’s. Give them a series of critera and ask them to mark vendors. It will help you massively in removing subjectivity and focussing any follow up conversation to achieve a result. 
 
We have worked a range of collaborative Vendor selection engagements working with a variety of tech platforms across a range of industries. If you feel that JumpRock can add value to a vendor assessment within your organisation. Feel free to reach out.

It was great to be part of the Opticon gathering again with Mando. 
Both Daniel from Satalia, on AI's and impacts on business and humanity, and Nazanin from the Product team at Optimizely, gave stand out talks. 
 
My key take on the conversation was that the direction of travel is realising efficiencies in the content supply chain. With content testing and personalisation making increasing demands on content teams for volumes of nuanced and varied content. Efficiencies through effective tooling can create some of the required bandwidth.
 
AI tooling is great for automating the leg work in content production but the intellectual property is currently still human. If I understood Daniel correctly not for long. 
 
Here is a piece I worked on with Rob and the team at Mando Group. Still largely human in origin, but it may have been given a shine by a LLM.

Stephen Gillespie
Copyright JumpRock 2024

In the realm of artificial intelligence, a topic that is being fervently debated, a multitude of opinions exist regarding its virtues and vices. Some envision it as a liberating force, while others fear its potential to wreak havoc on our world. As an independent consultant, I find myself subject to the demands of commerce, navigating this landscape with caution.
It never ceases to amaze me that when I engage in conversations with consultants from different industries and mention my extensive reliance on Chat GPT, their reactions are often a mix of curiosity and perplexity, although occasionally outright derision. To provide them with a concise explanation of my perspective, I feel compelled to expound upon my position.
Generative AI truly shines when tasked with sifting through copious amounts of unstructured data, offering unique insights. Admittedly, these insights may differ from my own, but it's essential to consider the specific contexts where such capabilities prove invaluable:

• Discovery exercises that necessitate the sourcing and analysis of vast information.
• Targeting activities that require identifying indicative focal points across a wide array of data points.

A scientist friend of mine aptly described these tasks as ones that you would assign to graduate students. The objective here is not to obtain their subjective opinions, although those can certainly hold value. What we seek is a moderately informed perspective that propels our own thinking forward with agility.
As a professional, I would never attach my name to something written by another entity, virtual or otherwise. However, I would gladly leverage the work of others to construct my own case. This becomes particularly crucial when reviewing and refining the desired viewpoint.
When approached for an opinion on a given situation, I disdain any delay between the request and the solution. While my effectiveness in conducting discovery activities may result in missed opportunities for day rates, the ability to swiftly compile a competitor list or a comprehensive ranking of vendors within a market is a significant efficiency gain.
My role then transforms into that of a reviewer, editor, and overseer. I meticulously examine the output generated, identifying any gaps or caveats, and supplementing the initial insights with high-value recommendations. Often, the discovery exercise merely lays the groundwork for a more comprehensive study, which may require additional primary research conducted by yours truly.
I admit I delegate some of the legwork to Chat GPT. Moreover, owing to its speed and efficiency, I can even orchestrate a series of similarly phrased requests, capturing nuances and shades of meaning.
From a commercial standpoint, one could argue that the occasional loss of a few days, while impacting short-term turnover, enables me to deliver results to my clients more swiftly, with reduced overhead, and most importantly, enhance their time-to-value. These outcomes bode well for both me and my clients. However, I must extend my apologies to the student I won't be able to take on this year, as a consequence of these choices.

Stephen Gillespie
Copyright JumpRock 2023
​

At the close of January every year Gartner publishes its Magic Quadrant for Digital Experience Platforms (DXP). This herald’s chest beating from the various vendors as they explain how and why they have all landed where they have.
 
Yet in a recent article on CMS Wire about DXP’s, the point is raised, that ‘many organizations are not utilizing this functionality to its fullest potential’.
 
All the DXP’s that Gartner feature are highly credible platforms, feature rich and often carrying an enterprise sized price tag for PAAS and SAAS functionality. 
 
Part of the challenge lies in the procurement process. As a core piece of infrastructure regardless of whether the organisation is utilising the commerce functionality. IT and procurement functions will be involved in tendering, as will marketing and potentially ops who will be responsible for some if not all of the administration of the platform once implemented and configured. 
 
By acquiring a DXP you’re not purchasing a digital experience you are purchasing the means to create and manipulate digital experiences. If you are purchasing a DXP for the first time you need to be also onboarding DX as a strategy and approach, not simply a platform or capability. 
 
And in part, here lies the challenge. 

• Skills and expertise within the organisation required to assess and define the platform implementation, and potentially procure the implementation, may fall away when the implementation project is underway. 

• Platform features identified within the procurement process, as important, may be lost in translation or deprioritised when the implementation is in discovery.

• Defining required features and functions within the platform, ignores the processes that will be required within the organisation to deliver a workflow of content and optimisation. The organisation needs to ensure that experiences are built, maintained and optimised. Not just implemented. 

 
Escaping the traps above will ensure that your DXP implementation will deliver the intended ROI and potentially exceed the headline expectation in the years to come. 
 
For some organisations the ‘website’ is a functional beast. A repository for content or product. That can be accessed to interact or transact. For these it may be worth considering that a DXP may be an unnecessary expense. Enhancing open-source content platforms with off the shelf marketing tooling may be sufficient.  
 
However, the organisational shift to an organisation that deals in experiences and not just content is essential to stay competitive and enhance margins. 
 
Within the plan for the new platform, it is important to understand that many DXP’s require extensive implementation, this may well require a technical partner aligned to your chosen platform. Platforms are increasingly complex and configurable. Selecting a PAAS system for its available features does not always mean that all the features will be applied in the implementation. It is important to be realistic about what features are needed and how they will be used by your teams. Staying in control of this will enable you to be sure that the features you need will be available to you on day one, and in the future. An essential part of the discussion here needs to be an understanding of how you are going to be using the platform. For instance, are you as an organisation keen on moving to the delivery of dynamically attributed, related content and product recommendations? If so, it is important that recommendations are considered within the development of the interface and the content workflow. Not just considered as a tick box in the procurement process. Even if you feel that AI driven recommendations may be a phase two or three implementation, having that consideration understood within the UI and accounted for in the development of the available blocks will enable you to adopt new technologies more quickly and cheaply at a later date.
 
Part of the issue is that some UX processes have been developed around the delivery of CMS systems, an important precursor and component of your DXP. However, an adept marketeer will be looking to understand the tools and opportunities to optimise recommendations, not only within the layout but the experience overall. Creating the flexibility in the implemented product to deliver ongoing optimisation of the recommendations, helping deliver an increasing ROI. As is/to be analysis of user journeys can sometimes be used to  define a single optimal journey that is then baked into an implementation. This can be short-sighted. Users do not always know what they want until they see it and an experience that is correct today may need to be adapted or enhanced by the time the platform is live. 
 
Our recent experience with Covid 19 has shown how customer expectations can shift rapidly. Customers who may have required telephone servicing previously are now more accepting of online to fit around home schooling and work. Equally expectations within ecommerce have developed radically as the volume of items consumed online escalates through the lockdown. We have tracked some of these changes here (1, 2-3) over the past 6 months. 
 
Ensuring you take steps to retain the inherent flexibility available to you within a DXP will assist your marketing team to enhance returns and the experience down the track. For some organisations divergent web platforms may need managing differently. For instance, the market facing corporate site may not need more than periodic upkeep and can be largely a content vehicle, however the customer facing product site which is an important customer digital experience. 
 
The ability to personalise content, or intelligently propose related experiences is a core feature of your DXP. Yet the definition of the journeys and the maintenance of them requires acumen and more importantly resources within the support teams to deliver and refine. 
 
As you go through a DXP implementation process it is important to identify where these resources are. They may be freed up by removing legacy activities from your old platform, if it required extensive maintenance or management. These resources may be repurposed. If not, it is important to identify what curation, promotion and optimisation skills will be required and build these into the implementation plan. 
 
If your implementation is the first DXP, it is essential that consideration is given not only before but during the implementation to how your organisation will use and deploy resources to support the DXP and what capabilities, you will be requiring of the DXP. 
 
To inform this process it’s important to understand what are the objectives of acquiring the DXP. Where is the return on investment that you will gain, on what will be a major investment?  How will you improve on that ROI moving forward and ingrain the featured functions of the DXP into your organisations marketing, service and sales workflow. 
 
If you don’t know how this will pan out, some implementation partners may have change management capability that will be able to assist (alternatively take a view from an independent consultant). If the task is an upgrade to a newer version make sure you don’t ignore understanding how the new DXP enhances your previous capability. Many of the major platforms have been on the M&A march (Since 2016, Adobe (4), Episerver (3), Acquia (3), Salesforce (4) and Sitecore (2)) and have incorporated or are incorporating new functionalities that will not only empower your team but may require you to look at your internal workflows around content and merchandising to ensure you continue to get optimal returns. 
 
Addressing why a DXP?

• You may have a varied or complex product set. 
• You may need to inform different groups of customers different things or take them on different journeys through your content. 
• For most you may need more flexibility over your site journeys so that you can engineer site experiences and certainly change them periodically. Its important to note here that we are talking about changing journeys not just content. 

Ultimately if the engineering of your company’s online experiences gives you the opportunity to drastically enhance your revenue, then a DXP is the tool you need to do it. 
A DXP, implemented mindfully and used well empowers your operation. However, in doing so it requires implementation to ensure not just successful roll out but ongoing success. It also needs a sophisticated  marketing team and a clear understanding of how to implement a change in how experiences are handled within your platform.
 
The important point is that A DXP is a powerful business tool. If you are going to make use of one and reap the benefits on an industrial scale it is important that you give the appropriate thought to how well it is implemented. 
If you are already paying a premium for a highly configurable business tool, and If you are not sweating it like any other asset. Take a look. 

​In the third in our occasional series of resources, 2021 is well under way with new global relationships and a worsening public health situation. The resilience and adaptability of business and consumers continues to impress with some new approaches and further ingraining of behaviours we’ve all learnt since March. 

First things first. This article is not directed at our usual audience of Digital Product, UX or Agency teams. Product natives will be very familiar with the concepts here. 
 
When working with broader stakeholders within organisations, I sometimes get push back. As a result I felt that they sometimes do need refreshing on some of the premises. For businesses it is now more important than ever to ensure that what you are delivering adds value. Value for the customer, and value for the business. 
 
Some of the basic premises. 
 
Our task is to create business benefit through digital channels. Jeff Bezos outlined how this is best achieved when he said ‘We see our customers as invited guests to the party and we are the hosts. It’s our job every day to make every important aspect of the customer experience a little bit better!’.
 
A party is a once only event. We are there to make everything perfect, to provide the guests with an experience that they will enjoy, and I feel that sometimes here is the tension. How can we prioritise when, for the party, everything is a priority!
 
The unfortunate fact is resources are finite. We balance our requirements across a group of broad variables. 

• Features. For the project team, this is the agreed functionality that is expected to make the customers overjoyed.
• Time. The available window of opportunity to get things done.
• Cost. This can manifest in many things, it is the budget available for resources software, assets and man hours to execute. 

 
The final measure is quality. To explain this, a feature could be executed quickly by few resources and with minimal manual effort to deliver, functionality that could also be delivered to a high degree of polish. Here is where the Prius/Rolls Royce analogy works but unfortunately also fails. They are both cars that can get four people from A-B. It’s just that the time that goes into the production of both products is completely different.  Ask any business owner and they will always want the Rolls Royce. But of course if you want a real Rolls Royce you have to join the waiting list and those wanting the Rolls Royce Phantom Drophead Coupe will have to wait five years.
 
This is in essence the requirement for prioritisation. There is a need to get from A-B. we all want an extemporary experience for our customers but we don’t want to wait 5 years for it. 
 
To build the experience that perfectly suits the needs of your customers. The goal should be to follow the deploy, measure and learn approach building feature by feature until you get from your Prius to your Rolls Royce ensuring that you are building in the right components along the way. 
 
I rarely get projects with unlimited resources. However, quality and functionality are always required in abundance. In the worst scenarios time is also short. 
 
It’s a short explanation but ultimately as a product manager, I am looking to ascertain a rounded picture of the real requirements across all pillars. It is only when I have this that I can manage your product to make every important aspect of the customer experience a little bit better!
 
In this scenario its important to gain an understanding of the organisational priorities. 
 
To understand this I use the following lens. 
 
Defining a prioritisation framework – Setting the prioritisation criteria  
 
Work out: 

• What will add most value to your business? 
• Company value: How valuable is this opportunity for the company?
• Customer value: How valuable is this opportunity to our customer? 
• How is this measured?
• What will it cost? 

 
Or think about this question. What will be the cost of delay if you delivered a certain feature 3 months down the road or within the next couple of sprints! 
 
When considering the cost of delay. Think about the following. 

• Expedite - For every minute in time that I lose, the impact increases. For example, it would cost me xx per day not to have this feature.
• Fixed date. There is a fixed date in which I need to get my task completed. There is not a lot of value in getting it done before that date, however if we miss it, there will be exponential cost.  
• Standard – There is greater value at the start that flattens out. Initially benefit to customer, then value disappears. This is the most typical type.
• Intangible – Mostly relates to removal of Technical debt.
• Ensure that everyone agrees, or clearly understand the delta.

So when we get a prioritised list we are not moving things out of scope, we are understanding their relevance to scope. We then use agile methodologies to develop, test, learn and iterate. 
 
Fail fast, excel quicker, iterate 
 
Even in our best efforts we don’t always get it right first time. 
 
That P1 priority item so painstakingly thought through doesn’t really deliver the expected results.  That’s also okay if you are working with the Agile framework, because you test , measure and learn.  The agile methods iterative nature also means the end product is ready for market much faster, staying ahead of the competition and quickly meeting the benefits. 
 
If you are live to market and the P1 enhancements are effective you are capitalising on that investment. Creating revenue in the short term to reinvest in further resources. 
 
To conclude, this article is not intended as rocket science or a definitive work. I’ve been in the industry so long that prioritisation is part and parcel of what I do. I do get a little surprised when people not from the same background ask, ‘But I want everything, why do I need a prioritisation exercise?’ 
 
I now have a little link, when I am asked that question again, I will send people here. 
 
And don’t forget. There is always another party. It’s not a one-time event!