Building Product in the Enterprise, with Emily Tate (Ep. 93)

Episode 78 · 48:14 · SRT · archive.org · all Tanzu Talk

well uh today it's a little warmer down here how is it up there in dallas what temperature do you got oh it's 66 degrees today oh see so what i'm looking at my watch 64 so this this is the first day in a long time i put some shorts on now i got the whole long sleeve hoodie shirt thing on top shorts on bottom so i'm trying to warm up the blood to go down to the legs to cool off like a car but but i'm i'm excited i'm wearing shorts so i just wanted to announce that significant event that's the title of this episode how about up there how about up there in in uh in seattle richard i think it's a high of 50 i was in los angeles last weekend where it was too hot it was like 80 like i can't handle that anymore i need winters to be like winter so i'm glad to be home have you been to those uh those plant pods they have downtown yet no i saw that between the plant pods and the uh cashier less grocery stores i don't know what's going on in seattle right now but i need to to check those out next thing you know you're going to be going to amazon to uh renew your driver's license now i get my insurance there now apparently so they're they're a one-stop shop that's right well uh you know why don't you introduce yourself briefly guest hi i'm emily tate a product manager here with pivotal labs and uh i we wanted to have you as actually as always richard's idea uh to have you on he has all the good ideas and uh you gave a talk at uh SpringOne platform the most awesome name conference ever recently um i think on a topic that i especially like and uh i i think most of our our listeners were which is like enterprises crazy and uh and and more you know more it actually had a different title that was my title but i think i think it was interesting about your talk was the uh uh as we would say around here there was a large degree of empathy in it still maybe some snickering but sort of empathy of like how did these companies get this way and uh how might we solve them

and then and then peppered with dilbert cartoons i haven't seen dilbert cartoons in a long time so that was refreshing i noticed at some point they switched over to wearing badges on lanyards on their neck which maybe that dates uh my bookmark in dilbert talk tobia i don't know what to call that but anyhow off to a fresh start here but before we get to that we'll go we'll go over some news things here uh just some little items we've been uh collecting now this just yesterday our our good friends over at red hat it looked like they they're uh they're acquiring core os for the uh the fine sum of 250 million american dollars which which uh that's that's a you know uh if you're into grandioseness you could also say a quarter of a billion dollars which is which is always fun uh but you know that's uh i you know correct me if i'm wrong uh richard but core os nowadays uh a lot of what what they're known for is having a kubernetes distribution right yeah that's fair they've done some pretty cool things with linux they are sort of the open source uh maintainer of things like rocket the other that's right container engine versus docker and also etcd and flannel so i mean they've got some cool tech some smart people it's probably a smart move by red hat so well done there i think you'll probably see more consolidation in this remarkably overheated container space remarkably overheated what i would be having if i was wearing pants instead of shorts today that's what i was thinking i said that because i was thinking of your your long sleeves and your shorts combo that's stuck on my brain now that's right you know there there's there's a uh if winding is still a word there's a winding weavy uh story of how one day me talking to core os made me end up having a job at pivotal i'll have to save for a fireside chat mysteriously with no fire one day that that would be fun but yeah as as you say as you say i think it's it's indicative of the uh the interest in in in the kubernetes space and and also i remember you know when i was introduced to them i was looking

this up i uh apparently wrote the first report at 451 research about about them back in 2014 and i remember uh alex over there their ceo he had this uh i don't know what you would call it sometimes epiphanies come from lateral thinking as de bono would tell you with his uh multiple colored hats and whatnot uh but you know he he had this he had this fun epiphany that was like have you ever noticed how chromebooks just update on their own and firefox just updates on their own and no one ever notices and it's really cool and he was like we should do that for servers and i don't know if that necessarily panned out as a major thing they were doing but i think starting from that basis of like uh we should stop doing dumb stuff and and do the smarter thing when it comes to patching and updating was that was that was a fun start to what they had and i think like a lot of people in this space uh they've been driven by the uh the cloud native interest where in this case cloud native means kubernetes uh entry i don't know if that's entry one or two in roger's book of technology but it's somewhere in there they did some good things with updating linux and some of the patterns they introduced so it'll be interesting to see how red hat incorporates them you know does that change any of their own back-end components when they launch their own kubernetes pieces i mean it's all the container stuff's fascinating it almost feels like as we deal with containers it's kind of skating where the puck is and serverless is where the puck is going so you have to keep an eye on the next thing while you also satisfy the current thing so that's where this whole market's fascinating because we're all now starting to get a wandering eye to different patterns of functions and things like that while hey containers are just becoming mainstream so how do you kind of balance all those pivotals trying red hat tries microsoft tries amazon google but if you're a uh a customer i was going back to to probably what we'll talk about with emily boy how do you balance all this and make sure you just don't overwhelm tech teams with all this tech changes it's uh it's tricky indeed that's the hockey one if i remember that's the that's the uh gretzky sort of quote yeah i gotta

