Agile strategy & roadmaps, with Joanna Beltowska (Ep. 77)

Episode 62 · 53:20 · SRT · archive.org · all Tanzu Talk

all right well we have this little internal newsletter that ostensibly is supposed to keep us informed on things which is nice i really like it because we have the the editor he's got such a nice smiling face you get to see his face every now and then steven there i always think like like the job of an airline newsletter an airline magazine editor must be nice it's fun right like you get to be in the back seat pocket it's kind of the equivalent of that anyways so i emailed you guest because uh you had one of the little featurettes in there that i thought was interesting aligned with a lot of stuff that comes up why don't you introduce yourself sure thanks so my name is joanna beltowska i'm based out of the new york office and what i do at labs is that i head up the product management practice and i wrote this thing about planning uh in in agile environments right and how that's uh often something that people have a misimpression around that these two things don't go together but i'm making the case that they indeed do um and they do so terrifically if you do it the right way yeah i i was i was just uh uh doing sort of a practice run of a talk i've been putting together about like uh what what's the deal with devops and enterprise architects um which i'm probably something you've encountered and and the uh in doing that uh you know and and also like looking over your stuff you kind of realize that the i don't know the early wizards of agile we're sort of like i don't ever want you to say the word planning again like like and and of course there's some inherent new way of doing it but the idea of uh having a long-term anything that uh might restrict you has never really been uh i don't know a very well-supported notion in doing agile oriented things which which you know tell me tell me if you experience this but like based on on the uh i don't know you might call it the world doesn't seem very helpful right like like i always figure i always figure it's like it's fine if what you're trying to do is try to figure out like what

color your hot dog and your augmented reality thing should be like you know you're just surviving quarter to quarter and trying to make sure facebook doesn't crush you uh which is a lot more reactive but i don't know if you're like selling insurance you probably have some long-term plans but um i mean what's been your experience of like working at someone who's uh at a in an organization that says like crazy agile is pivotal labs and then you're like hey i have the word strategy and vision on a slide that decomposes down to a backlog like how did you come to caring about road mapping yeah so i guess um there are two two things i i've i've heard the most often when it comes to planning one is um we need to have a plan where's the plan right uh all this agile stuff seems so uncertain and and we can't take it seriously because we're a serious business doing serious work and you need to have a plan for that so that's one side and that's often what we hear from our clients who come from these environments or plans are super important for a number of really good reasons um and that's often where they struggle the most um when it comes to adopting agile methodologies how how how how do we uh take this thing seriously when um no one can tell us when this feature is going to be ready for us when this app is going to be ready to launch yeah that's one side the other side is you know we are the agile team we um understand how important it is to have flexibility to be able to learn about and respond to change and we don't want to be bogged down by these plans that um you know truly these these contracts um forcing us to to deliver against a specific scope by a certain time by a certain budget right there's no flexibility in that so you have these two two sides that are are in true opposition with with one another yeah you know that second one well well to to as as i like to do to reword everything you just said to agree emphatically with you like i think uh you know the

first one is like oh we're enterprise we wear big boy pants so like don't bring your little short pants to us and like things like that which which is fine i mean that's a good reaction to change right like i remember uh i remember when i was i was i i use food analogies too much but i remember when i was aging becoming more mature it was like oh being a vegan that sounds terrible but i'll consider it right like like it's just this crazy idea you've never considered that is contrary to how you think that uh i don't know that you encounter and and then there you go right and then you're like tempeh how do you how do you actually cook tofu like they do in a restaurant so it tastes good this is a difficult challenge i don't think anyone challenges your entire world view exactly i don't think anyone's ever solved that in the home kitchen but whatever um but then the second thing i think as as um you know in the past few years and as as i was like reading over some of your stuff i think that's one of the more intriguing notions because it is i think i think i think implicit in that is this this idea this sort of like judoing of stuff of like well sometimes a long-term plan is a not only a barrier that you need to get over as an agile oriented team but often it's an actual deliverable like you actually have stakeholders and it should be treated i lose track of functional versus quality features versus like stick figures and all that stuff but like it's actually a requirement for you or a story it's a feature of that needs to be delivered on and so like if you think about it like that and then equally budget and planning and timing and everything that it's sort of not that big of a deal unless the deliverable purely becomes as as as you call it output instead of an outcome but um yeah it's a good it's a very comforting reframing of all of that that that you and other people are doing in it of like what what if we went back to the agile manifesto and we were like well we value long-term planning if that's the deliverable or whatever and yeah yeah yeah i guess i i don't know i i don't agree that that should be the deliverable right um and that is one of those mind shifts that can be so difficult for uh any organization to make

