Opinions & Insights

Webinar Transcript: Launching Web Experiences In Regulated Industries

Opinions & Insights

Webinar Transcript: Launching Web Experiences In Regulated Industries

On April 25, VShift's Managing Director of Strategy and Growth, Eric Feige, joined a Netlify roundtable webinar to share their experience and playbook. This is the video and transcript.

Non-IT business executives are often brought in to drive change

Sam Bhagwat: (principal engineer, Netlify) Let's get started. So the reason that we decided to do this webinar is that building in regulated industries is a topic that comes up a lot, usually with some complications.

Eric's an expert that we've gotten to know at Netlify and wanted to provide this opportunity to have him in conversation.

If you're here, we're assuming that you are in a regulated industry, whether you're an engineer or a tech lead or manager, and you're trying to drive change and move towards the modern web.

Min Kim: (product marketing, Netlify) We're excited to be joined by Eric from VShift to dive deep into this topic of building quickly in regulated industries. Eric, if you could also share a brief introduction about yourself, that would be great.

Eric Feige: (managing director of strategy and growth, VShift) Hello everyone. Great to have such a worldwide audience. I'm Managing Director of Strategy and Growth at VShift, and we'll go into a little bit about our organization here in a bit. But my personal background, I've been a Head of Digital at very large regulated industries: Prudential Financial, JP Morgan, helped create Deloitte's first digital center of excellence, and ran deloitte.com in 140 some odd countries. And countless dozens of languages. Have quite a bit of experience on both the client side, serving as a Chief Digital Officer/Head of Digital, but also as a consultant for many clients in regulated industries, big, complex global organizations.

Min Kim: Great. So this is the agenda for today. We will start by diving deeper into what VShift does, why they were founded, some of the past clients that they have served as well. And we'll also go into what a typical project approval looks like.

The client relationships and regulated industries are of course, a little bit more complicated than other industries. What are some of the specific pain points and stakeholders that you have to really persuade to help accelerate this pivot to composable? Eric will also share specific tips and tricks organizations can leverage to really accelerate this migration or pivot to composable.

And lastly, we will conclude by looking at an example of a past client that Eric has served. So Eric, without further ado, if you could tell us a little bit more about what VShift does exactly, the clients they serve, when it was started, and after that, if you could also explain more about the different web projects and migration campaigns that you've helped lead in these regulated industries, that'll be fantastic.

Eric Feige: Yeah. Excellent. VShift is headquartered here, Midtown New York. VShift was started in 2006. We're an independent digital agency. Our services are really broad and focused on developing digital strategies, multi-year programs, recommending new digital ecosystems, IT technology modernization, and then a big focus on brand campaigns, really what we would call go-to-market in new and innovative ways. We see that as fundamentally a big part of transformation is really changing the methods and tools with how you go to market as a business and pursue new markets or reinvigorate existing markets.

We started really with a heritage. I just described some of my background. Generally, we're experienced professionals that have been there and done that with large organizations. We do focus on financial services, healthcare, insurance, complex organizations, and I'll tell you why, but that level of problem solving and credibility with going to market in new ways, our background lends itself to really sustained transformation and culture change around innovation. And we see decoupled technology architectures, or what we call composable, a modular approach, as key to our success. And I'll go into a little bit of detail there.

Typically our client is the non-IT Executive within these regulated industries. And what I mean by that is that they're generally a member of the operating committee or the executive leadership team that has been brought on or hired to lead digital transformation or business transformation supported by digital. Really as a compliment to the CIO or CTO of that organization.

So usually that helps us with our focus on the go-to-market, being aligned to the business goals. What are the barriers that we need to break? And certainly decoupling and composability are excellent tools in that transformation toolbox.

What's different about web projects in regulated industries?

Eric Feige: So what's different about web projects in regulated industries?

So the early traction in the marketplace was generally with product-led organizations, tech-born, tech-native businesses that are led by a Chief Product Officer. They're venture-capital backed, and the business plan is all tied to, let's innovate and deliver in a new and different way.

So for those types of companies, it's much easier to have a product management methodology and a corporate strategy that is very singularly focused on that FinTech or that health tech or that new cloud-based offering.

So these composable technologies, serverless and headless and so on make a lot of sense because speed is of the utmost importance and there's a technology maturity within the organization, within the product management function that everyone rallies around.