bring sports every now and then mullet strategy well uh as here's one of those exciting items that i haven't read about but i probably should have so you can inform me so also there's uh the general availability of azure event grid so what is that richard yeah they announced this a few months ago is like a preview and what this is is a kind of a managed event processing service or routing service it sits there underneath your azure account and listens in on things like hey vm change events and storage things and so all the services in azure for example throw off information hey i you know did this did that and this gives you that one sort of bus to subscribe to and you can write your own events into that so really just kind of you know spin up functions whenever someone creates a vm it just really helps event-driven architecture it's something that for some reason is novel like other clouds don't have this idea of a single place to subscribe to sort of system events and and things like that so it's really cool tech i'm you know i know the team that made it and it was they did some really good work on here that was pretty interesting stuff so i think you'll see some people copy it because it is a good idea and if you're an azure customer it's a cool way to to start building event-driven apps you know that reminds me uh i should put a link to this i was uh i was catching up on just news in general and there's a uh you know i use instapaper a lot and so whenever anything's over like four minutes long i consider it long but there's this according to instapaper 17 minute uh little little write-up that datadog did about uh how to monitor rabbit mq and of course being a monitoring company they're like obviously step one datadog but what's interesting about it is uh it goes over like how rabbit mq works and the different different things that would happen in any event system and therefore what you would want to monitor uh with it including storage and things like that but it was it was a fun overview of like uh you know when we talk about like day two operations and and you know that the uh the implicit user story is always software should work it's it's a good it's a good peek into that so uh if people like you know monitoring or if you want to call it observability

whatever you want to do uh you should check that out so then also uh there was a uh in the economist they took a break from talking about how facebook is destroying civilization uh and and wrote about the the trend of i we might need to go update our marketing material richard because i think we're supposed to say edge instead of iot now but they had a pretty good overview of uh the rise of of edge or iot sort of like computing from consumer to industrial stuff and um you know their headline was a little um headliney i think the register needs to call up who wrote that headline for him and just teach them about alliteration they have a new headline writer but it was the error of the clouds total dominance is drawing to a close now i suppose if you as they used to say parse that what what it hinges on is total dominance uh but it is a good overview of uh off of the public cloud here are a bunch of things going on that uh will probably drive some it usage you know sort of like the uh the new pc that you would be targeting versus just all in whatever the cloud is yeah i mean it's interesting i mean i'll do i guess what people on twitter do which is comment without reading the article uh so in this case based on the title uh i mean all the public clouds continue to expand like crazy so this idea also that hey i'm going to use more localized things but i get the point that more things move to the edge you do more processing even in the client like how much stuff is happening in javascript i was on the plane without a connection the other day and i was still able to do stuff on a couple of websites i didn't expect so there's always things that are happening more in distributed spots but this idea that the back end of those won't be the cloud probably not the case the cloud keeps moving to more locations moves to more edges look cloud flare has a platform now so all of these sort of technology companies continue to add functionality i don't again not zero sum it's not going to be amazon or edge clearly amazon has a great edge story as well as does pivotal as does azure as do others so yeah i think it just means we keep feathering it federating out where stuff runs you're probably