as they try to become more more agile right so yep uh if we just step away from that buzzword for a second what does that mean well it it means being able to to um learn about things as they change which they always do right um the environment in which most companies operate today is is changing so quickly um but it doesn't make sense to try to plan ahead for a very long time because those plans are going to change and so when you're putting too much emphasis on the plans that deliverable you're missing that bigger picture of you know who are we trying to serve here what are their needs uh what is our competition up to what new technologies are out there that we could leverage that is the really important stuff it's the focus should be on the results that you're trying to create the change that you're trying to make in the world um and not you know on on creating that perfect plan which is any which is going to be um irrelevant pretty quickly anyway right unless you keep updating it so that it actually matches uh the current state of the world and what you know about it today so uh you know it's always dangerous to speak outside of an industry uh i understand but i would assume in in other industries it's sort of like um long-term planning is sometimes good and sometimes bad but there would be situation the reason you would have long-term planning i would assume or that it's possible to be more bottoms up is you have sort of a standardized process of things that you're doing and you're looking to optimize it right like like we we build a widget let's safely hide it under an ambiguously named three-dimensional object but we build a widget and we don't really vary the widget very much and so we optimize the construction of it and to some extent never minding drones and the threat of amazon and stuff which kind of proves the the point that we'll get to like then we also have to get the widget from the factory to the person we're selling it to whose hands so we've got the logistics of doing it and we can optimize that like don't ever make left turns or whatever other fantasy of delivery you encounter right uh and and so you're optimizing these things and they stay static and i would imagine your long-term planning for like marketing and

sales that's a lot more agile because that changes all the time um but we in the software world we're always like uh slightly precocious about it and we're like well software is very different right like these rules don't apply and so you know i don't always hear this very much so i'm curious what your answer is but like and you alluding to it but how is software different like what is what is the nature of software that that thus that like an epiphany isn't just like don't make left turns and then do that for five years like what what's the nature of software that you you can you can not only worry about long-term planning you can get the benefits of short-term planning yeah well so that's um that's exactly it right i think you alluded to it it's it's the cost of change and speed of change right so um the planning models that most enterprises um have adopted and and are utilizing today are based on traditional manufacturing right so you had your factory you were building your physical things you had an assembly line right so you were you were building machines or cars or you were making it and packaging i don't know soup right physical things um which are by nature very very different from anything that's virtual like an ios app right so um when we work on a physical thing as soon as it goes down that assembly line as soon as it's in the distribution chain it's very difficult if not possible to make any changes to it right so um if there's anything that you miss to think about or account for before that assembly line gets started you are taking on potentially tremendous risk and tremendous cost and and uh brand damage and you might upset customers and all the people that you have to work with to to get your um physical goods out there and into customers hands but software is you know if if you set it up right if you put the right processes in place it's actually easy to change it's easy to distribute and that's that's the assumption that we make around planning that we

often don't realize to to to question right that uh virtual things are very different in terms of how they're distributed how they're changed the costs involved yeah so we can take very different types of risks when you build software exactly and that that's another like fun uh you know i i get i'm always leery of too many turns out sort of like malcolm gladwell types of revelations but it's sort of like it turns out this long-term planning was a constraint you had imposed on yourself right and and so if you look at the as you say like the agility of software you can remove that constraint and so it's not so much that like needing to have a gantt chart is the only way to live through life and these agile people are subversive it's just like that was a tool that you were forced to use because of all these problems because of all this risk yeah so there's no reason to saddle yourself with that when when you're dealing with as you say a uh a sort of virtual thing yeah and another important difference is that when you plan uh when you plan for for software virtual things um you you you want to optimize for learning you want to optimize for that change right you're assuming that change is inevitable it's going to happen so let's make the best of it let's let's you know try to let's accept it right it's going to be part of of our reality uh whereas that's that's not possible with physical things again because change is not always possible if it is it's extremely expensive um and time consuming and it can be really damaging to your company so when we work with physical things we plan for physical things we have to optimize for predictability and so we plan um in different ways right so physical things are often planned um in a phased way so someone initiates the the creation of the thing conceives of it um there's another phase of analysis of design of planning of building it of testing it of distributing it right so you have these very very long feedback loops and it's all about extracting uncertainty

