Interview with Joe Rainsberger

Joe Rainsberger is a Canadian software development consultant and technology writer known for his contributions to agile development, for which he was awarded the highest honour from the agile community, the Gordon Pask Award in 2005 (its first year of existence). He is the founder of XPDay North America. He is also known for his book, JUnit Recipes : Practical Methods for Programmer Testing. He has been an agile practitioner since 2000, and in this time his articles on agile development have been published by leading programmer's magazines including IBM developerWorks and IEEE Software, for the latter of which he edits the regular "Not Just Coding" column.

Master-class by Joe Rainsberger Value-Driven Product Development. We are glad to present you the interview with Joe.

Later: JB - Joe Rainsberger, KM - Kurek Maciej.

Hello, JB. Or Joe? What is the preferable way?

I don't have a strong preference, so whichever one you like is fine with me.

Fair enough.

So, first of all, nice to meet you. My name is Maciej, and I am an Agile coach at Luxoft. And today, you know, I have a big pleasure to talk to you. To be honest, I met you once, that was in Kiev about two and a half years ago when Mr. Cockburn was conducting the preparation to get certified as a Scrum Master. I was attending that and that was preceding one of the Agile Central Europe conferences or something like that.

That was actually Eastern Europe, I remember now. I’ve spent a bit of time in Alistair's class when my class was done.

Exactly, so I was sitting at one of the desks there.

Oh, nice! Nice to see you again and to get a chance to actually say “Hello” instead of waving from across the room or something.

So I was told that you will be conducting that training called Value-Driven Product Development.

It is going to be an online training, am I right?

Yes, we're doing it. It’s normally a training course that I would do either as one-day or two days. And so we’re going to run it as two half-day sessions online in March.

Awesome.

So my first question is actually driven by the name of the training – “Value-driven product development”. To be honest, when I saw it for the first time, I have suddenly started thinking, “Aha! So this could be abbreviated as VDPD. Yet another buzzword, yet another keyword in my dictionary.” Could you please briefly describe what it is? Should we consider it a framework with the underlying principles like scrum or is this something different and brand new?

Well, so the name actually came about in response to the market, deciding that my first name “Product Sashimi” was not very good. I actually launched this course about five or six years ago with the name “Product Sashimi”. And of course, you know, I was trying to have a fun name and was thinking that it would be nice for the audience to hear something different and think, “Oh, Product Sashimi! I kind of understand what that means but what is it really?” We say in Agile that it's a good idea to deliver products incrementally. But for a long time we didn't do a very good job at explaining how to do it. And “Product Sashimi” is my style of exploring and delivering products in an incremental way. And of course “Sashimi” is meant to describe thin slices.

After several years of promoting the idea as “Product Sashimi” I finally decided to listen to the market when they didn't like the name. And so we chose the name “Value-Driven Product Development”, because it sounds like something that most businesses would understand: the idea of exploring products and delivering products by focusing on building the most valuable parts first.

And when I say that, then you could call it an Agile product development, or you could call it incremental product development - I think it's all the same things. “Value-driven” just emphasizes that we're making the decision more based on, “What do we think will provide the most value for our customers?” And not, for example, “What do we think is the easiest part to build first?” Or, “What do we think will be the least expensive part to build first?" and so on. And yes, you're right, whenever you put “driven” in the name of something, that we run the risk of becoming another buzzword, but I'm still open to suggestions on how to improve the name even more. But this is a version two, I guess, of the name so far.

I see.

Let’s focus on the word VALUE for a moment. Value is very subjective. And from my experience, working in small and big companies, I observed that these days there's no one single person who drives the product vision. Usually this is the group of people, right?

Yes.

And those people have different agendas hence the value is very subjective to them. Basing on your experience as a consultant, what would you say are the crucial considerations to bear in mind when defining value in a particular scenario?

Right, so, as you say, value is different to different people. So I don't think trying to decide on one widely useful definition of value is a particularly fruitful thing to try to do. I would instead want to say that first, of course, we need to acknowledge that we have a group of people who all have different ideas about what means value to them. And we need to find ways to help them discuss that among themselves.

And I know that sounds like kind of a cop-out answer, an answer that isn't really an answer.