not going to be using a single provider or a single way to deliver compute that's right federating and feathering two things that go great together that's that's what i'm thinking and then and then finally just as a pointer so i've i've been sitting on this uh write-up that i had for a while of like some uh i always think of these as proof points but just sort of overview of uh government uh people u.s government people who've done whatever you want to call it digital transformation or cloud native or devops or or as i you know at the end of the day call it you know figuring out how to compute or better with their custom written software and uh it just kind of picks from a lot of public sources about what the irs has done in the uh the air force u.s air force and even contractors too often the uh the perceived baddie of government work but uh there's there's a lot going on in there kind of surprisingly for people's uh bad attitude about government about how they're improving software so so i'll put a link into there but it's uh as always i think uh i think i think when you look at sort of like the the process that they they uh adapt adopt they adapt to their whatever they start using and then the uh the outcomes that they end up getting and i think interestingly especially in the case of the air force you can see how a few initial projects of doing things on an agile basis where you you're more or less textbook like uh even extreme programming but textbook like user-centric design and agile where you're you're actually talking to the users this is a novel idea for any sort of software project uh but you're talking to them and you're actually shipping on a weekly basis and adjusting it helps them expand out into other things not just that one uh initial project that they have so uh anyhow i'll put a link to that in there just it's it's uh well i think it's good stuff i guess i do too it was a good write-up i read it yesterday that was good job that's right uh so on that note speaking of talking to actual users i have to say uh emily i don't know what i have to say means but one of the one of the funnier things that i remember uh in your talk which which we'll go back

to summarizing was uh and and also sort of like incisive things was like every time you want to talk to an end user everyone wants to get in your way and actually prevent you from talking to an end user and and i think i think you listened listed the familiar cadre of people that uh would much rather talk to you about than actual end users but i think i think that one point to broaden it back up was uh one of many points you were making about how uh let's say doing good software and taking kind of like an agile approach to software and product management in uh enterprises and by enterprises i sort of mean large companies is uh it has its own challenges and is difficult but you know on on on that context like give it give us a a summary of the premise of of this talk that you did yeah it's funny the the talk actually came out of that section of of the of the talk uh i did a lightning talk at a meetup talking about getting to your actual users and and all the challenges pushing through and as i talked to people afterwards um the conversation naturally shifted into other challenges to building good software and using modern design thinking and product management practices and tech practices in these big companies um and and just continued develop developing it from there uh really the the talk that i gave was just describing the most common things that i see when i talk to people in big companies my experiences working in big companies that keep us from doing the things that everyone knows is right um and the way that we look at products the way we look look at what success looks like in a company uh is very different when you're talking about a big enterprise where frankly just checking the box that you got something done on time and on budget is considered success whether or not it actually does anything for the end users or whether or not it makes a dime of money

as long as you met your commitment delivered on time and on budget it's considered a success yeah i'll have to see if i can find this uh clip art i think it was in a book somewhere but i remember uh i remember back in the early 2000s when i was trying to be all agile hipster and in a genuine way one of my favorite like pieces of clip art were these two people with kind of like the the hairied uh loosened tie and one of them was holding up this big like gantt chart and he was like we have the plan the plan will save us and they were they were very excited about this plan that they had but it was representative to me of what you're saying of like yeah the plan's great but uh like the other 99 of greatness is actual running code that does something useful and so don't get too obsessed with that so i wonder like i know this is like a thankless impossible task but sort of like briefly can you kind of like lay out a baseline of what everyone knows you should be doing like like what does it mean to have like a good product mindset like uh in contrast to an enterprise if we were like in some functional small team of people of awesomeness or whatever mythical thing that actually doesn't exist out there like what what's the what's the good baseline we're shooting towards yeah you know you hear a lot in the industry of actually solving problems and and focusing on outcomes um you know making sure that you're you're starting from the user perspective and understanding what the user needs and being able to decide okay we want to make a user's life better in this way and then figuring out how you're going to do it and building working on it iteratively releasing uh you know what's kind of become the curse word in the industry the mvp um or something that you can like get out to users quickly um that's what we all are striving to do but when you get into these big corporations uh like you said you have to get the plan of record the amount of time i've spent uh in my career updating plans of record is unbelievable um right and you you build a