out of the process so you know exactly what is going to go down that assembly line but um with software because we do need to have that flexibility we can't we can't plan around outputs right around the actual manifestation of the thing that we're going to push out um we do want to plan around outcomes in this case so the actual goals that we want the piece of software to to to accomplish the results that we want to create and the way in which we get to those things is much more malleable meaning the actual features while important are not as important as why we're building the thing and again because of that cost of change being lower uh the feedback loops being shorter in terms of building the thing and distributing it when it's a virtual thing um software lends itself much much better to planning around outcomes and goals um whereas physical goods don't and and so so what are what are like some uh you know a handful of examples of what these outcomes are to distinguish them between outputs yep so outcomes can be things like um making our customers happier uh by making it easier for them to complete some sort of task um it could be things like um increasing productivity reducing cost increasing revenue so these are results consequences they're not they're not stuff like number of features that you ship uh or the size of the scope that you that you ship right so it all depends on who you're building the application for and what problems you're trying to solve for them and in their life or what desires you're trying to to satisfy for them right not every app is going to be solving for some some deep human problem like you know an instagram that's that's more of a uh you know a fun thing right it's not a not necessarily life-changing

that's right um thing right um at least for you and me it sounds like maybe there's some people who uh have you come across this word called uh uh a planneded photo that that that's like it's it's a it's not i guess it's not a portman too but whatever you call that kind of word it's it's a it's a mixture of planned and candid and so it's the idea of like you're an instagram and you're like uh i think the associated thing is the uh husbands of instagram if you've ever seen that video where the husband always has to go way up on the catwalk to take a picture of out of a wide angle but uh i don't know anyhow uh yes i'm just putting in a joke there it's true the the hot dogs are only meaningful to a subset of people not the enterprises of the world so um uh since i interrupted you and broke up your train of thought i mean so like like like can you like like that well to be more direct there's there's there's one slide in some of your presentations or i've only seen one i guess so the one i've seen that i like which i kind of alluded to earlier which is the kind of four-part walk down from uh everyone's first favorite vision that's that's good stuff from uh vision to strategy to uh i actually forget what the third one is to backlog i guess it's planned or something yeah yeah the roadmap and so like yeah what is like like let's sort of take it for granted well i don't know maybe we shouldn't but like what are those four columns and and what i'm especially interested in is like how how something like increased customer satisfaction gets decomposed to for example uh we should have a reactive web page that as a user scrolls they don't have to click on a button to go to the next page like i don't know maybe that's a bad example but like how how is that process managed right like how like what's the the human interaction of like getting down to that point and realizing that you need to do that cool all right that's a lot of questions let's see if we can tackle them one at a time yeah you know i don't ask short questions uh yes that framework of vision strategy roadmap and backlog is is exactly

that it's it's it's a framework for um thinking about planning um and defining um products right or really it doesn't just have to be products it can be services right anything really that you do as a company as an organization as a team um to create value for for for some group of people let's say right so it is it is a widely applicable um framework so the vision is is the starting point it's it should be a short inspirational ambitious uh motivational statement about the change that you want to create in the world right it's it's it's the idea um that's going to drive all of your decisions ultimately as a company as a product team as an ic on a team inside of a company um it's it is that shared focus and it is that motivation for for everything that you're doing so that that's that's really important starting points without that you know you're not going to have um necessarily the right focus as an organization um and it's going to cost you in terms of um you know miscommunication um waste um just people running around doing different things yeah having ideas about what matters being unaligned and and and hopefully won't won't like break your uh your your train of thought here but like first of all like who who sets that like what you know there there's this there's this metaphor i've been trying to use which is like you know we've all well anyone who's listening this we've all read like uppercase l lean manufacturing and it's like toyota figured out how to optimize this but like i always want to know like who decided to make looms and then who decided to make cars like who sets that initial who's the prime mover of all of this stuff that you know the strategy and everything yeah i mean it's gonna depend right a lot of times it's the person who starts the company or the people who

start the company right they see an opportunity in the world um whether it's to to uh create something awesome that is gonna create a lot of benefits a lot of people or whether it's to um you know go out and make money there's those folks too right right so they come up with the idea of let's build a car let's build a loom um and hopefully that that does come with with some sense of purpose some sort of vision for for why this is going to be an amazing loom the best loom possible right uh and not just you know your run of the mill loom yeah no pun intended yeah you know i i i always think if there's some magical uh chart of starting a business the first question in the chart the decision tree is do you want to be in the check cashing business yep if yes easy money if no all right now the real questions begin uh but yeah no that i i think i mean that lines up with with uh the the helpful non-answer that you get is like i don't know you got to just decide on something right like someone someone has to figure out what it is you want to do or what you can do and if you're lucky you've already inherited what it is you're doing and your job is just to uh to optimize it so so then if you have that strong vision just just to to add a you know a couple more things that are really important if you don't have you have that vision that is what's going to motivate you through those long rolling nights of trying to start a new business right get something off of the ground it's going to help you find people that want to work with you and make this thing a real thing right so um it's it's it has all these other additional benefits it's you know it's people like to come together um around a shared goal around something that is going to create impact in the world and that is what the vision accomplish help can help you accomplish right and and then so the next step in your your magic slide is like the strategy step so what does that start to look like and who messes around with that and what's going on there so this is a master plan this is how