So what's different is in regulated industries, that level of maturity and that product-led business strategy is still very nascent. There may be innovation programs, there may be the hiring of a new Chief Digital Officer, someone with my background that's leading the charge. But there needs to be really quite a bit more change management communication and what we might call digital maturity or educational programs that are really focused on proving it out.

Sam, I know you and I both were in San Diego, we talked about these organizations tend to have, on their technology estate, multiple CMSs or multiple digital experience platforms, right? So there's a lot of complexity of the technology and where content is stored or where knowledge is- exists, that needs to come out and be stitched together or integrated to deliver a new digital experience.

So generally there's far more complexity and a really a need for collaboration and cross-functional decision making that I'll go into in a little bit. So hopefully that answers your questions.

Min Kim: Yeah. That was super helpful and comprehensive.

Audience background & micro-industries

Sam Bhagwat: Question for the audience. You've shared a little bit about your background in terms of where you're from and where you work. But can you share a little bit about what industries you typically work with? Whether maybe you're at an agency, and so you have some industries that you work with, or whether you're within a company.

So I think that'll help us tailor the conversation as we go along. So please share the role you have and the kinds of projects in the chat.

Eric Feige: Great. And Sam while we're getting some responses, financial services is a good example. That's more of a macro category. Specifically when we look at financial services, there's a sector focus. We do a lot of work in asset managers, as an example.

Or within healthcare, we're doing some really comprehensive work in hospital healthcare providers, as a system of hospitals, as another example.

Life sciences as well. But, regulated industries and complex organizations can really be thought of synonymous, for the group as they're providing you a response here to the audience question.

Sam Bhagwat: Yeah I think that's a good point. And Eric, I appreciate your kind of savvy and sophistication around the nuances of these types of organizations.

That's one of the things, whether you're at an agency or in-house, that can be really helpful in driving changes, understanding which parts of the business are more amenable to these kinds of transformation efforts, and which ones might take another few years.

Ash Hitchcock from Fresh Egg says that they work a lot in insurance and charity, so that's super helpful. Excellent.

Ernesto says he's worked as a Software Engineer at a company that built financial, digital projects and is now trying to break into healthcare with a few ideas.

Awesome. Thanks Ernesto. Excellent.

Daria says that you're planning to start working with Mental Health Specialists. That's great, as well. Terrific. Okay, cool.

Steven says he has a general interest in CFS technologies of all kinds, financial and healthcare in particular. So thank you, Steven.

What a composable stack looks inside a regulated industry

Eric Feige: Excellent. Steven's question is a great transition to our next slide. There's a lot here.

There's a organization called Chief MarTech. They have an annual contest for what they call the Stacky. And we thought this would be a good one when we talk about composable architecture and decoupling as a tactic supporting a transformation strategy.

Sturdy at the bottom, flexible at the top

Eric Feige: The graphic shows that there's a bedrock at the bottom and there's grass at the top.

So a lot more organic, a lot more change with the seasons and a lot more fluidity at the very top layers than you've got the soil. And then at the bedrock, this is more synonymous with being perhaps this notion of vendor lock-in where the the vendor technology has been there for many years and there's a center of excellence, or very very much it's, IT-led.

So the idea, the higher up you go on the the grass to the bedrock, there's more freedom and flexibility to move more quickly and change and pivot at the bottom of some of the technologies. They're a little bit more what in the Netlify Gatsby vernacular would be more monolithic.

It's more coupled and it's hard to work with. At the very top, and I'll just go through this notion of why, and what is regulated or complex industries need?

At the end of the day, they're competing and their strategy is around customer experience, but specifically these digital customer experiences.

They could be public website, campaign landing pages, sales, new digital products. I know one of the folks here said, multiple financial products would be an example on that right hand side.

The beautiful thing about composable technology is that it's so modular and swappable, that you can go to market very quickly.

Business executives see composability as a way to reduce risk

Eric Feige: For the projects that we do, this goes back to having a non-IT business executive as an executive sponsor for the change, and cross-functional governance, essentially a decision making framework or playbook for how you're going to essentially take the composable technology and go to market more quickly, but do so together with a shared sense of components.