a roadmap a year out or two years out or you know god forbid 10 years out um thinking that you know what's actually going to happen in a year's time uh and that you know what the problems you need to solve are a year ahead ahead of time um it it just doesn't leave room and then when you're building those plans you have to say exactly what you're going to build i i'm going to build this feature i'm going to fix this bug and i'm going to fix it sitting here in you know february of 2018 i'm going to fix this bug in october of 2018 well how do you know that that's still going to be the most important thing to do in october of 2018 um so it's you know how do we take the things that we hear about when we go to conferences and when we go to meetups and we read all of the articles and we we read lean startup and and we want to go and do these experiments and try to understand what metrics we should be uh building to how do we actually do that in a big enterprise yeah i mean one one thing you i think about as you explain that i was reading some forester survey the other day that that talked about budgeting practices and funding and you mentioned this as well as i mean is that sometimes the trigger for this i mean why are we stuck on plan of records is it because there's an annual funding cycle and therefore i have to prove what i'm going to spend my money on like what do you think is that upstream driver that that steers us into this hyper planning model versus let's be responsive to customer need let's be a little more adaptable to what's going on what do you think that trigger is yeah i think i do think the funding model is the trigger to a lot of it and the funding model comes out of a desire for control um you know when you've got big companies that have hundreds of products they're managing big portfolios um at some point someone's looking to say how can we make sure that we're spending our money the most effectively um and it's it's easier it it's it's much more it's much easier to grasp for leadership to say we're going to have everybody submit all of the projects that they want to do and then we're going to decide which of those

projects deserves funding and then we're going to fund the project based off of a scope that people have told us up front um and and then we're going to measure on if people delivered on that scope so you end up with these processes where you're having to to request down to the line item exactly what you want to build really far in advance whereas when you look at uh kind of what's generally accepted as better practices is to build something small and iterate on that and continue to uh try to decide kind of what comes next based on market feedback so the the funding model doesn't really allow for responsiveness to change or uh responsiveness to kind of getting feedback from your users or from the market and if you want to change you have to go back through request processes and go make justifications and and a lot of companies they even kind of say you know hey uh if you if if you decide that what you want to build is not the right thing we're not necessarily going to give your product the additional funding we might move that to a different product so it incentivizes teams to kind of be very protective of their budget and even if they see it's the wrong thing and they want to change or they want to shift directions they kind of are forced to keep going forward on the path that they're on because that is how they keep their funding um so you know i think if if you're able to actually fund products differently and fund the product instead of the project um it allows the product managers the product owners the people who are actually on the ground and closest to the customers to be able to to know and be able to act on what they see um within their data what they see in interviews um but that's uncomfortable for executives to do because it requires a lot of trust uh to give the teams the autonomy they need to do that yeah i mean you're you're making me sad when you you say those things because it's all it's all super i mean i've lived that before and in my experience what you just said i think as you think of

funding products versus projects so yeah so help someone chip away at that so if somebody's nodding their head sadly as they listen to you say that and say yep that sounds exactly like how i have to plan my 2019 stuff already it's 2018 like there's this this giant cycle how do i tangibly start chipping away is it to say look let's find a couple of key mission critical products and make sure we build balanced teams around those and fund that team in independent of releases and projects and things like that how does big company x kind of start really incorporating this not just lip service yeah that what you just said is actually exactly where i would start i would you know kind of start with with one team and and prove the model out of being able to do things differently and even within that team so um i did this at uh at the last company i was at prior to coming to pivotal um we actually had a team um we still listed our i would say quote unquote projects but it was really more buckets of funding around some themes and so i was able to say okay uh you know i want to improve the traveler experience uh i want to you know form partnerships with additional third parties or you know kind of some different general categories um we built up the amount of funding we were asking for based on some hypothetical projects so we think we might improve the in-transit experience through these types of of projects and it kind of came up with a target number but then got agreement from leadership that okay i'm going to go forward with these themes and these strategies um the actual the actual projects and the line items within the that bucket of hours may change as the years as the year goes on and we're going to keep an updated roadmap we're going to continue to refine what the next right thing is to build um but we're going to spend this much money on this product um and you know being able to frame it a little bit more as a test or kind of as you know as the exception um let it let it be palatable