But in a lot of cases it's like this: whenever we have a bunch of people who are disagreeing about the details of something, trying to teach them what they should agree on, never works as well as teaching them how to articulate to each other what do they mean, and giving them ways to focus on what ideas do they have in common, and where are the differences. And so I wouldn't want to suggest anyone: you should focus on this kind of value; like, “Always focus on revenue”, or “Always focus on profit”, or “Always focus on quality”, blah blah blah… I think that would be a mistake. I think that the one thing that we probably all have in common, the one thing that makes us interested in any kind of Agile concept in the first place, is that whatever it is that we mean by value - we want to earn more of that value sooner. And this, to me, I think, is the overall philosophical value point, that makes Agile different from other approaches. It’s that in Agile software development whatever we mean by value, we know that we want to earn the value sooner.

So that usually translates to something like having cash in our bank accounts sooner. But it could translate to having more revenue sooner, even if it costs us more; or having more profits sooner, even if it's less revenue. Or eliminating more technical risks sooner, even if that delays revenue. But whatever it is that we have, whichever way that we define value, we probably want to get more of it sooner, instead of making bigger investments to get more value later.

I think, that is really the big difference. So, value-driven product development… I think you can decide for yourself, what kind of value you mean. But our overall goal is: invest less and generate more value sooner, instead of investing more and generating more value over the longer term.

Ok, unlike in the waterfall?

What makes waterfall - waterfall? It is that we are more willing to invest earlier and get our return later. Because we think that will maximize our return over the longer period: three to five years, or five to 10 years.

Whereas, I think, what makes Agile agile is that we have more of a cash flow mindset. I don't mean literally cash necessarily. But we have more of the cash flow mindset: we want the flow of value to start sooner. Because we think that getting that value sooner will make it easier for us to continue to invest over the longer time, instead of saving up all our money investing up-front and then hoping it will pay off in five years.

And those are just two very fundamental different ways in investing. It's the same whether you're investing in software projects, or you’re investing in real estate, or investing in stocks, or investing in anything else. You have to decide which is more important. “Can I invest more cash now and I can wait longer to get that cash back? In which case I might want to make a more waterfall approach. Or do I need to invest less now, so that I can generate more value immediately, so that I have more to invest over time?” That's more of an incremental or an Agile approach.

And value-driven product development assumes that you want the cash flow mindset instead of the long-term investing mindset.

That’s very interesting.

So is it really feasible these days to define the product vision once at the early stage or, if you say that most teams deliver software in an iterative and incremental fashion, then defining product vision is meant to be a repetitive exercise?

Absolutely! I think that the same question comes up in many-many aspects of Agile Software Development: in software design, in product design, in product vision, in company vision. When we talk about working incrementally and iteratively, sometimes people get the impression that we mean, “Don't think up-front.” They have an impression that we're giving them the advice: not to plan up-front but to make it up as you go. And I think that's a big mistake. And even when we take an incremental and iterative approach to product vision, for example, we still need a place to start - we still need to agree as a group.

We think right now, based on everything we know at this moment, our product vision should be this. And we do need to decide on something. We do need to be able to start by saying: “We have our vision of a product - that’s like this. And this is our first good guess at the direction we want to go, based, perhaps, on our understanding of where the market wants us to go.”

Actually, even though I say that, maybe that's a mistake.

Sometimes we make product vision decisions based on market information, and sometimes we make product vision decisions based on one person's idea about how to change the world. Like, it can be the Steve Jobs approach for you, or it could be the market research approach. I don't care which one. I think we've seen great examples of both. So for me the important thing is that we don't choose a product vision and then pretend we can never change it. Of course, we don't want to change the product vision every 10 days. We do need to have some place to start; we do need to make a decision up-front. “We're generally going to move in this direction, as long as we're always prepared to change our vision when we learn something significant and new that changes our approach.” I think we'll be getting mistakes when we learn something, everyone agrees that we should change our vision, but we don't change it. And I think that's one of the fundamental differences between the long-term investment approach and the cash flow approach. In the long term investment approach we are discouraged from changing our visions, from changing our big ideas, even if we all agree that we should change them. Whereas in the cash flow approach if we learn something; like if our market is much different than we expected, or if one of our competitors does something that they are going to beat us by four months to the market; if we learn this, then the cash flow investing mindset makes it easier for us to decide: “Yes, we’ll change our vision.” Even though changing our vision is expensive, and changing our vision is scary, and changing our vision is disruptive - the cash flow mindset says: “We didn't invest all our money. You still can invest some. Yes, changing our vision is going to be a little bit expensive. But we didn't invest so much up-front to stop us from doing it.”

