What is Your Platform GTM strategy with James Urquhart

Episode 120 · 29:40 · SRT · archive.org · all Tanzu Talk

Okay, I'm here with James Urquhart at CF Summit, just having a quick catch up. And James, you had tweeted a little while ago, which is kind of where our side conversation came from about, you know, if you're, you know, operating your platform as a product, what's your go to market strategy? And of course, you know, that's that got my attention, because I think about that kind of stuff all day long. So I wanted to unpack that a little bit with you. Where does, where are you kind of coming from, from the thinking about, you know, a platform team inside a company, their customers are just internal developers. Why should they be thinking about a go to market strategy? Yeah, well, so that came to me, the concept of that came to me from sort of my background in product marketing and, and building product. And I sort of looked around at the clients that I have currently, and at the struggles that they were having in understanding how to engage their developer communities in a constructive way, so that the value of what it is that they're offering could become clear. So it starts with, you know, a little bit of a question about sort of what we mean by platform as a product. And I think, great podcast, last podcast, on this topic with Patricia, Paula Kennedy, Paula Kennedy, Paula Kennedy, excuse me, so with Paula, I think she did a phenomenal job of sort of describing all that. So I won't go over it all. But the core of it was, you know, the concept that you need, instead of a project manager, and a project structure around things, you need a product manager, and somebody who's managing backlog, and can be very flexible to change, and can be very reactive, and understanding what users really need in order to kind of move them forward to the next step. And I like that a lot. But as I think about that problem, and I try to map it to sort of, what is it that you're actually offering, if you're a platform team,

it became too clear to me pretty early, that you're not stopping at just offering access to the platform, the platform has to do something more. And just as well happened that I was asked to do some research into simplifying ways to bring software to production in large enterprises through, through Pivotal. So we call that path to production. And in researching path to production, I kept finding the And I found myself bumping into a lot of the same questions and a lot of the same issues that I looked at when I was trying to help teams figure out how to do platform as a product. And so it resulted with me kind of realizing that the go to market strategy for a platform team has to be about path to production as a service. It has it really the service that you're offering developers is a way to quickly yet within constraints as required get their software from development through testing and into production. So let's go back a little bit when you said you're running into the same issues as you were thinking through kind of the challenges of path to production. What are some examples of the kinds of things that you were coming across that, that reminded you to that same, the same issues and challenges and mindset shift of the product mentality around your platform? So the big area where there's overlap in the concepts is really in the dev built and deployment chain, right? The big overlap comes with not so much, it's not so much about the code itself. It's not so much about the deployment environment itself. Although both of those things have to be compliant with certain roles as well.

how do I move it through the process from a finished writing code concept is strong. And actually begins before that to be really honest, if you think about the need to even identify whether a project is, you know, is worth investing in from a coding perspective, there are elements of path to production that start even earlier than that. For instance, you know, something that a website that broadcast Welles Fargo's, you know, security keys would never ever, ever be the right thing to start building, right? It would be something so there's some path to production things were maybe helping teams understand and get so the pre-approvals that they require to determine whether building something makes sense might be part of the service and I would argue is something to really think about. But the bigger part is once code is done, then okay, it's more than just can I run it through automated testing, unit testing, integration testing, system testing, all that stuff. It's also about can I run it through automated testing, unit testing, integration testing, system testing, all that stuff. It's also about can I run it through automated testing, unit testing, integration testing, system testing, all that stuff. It's also about can I can I get it through the right approval process and the right approval change in the course of all those steps that I do in the right places. And so what large companies struggle with is they've custom built those processes. Basically, each development team, my experience has been each development team has had to go out and discover what is their path to production, right? They've had to go out. Like they've had to go talk to all the teams and learn, oh, I also have to talk to legal, oh, I've also got to talk to, you know, this team that, the accounting team, because they're sort of handling money or whatever. And so that, that beginning to understand that chain becomes something where everybody ends up with a custom, you know, a custom built chain of some sort that involves human steps where they have to stop everything and go send everything off to, or write a document for Pranet Library. Take seven days to write, right? Take seven days to write a document to go send somebody else to wait another seven days for it to be approved. And that's highly inefficient. And that's the kind of thing that developers, the kind of toilet that developers would really like to get rid of the most, right? That's the, they've done their hard work. They just want stuff to, to, you know, to be told if there's bugs or problems, compliance issues, whatever, and get those taken care of and then get the stuff into production.