um but i think what it started to show is that you know when we were able to give examples where something that we didn't even know was going to be on the radar at the beginning of the year suddenly became really important and we were able to turn on a dime and and exploit some opportunities that came our way that in the old model we wouldn't have been able to do it would have been way too much red tape it started to prove that yeah this is a viable way of of running a product is that a metric you would show like if you were measuring that at the end of the year it can't be touchy-feely right there's got to be a reason that giving this team seven million dollars to run as a product yielded benefit so yeah what are those kpis yeah so we as a product kind of set out what our metrics were so we in general had three big ones you know we had an acquisition metric and engagement metric and a revenue target and so we kind of from those targets came out with what we thought we could do to impact them and then um you know basically the company agreed to here's how much investment we think these targets are worth um and we really got put on the hook for those targets a little more than other products were because um you know historically again as long as you met your on time on budget uh it was those were usually built out of some business plans but no one ever actually went back to the business plan to see if they did what they said they were going to do as long as you got the features out that you said you were going to get out um we were held a little bit more accountable to the actual numbers and the outcomes of what we built um which is what we should be anyway like if a product is getting things out on time and on budget but they're building the wrong things then maybe that product's not what's needed in the market so that's how that's kind of how we managed it within within one large company so i i've noticed in uh i don't know my my uh paying attention or trying to figure out change management that as as part of what you're saying a lot of it gets down to uh uh to use hollywood-y

terms you got to have this one uh let's call it a little break not a big break where where someone says oh you should just try that in the new way like like you just at some point you have to get a small enough project where uh you can see if it works out and sort of prove to yourself that that it pans out and i don't know sometimes like a skunk works kind of thing uh works out which has its own risks like if you fail at it then you'll probably get fired or uh you know be assigned to uh write the new supply chain management system for pencils and post-it notes or stickies as i think uh but it it it does kind of get to uh getting someone to say that and and even the way i'm wording it is a little weird give permission for it it gets to another point that you raised up that was fun and it's like there there's always this mysterious entity called uh they that that you know they won't let you do this or sometimes i think they turns into a we like we don't do things that way but there's there's this uh sort of like headless uh sort of body of authority that people keep uh referencing as as a reason you can't do that and so so what you know how would you describe who this this sort of they is and then and then how you sort of like tactically deal with almost like the uh is if falsity is a word almost like the myth of who they is so you can get beyond it the concept of of the figure that i like to call the mysterious day is is i think a big challenge in big companies um it's it's really the thing that gets thrown out as a conversation ender um and becomes a way to deflect responsibility from the things that you just either don't want to deal with or from your own opinion uh so an example i gave in in the talk and really where this concept came from you know we had an an outage one time that caused them to you know caused our enterprise architecture team to lock down the data center no changes could go in nothing could happen unless you

could prove you know you're going to be losing two hundred thousand dollars of revenue a day or or some insane metric um for my product we were completely unrelated to the system that had the outage we weren't touching anything that could even come close to taking it down but they wouldn't let me put uh do a change that my customers needed and that was really important to my market and so i started talking to one of the ops guys and and just say well you know who do i need to talk to in order to make this happen and he said well there's just no way they're going to let you do that and i said well who's they and he kind of paused for a second and said what do you mean i was like well is that the the you know cto is that our is that our chief technology officer i can go talk to her i'm more than happy to have that conversation he's like well no that's not she doesn't make that call and i just walked down the org chart until he finally admitted that like there was no they that was really stopping this he just didn't want to go ask the question or he assumed that the uh he assumed he already knew the answer and and at the end of the day no one really had the authority to say yes but a bunch of people had the authority to say no um and so you know i i just it became a a phrase that i i may say i became famous or or infamous for of you know okay who is they who's the mysterious they i want to talk to they and have a conversation about why we need to do things differently um so and frankly the biggest the biggest way i have found to push through that is to just push back and to just be the person to constantly you know just say who is they tell me who i need to talk to who's the person who can make the decision um you know people want to appear like they've made thoughtful decisions about these things and that they that these are like actual policies that are grounded in reason and procedure and a lot of times it's not a lot of times it's just i don't want to ask the question or i assume

