Adventures in alliances land #11 – permanent conversations; joint solutions c_components

I’ve been in a lot of debates in the last few weeks about designing and building joint solutions/propositions/offerings /services/etc - which is another example of a ‘permanent conversation’.? Whatever the choice of the name of the thing we’d like to sell, agreeing its definition and building it has been a permanent conversation in my 20 odd years of strategic alliances.? A ‘permanent conversation’ is something that has been true forever and despite learning it well needs continual effort to align for successful partnerships.? They are points of debate, iteration and friction that are enduring and therefore need continual attention, adjustment and intervention from professional strategic alliances practitioners.?

I’ve been thinking, writing and doing strategic alliances for more than 20 years.? When something in the alliances space catches my attention that I can share, I will – so if ecosystems, partnerships and alliances are your gig and your passion too I hope you’ll find these scribblings useful.? If you enjoy this article please follow me, subscribe, like, comment and repost.? My book on strategic alliances is here if you’d like to read more adventures in alliances land.? https://www.amazon.co.uk/Strategic-Alliances-Fieldbook-Art-Agile/dp/103212900X/ref=sr_1_1?keywords=strategic+alliances+fieldbook&qid=1691319592&sr=8-1

?

So the last two articles discussed naming taxonomy and gave examples of joint solutions.? Now we’ll move on to what are the components of the solution, and the assets needed to build the solution.? From page 200 of the book there is a suggested list of material needed as part of the blueprint to create the foundations for the alliance.? Of the 33 elements suggested, 14 of them are directly related to the joint solutions, illustrating how important this focus on co-build and co-sell of joint solutions is. The subset of 14 is listed below.

?

“Before we plough into the long list of assets that our collective experience has taught us are worth creating, we wanted to hit a possible critique head on. The reader may see the list for the Blueprint and say, ‘that’s a lot of stuff to do, how is that agile’? We don’t see it as a contradiction to say simultaneously that modern alliances need to move faster and be nimbler and say that there is a minimum amount of work that needs to be done to scale effectively. It’s a beguiling delusion we’ve experienced many times to believe that just continuing with an alliance professional and a virtual skeleton crew of technologists and consultants will succeed as the alliance moves from ‘incubate’ to ‘big bet’ maturity stage. It’s at this inflection point where this Blueprint has value to help shape what its next leap towards stardom will look like.

?

To stick with the parallel between agile development and alliances, the ‘incubate’ phase is like building a minimum viable product (MVP). A small group works fast and iteratively to prove or disprove there is some value in their idea. As with software development, if the ‘incubate’ stage wins a couple of clients, then it proved the idea has legs and warrants further investment. This list of Blueprint assets then becomes like the ‘must have’ feature backlog in agile. It’s certainly possible to launch the product without all the features, but not having one will have a consequence in terms of adoption and satisfaction downstream. Some of the assets we’ve suggested here will appear to be ‘no brainers’ and others the reader might consider them ‘nice to have’. In our experience, all of them offer at least a 10× return on investment. If the cost of building the asset slightly ahead of the curve is one week, we believe that not having it will cost at least ten weeks of effort later.”

?

Bringing the importance of pre-building IP for a joint solution to life is this example where the PS firm got 5x the revenue from an alliance with a joint solution with IP compared to an alliance with 100x higher addressable market where there was no IP in the joint solution.

In real life….case study.?As an example of variation in success for different alliance design, consider the value of investing in a joint proposition and the potential return on investment (ROI). A professional services (PS) firm had two alliances. ?One alliance was with a small software company with a niche product. ?There was a very clear value proposition based on tangible business benefits experienced by clients from earlier engagements.?The consultant had their intellectual property (IP) for operating model and technology configuration baked into sales and delivery assets.?They also had a clear view of the functional target buyers.?The other alliance was with a large cloud company who’s market share made it feel obvious that there would be lucrative joint opportunities.?However, the breadth of the product portfolio meant there was limited investment in defining a specific value proposition, and IP infused into assets was a challenge as there was so much to incorporate.?It also meant targeting IT buyers with an undifferentiated proposition meant the go-to-market had a lot of ground to cover.

Looking back after a couple of years the PS firm achieved 5× greater services revenue from the alliance with the smaller technology firm, despite the addressable market for services associated with the larger tech firm approaching 100× higher.

The case study above illustrates the point about the value of investing in differentiating a joint offering.?The text below comes from a section of the book that discusses the importance of flexing the services components of the offering around the technology product.

“Whilst we’ve picked up the difference between product and services in the earlier points, it’s worth emphasising a little more specifically here. ?Technology firms will have a finite portfolio of definable products. ?Each of the products will have a specification of some kind that describes what it does and a form of instruction manual that tells users how to configure and run it.?Services on the other hand can be constantly changed.?PS firms will have an uncountable number of service permutations. ?They will have a service catalogue of some kind, big categories of services with subcategories.?‘Cloud services’ might be a big category, ‘cloud strategy’ and ‘cloud migration’ might be a subcategory, for example. ?However, the variations will be almost infinite. ?A ‘cloud strategy’ engagement for two people for a month for a client in an unregulated industry will create entirely different deliverables and outcomes to a ‘cloud strategy’ performed by a team of ten that takes three months for a regulated industry client. ?This tailoring means their services don’t yield simply to objective specifications or measurement.

For an alliance, this means endless flexibility for how to develop relevant offerings around the technology. ?Adding some financial work to define the business case in more depth, removing some design work so the architecture is high level only, it’s the work of moments to change the scope of the offering. ?Unlike the technology firm who will have months of approvals, changes to the development roadmap and software engineering to fundamentally change their product, the PS offering can be flexed at will. ?Whilst this is very useful in terms of speed to adjust in-flight, it does mean that the initial build of a ‘minimum viable offering’ needs focus to create something market ready quickly to get started.? The implication for the alliance is that the product becomes a relatively stable component in the offering and that much more thought and effort and experimentation is required on the professional services for designing the joint offering.”

?

What do you see as ‘must haves’ for components of consulting solutions?

?