actually about a year ago at CF Summit where they were explaining basically that I think it was something on the order of like 800 different controls that needed to be met in order for you know an you know Air Force developer to actually put their code into production and you know one of the things that the of course the cloud this was Cloud Foundry Summit so Cloud Foundry was a big part of it but I think it was to your point you know not just hey we've got some software and plugging it in it was looking at hey this these are the 800 controls that you know they have to deal with how many of these can we tick off I mean some of the things that he mentioned were you have to make sure that there's like a fire extinguisher like within 10 feet or I don't know something like that the proximity of a fire extinguisher to where the code was deployed which you can imagine how difficult it is for a developer to actually provide assurance for that right because it's like I don't know where the fire extinguishers are you know like in the data center like ask the data center team to write me up a document right include in mind and then of course it's like you know you're constrained like I know if if they want to move my code to a different server or a different rack I've got to now like do I need to go walk and take a few steps to like oh I'm outside of my 10 foot right something like that right but that then became what they could encode in their platform and in their offering so there were only like 40 or something controls at the end that the developers really had to deal with which were probably all very specific to their code anyways and much more manageable set perfectly articulated I think that's exactly the the value of the platform and the value of PCF and the server plus the surrounding tool set that supports it is that ability to tick off check marks and so many of the check marks are related to legal concerns which are very simply making sure the wrong licenses don't get into the code base that that exposes risk that the data is managed in a way that that mitigates

any sort of legal risk right there are things that the platform can completely remove from the developer concern in those those senses your PCI compliant application okay these are the services that you have to consume and those services will take care of making sure that data is distributed to the right places not running geographies that they shouldn't be running and you know that might be some work for the platform team to support them right but that's the service yes the service that's being offered so what's interesting is I think about you know in some ways you would imagine gosh like the air force has it the worst or anything in government military it's got to be the worst because it's so bureaucratic but on the other hand now you've got me thinking that well at least they probably had the 800 controls written down somewhere and most enterprises like where do they even you know because it's so custom and it you know it didn't have to you know have a act of congress to to pass how do folks even begin to figure out you you mentioned you've got to go talk to legal and talk to accounting there is no list of the it could be 800 controls in your enterprise but right no one actually knows because no one's written it down is that what you find banks banks will have it written okay so those that are regulated will generally have tons of information written down my understanding is is that like a bank like wells fargo that what they you know they have documentation about policy that is like six volumes of thousand pages each of written policy that needs to be considered something like that right so you're talking about massive massive amounts of information and you have people whose career at the company is to know what those documents are and what's in those documents and to help guide teams through that so if you're building a new application the first thing you have to do is to go find somebody who can help you interpret what the controls are even though they're written down on the other end of the spectrum you know i worked on a commercial application for a large

large cloud provider um that in part was selling going to sell uh you know professional services type things um and so this provider you um would think would have really easy commerce capability and in fact to get an e you know a transaction executed at the company um there were five different teams involved uh each of them had uh changing set of requirements because they were learning as they went about selling services um which was different than what they traditionally sold and um and then you know including accounting which had you know all kinds of crazy accounting practices because of different geographies around the world so it was never simple it was always something where well you know rules led to more rules led to more rules and so now the the good news there is if there's a single interface between that complexity and the developer environment development environment then each of those teams has one team to deal with to make those modifications and each of the modified now each of the the platform team can deal with that stuff and the developers only have one team that they need to talk to them yeah but they're kind of working on those compliance issues um you know i don't think it's necessarily as straightforward as okay the platform team can solve everything but to your point earlier i think the idea is to check off as many check boxes as you can as well as you can and to be a trusted advisor on if you use the platform how do you stay in compliance and if we run into an issue that the platform team can help negotiate with the appropriate you know um compliance body uh with um how can we resolve this in a way that will be resolved not just for this one team but potentially for every team downstream and i think just it sets that iterative process up around the compliance piece to over time make it

better and easier to stay compliant what about um i mean you mentioned like yeah this cloud provider trying to do kind of commerce transactions was actually a lot more squirrely if you will that's a technical term um a lot more squirrely than uh than a regulated entity that you would think and probably does have a lot of requirements um is that something you that you know you've seen kind of be pretty consistent where you know everyone has a pile of requirements it's just a different degree of who like how well they're understood and is there actually someone potentially already in the organization who might know how to deal with all of them yeah um there's the wells fargo situation there's definitely people who you would bring in to that conversation who kind of knew how to deal with the generality of policy right they may not know all the specifics down to total detail but they know you know i think that topic is covered over here in this section of this document and so you need to talk to these people to figure out how to resolve it um and i think uh on the other hand i think there are many organizations where at a very very high level they say okay um you know if you're doing certain kinds of activities you need to talk to legal if you're doing certain kinds of activities you need to talk to accounting if you're doing certain kinds of activities you need to talk to you know um right you know compliance or whatever the the group might be that that adjustment is um that that difference is really why every single company that we've talked to some people have good order around how they customize path to production for people so it's it's just not automated constrained yeah it's not very automated but every single company right now i think that gets the platform thing gets the acceleration benefit but then slams into the wall of um of how do you deal