the answer is going to be no yeah you know that that that makes me uh kind of coalesce uh uh a few things uh you know i i'm i'm i'm always uh well it's always good when you're talking to a room full of people to start uh bagging on managers first people find that delightful uh but but more genuinely uh i guess i say that speaking to two managers effectively but uh uh uh you know it it doesn't make me think that one of the responsibilities in in computering better as i was joking about earlier that managers have is to almost like unday themselves in the sense of um it's easy for for let's say staff and teams to kind of imagine and presume what what managers would say and what their reaction would be to things kind of based on yesterday's policy so to speak or just the status quo you know use uh the old uh larman's law or whatever but you know it's it's been my own experience in in uh suggesting change and doing things that oftentimes you go to like a decision maker or whatever uh and you kind of propose new things to them and they're usually pretty open to it like oh yeah that sounds great we should do that and i get the feeling that a lot of people in the types of large organizations i talk to they don't really think of managers as very accessible as as someone that they could uh talk with and instead they're kind of in their uh executive tower so i don't know it seems like that's part of what you would want managers to do is to you know i probably no one should ever use that open door policy again but to somehow communicate that they'd actually like them to ask things on the other hand i think you had a dilbert cartoon illustrating that point of wow it's terrible well i mean that's why i want to almost flip that into a question emily and say i mean again going back to that same forester thing i just read two days ago was that many of the respondents like 30 said lack of executive leadership on agile was kind of just a barrier in general to adapting new mindset so to Coté's kind of point in what you

mentioned like how does a management team start to change whether that's a middle manager or an executive like is it about finding the edges of your authority and sometimes pushing up against that so you can actually make decisions is it kind of encouraging a different level of empowerment like what is that change that has to happen in management so it doesn't become this they it becomes yep let's make the call and i'll justify it later or hey there's a smaller pool of people who make decisions and we can just move kind of how do you find that and how do you coach a manager that to get better yeah the first thing is empowerment uh you you have to empower your teams to make decisions and you have to give them the room to make some mistakes and do some things that don't work a lot of times you know nobody gets fired for not trying things you know it's generally people people get fired for trying something that doesn't go well but that's actually who we should be encouraging and who we should be investing in are the people who are willing to try different things and and challenge the status quo um so you have to be able to show examples of when you've given someone empowerment and not just when it's gone well but when it hasn't gone well and they didn't get the hammer dropped on them you know they didn't get all of their funding pool they didn't get fired they didn't get demoted um that that they actually got elevated for trying an experiment that didn't work and maybe saving us a bunch of money or at least you know testing out a theory that that had never been tested before um the other aspect i think is also letting people test some of those theories i guess that's really goes back to the empowerment as well um you know especially in in big companies and i found myself you know i managed a team of of people in in my last company that um you know i would get a new person on my team who would come in with ideas and i could immediately see where some of these things were probably not going to work because we tried similar things in the past or we had thought

through or someone had told me that that wouldn't work because they had tried it in the past and it was really tempting to just kind of say no to everything and and like oh there's just no way that that would work um you know let let people try things let people you know at a minimum let them take the time to do with a thought experiment on how would i test this out how would i go about these things without immediately shutting down uh you know oh there's just no way that that would work uh is you have to have to give people the room to to grow yeah how do you see this then reconcile with you know this move i guess call it devops whatever but this idea of these teams that are balanced teams or whatever the right team makeup is where you don't have to ask for so much outside approval right because if you're running it as a product you have more say in what happens and maybe i don't have to open tickets to get infrastructure because look we're using a platform where i don't need to request infrastructure i just push code so where do you see the team makeup first of all having to come into play is this co-located teams and balanced teams or can you work with separate pmos and dev teams and finance teams what have you and then kind of how do you try to maybe increase the scope of what you're responsible for so i don't have to find a they the they is us so we can just make our own decisions yeah ideally uh ideally a team should be completely autonomous and and have everything they need and able to uh and able to create software and put it out into the market so everything from being able to you know ideate on the ideas come up with the strategy um as making sure that it ties into the company strategy and it's pushing forward company goals um but once you get into the actual what we're building you should have a team that has product management design engineering um all the way through to devops um you know as much as you can to where a team could potentially come up with a feature build it test it out put it into production you know on

their own within a week um that that allows the team to be able to try more things to maneuver within the space that they have um and and actually get things to the end users um i see so often you know really that last mile like you you'll you'll have the the autonomous team within product management design and engineering but when it comes to actually deploying it to the end user they kind of get cut off at the knees um you know it has to go through 18 rounds of security approvals it's got to have you know load testing and we've got to fill out a checklist making sure that we've done all the things and it becomes a self-perpetuating cycle um it becomes really difficult to release so then the the the thought of something going wrong on a release becomes a much bigger deal because releasing is hard whereas if you can make releasing really easy if i have a bug in my software and i can fix it and get it back out into production within an hour um you know the the just the concept of releasing becomes less risky and the concept of things going wrong becomes less risky um so the more process you add the the more risky it becomes um so then you become more risk averse and you want to add more process to keep the risk from happening um so you know using a platform where you can get uh where you can let the teams take back a lot of that control within you know within reason you the reason that that platforms like pcf exist is to make it to where you can you can have the controls to where you're not introducing risk by letting your developers release into production um right so the more that you can do that and the more that you can kind of get get the full stack on one team the better um ideally co-located is even better on top of that um the conversations that you'll have when you have co-located teams versus even just the same city but in different buildings or on different floors of the same building is shocking um you know i at one point i was sitting right in the middle of of my development team as a