you're going to uh make your vision real so it's a high level plan um if your vision spans you know say five plus years decades your vision your strategy takes that down now to a couple of years months or maybe even a few months depending right so um it might actually be good to share an example here so one of my favorite examples is tesla so tesla is a car company right but it's actually not so you know their their vision is not to to build uh necessarily the world's most amazing car their vision is to um help make energy sustainable right to to create sustainable energy sources in the world that's a vision and the car that they're building is a means of getting there so um elon musk actually does have this thing that he calls his master plan which is create a low volume car which is going to be expensive then use that money that we make off of selling that expensive car to develop a medium volume car at a lower price use that money to create a more affordable high volume car and then ultimately provide solar power power by developing these amazing batteries that these cars run off of yeah no that that's that's i'm always suspicious of like you know tech companies like uh that their walk down from that but that's a good one because usually ends up being the old mythical pants gnome thing but that one has a good a good progression of uh you've got this kind of somewhat audacious goal i mean sort of like practically audacious if you will and uh yeah that seems like a good bet of how you would practically in big gigantic picture ways get to that point right like yep like if you work backwards from there what are the how do we fuel this how do we fund it and then also what are the innovations that will be required to get to that point and then how can we mix those together so yeah no that that that makes sense and and i guess you can kind of imagine out in more uh uh pedestrian examples of like retailing and and maybe like even even when you know for whatever reason i use this example too much even

like various types of insurance you could figure out similar strategies of how to get to some point right like maybe in the insurance business i mean this would sound crazy for insurance people but it's sort of like what if i just wanted to buy insurance for 10 minutes like maybe there's a way to work back to how you would get to that point of like this spot insurance stuff which um i don't know that would seem to like make actuaries heads blow up if you mess with like a annual or a longer term for for the gamble of insurance but there must be some way of getting there yeah and it would make you stand out right and you'll be able to build a business around that so so then so then you get to well first of all so so vision you know you can represent that uh you know verbally or in a really a really wordy plaque on a wall somewhere right like so that that's fine but like how do you how do you both see in in good ways and maybe bad ways how do you see and sort of recommend people like uh document their strategy like what uh do they need one of these six page bezosian memos with 20 pages of appendix to it or like is it good in a powerpoint or like how do you how do you set that down in stone so to speak yeah i would say you know try to keep it try to keep it simple because it's not if it's not simple people are not going to get it and people are not going to care and people are not going to know that it exists right so these things do typically live in these very very long powerpoints um that not everyone has access to but just write it up on a wall keep it close to a team right um when you have town halls and and get together to talk about what different teams are up to and where the company's headed share those vision statements and strategies out and just keep them really simple and short right a vision statement shouldn't be more than two or three sentences long um a strategy statement can just be a list of bullet points yes it can also be you know a very long document a lot of detail and analysis and that context is sometimes uh necessary um but

yeah i guess i would say try to try to at least get to one version of these things that is so simple and easy to understand that anyone can access it and get it and internalize it and understand why these things matter right and feel inspired by them right like your tesla one's a good example of that right and and and so like also also at the strategy stage and and i have like way too much interest in this because for a couple years i worked in the corporate strategy group and stuff so uh there were many overly educated uh overly driven people who had theories about how you do strategy in the same way that a bunch of developers will like uh entertain themselves in off time discussing like different ways to do pagination like all the mbas will talk about how you determine strategy which is can be fun maybe anyways uh so so so like how i don't know how long do you think that phase takes and like what do you do do you just like call up bain and or i guess maybe labs and have them come in and use their summer interns to pump out like a 30 page document with the one pager for you or like what what are you seeing people are doing when they're figuring out that strategy or or to ask it another way what are they doing that's helpful downstream when it comes to making software around it yeah i mean i would say um these things need to be tested and validated um they aren't always right sometimes if you take the traditional approach you're gonna call up your favorite consultancy they're gonna spend months and months working on this thing wordsmithing it um and then hand it over to you i don't know if that it really is is the best way to spend your time and money right um you can come up with something that is much more um scrappy in a couple of days for a couple of weeks by talking to people by watching them interact with the world around them uh by seeing what else is out there and