One of the big things and some of the operating committees that we work with, they love this word decoupled, right? They're decoupling to de-risk at this high risk of of failure of the transformation projects are often because the, maybe IT led, they're looking at an all-in-one suite. But by decoupling the UI to a set of front-end components that are shared, we see that these digital customer experiences can generally be addressed and reused with, maybe between 35 to 50 uh, hardened, tried and true components that can be reassembled to support different needs.

The big area here is MACH: microservices, API, cloud and headless based marketing technology. And the idea is that these operating committees, these organizations that need to move quick and nimbly without lock-in, really need to start out and deliver on a new market need or opportunity.

At the core, and you see this with the the logos off to the right, Netlify is a clear part of the MACH MarTech. Headless CMSs, we just throw out Contentful as an example, but there are many out there in the marketplace, easily swappable to meet a need. Search as a Service. There's Data as a Service.

There's a whole bunch more. But generally this starts giving us this notion of there's a layer of composable technology that is in fact less expensive to license. It's less expensive to maintain, but the benefits here are you can go to market much more quickly. That they're component based or modular, so they can coexist when you look at that digital experience level.

The analysts are wrong: there's no one-size-fits-all DXP

Eric Feige: So we firmly have a belief that many of these large organizations tend to have multiple systems, that house content, and that really there's also belief that there's a one-size-fits-all, all-in-one suite. And I think this has been validated by Forrester and other analysts that have coined the phrase DXP, that really they have fallen short and there's no single vendor that de- delivers all the solutions.

So that really bolsters the need for the MACH based marketing technology so that you can coexist and tap into multiple content stores or DXPs, but move quickly to support the needs. I know some of the folks Sam and Min had mentioned healthcare or life sciences, new offerings.

Oftentimes in a regulated industries, the reg- the regulators give you a window of opportunity to launch. And so if you're beholden or locked in to a monolithic platform or to, a pool of resources, IT resources that are already backlogged, you're gonna miss that window. Therefore, regulated industries we see as a terrific opportunity to just go through the top, down to the bottom to have an executive sponsor, have an organizing committee to quickly make decisions, deliver on those new digital customer experiences, launch, support their goals, and prove it out with a composable technology stack that is, doesn't require a long-term commitment, and it's really focused on the business.

Any questions before moving on? I know there's a lot here. We really like it, because it positions the MACH technology in a layer that is very harmonious with what is a little bit more monolithic or rigid.

Sam Bhagwat: Yeah, if we're coming to the table as a technologist, we may be more familiar with each of these pieces. But it's great to have this kind of diagram to share with a client or an executive in your company, to say: "Hey, here's where we're going." This can be almost a roadmap as well as an architecture.

Min Kim: Yeah, and Eric one thing I'll add is, it's really interesting that within regulated industries there is this another parameter to consider, which is the finite timeline that are imposed by these regulators.

Not only do these enterprise grade organizations have to pivot quickly to meet the needs of their end user, but they also have to take into consideration this extra parameter that they must adhere to. So I think that's super interesting. And another point is, I think the benefits of composable, headless, decoupled, they're all very compelling and clear.

The ability to quickly move, quickly ship things, time to market, but in order to really achieve those things, it's also critical for there to be a cross-functional governance that can also, align on different decisions that need to be made quickly.

Creating a 60/90 day timeline to move quickly

Min Kim: So on that topic, although the even when the benefits are clear, you still need a robust, tangible plan that can help you really get kickstarted to make things come into fruition. This is the 60-90 day jumpstart plan that you've outlined, and it really dives deeper into specific strategies and levers that organizations can pull.

It would be great if you can, dive a little bit deeper into what this means exactly and the key takeaways for our audience.

Eric Feige: Great, and if you could just go back to the previous slide real quick before going here. Another best practice, and Min you just mentioned it. Is that though this is from decoupled UI downward, really technology oriented, what you brought up is this cross-functional governance that is best practice tip number one or prime the really important one.

Tying your tech implementation to specific business goals

Eric Feige: We've seen a lot of headless serverless implementations that were divorced from a business context or, and not really thought of as, hey, we're building a reusable set of components that can help us move more quickly in a variety of different ways.

So I really start out by saying, having an executive sponsor that's part of a cross-functional team where there can be good communication and collaboration. Best practice number one. Now, let's go on to the next slide. When that executive sponsor says, look, there's a finite window of opportunity. I hear all the the MACH technology players saying that go to market and speed of implementation is really one of the big benefits.