product manager and you know we were able to have these conversations i would overhear things and be able to answer questions more quickly and they would ask me questions because i was right there rather than waiting uh we actually ended up moving into a different building where we were even on the same floor in the same space but instead of sitting right in the middle of the development team i said i'm talking maybe 20 feet away it was not a big change at all and we actually saw our uh our communication cycle and our rapid communication decrease just with a you know 20 foot walk uh because it just anytime that you put something in the way of getting an answer or having those conversations it makes you think twice about well do i want to interrupt them do i want to walk over there is it important enough to ask um it's you know it just having that co-located team makes that communication happen so much faster so i have one more question for it i'll let Coté uh bring us home but you know with your experience talking to large companies and hearing some of these stories i think sometimes it can be this kind of feeling that we all go like oh these these enterprises like aren't they just all nuts but but in reality like our all of our lives are impacted greatly by these companies being good at this stuff like i really desperately want my bank and my grocer and my travel company i mean i want them to be great so what are the enterprise advantages you see that these companies should actually remember that they should take advantage of that you know most enterprises have you would think some inherent advantages that pivotal does try to help them regain them sometimes when software upstarts kind of disrupt them but what do you see when you come into an enterprise and say gosh you should be taking advantage of a b c and d this is what you know if you get good at software and capitalize on this you're gonna you know you're on a rocket ship you're gonna be doing great yeah uh you know people always talk about startups changing the world and and being the ones to disrupt things and really make a difference but if you look at the vast amount of resources that these large enterprises have

startups can't even touch it um the amount the amount of money the amount of reach uh the the number of people that they're already touching on a daily basis uh if if enterprises could really get in there and be able to do these things in a different way and start to solve real customer problems they are just in a much better position than most startups to have a real impact in a much quicker way um you know i was having a conversation with uh some people at microsoft at one point and they were talking about a baseline product and like oh yeah you know i mean really all that we need in order to consider this a success is you know if we if we got this out to like a hundred million people we'd be really happy and to them a hundred million people was a small number um whereas like my product i thought i was doing good when i hit a million users at one point and uh you know for a for a consumer mobile app and you start to realize just the the scale of impact it um the the enterprises have the ability to just touch people so much faster um you know if you're looking at a you know fintech and and financial startups you know ones that are trying to gain their first million users or their first hundred thousand users compared to you know if capital one was able to do something and hit however many million people at one time um the impact is just so much greater and then the resources behind it uh the amount of um you know the amount of funding that big enterprises can put into solving some of the world's hardest problems um if you had the right way of thinking about them and the right way of doing um software development and understanding users and understanding what the problems are out there uh they could they could be solving some of the world's toughest challenges and some of the really important things much faster than any of the little startups could that are hoping for their first round of funding no i know that's it's exciting even when everyone panics when amazon enters

an industry yes amazon does great stuff but you know at the same time google tried to become a telco and dropped out of that because that was hard and other companies have a built-in advantage so i like when companies respond to somebody encroaching on their market with kind of a game on mode like okay now's the time for us to step in not to be scared of amazon google microsoft whomever else but to your points let's let's take advantage of what we've got and and go win on this market i'm glad we help people with that i hope that these enterprises don't get a defeatist attitude instead realize their opportunity right i see so many enterprises that will try to legislate their way out of disruption or um you know like put up more roadblocks to try to keep the things that keep things the same and protect their business model uh and and it's like if they just took that challenge instead and said we're just gonna make it better like there's obviously a problem here there's obviously a gap that we're not solving um you know let's find ways to to win by being better as opposed to win just by being able to out legislate everyone else so so the last the last question i had i think i think uh you know uh anyone who's like vaguely read the back of a cereal box about the french revolution like the concern you might have is like uh so when we get this new way put into place how do we make sure it doesn't become a new bureaucracy and so i'm curious like as you've observed large organizations which are very prone to put uh sort of like bureaucracy in place because it can be great right like that's a huge way that you uh you scale but like how how do you think in putting uh you know a lot of this thought into place you can also put in a process that ensures you don't equally cement up around this new thing when new and better things come along yeah uh the one of the biggest things that that we like to focus on is uh continuous improvement and continuous feedback um and i think that that's very important in making sure that uh bureaucracies