formulating a hypothesis about what the opportunity is to create something better whether it's you know a car or um a battery or or whatever else it might be um you know and put together some some simple essentially prototype of that write down your vision statement on a piece of paper and put it in front of people and see how they respond to it um same thing with with a strategy right identify your master plan um and try to start to implement it and see how it goes um i think you can make much more progress that way um in many cases than spending tons and tons of money and time um coming up with these things that feel incredibly robust and sound and look beautiful but haven't actually been tested um in a real sense yeah yeah yeah what one of the um back when i was doing strategy one of the uh what would you call him more firebrand and thus more unemployable persons that uh i worked with like he he was uh this was this was like at the apex of lean startup stuff and uh every single presentation he did it was just a reason to get to a slide that talked about lean startup stuff but but it does it does get to the point that you're saying is to to tell me if this seems right to summarize like your strategy should be testable and and by testable we also mean that if the test comes up negative that doesn't mean that you don't make your bonus that means that you go back and you get the chance to get it right and reformulate it again right and and so that would be a good smell if you will for the people who are overseeing strategy generation is like well how would i test this and then we don't need to know exactly what we would do next but like if it's successful then what and if the test isn't successful then what do we do and like yeah like i don't want to spend three months figuring out you know monte carloing out all the different simulations but like let's maybe spend a few hours on it just to like just like think out what the testable things are in it yep and this this goes back to

something that we talked about earlier on earlier on in our conversation about predictability versus learning right um if you come up with a with a master plan and you start to test it and it's not working out that's not failure that's learning right it means that you have learned sooner and later that this thing is not working out this was not the right idea so let's try something different and it's not something that you should be punished for it's something that you should be rewarded for if anything right all right so we got this we got this good testable strategy we've all uh we've got we've been reading our lean startup book so much that the spines cracked and we're missing a few pages we set some coffee on it or kombucha or whatever and uh and then we're gonna make kind of like the uh i i think the crown jewel of the sort of theory you've you've worked on in this body of work the the roadmap right yes so what is this roadmap so now we're getting down to the actual timeline and tactics of how we're going to make our plan real right so um one one way that i try to explain this um in in the slides that you refer to is through this visualization of um you know imagine that you're standing in front of a mountain and your vision is to get beyond that mountain is to reach something that is at the other end of that mountain so how you intend to get over the mountain is your strategy you could climb it you could dig a hole under it you could walk around it you could drill a hole through it but that's your strategy that's the plan for how do you intend to to get across that mountain um and everything um what the mountain represents is everything that's in between all the barriers that are in your way so when we think about the roadmap it's the actual map that you're holding in your hands as you're standing at the foot of that mountain and you're looking up it and you're trying to to get a sense of what would it mean to to begin to climb this thing what do i have to pack we have to bring with me how many people are going to need to have with me what sort of skills and experiences do these people need how much food should we pack how should we get dressed

for for this expedition so all that stuff is going to go into your roadmap and you're going to have a pretty good sense of what you need to do immediately because you've done a lot of research you have pretty good visibility into that initial phase of your journey but then after that things get a little bit more fuzzy right so again looking up the mountain you might see that there's a peak coming up but it's covered by clouds so you can make some guesses about what um the the the landscape is going to be like at that point of your journey but you still have to do a lot more research and you're just not going to know until you get closer to it so you have some initial ideas but you know that you can't create a good plan for for dealing with that part of your journey quite yet and then beyond that first peak you just have no visibility at all so you don't know what's coming up again you can make some initial guesses some high level guesses but you don't know exactly you need to do much more research and so um the idea behind an outcome oriented roadmap is the same we have a lot of visibility into the first leg of our work and after that things get fuzzier and fuzzier and we're not going to try to plan um too far into the future because things are going to change we're going to learn about new things the landscape is going to change so we're just going to plan as much as we have to um for now so so in the in the in the roadmap thing you're you're you're paying a lot of attention to uh what's going to be happening like week to week i guess sort of like challenges that you might encounter problems you're going to need to solve constraints that you'll have and as you say like coming up with tactics that that you would do i and and and i guess not only to like solve those problems but to like keep moving forward as it were right like what what how are we going to set things up so that we don't end up dead in the water like what are we what are we going to do so you know we we get lost in and i think in the software world down a hole of metaphors because our trade is like so new that we can't whatever the opposite of a metaphor literals like we can't speak literally about