Making speed-to-market real with rapid timelines

Eric Feige: How can you as a digital agency partner realize that benefit? We like this notion of a jumpstart or a kickstart really having a finite window of 60 to 90 days as a best practice for getting into production quickly with a working solution. In the agile world, we've all gotten comfortable with the the term MVP, minimal viable product.

You'll see here that we call 'em beacon sites, really with our clients. We, we look at a beacon site or a beacon digital product as a a new digital product. It could be a website, it could be a, password protected digital service, for insurance, or mental health screening and appointment setting as one of the the audience members mentioned that as a focus.

But we really like to look at, within two or three months, what can we do that supports that business need that proves out the benefits of addressing vendor lock-in, of decoupling the front end from some of the more complex or mon- monolithic technologies so that you can move more autonomously with what that digital customer experience is.

Four project phases

Eric Feige: And we'll just break this down into, generally four phases that depending on that 60 or 90 day window can expand or contract. But always starting with validating and clarifying the requirements, going a little bit outside of the organization to see what are others, what are the exemplars that we should be modeling to push the envelope and light that way.

Planning & Resourcing

Eric Feige: And then really planning from a resourcing standpoint. This is where that cross-functional part comes in: a lot of times we will be co-creating alongside a client team like a foundry. If designers are thinking in pages but not components, that's pretty useful for us to jump in and help them rethink their thinking on not only the content model, but the layout and a more component architecture.

Scenario mapping, prototyping, wireframing

Eric Feige: Then we'll go through a day in the life or map the scenarios and concurrently start not only prototyping what wire frames, IA, discrete components with calls to action, and particularly around the calls to action because the composable MACH architecture lends itself to really nice integrations to do more than just purely present content.

Finding beacon sites

Eric Feige: And often cases it's integrating into, we had some audience members talking about insurance into a quoting system, or initiating a claims management, or for retirement, changing the percentage of your paycheck that you wanna save for retirement. Those APIs are really where the gold is for these types of beacon projects because many of these clients and their sponsors and regulated industries are used to hearing, yeah, it'll be 2024 or 2025 before we can deliver that more robust digital business capability that does something special with a transactional monolithic system.

What we try and do is dispel that by working in this beacon site approach and really trying to focus in on those calls to action, those points of integration, so that the digital experience is really quite robust. So I'll go on. But there's an awful lot in this MACH marketing architecture that can be done in two or three month increments.

And often the idea here is to build a roadmap and backlog so that we have enough momentum to be in production with something that's meaningful, that lights the path, that the rest of it becomes more of a run mode where we're delivering more against the run, more value really just consuming that backlog or adjacent digital experiences that are pretty meaningful.

I'll stop there, but I would encourage everyone on this call to think in much shorter increments because the technology and the modularity lends itself to working in more of a quick assembly mode as opposed to thinking of everything as a net new problem to solve.

Solving for organizational challenges, not just tech ones

Sam Bhagwat: Eric, this thank you for walking through this. A lot of the challenges that you're outlining here are not technical challenges, they're organizational challenges. I want to call that out. I also want to call out what you're saying with the beacon sites: walking from the demo backwards.

That's a really valuable methodology that you've just outlined. What's the most compelling demo gonna be? What's the most value? How can we get that in the shortest amount of time, and how do we walk backwards from what do we need to do to get there?

Workshops for building familiarity, momentum

Eric Feige: Great, and Sam, before moving on, I'll point to a couple of things. The notion here is that we have a couple of workshops within the 60 90 day window. The composable tech workshop, really important for, Sam as you said, when there's a demo. And maybe this is a new approach, this more modular approach where you're doing kind of design and development and integrations a little bit more concurrently than linearly. Having a workshop with your tech team members and getting them, ramped up and familiar with the technologies, familiar with the speed at which we can do this is really quite important.

Showing that this is real code

Eric Feige: The next one is that composable business workshop. And this is really useful for the product owner, for the executive sponsor, to really understand that this is not theoretical. This is not a slideshow or a Figma clickable prototype. This is working code, the integrations work and, just kudos to to Netlify for really being an accelerator of taking all the hard parts and making it really automagical in terms of the way you can very quickly start showing progress with all the connectors and a CI/CD operation.