I think that's the big difference.

Yes, we need the product vision, and the product vision can be complicated if there's a lot of people involved. The important point for me is that we don't pretend we can never change that decision. We have to remain open to changing that decision when we agree that something significant has changed.

Okay, okay.

And speaking of building product vision. I tend to think about teams who deliver products or software, whatever it is these days, through the lenses of three roles Scrum defines: product owner, scrum master and the team. In your opinion, who should be involved in building that vision?

Should it be delegated to Product Owner – the person who represents business needs? Or other Scrum team members should participate too? JB

I don’t know if I have an overall rule for that. I would say that when we’re looking at product vision, and I want to be clear, when we talk about product vision, I think we're talking mostly about the market side of the equation, and not so much about the technical one. Actually, now that I say that I think it is wrong. Even though we are talking about very high level ideas, obviously we need marketing. We need to know what our market is. We need some understanding of why people would pay us money to do this. “Are they going to buy this product now or they're going to buy something from us later? And is this product going to allow us to build some credibility in the market?” and so on.

But we still need to have some technical input because we don't want to make the classic mistake of developing a vision that has no chance, that has no technical feasibility, right?

Right.

We have to at least know that it's possible to build it. We also have to know that it’s not going to cost us 50 billion euro to build something to make 5 billion euro. So, I think, instead of thinking about who needs to be involved, which roles, I think it's important that we have a tendency - most people have a tendency - to underestimate the value of having technical input in the vision.

I think everyone’s very clear that we need marketing input, we need sales input, and we maybe even need some management input because we need some idea of, “Will it take us five years to do this? Will it take us one year to do this? Can we do something in three months?” But we still need some technical input, some senior technical people typically, whose job is to tell us, “Wait a minute, guys, we don't know how to do this at all.” Or, “Wait a minute, guys, the technology hasn't been invented to do this” or, “Wait a minute, we don't know how to do this well; we would have to hire some brand new people or we need to invest a year in research and development to see if it's possible.” I think we run the risk of missing these questions, if we don't involve technical people in the vision.

As far as how many of each type, should it be 80 percent marketing and 20 percent technical? I don't know. I think that it depends a lot on the kind of a project. Is it a Steve Jobs kind of project where we're building a product that's brand new, that's never existed before? Or are we building the next evolution of some kind of service that we offer? Or are we building the next evolution of some kind of product that we've offered before? Then I think it's different, if it's an evolutionary change, maybe we already know the technical issues very well and we are going to focus on how it will change the market and whether people will be willing to pay us so much more for this tiny evolutionary change.

If we're trying to build a next iPad, or we’re trying to build the next phone, or we’re trying to build the next new thing that nobody can live without, then, perhaps, we do need somebody to tell us, “This is not technically possible at all, this needs some significant technological breakthrough” before we even think about what kind of market could possibly buy it.

I don't know what that would be. But I don't think that if we're building, you know, the house of the future, then that's going to be more technical input in the vision stage than it will be the marketing input. Because we’re probably building technologies that don't exist yet.

I think it sounds like the power of feedback: the feedback should be early and constant all the time.

Yeah, so I think that, you know, we don't have to decide up-front who should be in the room. If we can pay attention to what we're doing and talk about what we've decided so far and keep asking ourselves the question “What might we be missing?”

Whenever I'm doing any of this kind of work I always feel like we're missing something. I'm always looking for what could we be missing. It might sound like a great product, but we haven't verified that anyone actually wants to buy it. Or it could be: this sounds like an amazing vision, but we haven't verified whether we can actually build it. Or it could be: this sounds like a compelling product, but we don't know who might already be building it. I think that maybe the most important skill to have in that room is keeping our eyes and ears open for “What could we be missing?” You know, “What would have to happen for all the wonderful conversations in this room to be completely meaningless?” This is one of the standard business strategy tricks.

