Jeff Gothelf: Outcome-Based Product Planning — Hands-on Agile 43

Summary

Highlights

• Jeff Gothelf highlights the key difference between outputs and outcomes in product planning. 📊
• Adopting an outcome-focused strategy requires rethinking success metrics beyond traditional timelines and deliverables. 🕒🔄
• Gothelf shares personal anecdotes reflecting on shifting strategy in response to market changes and crises. 📈📉
• He emphasizes the role of customer feedback in aligning product strategies with real human behaviors. 🗣️👌
• Highlights the importance of agility and the ability to pivot from rigid plans in response to unexpected changes. 🚀🌍

Key Takeaways

• Shift focus from output to outcome by asking, 'What will people be doing differently if we succeed?' 🤔
• Embrace customer-centric planning by understanding user problems and solving them effectively! 🕵️‍♂️
• Continuous product planning is crucial in today’s fast-paced tech-driven world. 🏃‍♀️💨
• Engage in frequent check-ins and use data to adapt plans for future success. 🔄📈
• Outcome-based planning requires organizations to invest in product discovery and agile practices. 🚀

Overview

Chapters

• 00:00 - 00:30: Introduction and Welcome The Introduction and Welcome chapter kicks off the 43rd Hands-On Agile Meetup. It features an enthusiastic welcome to attendees and introduces Jeff Godhealth, a renowned author and speaker who co-authored 'Lean UX' and 'Sense and Respond.' His recent work 'Forever Employable' is also mentioned. The chapter sets a warm and engaging tone, inviting participants to look forward to the insights Jeff will share.
• 00:30 - 01:30: Topic Introduction: Outcome-Based Product Planning The chapter discusses the concept of outcome-based product planning. Jeff thanks Stefan for the introduction and begins by stating that outcome-based product planning is an interesting yet challenging topic for many organizations. This planning approach focuses on managing outcomes which can be difficult for organizations to implement effectively.
• 01:30 - 03:00: Focus on Outcomes vs Outputs This chapter discusses the distinction between focusing on outcomes versus outputs in project management and product development. The conversation aims to explore how to effectively plan work when the objective is to achieve outcomes rather than merely delivering outputs. It introduces the concept of OKRs (Objectives and Key Results) as part of this discussion. The chapter begins by posing a fundamental question about what makes people love certain products, such as their phones, Netflix, or Amazon, to set the stage for understanding the value and impact of focusing on outcomes.
• 03:00 - 04:30: Continuous Product Planning This chapter explores the true reasons why customers love a product. It emphasizes that consumers don't usually appreciate products just because they were delivered on time or within budget. Instead, the love for a product stems from its ability to meet a specific need or solve a particular problem for the user. These insights challenge the traditional metrics of product success, suggesting that meeting deadlines and budgets isn't as important as fulfilling the customer's needs effectively.
• 04:30 - 08:00: Challenges of Linear Product Planning This chapter discusses the importance of redefining how success is measured for products and services. It emphasizes that success should align with the way consumers define it, which in turn affects how work is planned and communicated. The chapter addresses the need to shift perspectives in product planning for better alignment with consumer expectations.
• 08:00 - 12:00: Example Story: 2008 Financial Crisis This chapter discusses the shift from linear product planning to continuous product planning, particularly in the context of the 2008 financial crisis. Linear product planning is suitable when the end state is certain and risks are low. However, in situations of high uncertainty, continuous planning becomes necessary.
• 12:00 - 13:00: Moving Beyond Rigid Product Planning The chapter discusses the concept of product planning, highlighting that in scenarios where the use of a product is well-defined and predictable, planning can be linear with minimal risk. However, it contrasts this with the outdated notion of applying the same approach to digital products, emphasizing that such a rigid method was only viable in the early days when software was distributed in physical boxes.
• 13:00 - 18:00: Steps for Outcome-Based Product Planning The chapter delves into the evolution of product planning, contrasting past linear methods with modern approaches. Historically, software planning was often linear because there was a definitive end point: when the software had to be printed on CDs and distributed physically. This method was suitable for a time when consumers purchased software in physical boxes. The narrative acknowledges the seeming absurdity of this method today, highlighting how planning has transitioned from these rigid constraints to more flexible, outcome-based approaches.
• 18:00 - 21:00: Challenges and Responsibilities in Outcome-Based Planning The chapter discusses the certainty and clarity provided by using a roadmap in planning. It highlights that roadmaps are particularly effective and metaphorically suitable in low-risk, high-certainty situations, allowing for a linear communication of plans, marking a start and end point along the course.
• 21:00 - 23:00: Cross-Functional Teams and Stakeholders The chapter discusses the evolution in software development from a static to a continuous world driven by technology. It highlights the limitations of the traditional approach, which relied on fixed timelines and outcomes, in contrast to the dynamic and ever-changing landscape we now navigate. With software now integral to everything we do, the chapter emphasizes the need for adaptability and fluidity to succeed in this technology-driven environment.
• 23:00 - 25:00: Scalability and Multiple Development Teams The chapter discusses the concept of continuous software updates in modern technology environments. In contrast to the past when software was purchased as a boxed product, today's software is updated continuously and automatically over the internet. This transition has accelerated the pace at which software improvements and updates occur, thereby enhancing the speed and efficiency of modern systems. The example of Amazon is highlighted, noting its capability to ship code to production rapidly, illustrating the advanced state of software update automation. This scenario underscores the importance of scalability and the ability of multiple development teams to handle continuous integration and deployment processes effectively.
• 25:00 - 29:00: Senior Leadership Buy-In In the chapter titled 'Senior Leadership Buy-In,' the discussion revolves around the modern capabilities of software delivery systems, exemplified by Amazon's ability to implement system changes rapidly. This represents a shift from traditional, linear product planning, where software delivery was a significant, infrequent milestone, often occurring after prolonged periods of development. The chapter emphasizes that in today's world, the delivery of software should be a seamless, ongoing process, marking a transition away from viewing these deliveries as major events. The focus is on understanding and adapting to the pace and expectations set by leaders in technology and business to stay competitive.
• 29:00 - 47:00: Q&A Session The chapter titled 'Q&A Session' discusses the evolution of software delivery. In the past, releasing software was a significant achievement often celebrated with parties and project-specific t-shirts. However, with technological advancements, the frequency of code deployment has increased to minutes or even seconds, making software delivery a routine, non-celebratory event. This shift has led to a more complex understanding of success and planning in the software industry.
• 47:00 - 47:30: Closing Remarks The 'Closing Remarks' chapter discusses the fast-paced delivery of code in today's technologically advanced world. It highlights the challenges that arise due to the increased accessibility of technology, leading to a larger and more diverse user base. This diversity introduces complex and unpredictable human behavior, affecting how products and services are experienced.