But, we would encourage everyone to think in much shorter cycles of what can be done within a three month window.

What projects in regulated industries should be composable?

Min Kim: And Eric I think that's a great segue into being a little bit more specific about what your average or typical project looks like at VShift. I'm sure it, there are some nuances depending on the company, but generally speaking what are some of the common pain points that these organizations experience?

Where do stakeholders that you're trying to persuade, et cetera?

Eric Feige: So we have the good fortune of not being a systems integrator or implementation shop. Meaning, we start working with across the functions or the different divisions, clarifying what are the business goals, what do we need to achieve.

And how do we measure success? It's getting into the risks or the barriers. And this is where composability has a significant benefit.

Look for stalled projects

Eric Feige: Typically what we'll hear is, yep, these are our goals. This is our north star. But the difficulty we have is that, we've had a lot of turnover in IT, or that they're short on resources or they've made a big investment with a big DXP.

Eric Feige: We hear a lot that: Gosh, we're trying to do everything on, let's say, Adobe, and we just don't have enough specialty Adobe resources. And, we spent through a lot of budget with a big systems integrator.

Eric Feige: Or, I'm not sure I can achieve my goal because I'm locked in, or I'm interdependent on a more monolithic approach and scarce resources.

To move faster, integrate composable tech with existing content stores

Eric Feige: So what we try and do is, and it's in that that layering is look at this MACH architecture can move much more quickly and tap into existing content stores and can coexist with an incumbent DXP.

Yeah, so you know, what you see here is. These layers work well together and it allows you to go into the marketplace.

It only works if stakeholders know there's an urgent need and are okay with a nontraditional approach

Eric Feige: The notion that the industry analyst will talk through is composability also means that it's swappable, and that it's more temporary and that's par- partially what we're trying to do here with the grass is say that it can change with the seasons. And the idea here is that liberates the business executive to move more quickly.

The question of what kinds of projects are composable? It's when there's an urgent need. For these projects, there's a notion that we need to be less locked into a vendor, particularly a suite or a portal, and that we need to have a decoupled front end experience of front-end code as opposed to a clunky portal.

And there's a lot of reasons, particularly with regulated industries of why that is, and a lot of it has to do with risk mitigation, of maintaining good web accessibility, of being performant and resilient.

But for these projects, there's a sense of urgency and there's a desire to not do it the traditional way with the extended timelines.

An example: shipping a retirement plan selector during COVID

Min Kim: Let's go to the next slide. This is a client example of VShift, so it would be super helpful if you could walk through some basics.

What did the timeline looked like in terms of implementation? What were, what was the specific stack that was prescribed to them? What were the business objectives that were outlined initially, and what were some of the end goals and benefits that they were able to reap?

Eric Feige: Yeah, and I'll keep this short cuz I do see a lot of questions coming in, but this is an example.

Retirement and retirement plans is complex because there are many employer organizations, those are the plan sponsors and then their employees are the participants. And this particular client had a very high touch meet clients in person and have material in paper form to walk through.

And it was pretty clear on the onset of the pandemic that they quickly needed to pivot. So this has got those characteristics of a business goal of we need to get our essentially our salespeople and our participant consultants or educators in the field to have a toolkit that is virtually deployed.

Gosh, our folks really need a Netflix or Amazon Prime-like interface where you can go through and at a glance, see the tiles and it's organized and searchable in an accessible and performant way. So all the characteristics that we just talked about, which is- the market's changed.

We need to react quickly. We can't do it in the traditional, more monolithic, very IT-intensive way. There's a compelling need to iterate and get out to market quickly.

Those are all the characteristics, and this is where a composable approach made quite a bit of sense. In those digital customer experiences, this is one that would probably not fall in a public website because it does have authentication. In this case we used Okta and I'll get to the elements of the serverless, headless and as a service composable technologies. But we needed to do this quickly and in less than a three-month period to get into market with a net new digital product that solves a need that takes advantage of a lot of what all was already resident within that digital ecosystem. Content that is stored in different ways that needed to be co, surfaced up. So it can be used just in time. The core technologies here are, Netlify, serverless orchestration platform, and really an ability to get the rest of the players really well integrated in a very quick period of time.

Contentful as a headless CMS, Algolia for search as a service, Okta as a super easy method of having users log in and be authenticated for access to proprietary information. And then Fauna, which we would include as composable as a very light data as a service utility to make some of the bookmarking and the other utilities work very well.