You know, “What could we possibly build that would put ourselves out of business?” And maybe we should build that? So let’s always have that skill to think about “What could we possibly be missing?” “This seems too easy, what we're doing, what are we missing?” And that could come from marketing, technical, sales, it could come from anywhere.

So does it mean that your role, if you are invited to work for a company to help them build a brand new product or change a current product, which is already on the market, does it mean your role boils down to asking them good questions?

Absolutely yes.

And in fact that's one of the things that… one of the surprising things - that's happened for me in the last five years in my work – is, more often, clients are telling me and saying to other people about me, you know, “He really knows how to ask good questions.”

I didn't set out to build this skill. I think I just started asking… I think I asked a lot of bad questions. And then I slowly learned how to ask better questions. And I think that's may be the most valuable thing that I could do for my clients, is to listen carefully and ask a really good question at the right time.

On the one hand it's good when a consultant gives their clients the feeling of magic. It makes you valuable.

On the other hand I wish I understood the skill better, so that it would be easier to teach to other people. I have done some small workshops on asking powerful questions. I've had some interviews with people talking about this. But I don't understand it enough to really be able to teach people how to ask great questions, although I can give them some examples.

And whenever I do training like Value-Driven Product Development or even when I do training about coaching, there's always going to be some session or some part of the session which maybe doesn’t answer how to ask great questions but more answers the question , “Are you aware of the problems in the questions you are asking now?”

Yes.

So that might be one of the most common mistakes that coaches make: they want to ask a question. But they also want to give a specific advice. So they just find a way to give advice in a question: “Don't you think you should … blah, blah, blah? Don't you think you should be running a stand-up now? Don't you think you should be running a retrospective?” That's just another way of saying, “You should be running a retrospective.” It’s not really asking a question. It is giving someone advice, but the tone in your voice goes up at the end; it's not the same as asking a question.

I guess that is one of the major differences between the coaching and mentoring. Mentors used to provide answers because they used to be in similar situations before. So they most likely know how to address, how to tackle a particular action rather than asking open-ended questions thereby driving the coachee towards the goal.

Yes. And I like to mix the two because on the one hand I think it's important to ask questions and also to teach. You don't want to force other people down the specific road just because it's a road that was good for you. On the other hand I've heard stories of so-called consultants who all they do was ask. They listen to your problem and then ask, “What do you think you should do?” And then say, “You should do that.” I don't find that particularly valuable either. At some point you do need to share some of your experience, you do need to have experienced these things before, you do need to have some ideas about how it works, you do have some tricks that are valuable. And so I like to make sure to combine this concrete advice along with asking open-ended questions.

I don't know whether you should ask three questions for every piece of concrete advice. I just know that if you only ever ask, “What do you think you should do” - that doesn't provide much value. Some, but not as much. I can write a computer program to do that for me, I don't need me for that. At the same time if you just tell people what to do all the time, they don't develop the skill to think for themselves. So I usually try to do three things:

One is share my experience. This is the mentoring part. Right?

Mhm J

“I’ve been in a situation like this, this is what I did, this was what the result was.” Some of the classic good questions are: “Why do you think you want that? Why do you think that's going to be a good idea to do? Have you thought about this part instead?”

But I also like to give people at least a little hint about why I chose a specific question. I like to say things like that: “I heard you say this, this and this… And that led me to wonder: maybe you invested too much in a specific solution and have not thought about other ways to solve the same problem. That's why I asked you, well, if you were to do this thing that you're thinking about doing, what result, you want, would that give you? And could be that done another way?”

Whenever I do, especially when I do one-on-one coaching sessions, I do like to, at least once, give the other person a little bit of a look, a little bit of a hint about why I chose certain questions. I'm hoping that they'll then think about that question themselves next time. I'm teaching them to coach themselves. And if that also helps them coach other people well, then the more you coach other people, the better you are usually at coaching yourself also.

Yes. I fully agree.