don't build up that start to get in the way so you know within our xp processes we have retros every week on a team level we have them at office levels um and whenever you start seeing too many like checklists and things come in that usually starts to play out in uh you know in our retros and we'll have conversations about them i think that that companies and executives should be doing that at their levels as well um and and trying to see where uh you know where they can be continually improving and not and basically breaking down processes rather than adding new ones um it is a really big risk because the the more you scale the more uh kind of coordination starts to be needed and people need ways you know to kind of report on programs and and things like that um but i think it's just important that that leadership keep in mind that the teams are where the decisions need to be made um and if they and focus the processes on how to get information out of the teams not disseminate information back into them i guess if that makes sense oh sure yeah yeah i mean i mean i think for uh you know more or less us us nerd types the idea of like recursiveness is sort of like a a natural sort of thing to think about but there's i don't know how the leadership mba set is what their comfort level with recursion is but uh they seem to like to talk about fractals because that's a lot prettier but anyways when it comes to like continuous learning and continuous improvement i think i think that recursive nature of it uh it's sort of how it sort of bends back on itself as a notion and you want to continually be figuring out if your continuous learning is a good idea so to speak seems to be something that's uh extremely helpful for those organizations that that do want to improve well uh thanks for being on if people want to uh i don't know keep up with you on the internet or uh check out other things you have

what's what's a good thing for them to look up yeah i'm on uh twitter and linkedin and basically everywhere at the daily m em and um yeah that's really where you can find me i love talking product i love talking tech so reach out yeah yeah and there's there's at least two other talks of yours recorded one that i saw at the uh the lightning thing about how you should uh turn you should shouldn't feel bad about turning your hobbies into uh things you're interested in and sort of confessions of a serial hobbyist i think always always good to have a combination of uh therapy and advice about how to thrive self-therapy as it were and uh there's another good one i guess is a little old now but we're where i think you do a good job uh or in my opinion you do a good job of i don't know demystifying what an mvp is versus how do you characterize it like there's two words that begin with v v or something right i forget the one slide you have yeah so there's a kind of minimum viable product i i talked about a different concept of minimum viable release point so when's the first point that i can release yeah um also heard it referred to as minimum valuable product at that time uh it's had many iterations since 2015 in the industry but uh but yeah it's uh thoughts around how to get things out to customers in early stages when you already have a product in market yeah yeah no and and to your point of it uh evolving under many different names i think i think it's a uh it's it's it's a good alternative to make hopefully the only statement i ever get remembered for is don't do dumb stuff in the sense of like if if if you think that like agile or mvps means you're gonna like release some lame software no that's not what it means right like like obviously it doesn't mean doing dumb stuff uh but anyways it's it's it's a good overview of that was perhaps the largest uh screen i have ever seen a presentation put on that that must have been very intimidating to uh i i think that was a lot

of fun that's that that was the product management festival in zurich switzerland they still hold it at that same location so every year uh it's the the biggest screen ever that you'll present in front of yeah i think if you were to imagine like one of those little uh check boxes on a on an app or or a web page i think they were taller than you on on that screen this is massive uh well anyways as always thanks for listening this has been another Pivotal Conversations if you want to get the latest episodes and quickly browse all the fascinating back catalog including many conversations like this talking about pivotal cloud foundry and also uh conversations we have with actual uh users and managers and people who are not just uh us vendors trying to peddle stuff you can go to soundcloud.com slash Pivotal Conversations and usually about every thursday if i remember to do my work that you can go see the full show notes including links to things we've talked about here at pivotal.io slash blog and with that we'll see everyone next time bye bye

Tanzu Talk · 🍕 Get more pizza.