So this is an example of what can be done in a short period of time. The challenges as Sam had mentioned are almost always organizational. We don't mind that because part of this is if you start this process thinking our challenges are technology related. Let's put that myth to bed. We now have working product and we can continue to extend it.

Now let's talk about the organizational challenges of how much content is enough. Is it in the right format? Who has responsibility essentially as a product owner to continue to manage the roadmap? We think this is an excellent example because it is not a traditional public website or marketing landing page, which are easy candidates.

This is a particular use case that brings in a little bit more complexity and for the audience here might trigger their thinking of, yep. I could see how beyond public websites or certain applications. You can do a lot here with the composable technology, particularly when you bring in, some other capabilities like search as a service, data as a service, and the Okta authentication.

Sam Bhagwat: I love this example because enterprises have so many of these client facing internal apps, especially in B2C industries. I love the Covid story around, we have to shift rapidly. This urgency driving change. And I love that you were able to do it in what's more of a traditional industry doesn't always move as quickly as technology focused organizations.

Eric Feige: Excellent.

Audience questions

Min Kim: Yeah, and I think we can pause here for a bit and answer some of the questions that folks have dropped in chat.

So we have Tom that asked how is documentation of code handled in regulated industries.

Code documentation in regulated industries

Eric Feige: It, it candidly probably the same as a a product led organization. We use, on the design we have a, an approach that we call a UI kit. So we really start with the let's call it the library of React components within themes, the styling, and within templates that can support a more rationalized content model.

Each of those components is essentially in that UI kit, documented and specified. In some cases, we're not doing the development, but you have enough documentation and pseudo code around the interactions that you're providing documentation at that level. And then, following a standard software development, software engineering process is to make sure that you're documented because and this may be at the core of the question, there is a much greater focus and regulated industries around business continuity.

Around resilience. What happens if, and there's a lot more mergers and acquisition are divesting. So the idea here of the composable enterprise of being more modular as a business and therefore things need to be documented and encapsulated so that if you divest the business, whoever's acquiring that business can, maintain it without you being there.

So there probably is a little bit more rigor, I would say, in the documentation really for matters of business continuity and resilience to make sure that code and experience can survive without a critically dependent, digital partner or key resources.

Min Kim: And the next question that we have is, what are good examples of enterprise applications that have rich developer capabilities allowing for usage as composable services when developing new digital experiences?

Eric Feige: Sam or Min, you may need to unpack that question. There's a lot, there's a lot there. I'm not sure if the questions around what are good use cases for composable.

Sam Bhagwat: Yeah. I'm a little bit confused if the person who asks that question can maybe clarify a little bit. Are you asking about end user applications? Are you asking about the architecture and the composable building blocks? Netlify, Contentful, Okta? It's not clear to me which side of the spectrum you're asking about.

Min Kim: And we'll come back to that one.

Recommended vendors & Netlify

Min Kim: I think the next question is a little bit easier for us to answer. So he's asking, or they are asking, besides a solid CMS, what other services or products provide the greatest results in your view? You listed Algolia earlier, what are other products that have had successful adoption as a composable technology?

Eric Feige: Yeah. In the serverless orchestration there, there may be, only a couple of alternatives versus in headless CMS, a wide array of alternatives. And I'll just say we, we love Netlify for its simplicity, particularly supporting go to market, but also because it's it's really focused on the heterogeneous nature of the organizations that we work with and can support multiple diverse front end frameworks.

On the headless CMS side, you, you've got Contentful, which we mentioned here, ContentStack. You've got Storyblok, quite a few different flavors of headless CMS that are natively born. At the same time, there are a lot of more traditional DXP technologies that are also positioned, have positioned themselves as headless, which they are just in our experience, some that are more natively developed, are easier to work with, and their pricing models are more utility based, meaning easier for organizations to adopt.

We candidly have only worked with Algolia for a search as a service. I do know that there are o other alternatives there. We, VShift, do not do much because our focus is healthcare, insurance and broad set of financial services, we don't do a lot in storefronts or e-commerce.

Composability empowers business leaders

Eric Feige: I would say that's another area like headless CMS where there's a wide array of options that continue to be available.