stuff very much but like it's sort of like if you're going to be on a old sailing ship thing your roadmap kind of might be like well we're probably going to have to spend two weeks going nowhere so we should bring some food right like like like we're going to need some plans and tactics to deal with the bumps and the stuff that we have and and you know what exactly we cook on day eight of being dead in the water we'll leave that up to the backlog but but as far as like knowing that we need to be ready and have a process for that like we need to roadmap this up to match our strategy of like i guess this is all like sometimes historically morally bankrupt but our strategy of expanding our empire so we can get more cheap resources to like fuel uh you know our 13 course edwardian meal but like you know and then then our vision of just living the life for the uh for the king but anyways it kind of maps all the way down to like one day the uh the gaunt chef is like cooking up some some fish in the galley there i guess but no no that makes it and then so i'm um i'm curious uh to try to retrieve myself from weird historic analogies uh like so what are some examples of what these roadmaps not only look like but like folks you've worked with like what are the roadmaps end up being like what are they oh you mean like what's the manifestation of the roadmap yeah like example examples of them um so i'm not sure if this is what you're looking for but typically the shapes that they take are stickies on a wall they can be a trello board they can be an excel sheet they can be a google doc they can be a powerpoint um and then there's tons and tons of different um apps out there that just help you put together a roadmap so just web apps that you sign into and you build a roadmap and then you can share with other people so that's what these things often end up looking like um then in terms of what you stick into them um there's a number of different ways of doing this um but i would say the most important components to account for are your time horizons so

so what i was alluding to when i was talking about standing at the bottom of the mountain and looking at your roadmap or your actual piece of paper that helps you navigate this this this mountain um you want to split it up into different chunks of time so that can be um what we're going to do right now what we're going to do next what we're going to do in the future and you can assign to each of those time horizons you know a month a quarter i would say probably not longer than a quarter because you do need to have um decently short feedback loops to to um account for those changes that are going to happen right so you've got your time horizons um those are going to be your uh columns just to help folks visualize what this might look like and then um looking at the rows going down you want to have your desired outcomes or your goals right so um this is the equivalent of identifying milestones essentially how far up the mountain do you want to go during uh you know this first quarter or you know this first leg of our journey so you've got your you've got your goals your desired outcomes the results that you want to get to then you've got your barriers or problems to solve so why is this desired outcome that we're trying to get to not real yet what what do we have to work through to make it a real thing after that comes metrics super important because you need to close that feedback loop right how do we know that we've actually realized our goal how do we know that we are where we want to be and where we need to be you need some sort of um metric to to track your progress against that and then after that you've got your actual tactics so these are your features and your scope the actual stuff that you're going to do and the stuff that you're going to build and i would say those are the most important pieces and you can also expand your roadmap with other things that might be important to to your organization things like um which customer are we

focused on now which persona are we focused on right now um what critical assumptions we have to test right what what do we still have to learn before uh we can assume all this other stuff in our current column to be um doing things that we have confidence in that we can act on yeah yeah yeah i mean that's that's sort of uh marveled with more of the uh the testability tactic which which which i think and and and and as with so much of this stuff right like like it also gives a um a more comforting bent to metrics right like kpis and metrics are always not very friendly from an individual standpoint but but it's almost like if you think of metrics as as the way that you're testing something and validating that something's happening and figuring out how well or poorly i mean the poorly parts the problem but you know figure out how things are going like it does it does make it more interesting also from the standpoint of just like producing this stuff of like you're uh you're architecting out a model like almost this uh sort of organism of like your ongoing work and like i don't know that's a lot more exciting than like a meko chart or something right like so so much so much like strategy stuff that i encounter and and you know planning and things like that um and i'm sure it's not all like this but it almost has this like uh boring sort of like uh this this boring arrogance which is sort of like if we do this profits will rise end of story yeah right it's it's not like it's not like the it's not like the question mark of the pants gnomes of like and so like how are we going to make sure this all works out well but so it seems a lot more entertaining yep yep yeah and you've got all these things together working as a system right they have to align with one another and they all help you um they all help you see how things are going anything to change anything right so it takes a lot of the guesswork out of building good products

and solving real problems for real people hopefully so so then so then tactically one area i think that uh you know you have a paper on is or a little write-up whatever you want to call it uh is um is basically like so how do you run the the whiteboarding sessions where you kind of come up with this stuff and and like what what's always interesting about that is like i mean we've all actually you know we've all read uh the lean startup thing or like the five dysfunctions of teams and then we have a nice weekend and we go back to work and you're sort of in the room and you're like holy crap i actually have no idea what i should do right and and so like so like stuff like this is like good because it's tactically like all right you're in the room everyone's talked about what they did on the weekend they've got fresh coffee here's a marker go right so like like what uh how do you kind of bootstrap into that and what do you do in these sessions where you're trying to get to those swim lanes of things that you're going to be doing yep so it's probably going to be really hard and how it how it actually might happen is going to depend a lot on on your company right because as we again as we talked about before different people different layers of the organization might own these different pieces of that framework right the vision the strategy the roadmap and the backlog it's not always the product team owning all these things so um i would say a good starting point is get your team all together in a room and you want to make sure that you have people representing products that's your product manager product owner whatever that role is in your organization you also want to have people representing um the um the customer and the product design sometimes that can be the product manager product owner sometimes that is a product designer or your ux researcher and then you also need to have um engineering in the room right because these people together um tasked with making sure that the product is something that people want something that we can build and maintain and it's something that is going to help us um have a viable business