with um all the compliance so that i think you know to get back to the concept of a go-to-market strategy i think your go-to-market strategy has to be um first have i actually built the right service around the platform product that i'm delivering and um do i have the right elements i don't think that has to be big onerous large staff kind of stuff i think what it has to be is you have to at least have your you know you know some program managers um as a part of the team um understand uh those elements where they have to reach out to the rest of the organization for the platform to be valuable um and then i think you're going to mark says instead of advertising we have this platform come use it i think um you're better off marketing what you're doing is saying hey we have this way of getting your code to this to production that's a thousand times easier than what you'd experience if you went on one to it on your own yeah come check it out so what's the mvp model in this scenario where just to get like one customer right the customer being an app team just to get one customer through this you've got that's a pretty uh potentially complex mvp just for one is there is there a an mvp model that someone can use i think you can build out the mvp for the first customer um by understanding what their path to production would be without the platform um and then in the course of getting that application onto the platform um doing the work required to automate the low-hanging fruit or whatever kind of easy stuff to get going but i think build automation is absolutely required i think deployment automation is absolutely required so if you want to say what's the mvp at least make sure that you have an environment that can do site cicd in some reasonable way that's extensible in terms of the

processes um but um but i think you can add some things of value into the picture like you know auditing documentation so a lot of stuff and you can you know set up auditing controls for the running application plus document everything you do to build and deploy the the document relatively easy because the platform can output all that information for you okay i mean so it sounds like maybe for that mvp there's still a little bit of like the the man behind the curtain happening i would expect i mean this is a complex problem as you said i i i don't want to you know overstate the simplicity of solving all these problems this is the service you're offering um and so i think you'd have to start with what's the what's the you know first thing of value we can do for developers to come here that makes their life easier and i think cicd is a great first step right without having any compliance check stuff but i think you're going to run into well everything hits hits a wall i mean the most common examples i see is everything hits a wall um after everything's been built and is ready to go to staging um but um is not absolutely not allowed to go to production until a crop passes the following gateways right when you hit that wall that's your you know theory of constraints stuff right it's just that's your constraint that's the thing that's going to build up your work in progress and that's the thing that you should go kind of look at to see if you can attack first and they're your your way of attacking the problem will vary depending on what that obstruction is it may be about shorting the the approval time um automatically generating documents to make approval easier something along those lines may be sort of what comes out of that picture and you may even find the early development teams are willing to help with some of that um and and help build code that can be used by the platform team and i would not be uh reticent to um ask for that help or to to have conversations with the development teams about you know the ways

that you can again automate their path to production make that easier but then reuse that information now those at least those activities for other teams when they come home okay and over time you'll learn some patterns hopefully um that will allow you to begin to say well here's a default complete end-to-end path to production chain that we think all apps should start with but there are ways to customize or add steps or add activities to different um steps um where needed because um because you know i i i'm one who believes very strongly that um when you lock down the opinion too much and don't allow other um opinions or customization of that opinion um that's the point at which support for what you're doing will start to fall apart because there'll be those things that pop up that just can't be done that way and so the whole thing kind of goes out the window and um so i you know that's a big thing for me is that's why the tooling is really important not only that the platform allows you to to manage services in a way that can be allow you to offer like different types of services for different scenarios or whatever but also that the build chain environment allows that extension as well okay um to kind of come back to you were starting to walk through what your go-to-market strategy should be you know make sure you're building the right thing effectively um and then i don't know if i sort of took you off on a tangent around the the mvp question but you know just to come back to that thought what else is sort of in building that and that go-to-market strategy so if you look at what product companies do to take stuff to market there's there's really sort of three key areas that they're focusing so one is they want to educate those that are going to discuss and evangelize the product to others so that's you know educate the sales force educate the sales engineers and in the case of an internal product i think what you want

to do is go educate the champions for platform use in the different business divisions um usually they're going to be development team members senior technologists maybe architects um but you want to go out and and and find and educate those evangelists on what it is that you're offering so they can know that no you know what the platform already does that or the platform could you know we could get that on the roadmap and that would be done in a reasonable period of time um the second thing is um there's a broadcast aspect to this which is um being able to understand uh you know basically having collateral that's available that's available a brand um things along those lines there's a big push i think among pivotal customers um to really begin to figure out how to brand the platform and i think the reason for that is because it is a service offering to the rest of the organization so it's really good to have something that people can say you know instead of say the platform they can say you know whatever bob or whatever your brand is and then the third thing is um then you need sort of a a a process to go to my markets kind of uh sales cycle would be typically the term or sales process would be the typical term in a product company but i think in an internal project it's an onboarding process you need a way for once people discover you and want to know more and then want to try it and then want to do a serious prototype and then okay now i'm going to use it you need to be able to give them a way to guide them through that um i would argue preferably self-service as much as possible so that you don't um you don't have create a huge need and demand for human resources in order to be able to support that um but uh but you have to figure out for your organization what's the right thing to do there and what's the right process and play to have to get people on board and then that's another element of the service design that's really important to iterate on in addition to what the platform functionality is