What do we think about that? Of having a wide array of options? I look at that because I'm not on the software vendor side as a great thing for the industry and a great thing for these clients that we work with.

If we fundamentally believe that composable technologies are swappable, you can move them in and out, it really then favors the large organization, the Head of Digital, the Chief Product Officer, who is now not at the mercy of a single vendor that has a lot of kind of power over the organization, but rather it shifts the power structure to the client and that executive leader or budget holder to do more digital experiences, more growth strategies at a lower cost, and more flexibly.

Sam Bhagwat: I love that framing.

Eric Feige: Great.

Authoring content vs content display?

Min Kim: And we have another question from Elca. It is asking how much of the project work goes into building tooling for authoring customer content versus showing content?

Eric Feige: Yeah. Why don't we go to the jumpstart with the four bubbles?The reality here is when we look at content and conversions for this beacon project, a critical part to this is understanding fairly quickly what kind of content you have. Almost always the client already has quite a volume of content.

Is it well-written? Does it meet the user journey? Does it support their goals? The answer to that is almost always no.

But they have a good starting point. So often what we'll see is a fork, at this first or second phase, where we may supplement and we employ, a very talented, creative and content team where we will work alongside our client and produce content with our client that is far more aligned to the content strategy to writing well for the web so that the Beacon site ultimately is populated with content.

Elca, to answer your question, I would say 50% of the time, the clients start the jumpstart program, and along the way they'll execute a change order because it quickly comes to everyone's attention that they need help with refactoring content or generating new content.

Great question.

Sam Bhagwat: A great answer. There's a lot of value to looking at the things that are already exist but aren't quite "there" and ask how do we tweak it in a useful way.

Sniffing out technologies that claim to be composable but aren't

Min Kim: We have another question that's asking how would you define a good candidate for a composable technology? Is headless architecture a requirement? How would you define a bad candidate for a composable technology? If you are an architect at a company, what kind of signals do you look in a service or an application?

Eric Feige: Yeah. That is a great question and one that is a little tricky to answer, but let me give it a shot here.

A lot of the composability technology vendors or players, the leaders will have something that I feel is quite important, which is, we have x number of developers or technologists that have used our product and they love it, right? So the testimonials and the net promoter score, but really this notion of our technology is not only fit for our purpose, but there's a passion.

If you're an architect or a tech lead and you work with Netlify as an example they- they'll really go to bat for Netlify. They'll say things like, we really need to use Netlify because it's gonna really eliminate all those barriers and issues when we start on this program. Contentful does a good job of this as well, from their origins in Berlin, they were the headless CMS of choice among developers, and they have a lot of evidence for that.

Ask your technologists

So what to your question, what makes a bad candidate, is when technologists don't love you the way that they love native-born Jamstack, headless serverless technologies.

When the technologists that work with the technology day-in and day-out say, yeah, you know what? It's clunky to work with. Yeah. You know what? It's not, it's not so easy.

And so I use that as an example not only with our clients, but with our CTO and other tech leads to basically gauge and take their pulse. What do you think? Was that easy? Tell me what's easy about it?

We do work with an awful lot of other technology, technologies that are, let's call it headless, but not natively. Meaning they can be more modular and can publish to multiple heads, but they're not part of this MACH ecosystem, and they're not designed to be loved by technologists.

Often with these technologies, there's a lot of manual process. You've got to submit a ticket to get something provisioned that otherwise can be auto- automatically done.

So it's a soft and squishy way of bad headless or bad composable. You will hear from your technology specialists that, yeah, it's headless or it's it's composable, but it's still laborious and difficult to work with.

We find that those that are easy and well loved by developers, those are the ones that we endorse and recommend to our clients. Sam, any comments on that?

Sam Bhagwat: I'm hearing you basically say, walk into the engineering sprint planning session and read the room on whether the devs like it or don't like it.

Eric Feige: If I were a client, I would be going down a level into the the scrum team and to the developers and saying, look, I want my developer to talk to their developer. And you'll hear the unvarnished truth of how easy or difficult some of the composable technology is.

And the disparity is glaring. What works well, works really well. Others can take a week to do what you might otherwise be able to do in 10 minutes. And they'll tell you about that.

Min Kim: I think one other thing that kind of adds to this mix of what makes a candidate stand out versus other composable pieces, I think is the breadth and width of integrations that's available out of the box.