around the product so those perspectives are all important and they have to come together to to inform the roadmap so you want to have those people in the room at a minimum and then you start by trying to articulate what the vision is and so what is this thing why should anyone care how is it helping our customers um solve whatever pain point that you might have how is it helping our company uh be more successful so you want to capture that then you want to capture your strategy again um it's about identifying that master plan and just going a little bit deeper into what that means it's about making a lot of different choices you want to think about who is our customer here right who do we want to potentially start with right we might have several people that want to serve through this product but maybe not at the same time are there specific markets that we care about whether it's a geography or a vertical um how do we think about pricing um what is going to make us different why should anyone pay attention to this thing that we want to create why would they pay for it and use it so you're trying to make all these choices about um how you're going to navigate the world um assuming that the team owns these pieces you know you're you're pretty much done with them and you want to go out and start testing them and implementing them and see see um how how they do when they meet uh when they contact with the real world um if these are things that are owned by someone else in the organization say a chief product officer or um someone at the director level you want to take them back to that person and just make sure that you've understood them correctly now you need to get that validation at least internally um in case someone else owns these pieces and is thinking about them and and so so yeah it's and and and just to like kind of uh bullet point it out it seems like uh like you know so you got you got this matrix well maybe we'll find a uh a version we can

put in the show notes but you've got like your the outcomes that you want and then as you're saying the metrics that you're going to use to measure it by and then and then essentially like the features the thing right and i and i think i think i think you know in the document i've been looking at like retail on e-commerce as we used to call it is always a good example because yeah everyone's a user of e-commerce so you can understand it and you know there's there's the typical i guess there's there's a couple things at least represented in the example you have right there's uh uh are in order to well ultimately i don't know if this is vision or strategy but it's like we would like people to give us more money in exchange for things that are they're buying for it from us right like that would be cool right yeah yeah i mean i guess you could have optimization things like profit of like we would we would like to uh we need to have robots who pack things because then we can eliminate the cost of humans so but anyways let's put that aside uh the internal operation stuff but like you know you could say so like uh we have a we think that if people like saw more reviews of stuff and got more material on our site they would buy stuff from us so like let's have videos and reviews or whatever so there's like that category of like you could almost call it like uh juicing the the retail experience of deciding to buy something and then there's the other one the other annual favorite is you know too many abandoned shopping carts whether that's like opportunities or whatever and and i think you know in in the in the um the process that you have like it makes a lot of sense that you would these are the things we want to get to and so like like how would we measure that and how would we do that and and like it seems like the other thing about lean like the way you're going over it that i think is a lot different than how most organizations go about this is like to put it in snarky terms like it's probably a good idea to have the people who are going to be implementing this in the room too to tell you if you're if you're full of crap or not right so that is the product team right that i mentioned that's the pm or po the engineers designers um and if we just talk about this specific piece and a specific example with the desired outcomes and

what we're actually going to build to make those things real um that collaboration um that might be a collaboration with some leadership in your organization right where they say our business goals this year are to increase revenue right to to um you know decrease whatever it is uh important metric that used to be decreased and then it's up it should be up to the product team to say okay let us go and do some research and try to understand what's going on here um how might we sell more right um is it that people are abandoning their carts too much is it that they can't find the checkout button is it that our product photos are so crappy that no one feels compelled to buy our stuff right um and once the product team has identified what is going on what's what are the potential problems here um they should be the ones who come up with the solutions and test the solutions yeah yeah no i mean and there's also like to use like a nasim talabian thing right it's sort of like you want as many people of those to have skin in the game right to to yes to benefit and not that we pivotal people would like this but to benefit and suffer to have all the great human motivations to make sure they're doing things well versus the kind of throw it over the wall long-term planning that you would see where someone's just like we should enter latvia as a market see you later right and and not really have the uh the consequences of if that was a good idea that thus drives doing all of the work needed to uh ongoing make sure it's panning out absolutely and when you empower your product team to do that work um you're going to move faster because you have these people you have you know at the very least um the designers but also typically the product managers often also the engineers talking to the actual end users and customers right so you have those conversations happening much more often at a much bigger volume than if you um have you know really senior people