And these are the kinds of questions that you come up in value-driven product development. It's very common that everyone in the room thinks that we need to build a specific product. And I find that it's very important for one person in the room to keep asking: “What benefits are we really trying to deliver? Could we give it to people another way and, especially, can we give it to them in a different way and sooner? Instead of building these 27 features, is there something else that we could do, that will give them 60 percent of the value, that we can build in 20 percent of the time?” Because again, that goes back to our cash flow mindset: the idea of how can we deliver more value with less investment, so that future investment will cost less money.

That sounds to me like Pareto Principle 80/20 you mentioned a number of times already. And that makes me wonder whether apart from product backlog, which usually focuses on or is an artifact that applies that rule in practice, are there any other artifacts you would suggest to use, or, you would say, are a must-have, basing on experience, besides product backlog?

Yeah, in fact, one of the funny things about value-driven product development is that one of the most common tools that we teach in Agile product development - the user story - is actually something that I… I don't say I ignore it, but I push it to the side a little bit.

One of the things that make value-driven product development different is that I don't focus on user stories. So the concept of a product backlog isn't as much important to me. I don't organize it quite the same way. For me it's even more important, strangely enough, to jump straight to individual scenarios.

Hmm.

So this is already a little bit of a sneak preview of what we’ll talk about in the course. I’ve seen a lot of teams that spend a lot of time worrying about getting the product backlog right. Either they're worrying about, “What exactly should be the items in my product backlog? How do I write a story correctly?” They also worry about prioritizing everything in their backlog, so that if there are, you know, 180 items, that they feel confident that the 97th one is really higher priority than the 107th one. So some of the principles in value-driven product development: move away from this. Because I think that sometimes teams get stuck in details that are less important. And I'd rather have them focus their energy on the more immediate things that they're planning to do, the things that they’re planning to do over the next few weeks and few months, and less about the details of what will happen in six months to a year. And so the product backlog itself, as Scrum describes it, - I tend not to worry about having product backlog more than a few months in advance. It's okay to me that the product backlog consists of 10 to 20 things that we think we're going to do next, and then a bucket of stuff that we might do later. This is something that I first learned from Mary Poppendieck, one of the first simple tricks that I learnt from her that always seems to help and never seems to cause a problem.

It is to go into a new project, a new company, if they have one of these very detailed backlogs, to take the bottom eighty percent of the backlog and throw it away.

I often do this also with the bug databases if they have a bug database. I ask them to sort all their bugs by age: how long ago was it recorded. And I tell them to throw away the oldest eighty percent of their bugs. To stop tracking them; it doesn't matter. No one's ever going to fix them; no one's ever going to talk about them again. If it's a real problem somebody will record it and it goes up to the top of the list.

So this is another example of that Pareto principal at work. I'm not sure that the Pareto principal is the most important thing in the world. It might not even be true, but it seems to be helpful in a lot of cases. I find that if we assume that it's possible to get a lot of value from a small part of the work and we try to figure out that small part first - good things seem to happen.

So I think that the artifacts that I focus on are more a small diagram that shows the overall picture of the system. Not from the point of view of “how we design it”, but from the point of view of “what does it need to do”, combined with a database of scenarios.

Yes…

And what's missing in the middle - the use of the thing that we usually call the user stories. I tend to think of the user stories more as a way to guide us to think about those scenarios, instead of an artifact that we should keep over long periods of time. And if you go back and read the early writings about user stories from people like Alistair Cockburn and Ron Jeffries and some of the people that I’ve learned from, that's what they used to say. They used to say that a user story is a ticket for a conversation. It's a reminder to have a discussion. It's not supposed to be an artifact for itself. The artifact is more meant just to be a reminder: “Hey, here’s some stuff that we think the system needs to do, why do we think that generated value again? Oh, yes I remember. Now how are we really going to build it? OK, let's talk about that.”

I find that writing the scenarios helps us think about those details much better than keeping a list of two-sentences user stories in the spreadsheets.

For me a diagram that shows how the big pieces of the system fit together, and a database of scenarios are more important than having an ordered list of user stories the way that the Scrum product backlog is usually described.

So, are you saying that all models are wrong and some are useful?

I’d say that all the time, yes J

Okay.