What is the initial developer work that is going to be required to provision these seamless experiences versus something that is very readily available just out of the box, and you can get started right away. I think there is a difference that can be set in around that aspect as well.

Eric Feige: Absolutely. I'll just echo that. Pre-composable, so much of our time was spent working through endpoints and integration and testing. And with MACH architecture, working with the technologies that I mentioned, it's already done, right?

How to turn skeptics into enthusiasts

Min Kim: So I think we just have a few more slides to cover. So Eric, I think we, we touched on a lot of this topic already, but you know that we've mentioned timeline some of the stakeholders that you work with but are, is there anything else that we've missed that you would like to cover?

Eric Feige: Work- workshops in terms of tip tips and tricks are really important for that, that middle bullet of the enthusiasts and the skeptics. In that jumpstart process, I was like, yeah, here's a tech workshop. You're doing that to win over The skeptics who might be very traditionally minded might think, gosh, I don't see why we're doing it with this technology.

We've always been doing it with, this monolith, right? Oftentimes we see that there's a job security with the IT organization to lean on a more cumbersome technology that they know or that they've worked with for the last, decade or so. So those workshops, really important trick to get alignment and enthusiasm from the skeptics who may have started that journey reluctantly on the tech side, similar on the business executive sponsor side, it's demoing.

It's showing. Hey, we started 60 days ago. Now we have this production ready digital experience that, solves a business goal. That's how we're handling a business sponsor skeptic, is by showing them that in the backlog and in the roadmap, we can continue doing more and kind of change, convert them, if you will, from a skeptic to an evangelist of, hey, our business goals can be achieved here.

So the workshops and the co-creation aspect is very important as a as a tip. And then the other, and I think someone in the comments had said this, being a trusted partner, right? Of really working across functions despite being brought in by a Chief Marketing Officer or a Chief Client Officer, A COO, or a Chief Revenue Officer, a non- IT executive spanning the different silos with some formality, with some governance is also critically important as a tip so that everyone begins to trust each other again.

And that's one thing that composable architectures really do organizationally, is that you can move quickly and autonomously with a good operating model. But what we see is that IT and marketing start trusting each other much more when they deliver better together. That's a big win in the process.

Sam Bhagwat: Yeah. I think winning is a thing that brings people together.

Eric Feige: Everyone wants to be a part of the winning team, for sure.

Sam Bhagwat: Everyone wants to be part of the winning team.

Eric Feige: Yep. Okay. Any more questions before we wrap up?

Making it easier for large organizations to purchase several categories of composable technologies

Min Kim: What parts of the composable architecture do you see is going to be mostly changed during next three years?

Eric Feige: Yeah. In the interest of time, I'm only gonna hit on one of the three if I could. There's a lot of emerging interoperability standards, but they're still nascent, they're still emerging.

So I'll say, actually there's two things. There's one I think needs to be an industry-wide movement among composability to really that out of the box interoperability. That it just works. The integrations work that there's a marketplace. Everyone is more in it together as frenemies as they say.

You may be competing, but you the MACH or composability players need to interoperate, interoperate in a very easy way because clients, particularly as large regulated clients that more than just needing a headless CMS or a serverless orchestration platform, they need the other parts, which gets me to not only the technical interoperability and kind of the standards kind of orientation, but on the business licensing, it is very frustrating for complex, large organizations who struggle with procurement.

That's a big thing, they don't like going back to vendor management procurement and say gosh, I know you're saying that the monolithic single vendor all in one platform, is has proven not to work. There's evidence of that. But now the benefit was I only needed to go through one vendor management, procurement cycle.

Here what we're saying is, boy, there's a real need to not only have these inable systems or these solution stacks, but how do we help these organizations purchase in a way that is easy for them? So that is a big focus I think, for the rest of this calendar year, certainly 2024 for the composability sector to elevate itself beyond kind of the product led more simple organizations to these much larger global enterprises.

Sam Bhagwat: Great statement there. And I see that we hit the top of the hour. Thanks everybody for coming. We are really glad to have this conversation. Thank you for joining us. It's really just been a pleasure, like diving into the complexities of these complex organizations.

Eric Feige: Great. Thank you. Be in touch.

Keep reading

Recent posts

Streamline website development with Netlify's Composable Web Platform

Untangle development bottlenecks

Access the guide