Jeff Gothelf: Outcome-Based Product Planning — Hands-on Agile 43 Transcription

• 00:00 - 00:30 [Music] welcome everyone to these 43rd hands on agile meetup and today it's my great pleasure to welcome jeff godhealth to the meetup and i'm really looking forward to that jeff is very well known author and speaker and you probably know him from co-authoring the lean ux book and sentence respond and his recent book forever employable
• 00:30 - 01:00 so jeff would you like to take over the stage is yours sure thank you hey folks thanks stefan um it's a it's a pleasure to be here nice to see everybody thanks for joining stefan mentzen the topic today is outcome-based product planning which is a really interesting topic because it's a difficult topic it is something that keeps organizations from managing the outcomes because
• 01:00 - 01:30 managing output's a lot easier and we're going to talk about why that is in just a second okay so that's the focus of the conversation today how to plan work when you're managing to outcomes and we'll talk a little bit about output versus outcome we're going to talk a little bit about okrs but let's start off with this question here right what do people love about the products that they love right what is it that when someone says i love my phone or i love netflix or i love you know amazon whatever service they or product they love i'll tell you what
• 01:30 - 02:00 they never say right what they never say is uh i love netflix because it was delivered on time right right i love my iphone because it was delivered on budget right oh that amazon feature shipped on the date that they told me it would ship that's not why i love it right people never say that's why they love it people love their products because it meets a need or it solves a specific problem for them right and what's interesting is
• 02:00 - 02:30 that this is the way that the people that we serve the people who consume the products and services that we create this is the way that they define success in addition this is the way that we should be defining success with our products in services and if we start to reframe how we measure success then it changes how we plan our work and it changes how we communicate about our work and about the work that we're going to do now the
• 02:30 - 03:00 interesting thing is that we have to start to take a look at a shift from linear product planning to continuous product planning now there was a time or you know or there is a time let's be honest where linear product planning makes sense right when we know exactly what the end state is going to be when there is a high level of certainty and a low level of risk we know exactly what it's supposed to look like we know everything that's going to
• 03:00 - 03:30 go into the product we know exactly how it's going to be used and in those situations we can plan the work linearly because there is very little variability or risk in the final product in the thing that we actually make and there was a time where this also made sense for digital products and services for software now that time was a long time ago it was when software came in a box
• 03:30 - 04:00 and uh i was perhaps fortunate perhaps not fortunate to be working during that time and we planned software linearly back then because software had a definitive end because at some point we had to go and print millions of copies of cds and put them in boxes and get them out to the store so you could go to the store and buy a box of software which sounds ridiculous today and in those situations where there is a clear and definitive end to the project where
• 04:00 - 04:30 there is a certainty about what we're going to ship and when we're going to ship it and what it's going to look like when it's done we use the planning tool called the roadmap and the roadmap is a great metaphor for linear product planning right in in low risk high certainty situations it's easy to communicate our plans in a linear fashion and a map is a great metaphor for that we're going to start at point a we're going to end the point b and the
• 04:30 - 05:00 amount of time and distance between those two points and it's going to take us this much time to traverse that distance and that's when we'll arrive at point b and have the desired result and that particularly when it comes to technology products and software products that made sense in a static software world but today we don't live in a static software world we live and work and consume in a continuous world we live in a world that's driven by software technology drives everything and the software that
• 05:00 - 05:30 drives everything is continuous it updates continuously nobody goes to the store and buys a box of software anymore the software is just simply updates on our devices it updates online you know we send updates to enterprise systems and our ability to update these systems and to continuously improve them is getting faster and faster and faster and faster in fact just to kind of put a fine fine line on it today amazon ships code to production once every
• 05:30 - 06:00 second once a second some amazon customer in the world experiences a change in the system and that might be the extreme end of things but that's what's possible today and in that world the delivery of software becomes a non-event right so if you think about linear product planning the delivery of the software was an event it was a big event in fact because we've been working on this thing for six months or 12 months or 24 months
• 06:00 - 06:30 or whatever it was and we shipped it and the fact that we shipped it was a big deal we had a party every time we got a t-shirt with the name of the project on the t-shirt i had tens of these t-shirts back in the day but today if you can get code out into production once every second once every minute every hour every day every week then the delivery of software becomes a non-event it's not a measure of success anymore now that starts to complicate how we define success and how we plan our work
• 06:30 - 07:00 when we can deliver code that fast but it gets even more challenging because today there are so many more people who have access to technology there are so many more people who use our products and services and have experience with it and diversity of the humans who use our products and services drives complex behavior human behavior is complex it is also highly unpredictable and in many cases
• 07:00 - 07:30 behavior emerges from the use of our system so even if we believe that we know what people will do and even if they do those things initially over time people start to use our systems to do things that we never expected and we've seen that in a variety of different situations including social media where initially social media was just used to connect people to find dates perhaps to keep track of what family and friends
• 07:30 - 08:00 are doing from far away and then these days you know social media can also be used perhaps the emergent behavior there has been a little negative to subvert elections and spread misinformation nobody really expected that initially right people do things that we don't expect and that starts to complicate our planning process as well now the other thing too with product planning is that we can make a plan but because the world is continuous and because the pace of change is so rapid because so much stuff can take place
• 08:00 - 08:30 between the time that we confirm the plan and the time that we ship the product it doesn't mean that the thing that we planned still makes sense when we actually ship it right we planned for it and by the time we got out to market well the market moved on and the thing doesn't make sense or it doesn't work as we hoped or people don't do the thing that we expected them to do because maybe some new competition came to light in the market or some new
• 08:30 - 09:00 behavior or consumption pattern emerged while we were developing and so what's interesting about this is that when we plan work in a linear fashion we create these rigid plants and rigidity right the rigid nature of linear product road mapping is the enemy of agility if we want to be very very explicit about it um they're a lie we're lying to ourselves we're lying to our bosses we're lying to our consumers if we think we can predict what we're going to be working on in six months nine months or
• 09:00 - 09:30 let alone a year and the interesting thing about this is that we set expectations with these linear roadmaps about dates about features about roi right here's how much money we're going to make off of this thing and then we're on the hook for it which is super risky for us just as practitioners as people who'd like to keep stay employed right what if something new emerges what if there's a new competitive threat what if there is human behavior changes a consumption pattern a disruptive product or if
• 09:30 - 10:00 there's a pandemic right what are we going to do how are we going to adjust this thing that we've committed to right it's on paper we've negotiated it we fought for it and there it is right i'll tell you a quick story that sort of illustrates this in 2008 which feels like a thousand years ago now but in 2008 i took a new job in october of 2008 i was back in new york and i became the director of user experience at a company called the latter's which was a high-growth startup a job board for people who made a hundred thousand dollars or more
• 10:00 - 10:30 now i took that job at the beginning of october 2008 we had a nine-month roadmap and a clear plan a linear roadmap of what we're going to build the roi of that exactly what we're going to do and i was starting to not only build my team but to help the organization execute that roadmap now if you remember that far back a thousand years ago in 2008 particularly october 2008 that was a bad month for the economy particularly initially the u.s economy and then lucky for everybody else it spread globally but three weeks after i started my job
• 10:30 - 11:00 in new york city lehman brothers melted down the brokerage house collapsed and the financial crisis of 2008 began this is three weeks after i started my new job now remember we were in the business of matching high earners with employers right so executive job search with people and for that system to work well it's it's like a dating system it's a two-sided marketplace you've got to have a balanced supply of employers and job seekers and we did for the first three weeks that i worked
• 11:00 - 11:30 there and then overnight lehman brothers melted down and all of a sudden the ecosystem looks like this no jobs lots of job seekers right literally overnight it doesn't usually happen like that but in this case we went home we came back the next day and the system was flooded with new job seekers the challenge here was that what were we going to do we had a nine-month road map we had a plan and we'd negotiated and people had committed that and do we follow the plan or do we adjust course and so it's the
• 11:30 - 12:00 question that we have to keep asking ourselves with linear product planning how can we respond effectively right we can't be agile we can't inspect and adapt sense and respond build measure learn think make check whatever your favorite phrase is we can't do that if we commit to these linear rigid plans because the world will i guarantee it the world will throw obstacles challenges surprises competitors at us and they will break
• 12:00 - 12:30 our plans and it will challenge the organization's inertia that comes behind the hours of work and negotiation that it took to finalize this list of features and dates that we agreed to and so we've really got to move kind of beyond this rigid product planning and redefine it away from focusing on the delivery of specific features by specific dates and much more towards delivering outcomes and so we need a different way of planning work and so
• 12:30 - 13:00 we're going to talk about that for the rest of the conversation today which is what does an outcome-based product plan look like how do we actually build something that doesn't fix scope and time and gives us the flexibility to react to respond to the market to geopolitical shifts to pandemics to whatever it is the first step in outcome-based product planning is to change the question that we're asking as
• 13:00 - 13:30 we start to define our work the old question is what will we build right that's always been the question and we people still ask that today what are we making what are we building and again this fixes us in a feature based and output-based conversation instead we want to change the question the new question that we need to start to ask if we're going to shift our planning process is what will people be doing differently if we succeed and
• 13:30 - 14:00 let's be clear succeed means we understand the customer problem we choose a set of features to deliver and we do a great job designing developing and implementing those features right what will people be doing differently if we succeed the old question fixes us in output thinking feature based thinking what are we making the new question focuses us on outcomes how will people's behavior change
• 14:00 - 14:30 if we do a great job in other words how do we know we've done a great job what will people be doing differently if we succeed and that's the first thing that we want to start doing is starting to change that conversation so when someone says hey what are we what are we building and we could say well um instead of talking about that maybe the question should be regardless of what we choose to build if we do a great job what do we hope to see people doing differently that's a nice way to start to shift that conversation at work the second step in the process is to change how we view our work a lot of us are really fixed i
• 14:30 - 15:00 think a lot of organizations certainly the ones i work with are fixed in this inside out view of the world right that we know what's best we understand our customers we're going to push out these products into the world and they're going to love them right instead we have to start taking this outside in view a customer-centered view onto the work that we're doing because look the majority of us with exception to be fair but the majority of us are not geniuses delivering magic
• 15:00 - 15:30 products to people who don't know they need them i mean there are people like that who exist you know that's and they're very lucky to be those folks but the majority of us are empathetic problem solvers for our users that give them solutions that make them more successful so instead of saying here is my genius idea that i know you love let me go outside in and say let me understand what problem you're having and then let me see how i can best give you something that will make you more successful and it's changing that conversation from i'm going to give you
• 15:30 - 16:00 something i'm actually going to make you more successful and we'll know and more successful when their behavior changes right now the third step in determining how to build a product plan around outcomes is you have to change the destination and this is where we get into kind of the tactical conversations right so i love this quote from tammy rice she says a roadmap is a marketing tool with your plans for the coming quarter and year which means that we can adjust the marketing for our work as we
• 16:00 - 16:30 learn new information and that's the goal in our outcome based product plan and this is at a very high level and at a generic level i'll be honest right what an outcome-based roadmap or an outcome-based product plan can look like so let's start at the top at the top we are going to list the long-term or the longer term strategic theme for the team this is kind of the objective if you're familiar with okrs and we'll talk about okrs in just a second right but this is the o
• 16:30 - 17:00 in okrs right what is the objective that this team is working on for the next six nine or 12 months right what's the goal for this particular team next we set quarterly key result targets for the team to hit so in q1 we really want to focus on acquisition of new customers and q2 we may still want to focus on acquisition but also activating those customers and maybe looking forward into three and four we're going to start to shift into retention mode we want to get a sense of what we believe
• 17:00 - 17:30 the behavior changes are that we should be targeting on a quarterly basis now i'm using quarters for a few reasons number one it's common a lot of organizations work with quarters number two it's shorter than a year and anything shorter than your current planning cycle and for most organizations a year is what their planning cycle is but anything that you're doing shorter than your current planning cycle is a step in the right direction so i'm using quarters here as an illustration but if that doesn't make
• 17:30 - 18:00 sense in your world if it needs to be six months or if it could be shorter even then then you can adjust that but the cycle time here is a quarter and we're going to commit to key results on a quarterly basis based on what we know today okay now in the short term we can start to take fairly good educated guesses assumptions also known as hypotheses about what we will work on this quarter and maybe a little bit in the next quarter as well
• 18:00 - 18:30 right we believe that here are the the six seven eight things that may help us achieve our key result goals and next quarter there are three or four things that we're also thinking about working on now these are hypotheses we are not committing to delivering every single thing in this list in fact the commitment that we're making is to the key result at the top of the quarter that's what we're committing to that behavior change
• 18:30 - 19:00 that outcome and if we find along the way that the hypotheses that we've listed the work that we've identified for this quarter isn't driving that behavior change we are going to pivot we are going to kill that idea or change it or uh figure out something that may actually achieve that goal now the interesting thing here and this is where this gets tougher i think from a conversation with stakeholders is that the further out in time that we look
• 19:00 - 19:30 the less accurately we can predict the work that we're going to be doing right we talked about the rigidity of linear product planning right if you think you can predict you'll be working on nine months or 12 months from now most of us are going to be wrong right and so we don't want to make any strong commitments beyond you know a quarter ahead so it's like we've got a fairly high level of confidence in in the current quarter a slightly lower level of confidence in the subsequent quarter beyond that it's anybody's guess and so we want to be
• 19:30 - 20:00 super clear about that now what's interesting is that as we start to work in this quarter we are starting to collect evidence and that evidence is going to impact our backlog of work we're going to ship some ideas we're going to kill some ideas we're going to pivot on some ideas and it's going to give us more confidence in the next quarter's work and so when we reach the end of each quarterly cycle we can adjust our levels of certainty a quarter ahead so we can be a lot more
• 20:00 - 20:30 confident in the second quarter slightly more confident in the third quarter and maybe start to add things into q4 right we're shifting our time horizon kind of the time horizon within which we have certainty based on the evidence that we're collecting along the way and we can do that on a quarterly basis if we have these kind of quarterly check-ins right we can check it on a quarterly basis and say how are we trending towards our key results what are we learning what did we ship right and what do we think we need to do
• 20:30 - 21:00 next quarter in in order to achieve the key results do the key results for the next quarter make sense and if they do what do we need to do to move that forward so we're kind of shifting our window of certainty forward in time with evidence the best metaphor that i've come up with to sort of help this concept hit home is this idea of walking through a fog if you've ever walked through a fog then this should hopefully resonate and i've built a lovely fog animation here in a
• 21:00 - 21:30 second you'll see it kind of come in here it took me a long time so let's give it some time to build in here but if you ever walk through a fog you know that you can see three or four steps ahead but you can't see 10 or 15 steps ahead and so you're not going to be running full speed ahead or driving full speed ahead into a fog you're gonna drive slowly right work in small batches go a bit of a distance and then as you move forward four steps you reveal the next four steps and you can see whether or not the road is clear ahead and if it is terrific
• 21:30 - 22:00 keep going that way and you reveal the subsequent four steps but maybe in one of those points you actually reveal that there's a brick wall in front of you where there's a tree and you need to turn left or you need to turn right all right that's exactly what we're doing here we're revealing the next couple of steps by taking a few steps and we're increasing our confidence in the direction that we're moving in that's the focus with this way of working okay let's get a bit more specific about how we actually do this
• 22:00 - 22:30 how we build the components that fall into this the first thing that we want to do is we want to start with a clear business problem this is really important because most teams start with a solution to implement we want to start with a problem to solve so i'm going to give you an example in this particular case this is an online education service for lawyers continuing education service for lawyers to maintain their credentials that we're running we've observed that our customers sign up for an account take one of our courses and then don't come back and this decreases the benefit of
• 22:30 - 23:00 their continuing education it's expensive for us to continuously acquire new customers and so we need to fix this this is the business problem that we are going to work on in the next quarter or two what we then do is we want to think about well strategically what's the goal here if we turn this business problem into a positive goal right then we look at it from a positive lens if we solve that problem then we're building an effective and engaging continuing education learning product for the entirety of a lawyer's career
• 23:00 - 23:30 to ensure that their skills are current right so ideally for that problem turned into a positive statement could look like this and what this is that's our objective that's our strategic goal that goes at the top of that outcome-based product plan then we ask the key question right if we solve that problem if we achieve that objective what will people be doing differently and now we start to list the behavior change that will tell us
• 23:30 - 24:00 that we've actually solved the problem and built this compelling continuing education program right so every user that we have will take at least three courses each year 25 of new customers will come from word of mouth referrals and every law firm that signs up registers at least 50 of its staff these are measures of behavior their outcomes or their key results right these are the goals that we can set up on a quarterly basis to tell us what we're signing up for and what we've
• 24:00 - 24:30 essentially done here is exactly that we've written our first okr statement and then we can take that okr and we can map it to that diagram that i showed you right so we put our strategic theme at the top we put our krs on each quarter and those become our quarterly plan goals now once we've got those quarterly plan goals we can work together to brainstorm solution hypotheses that we think will help us achieve those okrs right and so the template that we're
• 24:30 - 25:00 using here this is a template that comes right out of the lean ux book for hypotheses this could be one way that we might actually achieve the key result right we believe will increase the number of classes taken by each customer by 300 percent right if mid-career lawyers feel like they're progressing ahead of average rates in their career with a leaderboard of internal and external usage statistics so we're going to gamify the process that's the feature that's the hypothesis and we can write a bunch of these things right we can brainstorm these together and those
• 25:00 - 25:30 hypotheses become our quarterly activities right they populate that list these are the things that we're going to work towards that we think that will achieve our key results as we prioritize that list the next step in the process is to determine the risks in those hypotheses and then of course design experiments to test them our goal is not to just ship stuff and hope that it works unless we're highly confident in it right our goal is to make sure that the thing that we're building will actually achieve
• 25:30 - 26:00 the desired behavior change and if it doesn't we want to shift gears we want to move off of that and pivot off of that as quickly as possible right that's the agility component that we're building into outcome-based product planning right is that if the evidence from our experiments contradicts the key result goals the outcome goals well we want to get off that very quickly and i love this this is an experiment in rotterdam in the netherlands where they're trying to figure out where to put bike racks they have ideas about where to put bike racks but instead of just putting down a
• 26:00 - 26:30 bunch of concrete and hoping that it'll work they've got this mobile bike rack they see if people use it and then they commit if people actually change their behavior and start locking their bikes to this thing okay now we talked a little bit about these quarterly check-ins they're super important i want to be very specific about the kinds of questions that you want to ask in these quarterly chickens so we start working for a quarter at the end of that quarter we get together and remember it's really really important that these quarters are forward-looking
• 26:30 - 27:00 in other words no one should be surprised about anything we're going to share at this and there's a responsibility here for the team to communicate proactively over the course of their work about what's happening instead we want a forward-looking conversation that asks how are we trending towards our targets what are we learning are the hypothesis we're currently working on true or false should we change the backlog what will we keep funding right what what initiatives should we keep working on what should we kill should we keep funding this should we
• 27:00 - 27:30 even be chasing this problem any further does it still make sense are there things we should pivot on things we should kill are there new ideas that we've come up with right these are the kinds of conversations we want to have at our quarterly check-ins to help move the conversation forward now i talked about it as without being really deliberate about it and so i want to call out that if you're going to work this way if you're going to try to convince your teams to plan work with outcomes to manage towards customer behaviors this way of working in this way of
• 27:30 - 28:00 product planning explicitly requires you to do product discovery it requires you to do design thinking lean startup lean ux product discovery whatever you want to call it right it's the testing the experimentation the learning the customer conversations the research that informs you about whether or not your hypotheses are actually going to deliver the outcomes that you're targeting and if your organization isn't particularly good at product
• 28:00 - 28:30 discovery you will have to train that organization and if you happen to know how to do it but the organization doesn't enable discovery to take place we have to start to identify the blockers for product discovery and start to unblock them because without this the outcome-based product planning doesn't work right because if you'll notice right in the objectives and the key results that are our goals the measure of success is not the delivery of a specific feature it's the delivery of a behavior change and our hypotheses are just guesses right these are the things
• 28:30 - 29:00 that we think might get us there and so we have to test which ones are actually going to get us there as we start to build these road maps you're absolutely going to face some challenges from your colleagues and your stakeholders this is not going to be easy right one of the the hardest things you're going to have to manage is there's going to be pushback and anxiety one of those reasons for the anxiety is that managers particularly middle managers and stakeholders are used to telling people what to do and we are now saying look the team is
• 29:00 - 29:30 going to determine what to do based on evidence they're going to brainstorm some ideas they're going to run some experiments and based on their learnings they're going to re-prioritize their work because the goal is not to deliver a specific set of features it's to change behavior and so it's really important to understand what are people going to do how managers behaviors are going to change right and this question will come up a lot particularly in folks who are used to very clearly and very deliberately and explicitly telling teams what to do because remember we're taking that away
• 29:30 - 30:00 from them right what do i do if my job is not to tell people what to do then what's my job and i think that if you're in a position where you're leading teams or you've got somebody who's managing your team and we're going to start to get them towards this outcome way of thinking their job is to help define communicate and clarify strategy and make sure you're on track to set guard rails and scope right this is we're focused on the mobile channel only right this is what we're working on help you make key decisions or break some ties their job
• 30:00 - 30:30 is absolutely to remove obstacles to make it easy for you to do product discovery whatever it is you need to do and whatever else that you know provides you with the tools the data the analytics that help you be more successful that's their job right now in return if we're going to ask our managers and our stakeholders to change how they do their job we have to take on as members of the team there's a responsibility for us to make it easier for them to be successful in this new reality right
• 30:30 - 31:00 because this is the number one question that they're asking themselves what if my boss comes to me and asks me what the team is doing and i don't know the answer because i didn't tell them what to do this is where our responsibilities come in as a team as a team we have to practice radical transparency this is where we step up to make our bosses successful in this new way of thinking we have to practice radical transparency which means over communicating both up the chain as well as out to our
• 31:00 - 31:30 colleagues every time we communicate every time we make a decision we want to support that decision with data we are pivoting here because we learned x from this experiment we're killing this idea and shifting to another idea because this is the feedback that we got right we always want to reference the key results as the goal right we're not killing a feature because we didn't like it or because it was hard to implement we're killing it because the data says
• 31:30 - 32:00 the evidence says that it is not moving us towards our key results and most importantly right checking in after every short cycle with the stakeholder after every sprint hey listen this is what we learned come to the uh you know the sprint review meeting all right let me give you a quick recap of what happened the responsibility is on us to get these folks the data the information that they need so they're calm and when they're calm they stay out of our way and they let us do our work one other obstacle that you're absolutely going to run into is sales
• 32:00 - 32:30 right sales is going to say listen i need to know what you're building so i can sell it right how can i sell it if i don't know what's coming if you're going to change the roadmap on me potentially in three four or five weeks how can i sell anything and that's a fair question right and so we want to work first of all we want to involve the sales teams in that over communication so they know exactly what you're doing and why and then most importantly we want to work with them to help them sell the benefit
• 32:30 - 33:00 not the features instead of saying you know we're going to give you calendar integration right go sell calendar integration we're going to say we're going to make sure that nobody ever misses another meeting again in your company go sell that right sell the benefit not the feature go sell the fact that no one will ever miss a meeting again right i don't know if that's a benefit or not but you know that would be certainly an outcome that would come of that right so we're speaking in outcomes and then those outcomes inevitably have financial impact right we're going to increase the productivity of your team you're going
• 33:00 - 33:30 to save this much money you're going to reduce this much waste and so the sales conversation can change as well because the tactical implementation will inevitably vary right remember we're building these continuous systems they never end and so we have the opportunity to improve them in the future particularly if we haven't committed in the sales process to very explicit things i understand that that's difficult but that's the kind of conversation we need to have with our sales folks the more they're involved in these discussions with us the more they're part of this
• 33:30 - 34:00 over communication the easier this gets look this is where agility comes from right managing to outcomes ensures that we're paying attention to how well our work is meeting the needs of our customers right if we're not changing their behavior in a positive way we have objective measures for that and we can adjust our work to reflect that we can objectively say look the work that we're doing is not achieving the goal and so we need to change the work
• 34:00 - 34:30 this fits beautifully into agile short cycles right sprints because those sprints give us the opportunity to minimize our investments in our hypotheses in our feature ideas and if we find out those feature ideas aren't going to help us achieve our key results our outcomes then we can pivot from that we've got the evidence to do that and then ultimately this forces us to continuously learn and build that inspect and adapt from scrum that build measure learn from lean startup that
• 34:30 - 35:00 ship sense and respond from sense and respond into the process and gives us that course correction right because outcome-based product planning is objective we're making these decisions based on the data and it helps us use evidence to convince our colleagues our stakeholders and our sales teams to come along and then ultimately outcome-based product planning helps us stop lying to ourselves and to our bosses right we start to be more honest about what we're actually going to build and when it's going to happen and why we think it's actually valuable so look i
• 35:00 - 35:30 hope that was helpful and i hope that that gave you some ideas to think about we've got time for questions and so i'll hand it back to stefan hopefully can navigate us through any questions or conversations that may have come up while i was talking excellent jeff spot landing we indeed have a few questions and uh i'd like to follow up with one question that's closely related to the sales stuff that you were talking about so question in order to gain new clients sales management commit to prospect a
• 35:30 - 36:00 new feature to be delivered on the existing platform by x date how do we change the mindset and the narrative of these sales leaders there's a lot of language nuance i think that we can use right and you can argue well jeff that's just spin or it's just marketing and well i don't necessarily disagree it does start to get us into a more realistic perception of the nature of software so instead of feature right we can say functionality we're going to deliver calendar integration functionality by
• 36:00 - 36:30 first of august that's great what's the feature maybe it's just a wizard of oz maybe it's just a few of us sitting in the office and plugging in dates into a calendar for you but it enables the feature and again the key thing here is that the functionality is never done we get a sense of how well it worked we get a sense of how many people are using it we get a sense if there's actual traction with it and then we can decide if you want to invest further in solidifying it expanding it scaling it etc and so i think the narrative
• 36:30 - 37:00 becomes we're going to deliver some level of functionality i'll give you an example it was a marketing tool for small businesses and it was for a big credit card company that we were building this is back in new york city when i was living in new york we built the system knowing full well that it could not scale beyond a thousand users right that was an explicit decision that we made to ship this thing to ship these functions that could not scale beyond a
• 37:00 - 37:30 thousand users we knew that the client had tens of thousands of users the idea was to get something out there by a particular date that did something that offered some level of functionality that gave us an opportunity to test whether or not this was actually valuable this was the right direction to do it and then the data allowed us to iterate and improve that over time so really changing the language from feature to function and this idea that it's it's never done we're going to make it better over time is critical to the
• 37:30 - 38:00 success here as well and i'll be honest with you really quick about that particular story this small team is about four engineers on there we had uh three of them who were fully on board with this and we had one engineer he could not in good faith he really really could eventually did it right but he struggled to build this system that he knew was going to break if it had more than a thousand users i'm not bad-mouthing him he was an excellent engineer and he worried about quality
• 38:00 - 38:30 right he's like this is not a high quality product and he was right it wasn't a high quality product by design we were going to make it higher quality over time if it proved the value if it achieved the outcome and the goals it's a different language right but it starts to get the conversation headed in the right direction okay another related question how to transform from a classic feature-based roadmap to a goal-oriented approach uh what would be the first three or four
• 38:30 - 39:00 steps in a 5000 people organization first of all it's it's about asking different questions right so the question always becomes what are we going to build right now we're going to build like what's the behavior change we're seeking what will people be doing differently if we succeed is a great way to start that conversation right what problem are we solving right when someone says go build me this blue button and ship it by friday right and make it big you're like great what problem did that solve well it solves the problem that people keep failing out of the checkout
• 39:00 - 39:30 process oh people keep failing out of the checkout process do we know why no we don't okay let's go figure that out right and then let's build stuff that actually changes their behavior it's just instead of just assuming that a big blue button is going to do that and so we start to change the conversations right and then we start to redefine success from making me a blue button to reduce shopping cart drop out by 90 percent right all of a sudden right blue button might do that red
• 39:30 - 40:00 button might do that longer checkout process shorter checkout process all kinds of ways to solve for that but we really want to start to change the conversation from build me a thing to solve this problem and change this behavior right that's that's the goal but there's a lot more stuff back in the presentation next question now in a chronological order what to do when the product requires many development teams yeah really good question right so scaling is really interesting and there's an article on my blog that that addresses this a little bit but the short of this and i will
• 40:00 - 40:30 give credit where it's due the idea that i have for this uh came from uh mary poppindike it came because i was lucky enough to be sitting at a panel next to her in sweden i think a whole bunch of years ago but the short of it is if we've got multiple development needs which we normally do then one way and i'm not saying this is the only way but one way that you can align them is to give a set of teams
• 40:30 - 41:00 the same okr the same outcome goal to achieve now what does that do well first of all it binds those teams together in a shared goal right so those teams have to work together so they have to figure out how to self-organize how to communicate how to share knowledge how to share learning how to share information and also it reminds those teams that they win or lose together even if we start to kind of divide leading indicators among those teams and one team does really well if other teams don't achieve their goals
• 41:00 - 41:30 we fail right because we've got the same goal here together and so that's one way to do that is to take a set of teams and then to give them the same outcome to achieve and then really kind of let them go they'll figure out how to self-organize in most cases so next question very interesting your emphasis on teams that includes all of the many stakeholders implies that everyone needs to have a basic understanding on every aspect of product and delivery do you agree that people do not exist in
• 41:30 - 42:00 intellectual silos i hope that people do not exist in intellectual silos and that they broaden their perspective on the world by seeking other ideas look the reality is my emphasis is on cross-functional teams those cross-functional teams should have a good sense of the strategy the product strategy that they're working on the goal that they're working on and some level of understanding of what their colleagues do right so the people on their team they don't have to write code per se they don't have to do
• 42:00 - 42:30 design work per se but they have to get a sense they have to understand what everybody in the team does and to to kind of respect the fact that they may have their own process they have their own vocabulary and and to start to build that collaboration as part of the work together that to me is the foundational level of needs that a team requires to be successful i'm not sure if that answered the question but i think everyone needs to have a very clear understanding of the strategy and the goal and what their colleagues are there to
• 42:30 - 43:00 do again you don't have to be an expert in their field right but you have to get a sense of kind of how the process works and then the collaboration can build from there so yes i think that that's i i do believe that that's required okay here's a great question it is one thing to try to support the middle managers to accept the fog one of the challenges i see is if the team composition to define the product delivery more specifically the death team from my experience there are developers that like to be part of those decisions
• 43:00 - 43:30 but a lot of them like to code what would you be your recommendation to bring them into the product outcome outcome you have to invite them i mean that sounds really basic right like invite them to the conversation that you want them to be in but that's a good place to start ask them to come if they don't show up asking why they didn't show up look it's 2022 and and i think that in most organizations today i don't know that it's true but i'd like to believe that in 2022
• 43:30 - 44:00 this idea of a developer who the only thing that they do at work is put on their headphones and write code is out of date i'm sure those jobs exist i just don't think that that's the right job description for a software engineer in 2022. and so that starts to challenge hiring and job descriptions and performance management criteria and that type of thing but some aspect of software development software engineering needs to include customer understanding outcomes
• 44:00 - 44:30 discussions collaboration with colleagues that you don't have to lead that you don't have to drive it but you do have to participate in it in some way and your bosses need to recognize that you will be spending some of your time doing that kind of work because that's going to help you write better code and so that's how i feel about it i know that's not the full reality yet but i think that that's critical it's a critical change in sort of job descriptions for engineers in 2022 that needs to happen okay
• 44:30 - 45:00 next question are there any tips on getting senior leadership to buy in with becoming more outcome based from output absolutely the question was are there any tips this is a very tactical and practical tip one exercise that we do with leaders particularly stakeholders for a particular initiative when we work with teams is we visualize the connection between impact metrics so kpis the things that end up on executive dashboards things like profit revenue sales satisfaction
• 45:00 - 45:30 etc with outcomes we literally visualize it right so what outcomes are leading indicators of sales revenue profit retention etc and the outcomes are very tactical measures of what people do in the system they land on the home page they create an account they come back they sign in they add something to cart they add a second thing to cart they check out right all of these different things and we visualize that connection for them the
• 45:30 - 46:00 first benefit of that is that you're not talking about features which is good that's a good start the second benefit of that is that you are making a very literal and visual connection for these folks that says when people do this we make money right when people do this we save money right so that you're literally connecting the dots for them very very very visually so that that's very helpful because again now you're saying oh maybe if we did more of that we'd
• 46:00 - 46:30 save more money if we did more of that we'd make more money right and then and then we say okay great now if you do this exercise for real like over the course of maybe an hour or two you really kind of build this tree you're going to end up with dozens of post-it notes digital post-it notes or physical post-it notes on the wall and so then the question becomes to the executives that you're working with in this exercise well strategically of the 50 things 50 behaviors 100 behaviors that we have here on the wall we have 10 product teams we have 15 product teams what are
• 46:30 - 47:00 the 10 to 15 top behaviors you think that are strategically most important for us in the next six to nine months and so what we're asking them to do in that exercise is to say well i'd like the teams to focus on on this behavior and that behavior and this outcome and that key result and that's great so all of a sudden we can say great now we've got 10 teams to go after these 10 outcomes and we're going to come back to you with what we believe those teams are going to work on not exactly but that we believe
• 47:00 - 47:30 those teams are going to do to help achieve this behavior change it's a really nice way to start that conversation and to visualize it in a way that pretty much everybody gets it's not a silver bullet but everybody gets it we've come to the end of the time box uh your dog is waiting uh it's been amazing journey thank you so much for uh spending your evening with us and giving us insight into your experience it's been a pleasure to be here thanks for having me stefan it's nice to see you thanks a lot
• 47:30 - 48:00 [Music]