in your company dictating what the features should be right so you have much shorter feedback loops between the people building the product and the people that the product is intended for and you also have um so you're going to have many more data points you're going to have many more conversations many more observations of these people that you're building for which means they're going to understand them better you're going to empathize with their problems much better and you're going to come up with much better solutions yeah well well before we wrap up is there any uh vital thing we're leaving out i mean we left out the whole backlog thing but that's probably a whole other discussion but but like in in getting to that point uh you know from everything we've talked about where you actually do have a backlog and you're like all right let's open up the crazy you know roboto slab green on black screen and start coding this thing right like is there anything like we that that we're missing i think so one of the things that i uh feel the most passionate about in terms of shifting the way that we plan from outputs to to outcomes right or from having these long feature lists that someone has come up with to to actually empowering the team to solve their problems and come up with their own solutions is the idea of employee happiness right so i think anyone who works in software is really motivated by having an impact and when you're given a thing to build with very little context without understanding the big picture that's not super exciting it's not super motivating it's not super engaging you sort of just churn out these features but you don't really know to what end right um and if you actually share that context with teams if you get if you if you allow um engineers even to think about who is the user what how can we how can we do something for them that makes them happy or makes their life easier you're gonna get so much more out of out of your people uh you're gonna build much better products and you're gonna have much more motivated teams right people who stay with you

longer who do better work um and who much who are much happier yeah i think that's that's something that um a lot of companies sometimes forget about um that you have all this pent-up creativity um in your people uh that you can let loose if you just give them a little bit more trust and empower them a little bit more yeah this is another one of those areas of like uh corporate mysticism that i that i think recently is being demystified and and i mean just that in in in the sense of it's sort of like uh without without as you as you went through the supporting facts for it sort of like you should have your people be happy it's sort of like yes and i i should also eat a low calorie diet right like i mean also all sorts of things i can shit all over the place and see what happens but like uh it is like like trying to be empathetic towards the uh or you know you know hack hack something out with sort of an empathetic sort of thing with the senior managers it's like well even the most devilish of y'all is motivated by money right and so your happiness is derived by increasing the share price and so that's what motivates you right like and if you weren't motivated by that you kind of intuitively know that you would do a crappy job right so that's that's what you're motivated by so think about like your staff all the way down the chain like they need some motivation to be happy and do what they want or you get like a new me plant situation right and so like yep you should figure out like like and it couples with another thing that i think uh i don't know us wacky agile people are kind of always going on about is like uh you know humans are pretty expensive valuable resources and you probably manage your paperclip supply more closely than you manage your humans so like maybe you should think about how you're managing and optimizing the humans because there's much they're much more confusing and difficult things to manage than paperclips but like the rewards and the risks are a lot huger than just like making sure you're optimizing the amount of paper that you have in your printers and in the building yeah and and a lot of times big organizations

um manage your people closer but not necessarily better than they manage their paperclips right right because they have a lot of oversight yeah you have all these management chains uh you have like you'll have a line manager just that is sitting and sort of watching you over your shoulder right um and that is not the best way to go about it yeah yeah well great well thanks for coming on this this is good it's uh it's good to you know normally we cover just sort of like the straight up like more locky and infrastructure software stuff but it's good every now and then to resurface and see what the eloys are up to in in the uh the more the top of the stack so that's that's helpful and like i was saying at the beginning like uh yeah i think i think i think at least you know not only in my work at pivotal but my ongoing sort of like figuring out how to do software better like uh this is the thing that hasn't really been figured out is like so then if we go back up to whatever it is those business strategy people do that seems to always become a buzzsaw that we get severely cut on like like it kind of it's limiting our ability to like make the world better with software uh because people as as you were talking about at the earlier people just like they sort of like brain fart on it it doesn't really make sense for them so and it doesn't have to be that way yeah yeah yeah no it turns out i mean this is a little bit of whichever bias this is but like you can engineer this like you can engineer anything else yep yeah yep which uh it would be fun to like figure out one day things you can't engineer but i don't know maybe there isn't anything you can't engineer so if people want to uh i don't know follow up with you like online or whatever you got a you got a twitter account or uh anything you want to throw out there i do uh i am on the twitter uh my handle is j biltauska all right well i'll put that in the show notes uh you know you can probably search around for it and find it but uh but thanks again and with that this has been another episode of Pivotal Conversations if you want to get the most recent episodes the most quickly with the fancy little flash player and everything and see past ones and things like that you can go to soundcloud.com slash pivotal conversations and unlike this week when i've been too busy usually every thursday we formally post

some show notes over at pivotal.io slash podcast and with that we'll see everyone next time bye Bye-bye.

Tanzu Talk · 🍕 Get more pizza.