The others say that we should learn from mistakes in fail-safe environments and we should do that by experimenting. And this is where my next question comes.

So I believe you’ve been through a number of engagements with different clients - small and big companies - what's the ratio between experiments and proven practices, while building products? You were talking about, you know, conducting sessions either with individuals or the whole groups - do you, as a facilitator, control the ratio between letting them experiment and failing, and following the practices that you know would work?

Oh, what's interesting is that they are proven practices to me but experiments to them.

Okay.

That's an important thing to keep in mind. If they've never done it before then it's an experiment for them, even if it’s a proven practice for me. So, for example, the style, my way of running meetings is a proven practice to me, but it's an experiment to them. Because they are accustomed to running meetings in a certain way.

You know, we've seen in a number of times where everyone gets together in a room and then someone just starts talking, usually it's someone who has some authority in the room - it's a manager or a senior manager, or a technical lead - somebody expected to be an authority. They just start talking. And 8 minutes goes by, 10 minutes goes by, 12 minutes goes by; it’s unclear to me why they're talking, what they're talking about and how it relates to the objective of the meeting. Now to me it's a proven practice to run meetings starting with a very clear statement of the objective of the meeting. But for them that's an experiment, because they're used to this way of doing things. So the kind of engagement that I do with clients, I think, determines how much I push practices into. If I’m only there for two or three days, and the stated objective with the client is to teach a specific skill, then what I do is I create an environment where they can learn the skill by experimentation. But the engagement itself consists of me teaching a proven practice to them. It could be test driven development, it could be value driven product development, it could be getting things done. These to me are proven good practices, and so my job in that two or three days is to teach those specific techniques to them. The way that I teach them might involve some experimentation, but it also will involve some “just me telling them things”, “me justifying them” and “them trying it.”

If I’m in a longer engagement, spending several weeks or several months, then, of course, I don't want to try to push a bunch of techniques at the very beginning. It's very important for me to spend time really observing what they do, figuring out what's good about it, what's bad about it, figuring out what worries me and what doesn't worry me, and then slowly telling them: “Here are the things I'm worried about. Do they worry you as well?” And when we find areas where I'm worried and they're worried, then we can very quickly have conversations about, “What do you think we should do about it?” If they don't seem to have any good ideas, then I will suggest them. And this is more of the fail-safe experimentation kind of, you know, “letting them fail” approach. It's very hard to do that in two or three days. I can give them a few hours, where I give them an idea, I give them a task, I let them fail, I show them how I would do it, we discuss what's good about my way, what's good about their way, and then together we develop what we think will be a better practice for them.

But it's not the same kind of significant failsafe experimentation that I can do if I can spend a few months with them. And say, “Well, let's try your way for a while, let’s try my way for a while, and we'll talk about the difference.” Or where I spend the first two weeks only watching them and really asking a lot of questions. “Why do you do it this way? Why do you do it that way? Do you find this valuable? Yes or no? What do you find valuable about it?” That, of course, stops me from just coming in, giving a bunch of advice, fifty percent of which is wrong because I didn't pay attention to what they're really doing, walking away; and I didn't make anything better. I changed a bunch of things but I didn’t make anything better.

Yes. OK.

From your experience what is the most frequent obstacle that you face when working with companies when it comes to driving product development by value? Is there anything like that?

I think the single biggest obstacle is that a lot of high-level product decisions and even some of the medium level product decisions have already been made by people who are not in the room now. It's very common that you have something you're trying to build, I'm asking you a bunch of good questions about why are you trying to build it that way, and it only takes a couple of hours for us to reach the point where you look at me and I look at you and we agree we don't understand why we’re building it. We don't know the marketing reasons for it. And we look at each other and say: “You know, it would probably be a bad idea to build this. We should build something else first. And then use that to get information about whether we should build the thing that you've described at the beginning.” And the problem is… the obstacle that I face is that the people who made those decisions made them several months ago. In a bunch of other meetings they've already spent a lot of money to make those decisions. If you and I now question those decisions then we have the sunk cost fallacy problem. There are a bunch of people that will just say: well, we already spent a lot of money making those decisions, we're going to go forward with those decisions even if now we maybe think it's a mistake. That, I think, is the single biggest obstacle. That either we feel forced to live with the decisions other people made, even when we think it's a bad idea, or the people who made those decisions, and made them several months ago, are no longer available because they're working on the next product, the next product line. And that limits the amount of value we can get from the value-driven product developments techniques. We can still use them to help us understand very well the product that we're building. And that helps us build the product incrementally and iteratively. And that has many benefits. But it encourages us to do more like small safe waterfalls than doing a truly incremental product. So, we have the benefit that we have technical feedback, which helps us find our mistakes sooner. We have the benefit that we can make some decisions about “do this part of the product before that part of the product”. But it doesn't really give us the chance to have the big-big benefits from value-driven product development.

