Apr 28, 2024
Bio
Luke Hohmann is Chief Innovation Officer of Applied Frameworks.
Applied Frameworks helps companies create more profitable
software-enabled solutions. A serial entrepreneur, Luke founded,
bootstrapped, and sold the SaaS B2B collaboration software company
Conteneo to Scaled Agile, Inc. Conteneo’s Weave platform is now
part of SAFe Studio.
A SAFe® Fellow, prolific author, and trailblazing innovator, Luke’s
contributions to the global agile community include contributing to
SAFe, five books, Profit Streams™, Innovation Games®, Participatory
Budgeting at enterprise scale, and a pattern language for
market-driven roadmapping.
Luke is also co-founder of Every Voice Engaged Foundation, where he
partnered with The Kettering Foundation to create Common Ground for
Action, the world’s first scalable platform for deliberative
decision-making. Luke is a former National Junior Pairs Figure
Skating Champion and has an M.S.E. in Computer Science and
Engineering from the University of Michigan. Luke loves his wife
and four kids, his wife’s cooking, and long runs in the California
sunshine and Santa Cruz mountains.
Interview Highlights
01:30 Organisational Behaviour & Cognitive Psychology
06:10 Serendipity
09:30 Entrepreneurship
16:15 Applied Frameworks
20:00 Sustainability
20:45 Software Profit Streams
23:00 Business Model Canvas
24:00 Value Proposition Canvas
24:45 Setting the Price
28:45 Customer Benefit Analysis
34:00 Participatory Budgeting
36:00 Value Stream Funding
37:30 The Color of Money
42:00 Private v Public Sector
49:00 ROI Analysis
51:00 Innovation Accounting
Connecting
Books & Resources
· Innovation Games: Creating Breakthrough Products Through Collaborative Play: Luke Hohmann
· Extreme Programming Explained: Embrace Change 2, Kent Beck, Cynthia Andres
· The Mythical Man-Month: Essays on Software Engineering: Brooks, Frederick Phillips
· Understanding Comics: The Invisible Art, Scott McCloud
· Ponyboy: A Novel, Eliot Duncan
· Lessons in Chemistry: A Novel, Bonnie Garmus, Miranda Raison, Bonnie Garmus, Pandora Sykes
· Training | Applied Frameworks
Episode Transcript
Intro: Hello and welcome to the Agile Innovation Leaders podcast. I’m Ula Ojiaku. On this podcast I speak with world-class leaders and doers about themselves and a variety of topics spanning Agile, Lean Innovation, Business, Leadership and much more – with actionable takeaways for you the listener.
Ula Ojiaku
So I have with me Luke Hohmann, who is a four time author, three time founder, serial entrepreneur if I say, a SAFe fellow, so that's a Skilled Agile Framework fellow, keynote speaker and an internationally recognised expert in Agile software development. He is also a proud husband and a father of four. So, Luke, I am very honoured to have you on the Agile Innovation Leaders podcast. Thank you for making the time.
Luke Hohmann
Thank you so much for having me, I'm very happy to be here, and hi everyone who’s listening.
Ula Ojiaku
Yes, I'm sure they're waving back at you as well. I always start my conversations with my guests to find out about them as individuals, you know, so who is Luke? You have a BSc in Computer Science and an MSc in Computer Science and Engineering, but you also studied Cognitive Psychology and Organisational Behaviour in addition to Data Structures and Artificial Intelligence. AI is now making waves and is kind of at the forefront, which is interesting, you had the foresight to also look into these. So my question is, what took you down this path?
Luke Hohmann
Sure. I had a humble beginning in the world of technology. I worked for a large company, Electronic Data Systems, and it was founded in the mid 60s by a gentleman named Ross Perot, and it became a very, very large company. So my first job at Electronic Data Systems was working in a data centre, and we know what data centres are, but back then, data centres were different because they were predominantly mainframe-based data centres, and I would crawl underneath the floor, cabling the computers and cabling networking equipment. Now, when we think networking, we're really thinking one of two kinds of networking. We think of wireless networking or we think of some form of internet networking, but back in those days, there were varieties of network protocols, literally the standards that we use now weren't invented yet. So it was mainframe networking protocols and dial ups and other forms of networking protocols. From there, I worked my way from beneath the ground up. I had some great managers who saw someone who was worthy of opportunity and they gave me opportunity and it was great. And then eventually I started working in electronic data systems and there was, the first wave of AI came in the mid 80s and that's when we were doing things like building expert systems, and I managed to create with a colleague of mine, who's emerged as my best friend, a very successful implementation of an expert system, an AI-based expert system at EDS, and that motivated me to finish off my college degree, I didn't have my college degree at the time. So EDS supported me in going to the University of Michigan, where as you said, I picked up my Bachelor's and Master's degree, and my advisor at the time was Elliot Soloway, and he was doing research in how programmers program, what are the knowledge structures, what are the ways in which we think when we're programming, and I picked up that research and built programming environments, along with educational material, trying to understand how programmers program and trying to build educational material to teach programming more effectively. That's important because it ignited a lifelong passion for developing education materials, etc. Now the cognitive psychology part was handled through that vein of work, the organisational behaviour work came as I was a student at Michigan. As many of us are when we're in college, we don't make a lot of money, or at university we're not wealthy and I needed a job and so the School of Organisational Behaviour had published some job postings and they needed programmers to program software for their organisational behaviour research, and I answered those ads and I became friends and did the research for many ground-breaking aspects of organisational behaviour and I programmed, and in the process of programming for the professors who were in the School of Organisational Behaviour they would teach me about organisational behaviour and I learned many things that at the time were not entirely clear to me, but then when I graduated from university and I became a manager and I also became more involved in the Agile movement, I had a very deep foundation that has served me very well in terms of what do we mean when we say culture, or what do we mean when we talk about organisational structures, both in the small and in the large, how do we organise effectively, when should we scale, when should we not scale, etc. So that's a bit about my history that I think in terms of the early days helped inform who I am today.
Ula Ojiaku
Wow, who would have thought, it just reminds me of the word serendipity, you know, I guess a happy coincidence, quote unquote, and would there be examples of where the cognitive psychology part of it also helped you work-wise?
Luke Hohmann
Yeah, a way to think about cognitive psychology and the branch that, I mean there's, psychology is a huge branch of study, right? So cognitive psychology tends to relate to how do we solve problems, and it tends to focus on problem solving where n = 1 and what I mean by n is the number of participants, and where n is just me as an individual, how do I solve the problems that I'm facing? How do I engage in de-compositional activities or refinement or sense making? Organisational behaviour deals with n > 1. So it can deal with a team of, a para-bond, two people solving problems. It can deal with a small team, and we know through many, many, many decades of research that optimal team structures are eight people or less. I mean, we've known this for, when I say decades I mean millennia. When you look at military structure and military strategy, we know that people need to be organised into much smaller groups to be effective in problem solving and to move quickly. And then in any organisational structure, there's some notion of a team of teams or team engagement. So cognitive psychology, I think, helps leaders understand individuals and their place within the team. And now we talk about, you know, in the Agile community, we talk about things like, I want T-shaped people, I want people with common skills and their area of expertise and by organising enough of the T's, I can create a whole and complete team. I often say I don't want my database designer designing my user interface and I don't want my user interface designer optimising my back end database queries, they're different skills. They're very educated people, they're very sophisticated, but there's also the natural feeling that you and I have about how do I gain a sense of self, how do I gain a sense of accomplishment, a sense of mastery? Part of gaining a sense of mastery is understanding who you are as a person, what you're good at. In Japanese, they would call that Ikigai, right, what are the intersections of, you know, what do I love, what am I good at, what can I make a living at and what do people need, right? All of these intersections occur on an individual level, and then by understanding that we can create more effective teams.
Ula Ojiaku
Thank you. I've really learned something key here, the relationship between cognitive psychology and organisational behaviour, so thanks for breaking it down. Now, can we go quickly to your entrepreneurship? So there must be three times you started three times a company and you've been successful in that area. What exactly drives you when it comes to establishing businesses and then knowing when to move on?
Luke Hohmann
Sure. I think it's a combination of reflecting on my childhood and then looking at how that informs someone when they're older, and then opportunities, like you said, serendipity, I think that's a really powerful word that you introduced and it's a really powerful concept because sometimes the serendipity is associated with just allowing yourself to pursue something that presents itself. But when I was young, my father died and my mum had to raise six kids on her own, so my dad died when I was four, my mum raised six kids on her own. We were not a wealthy family, and she was a school teacher and one of the things that happened was, even though she was a very skilled school teacher, there were budget cuts and it was a unionised structure, and even though she was ranked very highly, she lost her job because she was low on the hiring totem pole in terms of how the union worked. It was very hard and of course, it's always hard to make budget cuts and firing but I remember when I was very young making one of those choices saying, I want to work in a field where we are more oriented towards someone's performance and not oriented on when they were hired, or the colour of their skin, or their gender or other things that to me didn't make sense that people were making decisions against. And while it's not a perfect field for sure, and we've got lots of improvement, engineering in general, and of course software engineering and software development spoke to me because I could meet people who were diverse or more diverse than in other fields and I thought that was really good. In terms of being an entrepreneur, that happened serendipitously. I was at the time, before I became an entrepreneur in my last job, was working for an Israeli security firm, and years and years ago, I used to do software anti-piracy and software security through physical dongles. This was made by a company called Aladdin Knowledge Systems in Israel, and I was the head of Engineering and Product Management for the dongle group and then I moved into a role of Business Development for the company. I had a couple of great bosses, but I also learned how to do international management because I had development teams in Israel, I had development teams in Munich, I had development teams in Portland, Oregon, and in the Bay Area, and this was in the 2000s. This is kind of pre-Agile, pre-Salt Lake City, pre-Agile Manifesto, but we were figuring things out and blending and working together. I thought things were going pretty well and I enjoyed working for the Israelis and what we were doing, but then we had the first Gulf War and my wife and I felt that maybe traveling as I was, we weren't sure what was going to happen in the war, I should choose something different. Unfortunately, by that time, we had been through the dot-bomb crisis in Silicon Valley. So it's about 2002 at the time that this was going on, and there really weren't jobs, it was a very weird time in Silicon Valley. So in late 2002, I sent an email to a bunch of friends and I said, hey, I'm going to be a consultant, who wants to hire me, that was my marketing plan, not very clever, and someone called me and said, hey, I've got a problem and this is the kind of thing that you can fix, come consult with us. And I said, great. So I did that, and that started the cleverly named Luke Hohmann Consulting, but then one thing led to another and consulting led to opportunities and growth and I've never looked back. So I think that there is a myth about people who start companies where sometimes you have a plan and you go execute your plan. Sometimes you find the problem and you're solving a problem. Sometimes the problem is your own problem, as in my case I had two small kids and a mortgage and I needed to provide for my family, and so the best way to do that at the time was to become a consultant. Since then I have engaged in building companies, sometimes some with more planning, some with more business tools and of course as you grow as an entrepreneur you learn skills that they didn’t teach you in school, like marketing and pricing and business planning etc. And so that's kind of how I got started, and now I have kind of come full circle. The last company, the second last company I started was Conteneo and we ended up selling that to Scaled Agile, and that's how I joined the Scaled Agile team and that was lovely, moving from a position of being a CEO and being responsible for certain things, to being able to be part of a team again, joining the framework team, working with Dean Leffingwell and other members of the framework team to evolve the SAFe framework, that was really lovely. And then of course you get this entrepreneurial itch and you want to do something else, and so I think it comes and goes and you kind of allow yourself those opportunities.
Ula Ojiaku
Wow, yours is an inspiring story. And so what are you now, so you've talked about your first two Startups which you sold, what are you doing now?
Luke Hohmann
Yeah, so where I'm at right now is I am the Chief Innovation Officer for a company, Applied Frameworks. Applied Frameworks is a boutique consulting firm that's in a transition to a product company. So if this arm represents our product revenue and this arm represents our services revenue, we're expanding our product and eventually we’ll become a product company. And so then the question is, well, what is the product that we're working on? Well, if you look at the Agile community, we've spent a lot of time creating and delivering value, and that's really great. We have had, if you look at the Agile community, we've had amazing support from our business counterparts. They've shovelled literally millions and millions of dollars into Agile training and Agile tooling and Agile transformations, and we've seen a lot of benefit from the Agile community. And when I say Agile, I don't mean SAFe or Scrum or some particular flavour of Agile, I just mean Agile in general. There's been hundreds of millions of dollars to billions of dollars shoved into Agile and we've created a lot of value for that investment. We've got fewer bugs in our software because we've got so many teams doing XP driven practices like Test Driven Development, we've got faster response times because we've learned that we can create smaller releases and we've created infrastructure that lets us do deployments automatically, even if you're doing embedded systems, we figured out how to do over the air updates, we’ve figured out how to create infrastructure where the cars we’re driving are now getting software updates. So we've created for our business leaders lots of value, but there's a problem in that value. Our business leaders now need us to create a profit, and creating value and creating a profit are two different things. And so in the pursuit of value, we have allowed our Agile community to avoid and or atrophy on skills that are vital to product management, and I'm a classically trained Product Manager, so I've done market segmentation and market valuation and market sizing, I've done pricing, I've done licensing, I've done acquisitions, I've done compliance. But when you look at the traditional definition of a Product Owner, it's a very small subset of that, especially in certain Agile methods where Product Owners are team centric, they're internal centric. That's okay, I'm not criticising that structure, but what's happened is we've got people who no longer know how to price, how to package, how to license products, and we're seeing companies fail, investor money wasted, too much time trying to figure things out when if we had simply approached the problem with an analysis of not just what am I providing to you in terms of value, but what is that value worth, and how do I structure an exchange where I give you value and you give me money? And that's how businesses survive, and I think what's really interesting about this in terms of Agile is Agile is very intimately tied to sustainability. One of the drivers of the Agile Movement was way back in the 2000s, we were having very unsustainable practices. People would be working 60, 80, death march weeks of grinding out programmers and grinding out people, and part of the Agile Movement was saying, wait a minute, this isn't sustainable, and even the notion of what is a sustainable pace is really vital, but a company cannot sustain itself without a profit, and if we don't actually evolve the Agile community from value streams into profit streams, we can't help our businesses survive. I sometimes ask developers, I say, raise your hand if you're really embracing the idea that your job is to make more money for your company than they pay you, that's called a profit, and if that's not happening, your company's going to fail.
Ula Ojiaku
They'll be out of a job.
Luke Hohmann
You'll be out of a job. So if you want to be self-interested about your future, help your company be successful, help them make a profit, and so where I'm at right now is Applied Frameworks has, with my co-author, Jason Tanner, we have published a bold and breakthrough new book called Software Profit Streams, and it's a book that describes how to do pricing and packaging for software enabled solutions. When we say software enabled solution, we mean a solution that has software in it somehow, could be embedded software in your microwave oven, it could be a hosted solution, it could be an API for a payment processor, it could be the software in your car that I talked about earlier. So software enabled solutions are the foundation, the fabric of our modern lives. As Mark Andreessen says software is eating the world, software is going to be in everything, and we need to know how to take the value that we are creating as engineers, as developers, and convert that into pricing and licensing choices that create sustainable profits.
Ula Ojiaku
Wow. It’s as if you read my mind because I was going to ask you about your book, Software Profit Streams, A Guide to Designing a Sustainably Profitable Business. I also noticed that, you know, there is the Profit Stream Canvas that you and your co-author created. So let's assume I am a Product Manager and I've used this, let’s assume I went down the path of using the Business Model Canvas and there is the Customer Value Proposition. So how do they complement?
Luke Hohmann
How do they all work together? I'm glad you asked that, I think that's a very insightful question and the reason it's so helpful is because, well partly because I'm also friends with Alex Osterwalder, I think he's a dear, he's a wonderful human, he's a dear friend. So let's look at the different elements of the different canvases, if you will, and why we think that this is needed. The Business Model Canvas is kind of how am I structuring my business itself, like what are my partners, my suppliers, my relationships, my channel strategy, my brand strategy with respect to my customer segments, and it includes elements of cost, which we're pretty good at. We're pretty good at knowing our costs and elements of revenue, but the key assumption of revenue, of course, is the selling price and the number of units sold. So, but if you look at the book, Business Model Generation, where the Business Model Canvas comes from, it doesn't actually talk about how to set the price. Is the video game going to be $49? Is it going to be $59, or £49 or £59? Well, there's a lot of thought that goes into that. Then we have the Value Proposition Canvas, which highlights what are the pains the customer is facing? What are the gains that the customer is facing? What are the jobs to be done of the customer? How does my solution relate to the jobs? How does it help solve the pain the customer is feeling? How does it create gain for the customer? But if you read those books, and both of those books are on my shelf because they're fantastic books, it doesn't talk about pricing. So let's say I create a gain for you. Well, how much can I charge you for the gain that I've created? How do I structure that relationship? And how do I know, going back to my Business Model Canvas, that I've got the right market segment, I've got the right investment strategy, I might need to make an investment in the first one or two releases of my software or my product before I start to make a per unit profit because I'm evolving, it's called the J curve and the J curve is how much money am I investing before I well, I have to be able to forecast that, I have to be able to model that, but the key input to that is what is the price, what is the mechanism of packaging that you're using, is it, for example, is it per user in a SAS environment or is it per company in a SAS environment? Is it a meter? Is it like an API transaction using Stripe or a payment processor, Adyen or Stripe or Paypal or any of the others that are out there? Or is it an API call where I'm charging a fraction of a penny for any API call? All of those elements have to be put into an economic model and a forecast has to be created. Now, what's missing about this is that the Business Model Canvas and the Value Proposition Canvas don't give you the insight on how to set the price, they just say there is a price and we're going to use it in our equations. So what we've done is we've said, look, setting the price is itself a complex system, and what I mean by a complex system is that, let's say that I wanted to do an annual license for a new SAS offering, but I offer that in Europe and now my solution is influenced or governed by GDPR compliance, where I have data retention and data privacy laws. So my technical architecture that has to enforce the license, also has to comply with something in terms of the market in which I'm selling. This complex system needs to be organised, and so what canvases do is in all of these cases, they let us take a complex system and put some structure behind the choices that we're making in that complex system so that we can make better choices in terms of system design. I know how I want this to work, I know how I want this to be structured, and therefore I can make system choices so the system is working in a way that benefits the stakeholders. Not just me, right, I'm not the only stakeholder, my customers are in this system, my suppliers are in this system, society itself might be in the system, depending on the system I’m building or the solution I'm building. So the canvases enable us to make system level choices that are hopefully more effective in achieving our goals. And like I said, the Business Model Canvas, the Value Proposition Canvas are fantastic, highly recommended, but they don't cover pricing. So we needed something to cover the actual pricing and packaging and licensing.
Ula Ojiaku
Well, that's awesome. So it's really more about going, taking a deeper dive into thoughtfully and structurally, if I may use that word, assessing the pricing.
Luke Hohmann
Yeah, absolutely.
Ula Ojiaku
Would you say that in doing this there would be some elements of, you know, testing and getting feedback from actual customers to know what price point makes sense?
Luke Hohmann
Absolutely. There's a number of ways in which customer engagement or customer testing is involved. The very first step that we advocate is a Customer Benefit Analysis, which is what are the actual benefits you're creating and how are your customers experiencing those benefits. Those experiences are both tangible and intangible and that's another one of the challenges that we face in the Agile community. In general, the Agile community spends a little bit more time on tangible or functional value than intangible value. So we, in terms of if I were to look at it in terms of a computer, we used to say speeds and feeds. How fast is the processor? How fast is the network? How much storage is on my disk space? Those are all functional elements. Over time as our computers have become plenty fast or plenty storage wise for most of our personal computing needs, we see elements of design come into play, elements of usability, elements of brand, and we see this in other areas. Cars have improved in quality so much that many of us, the durability of the car is no longer a significant attribute because all cars are pretty durable, they're pretty good, they're pretty well made. So now we look at brand, we look at style, we look at aesthetics, we look at even paying more for a car that aligns with our values in terms of the environment. I want to get an EV, why, because I want to be more environmentally conscious. That's a value driven, that’s an intangible factor. And so our first step starts with Customer Benefit Analysis looking at both functional or tangible value and intangible value, and you can't do that, as you can imagine, you can't do that without having customer interaction and awareness with your stakeholders and your customers, and that also feeds throughout the whole pricing process. Eventually, you're going to put your product in a market, and that's a form itself of market research. Did customers buy, and if they didn't buy, why did they not buy? Is it poorly packaged or is it poorly priced? These are all elements that involve customers throughout the process.
Ula Ojiaku
If I may, I know we've been on the topic of your latest book Software Profit Streams. I'm just wondering, because I can't help but try to connect the dots and I'm wondering if there might be a connection to one of your books, Innovation Games: Creating Breakthrough Products Through Collaborative Play, something like buy a feature in your book, that kind of came to mind, could there be a way of using that as part of the engagement with customers in setting a pricing strategy? I may be wrong, I'm just asking a question.
Luke Hohmann
I think you're making a great connection. There's two forms of relationship that Innovation Games and the Innovation Games book have with Software Profit Streams. One is, as you correctly noted, just the basics of market research, where do key people have pains or gains and what it might be worth. That work is also included in Alex Osterwalder's books, Value Proposition Design for example, when I've been doing Value Proposition Design and I'm trying to figure out the customer pains, you can use the Innovation Games Speed Boat. And when I want to figure out the gains, I can use the Innovation Game Product Box. Similarly, when I'm figuring out pricing and licensing, a way, and it's a very astute idea, a way to understand price points of individual features is to do certain kinds of market research. One form of market research you can do is Buy-a-Feature, which gives a gauge of what people are willing or might be willing to pay for a feature. It can be a little tricky because the normal construction of Buy-a-Feature is based on cost. However, your insight is correct, you can extend Buy-a-Feature such that you're testing value as opposed to cost, and seeing what, if you take a feature that costs X, but inflate that cost by Y and a Buy-a-Feature game, if people still buy it, it's a strong signal strength that first they want it, and second it may be a feature that you can, when delivered, would motivate you to raise the price of your offering and create a better profit for your company.
Ula Ojiaku
Okay, well, thank you. I wasn't sure if I was on the right lines.
Luke Hohmann
It's a great connection.
Ula Ojiaku
Thanks again. I mean, it's not original. I'm just piggybacking on your ideas. So with respect to, if we, if you don't mind, let's shift gears a bit because I know that, or I'm aware that whilst you were with Scaled Agile Incorporated, you know, you played a key part in developing some of their courses, like the Product POPM, and I think the Portfolio Management, and there was the concept about Participatory Budgeting. Can we talk about that, please?
Luke Hohmann
I'd love to talk about that, I mean it’s a huge passion of mine, absolutely. So in February of 2018, I started working with the framework team and in December of 2018, we talked about the possibility of what an acquisition might look like and the benefits it would create, which would be many. That closed in May of 2019, and in that timeframe, we were working on SAFe 5.0 and so there were a couple of areas in which I was able to make some contributions. One was in Agile product delivery competency, the other was in lean portfolio management. I had a significant hand in restructuring or adding the POPM, APM, and LPM courses, adding things like solutions by horizons to SAFe, taking the existing content on guardrails, expanding it a little bit, and of course, adding Participatory Budgeting, which is just a huge passion of mine. I've done Participatory Budgeting now for 20 years, I've helped organisations make more than five billions of dollars of investment spending choices at all levels of companies, myself and my colleagues at Applied Frameworks, and it just is a better way to make a shared decision. If you think about one of the examples they use about Participatory Budgeting, is my preferred form of fitness is I'm a runner and so, and my wife is also a fit person. So if she goes and buys a new pair of shoes or trainers and I go and buy a new pair of trainers, we don't care, because it's a small purchase. It's frequently made and it's within the pattern of our normal behaviour. However, if I were to go out and buy a new car without involving her, that feels different, right, it's a significant purchase, it requires budgeting and care, and is this car going to meet our needs? Our kids are older than your kids, so we have different needs and different requirements, and so I would be losing trust in my pair bond with my wife if I made a substantial purchase without her involvement. Well, corporations work the same way, because we're still people. So if I'm funding a value stream, I'm funding the consistent and reliable flow of valuable items, that's what value stream funding is supposed to do. However, if there is a significant investment to be made, even if the value stream can afford it, it should be introduced to the portfolio for no other reason than the social structure of healthy organisations says that we do better when we're talking about these things, that we don't go off on our own and make significant decisions without the input of others. That lowers transparency, that lowers trust. So I am a huge advocate of Participatory Budgeting, I'm very happy that it's included in SAFe as a recommended practice, both for market research and Buy-a-Feature in APM, but also more significantly, if you will, at the portfolio level for making investment decisions. And I'm really excited to share that we've just published an article a few weeks ago about Participatory Budgeting and what's called The Color of Money, and The Color of Money is sometimes when you have constraints on how you can spend money, and an example of a constraint is let's say that a government raised taxes to improve transportation infrastructure. Well, the money that they took in is constrained in a certain way. You can't spend it, for example, on education, and so we have to show how Participatory Budgeting can be adapted to have relationships between items like this item requires this item as a precedent or The Color of Money, constraints of funding items, but I'm a big believer, we just published that article and you can get that at the Scaled Agile website, I'm a big believer in the social power of making these financial decisions and the benefits that accrue to people and organisations when they collaborate in this manner.
Ula Ojiaku
Thanks for going into that, Luke. So, would there be, in your experience, any type of organisation that's participatory? It's not a leading question, it's just genuine, there are typically outliers and I'm wondering in your experience, and in your opinion, if there would be organisations that it might not work for?
Luke Hohmann
Surprisingly, no, but I want to add a few qualifications to the effective design of a Participatory Budgeting session. When people hear Participatory Budgeting, there's different ways that you would apply Participatory Budgeting in the public and private sector. So I've done citywide Participatory Budgeting in cities and if you're a citizen of a city and you meet the qualifications for voting within that jurisdiction, in the United States, it's typically that you're 18 years old, in some places you have to be a little older, in some places you might have other qualifications, but if you're qualified to participate as a citizen in democratic processes, then you should be able to participate in Participatory Budgeting sessions that are associated with things like how do we spend taxes or how do we make certain investments. In corporations it’s not quite the same way. Just because you work at a company doesn't mean you should be included in portfolio management decisions that affect the entire company. You may not have the background, you may not have the training, you may be what my friends sometimes call a fresher. So I do a lot of work overseas, so freshers, they just may not have the experience to participate. So one thing that we look at in Participatory Budgeting and SAFe is who should be involved in the sessions, and that doesn't mean that every single employee should always be included, because their background, I mean, they may be a technical topic and maybe they don't have the right technical background. So we work a little bit harder in corporations to make sure the right people are there. Now, of course, if we're going to make a mistake, we tend to make the mistake of including more people than excluding, partly because in SAFe Participatory Budgeting, it's a group of people who are making a decision, not a one person, one vote, and that's really profoundly important because in a corporation, just like in a para-bond, your opinion matters to me, I want to know what you're thinking. If I'm looking in, I’ll use SAFe terminology, if I'm looking at three epics that could advance our portfolio, and I'm a little unsure about two of those epics, like one of those epics, I'm like, yeah, this is a really good thing, I know a little bit about it, this matters, I'm going to fund this, but the other two I'm not so sure about, well, there's no way I can learn through reading alone what the opinions of other people are, because, again, there's these intangible factors. There's these elements that may not be included in an ROI analysis, it's kind of hard to talk about brand and an ROI analysis - we can, but it's hard, so I want to listen to how other people are talking about things, and through that, I can go, yeah, I can see the value, I didn’t see it before, I'm going to join you in funding this. So that's among the ways in which Participatory Budgeting is a little different within the private sector and the public sector and within a company. The only other element that I would add is that Participatory Budgeting gives people the permission to stop funding items that are no longer likely to meet the investment or objectives of the company, or to change minds, and so one of the, again, this is a bit of an overhang in the Agile community, Agile teams are optimised for doing things that are small, things that can fit within a two or three week Sprint. That's great, no criticism there, but our customers and our stakeholders want big things that move the market needle, and the big things that move the market needle don't get done in two or three weeks, in general, and they rarely, like they require multiple teams working multiple weeks to create a really profoundly new important thing. And so what happens though, is that we need to make in a sense funding commitments for these big things, but we also have to have a way to change our mind, and so traditional funding processes, they let us make this big commitment, but they're not good at letting us change our mind, meaning they're not Agile. Participatory Budgeting gives us the best of both worlds. I can sit at the table with you and with our colleagues, we can commit to funding something that's big, but six months later, which is the recommended cadence from SAFe, I can come back to that table and reassess and we can all look at each other, because you know those moments, right, you've had that experience in visiting, because you're like looking around the table and you're like, yeah, this isn't working. And then in traditional funding, we keep funding what's not working because there's no built-in mechanism to easily change it, but in SAFe Participatory Budgeting, you and I can sit at the table and we can look at each other with our colleagues and say, yeah, you know, that initiative just, it's not working, well, let's change our mind, okay, what is the new thing that we can fund? What is the new epic? And that permission is so powerful within a corporation.
Ula Ojiaku
Thanks for sharing that, and whilst you were speaking, because again, me trying to connect the dots and thinking, for an organisation that has adopted SAFe or it's trying to scale Agility, because like you mentioned, Agile teams are optimised to iteratively develop or deliver, you know, small chunks over time, usually two to three weeks, but, like you said, there is a longer time horizon spanning months, even years into the future, sometimes for those worthwhile, meaty things to be delivered that moves the strategic needle if I may use that buzzword. So, let's say we at that lean portfolio level, we're looking at epics, right, and Participatory Budgeting, we are looking at initiatives on an epic to epic basis per se, where would the Lean Startup Cycle come in here? So is it that Participatory Budgeting could be a mechanism that is used for assessing, okay, this is the MVP features that have been developed and all that, the leading indicators we've gotten, that's presented to the group, and on that basis, we make that pivot or persevere or stop decision, would that fit in?
Luke Hohmann
Yeah, so let's, I mean, you're close, but let me make a few turns and then it'll click better. First, let's acknowledge that the SAFe approach to the Lean Startup Cycle is not the Eric Ries approach, there are some differences, but let's separate how I fund something from how I evaluate something. So if I'm going to engage in the SAFe Lean Startup Cycle, part of that engagement is to fund an MVP, which is going to prove or disprove a given hypothesis. So that's an expenditure of money. Now there's, if you think about the expenditure of money, there's minimally two steps in this process - there's spending enough money to conduct the experiments, and if those experiments are true, making another commitment to spend money again, that I want to spend it. The reason this is important is, let's say I had three experiments running in parallel and I'm going to use easy round numbers for a large corporation. Let's say I want to run three experiments in parallel, and each experiment costs me a million pounds. Okay. So now let's say that the commercialisation of each of those is an additional amount of money. So the portfolio team sits around the table and says, we have the money, we're going to fund all three. Okay, great. Well, it's an unlikely circumstance, but let's say all three are successful. Well, this is like a venture capitalist, and I have a talk that I give that relates the funding cycle of a venture capitalist to the funding cycle of an LPM team. While it's unlikely, you could have all three become successful, and this is what I call an oversubscribed portfolio. I've got three great initiatives, but I can still only fund one or two of them, I still have to make the choice. Now, of course, I'm going to look at my economics and let's say out of the three initiatives that were successfully proven through their hypothesis, let's say one of them is just clearly not as economically attractive, for whatever reason. Okay, we get rid of that one, now, I've got two, and if I can only fund one of them, and the ROI, the hard ROI is roughly the same, that's when Participatory Budgeting really shines, because we can have those leaders come back into the room, and they can say, which choice do we want to make now? So the evaluative aspect of the MVP is the leading indicators and the results of the proving or disproving of the hypotheses. We separate that from the funding choices, which is where Participatory Budgeting and LPM kick in.
Ula Ojiaku
Okay. So you've separated the proving or disproving the hypothesis of the feature, some of the features that will probably make up an epic. And you're saying the funding, the decision to fund the epic in the first place is a different conversation. And you've likened it to Venture Capital funding rounds. Where do they connect? Because if they're separate, what's the connecting thread between the two?
Luke Hohmann
The connected thread is the portfolio process, right? The actual process is the mechanism where we're connecting these things.
Ula Ojiaku
OK, no, thanks for the portfolio process. But there is something you mentioned, ROI - Return On Investment. And sometimes when you're developing new products, you don't know, you have assumptions. And any ROI, sorry to put it this way, but you're really plucking figures from the air, you know, you're modelling, but there is no certainty because you could hit the mark or you could go way off the mark. So where does that innovation accounting coming into place, especially if it's a product that's yet to make contact with, you know, real life users, the customers.
Luke Hohmann
Well, let's go back to something you said earlier, and what you talked earlier about was the relationship that you have in market researching customer interaction. In making a forecast, let's go ahead and look at the notion of building a new product within a company, and this is again where the Agile community sometimes doesn't want to look at numbers or quote, unquote get dirty, but we have to, because if I'm going to look at building a new idea, or taking a new idea into a product, I have to have a forecast of its viability. Is it economically viable? Is it a good choice? So innovation accounting is a way to look at certain data, but before, I'm going to steal a page, a quote, from one of my friends, Jeff Patton. The most expensive way to figure this out is to actually build the product. So what can I do that's less expensive than building the product itself? I can still do market research, but maybe I wouldn't do an innovation game, maybe I’d do a formal survey and I use a price point testing mechanism like Van Westendorp Price Point Analysis, which is a series of questions that you ask to triangulate on acceptable price ranges. I can do competitive benchmarking for similar products and services. What are people offering right now in the market? Now that again, if the product is completely novel, doing competitive benchmarking can be really hard. Right now, there's so many people doing streaming that we look at the competitive market, but when Netflix first offered streaming and it was the first one, their best approach was what we call reference pricing, which is, I have a reference price for how much I pay for my DVDs that I'm getting in the mail, I'm going to base my streaming service kind of on the reference pricing of entertainment, although that's not entirely clear that that was the best way to go, because you could also base the reference price on what you're paying for a movie ticket and how many, but then you look at consumption, right, because movie tickets are expensive, so I only go to a movie maybe once every other month, whereas streaming is cheap and so I can change my demand curve by lowering my price. But this is why it's such a hard science is because we have this notion of these swirling factors. Getting specifically back to your question about the price point, I do have to do some market research before I go into the market to get some forecasting and some confidence, and research gives me more confidence, and of course, once I'm in the market, I'll know how effective my research matched the market reality. Maybe my research was misleading, and of course, there's some skill in designing research, as you know, to get answers that have high quality signal strength.
Ula Ojiaku
Thanks for clarifying. That makes perfect sense to me.
Luke Hohmann
It's kind of like a forecast saying, like there's a group of Agile people who will say, like, you shouldn't make forecasts. Well, I don't understand that because that's like saying, and people will say, well, I can't predict the future. Well, okay, I can't predict when I'm going to retire, but I'm planning to retire. I don't know the date of my exact retirement, but my wife and I are planning our retirement, and we're saving, we're making certain investment choices for our future, because we expect to have a future together. Now our kids are older than yours. My kids are now in university, and so we're closer to retirement. So what I dislike about the Agile community is people will sometimes say, well, I don't know the certainty of the event, therefore, I can't plan for it. But that's really daft, because there are many places in like, you may not for the listeners, her daughter is a little younger than my kids, but they will be going to university one day, and depending on where they go, that's a financial choice. So you could say, well, I don't know when she's going to university, and I can't predict what university she's going to go to, therefore I'm not going to save any money. Really? That doesn't make no sense. So I really get very upset when you have people in the agile community will say things like road mapping or forecasting is not Agile. It's entirely Agile. How you treat it is Agile or not Agile. Like when my child comes up to me and says, hey, you know about that going to university thing, I was thinking of taking a gap year. Okay, wait a minute, that's a change. That doesn't mean no, it means you're laughing, right? But that's a change. And so we respond to change, but we still have a plan.
Ula Ojiaku
It makes sense. So the reason, and I completely resonate with everything you said, the reason I raised that ROI and it not being known is that in some situations, people might be tempted to use it to game the budget allocation decision making process. That’s why I said you would pluck the ROI.
Luke Hohmann
Okay, let's talk about that. We actually address this in our recent paper, but I'll give you my personal experience. You are vastly more likely to get bad behaviour on ROI analysis when you do not do Participatory Budgeting, because there's no social construct to prevent bad behaviour. If I'm sitting down at a table and that's virtual or physical, it doesn't matter, but let's take a perfect optimum size for a Participatory Budgeting group. Six people, let's say I'm a Director or a Senior Director in a company, and I'm sitting at a table and there's another Senior Director who's a peer, maybe there's a VP, maybe there's a person from engineering, maybe there's a person from sales and we've got this mix of people and I'm sitting at that table. I am not incented to come in with an inflated ROI because those people are really intelligent and given enough time, they're not going to support my initiative because I'm fibbing, I'm lying. And I have a phrase for this, it's when ROI becomes RO-lie that it's dangerous. And so when I'm sitting at that table, what we find consistently, and one of the clients that we did a fair amount of Participatory Budgeting for years ago with Cisco, what we found was the leaders at Cisco were creating tighter, more believable, and more defensible economic projections, precisely because they knew that they were going to be sitting with their peers, and it didn't matter. It can go both ways. Sometimes people will overestimate the ROI or they underestimate the cost. Same outcome, right? I'm going to overestimate the benefit, and people would be like, yeah, I don't think you can build that product with three teams. You're going to need five or six teams and people go, oh, I can get it done with, you know, 20 people. Yeah, I don't think so, because two years ago, we built this product. It's very similar, and, you know, we thought we could get it done with 20 people and we couldn't. We really needed, you know, a bigger group. So you see the social construct creating a more believable set of results because people come to the Participatory Budgeting session knowing that their peers are in the room. And of course, we think we're smart, so our peers are as smart as we are, we're all smart people, and therefore, the social construct of Participatory Budgeting quite literally creates a better input, which creates a better output.
Ula Ojiaku
That makes sense, definitely. Thanks for sharing that. I've found that very, very insightful and something I can easily apply. The reasoning behind it, the social pressure, quote unquote, knowing that you're not just going to put the paper forward but you'd have to defend it in a credible, believable way make sense. So just to wrap up now, what books have you found yourself recommending to people the most, and why?
Luke Hohmann
It’s so funny, I get yelled at by my wife for how many books I buy. She'll go like “It’s Amazon again. Another book. You know, there's this thing called the library.”
Ula Ojiaku
You should do Participatory Budgeting for your books then sounds like, sorry.
Luke Hohmann
No, no, I don’t, I’d lose. Gosh, I love so many books. So there's a few books that I consider to be my go-to references and my go-to classics, but I also recommend that people re-read books and sometimes I recommend re-reading books is because you're a different person, and as you age and as you grow and you see things differently and in fact, I'm right now re-reading and of course it goes faster, but I'm re-reading the original Extreme Programming Explained by Kent Beck, a fantastic book. I just finished reading a few new books, but let me let me give you a couple of classics that I think everyone in our field should read and why they should read them. I think everyone should read The Mythical Man-Month by Fred Brooks because he really covers some very profound truths that haven't changed, things like Brooks Law, which is adding programmers to a late project, makes it later. He talks about the structure of teams and how to scale before scaling was big and important and cool. He talks about communication and conceptual integrity and the role of the architect. The other book that I'm going to give, which I hope is different than any book that anyone has ever given you, because it's one of my absolute favourite books and I give them away, is a book called Understanding Comics by Scott McCloud. Comics or graphic novels are an important medium for communication, and when we talk about storytelling and we talk about how to frame information and how to present information, understanding comics is profoundly insightful in terms of how to present, share, show information. A lot of times I think we make things harder than they should be. So when I'm working with executives and some of the clients that I work with personally, when we talk about our epics, we actually will tell stories about the hero's journey and we actually hire comic book artists to help the executives tell their story in a comic form or in a graphic novel form. So I absolutely love understanding comics. I think that that's really a profound book. Of course you mentioned Alex Osterwalder's books, Business Model Generation, Business Model Canvas. Those are fantastic books for Product Managers. I also, just looking at my own bookshelves, of course, Innovation Games for PMs, of course Software Profit Streams because we have to figure out how to create sustainability, but in reality there's so many books that we love and that we share and that we grow together when we're sharing books and I'll add one thing. Please don't only limit your books to technical books. We're humans too. I recently, this week and what I mean recent I mean literally this weekend I was visiting one of my kids in Vermont all the way across the country, and so on the plane ride I finished two books, one was a very profound and deeply written book called Ponyboy. And then another one was a very famous book on a woman protagonist who's successful in the 60s, Lessons in Chemistry, which is a new book that's out, and it was a super fun light read, some interesting lessons of course, because there's always lessons in books, and now if it's okay if I'm not overstepping my boundaries, what would be a book that you'd like me to read? I love to add books to my list.
Ula Ojiaku
Oh my gosh, I didn't know. You are the first guest ever who's twisted this on me, but I tend to read multiple books at a time.
Luke Hohmann
Only two.
Ula Ojiaku
Yeah, so, and I kind of switch, maybe put some on my bedside and you know there's some on my Kindle and in the car, just depending. So I'm reading multiple books at a time, but based on what you've said the one that comes to mind is the new book by Oprah Winfrey and it's titled What Happened to You? Understanding Trauma, because like you said, it's not just about reading technical books and we’re human beings and we find out that people behave probably sometimes in ways that are different to us, and it's not about saying what's wrong with you, because there is a story that we might not have been privy to, you know, in terms of their childhood, how they grew up, which affected their worldview and how they are acting, so things don't just suddenly happen. And the question that we have been asked and we sometimes ask of people, and for me, I'm reading it from a parent's perspective because I understand that even more so that my actions, my choices, they play a huge, you know, part in shaping my children. So it's not saying what's wrong with you? You say, you know, what happened to you? And it traces back to, based on research, because she wrote it with a renowned psychologist, I don't know his field but a renowned psychologist, so neuroscience-based psychological research on human beings, attachment theory and all that, just showing how early childhood experiences, even as early as maybe a few months old, tend to affect people well into adulthood. So that would be my recommendation.
Luke Hohmann
Thank you so much. That's a gift.
Ula Ojiaku
Thank you. You're the first person to ask me. So, my pleasure. So, before we go to the final words, where can the audience find you, because you have a wealth of knowledge, a wealth of experience, and I am sure that people would want to get in touch with you, so how can they do this please?
Luke Hohmann
Yeah, well, they can get me on LinkedIn and they can find me at Applied Frameworks. I tell you, I teach classes that are known to be very profound because we always reserve, myself and the instructors at Applied Frameworks, we have very strong commitments to reserving class time for what we call the parking lot or the ask me anything question, which are many times after I've covered the core material in the class, having the opportunity to really frame how to apply something is really important. So I would definitely encourage people to take one of my classes because you'll not get the material, you'll get the reasons behind the material, which means you can apply it, but you'll also be able to ask us questions and our commitment as a company is you can ask us anything and if we don't know the answer, we'll help you find it. We'll help you find the expert or the person that you need talk to, to help you out and be successful. And then, and I think in terms of final words, I will simply ask people to remember that we get to work in the most amazing field building things for other people and it's joyful work, and we, one of my phrases is you're not doing Agile, if you're not having fun at work, there's something really wrong, there’s something missing, yeah we need to retrospect and we need to improve and we need to reflect and all those important things, absolutely, but we should allow ourselves to experience the joy of serving others and being of service and building things that matter.
Ula Ojiaku
I love the concept of joyful Agile and getting joy in building things that matter, serving people and may I add also working together with amazing people, and for me it’s been a joyful conversation with you, Luke, I really appreciate you making the time, I am definitely richer and more enlightened as a result of this conversation, so thank you so much once more.
Luke Hohmann
Thank you so much for having me here, thank you everyone for listening with us.
Ula Ojiaku
My pleasure. That’s all we have for now. Thanks for listening. If you liked this show, do subscribe at www.agileinnovationleaders.com or your favourite podcast provider. Also share with friends and do leave a review on iTunes. This would help others find this show. I’d also love to hear from you, so please drop me an email at ula@agileinnovationleaders.com Take care and God bless!