that onboarding process is really important to have the product manager at least pay attention to yeah this is something where you know just as a as a product marketer by by craft or trade um you know you can see the difference sometimes between a product that's built with the the effectively the marketing and the proliferation in mind versus one that's not right and you can see a lot of the especially the kind of sas offerings a lot of consumer software you know folks have gotten really clever in terms of you know whether you want to call it growth hacking or what but they've they've really started to tune in and it's true like they have to build that into the product you have if you have a product manager who's not receptive to that then you know you're going to struggle because there's a lot of ways where well you know we want to be able to offer a like a free trial version right and i'm thinking about on the commercial side not an internal product but you see this with well start with a free trial but you know give them a way inside the trial to to upgrade right instead of having to make it a painful process of well actually you're gonna have to go re-download everything right that's that's an unnecessary friction in the experience or you know things like hey once you've you've activated your account right you downloaded our app and you you signed up well now like you know you can't pop the the champagne cork yet because they could just abandon that immediately so good how do you follow up you got their email address so like felt follow up with an email like tell them hey here's how to get started like gamified a little like you like let them get their first achievement unlocked within you know just by walking to the bathroom right i'm using like the fitbit analogy where i don't know if you ever use that but you seriously got that first achievement like just walking to the bathroom and you're like oh cool i unlocked and then they make it harder but right you know it's that those notions i think can

totally be applied on an internal product right if someone has to register on your platform with their internal email send them a follow-up email like with that collateral with that kind of onboarding welcome experience so that you know they they know how to take the next steps and you you can retain them as a as a customer if you will yeah i think that the scaling question is the thing people get afraid about there and i i just sort of say i've never seen it even the larger enterprises i've never seen a situation where the number of leaders that you have to interact with in order to kind of sell the platform gets to be an onerous amount um and so i think you you look at sort of what relationships you want to build with what people within the organization in order to kind of complete the the transition and i like the idea of the emails and i think uh you know that that's absolutely the kind of thing that you should be doing um uh to to make people feel like they're they're welcome and comfortable another thing i think is just you know and people want to go through architectural transformation as part of sort of app modernization as a part of adopting platform too and that's happening in a few customers and so that the the the tendency i think is to think so unless your app's ready to be on a modern architecture you know we don't want to deal with you but in my personal opinion i think that's the wrong way to think about it i think letting people understand and see the path to production just the beginning of the path to production is easier even if the app's not compliant and never going to get to production in the long term um understanding that there are these guideposts and these things that help you make sure that you uh your application will be compliant downstream with new architectures with everything else um i think that's way more valuable yeah and so you know having just a sandbox environment that um that you're much more kind of comfortable and flexible with allowing to happen uh whatever the developers want to play with there but it's

secure and safe and not production um i think that's really a critical piece of the puzzle too that makes sense i was talking to a customer you know not too long ago maybe a month ago and they they were talking about you know they have a lot of uh legacy web sphere applications and from other customers i talked to you know who have a whole slew of legacy apps it's they those teams feel overwhelmed and buried and just trying to keep up with you know patches and updates and they're on way outdated versions and they they they feel like they can't find any time to do any of this and so asking them to your point to like oh yeah sure you can come on this great shiny new platform you just gotta re-architect the whole thing right is like yeah like no thanks right so you know this this platform uh team they they they tried they took the the liberty build pack they made a few modifications and then they kind of went around a team just like in their sort of i don't know if they called it sandbox but it wasn't prod but they just said just try it just just just try it right see if it works and what they found was most the time it worked right and it was hey a pretty low barrier to just get something on the platform give them a little bit of taste of oh gosh this is going to be a lot easier and i like then you can start to work with them to build out not only more of what requirements they have but you know over time they get freed up to be able to go back to some of those apps and say i think that's the one we really do want to re-architect a bit and just and invest more but we we were too buried in our tech debt to to think about investing in that and just one quick more comment on it so the court the question we've been going around and beginning to talk to the leadership of platform teams about is you know the question they should be asking their teams when the teams think they've made an accomplishment or want to propose a change the way they're doing things is very simply um great do the developers love it

right i mean very very simple question get the get the attention turned away from how do we how do we work the mechanism so that we make our immediate leadership happy and shift the attention to how do we how do we build a service and create a service that makes our end users and our ultimate customers happy yeah well on that note that seems like a good place to pause but great great chatting with you um and uh i think there's a lot of illuminating ideas for folks so thank you so much thank you so much

Tanzu Talk · 🍕 Get more pizza.