I was at the clients in Sweden about a year ago. And I was doing a version of this course with about 65 people. All from the same company.

Huge number!

Yes, it was a huge number. We’ve spent two days and I taught them all the ideas, so they spent a lot of time really exploring the products that they’re building. And it's a typical enterprise environment where we have five or six teams that have already divided a big product into small pieces and they're building the pieces. But those pieces have to go together some way. In the afternoon of the second day I noticed one team - they weren't doing very much. So I sat with them for a little while and asked them to tell me what they were doing and how it was going. And one of the guys on that team really had this worried look on his face. And so I asked him what was going on. And after a few questions he admitted to me that he now thinks his entire product is a bad idea. He thinks now his part of the product is a bad idea and they shouldn’t do it. That it's not actually adding value to the overall product. It's only going to cost money and it's not going to make things better.

And he had a very worried look on his face. Of course there are six people now who are assigned to this team. They've already made the decision that they're going to build this part of the product. And they're starting to agree that it's a bad idea. That's a scary thing. To think, “I was expecting to do this work for the next year and now maybe we shouldn’t do it at all.” I think of this as a huge benefit. Of course it was easy for me to say because this was not my job.

But from the company’s point of view it could save them a lot of money. They could use these people to work on more valuable projects instead of this thing that they were going to work on. And the only reason they're here is because some people, who aren't in the room now, made a decision six months ago or a year ago back, based on that, “In our understanding we have to build six parts” and so they've been waiting for a year to build these six parts. Now they have a team that's allocated to build this part, and maybe the sixth part isn't useful.

It’s a very difficult conversation - to go back to those people and say, “We think we shouldn’t do this at all. Maybe we should do something else.” But to me that's maybe the most valuable part, the single most valuable thing that value-driven product development can do – it is to help us find the parts of the product that we should never build. To help us find the features that we should never build. We don't have to decide now that we’ll never build them. But if we know that these three parts are much more valuable, and we should focus our energy to build those first, then we can delay the decision by three months. Maybe in three months some market change happens, and it tells us that the three months of work that we did is enough investment, it’s generating enough cash, and now we can move in another direction. We don't have to continue to do what we expected to do. When the people who make those decisions make them a year ago and move on to the next products, it limits our ability to move our resources, our people’s time and energy to more valuable products. It becomes more likely that we will do what was decided even when it's no longer such a good idea. That, I think, is the single biggest obstacle.

That happens most often in organizations where the marketing, sales and vision parts of the business are kept separate from the development and delivery part of the business. And so one of the most valuable things I can do is encourage those two parts of the business to come closer together. But it's also a very difficult and expensive thing to do. Because it's still in mainstream culture to keep them separate, although it's becoming more and more common sense to put them together. Especially in large enterprises it's still very common culture to keep them separate. And that means that we can do a better job of building some of the wrong products instead of building only the parts of the product that we know are the right parts. I think for me it is the biggest obstacle.

And it's a big culture change – it’s not just a culture change inside of a company, it's a culture change in business. In the way that we teach people to run software companies, not just software projects.

When I was looking at the description of the training on the page, I noticed some terms like “lost luggage”, “magic wand” and “try to stop me”. Does it mean that we can introduce some elements of play to the way the product is developing?

Absolutely. In fact you can think about the value-driven product development as about JB's style of behavior-driven development. One of the key techniques (for those listening: you will have to join the course to learn what it is) is actually something that feels a lot more like play than it does work. This turns some people off and also makes some people excited. It tries to build, it tries to use some humor to help activate the creative parts of our brain. This is the technique that we use to figure out which parts of the product we should build earlier, and which parts of the product we should build later. And I can say it this way: when I tell the story of how I learned to do it this way, that’s easily the funniest and most fun part of the course. It's a funny story, it's an embarrassing story for me, it's one of those stories of learning a lesson the hard way. But I'll never forget it. And that's why I teach it to other people. It’s a little bit the parental feeling of helping people from learning from your mistakes. This is a really big mistake I've made. I was lucky to make it with the right people in the room. Somebody taught me something amazing. They've made it really fun. And that's what I'm teaching to the people who attend this course.

I believe in the idea that if you can include some humor then it makes the information stickier in the brain, easier to remember, easier to recall. And so things like “lost luggage” and “the magic wand”, these are fun little ways to help us remember the various techniques that go into value-driven product development.

When I use the “magic wand”, I literally do say “Thhhhhoooww”. And I wave the wand. It's a stupid thing that helps people relax more and, I think, get more out of the exercise. If they're having fun then they're probably going to remember more.

To be honest I was googling for those names because I wanted to find a description and better understand those concepts. However, I failed. I didn't find any description. Does it mean that you created them?

Yes and no. I didn’t develop the “lost luggage” technique. But I noticed that the technique that we use to help explain to an airline what our luggage looks like, so that they can find it, happens to be a similar technique that we can use to help technical people and business people better understand the details of a feature. So what might be new is connecting those two ideas together and thinking of it as lost luggage. And that's the name that I used to help me remember what to do when I'm in a situation where a programmer and a product owner are disagreeing about what a feature should be.

So the techniques are not new. I learned them; somebody taught them to me. I think what might be new is the way that I use them. Because I learned them in a different context and noticed that they could be useful in writing scenarios, they can be useful in exploring products. The “magic wand” is a generic technique that everybody knows. They just don't know that it is a magic wand. It's really asking people the question. If you tell me, “I want ‘X’”, I’ll say, “Okay, if you had ‘X’, what would you do with it?” So I wave my magic wand and I say “Thhhhhoooww”. “Congratulations! You now have “X”! What are you going to do with it?” Than you tell me, “Well I'm going use it to get ‘Y’.” And then I say “Thhhhhoooww”. Okay, magic wand again. “Congratulations! You now have ‘Y’, what are you going to do with that?” This is just the “five whys” questions.

You can use it for the root cause analysis, you can use it for any number of things. I just like calling it a “magic wand” technique because it easier for me to remember. And it makes a little bit more fun. Using it in how to explore a product is the part that may be not new - I didn't invent it - but it's still not common technique. And again, it’s a proven practice for me but it's new for them.

Great.

So that makes me think that the training would be even more promising and playful than I initially thought.

I hope so. You know, it's going to be hard work. I warn people that value-driven product development is hard work, it's difficult work, sometimes it's frustrating work. And that's the reason why I want to try to add as much fun into it as I can. Because otherwise it's just a lot of stress. I mean, deciding which products to build, deciding which features to build is a very stressful thing to do.

Fred Brooks in his famous essay “No silver bullet”, I think it's in that essay, he said that deciding what to build is the single most difficult thing that we do in software.

I mean, it really is. That’s when you start spending money. The moment that you start making a decision about what to build, that's the moment that you have started spending money on the project. The clock is now ticking. You need revenue to justify your investment. And so it's stressful. It's stressful to figure out what a product vision is. It's stressful to figure out what does it really mean, when we say we want the product to do “X”. And so we need to make it fun. If we don't make it fun we're going to die of heart attacks and I don't want that. Nobody wants that. I try to add some fun. But not only to make the ideas easier to remember, but also to remind us to relax a little bit while we do this stressful work.

That was actually the last question I had.

So thank you very much for your time. That was a very interesting experience for me to find out a little bit about building a product and about value-driven product development. And I really look forward to participating in the training.

Well, thanks very much for asking these questions and listening to my long-winded answers. I look forward to seeing and hearing from and working with some people in March. I think we’ll have a lot of fun.

Yes, I’m looking forward to this. Thank you.

Thank you!