Build the Right Product, with Gojko Adzic

Alexis:

Hey, Gojko, glad to have you here. How are you and can you tell us a little bit more about you and your background?

Gojko:

Hey, wonderful to be on the show. I'm a developer, currently working on two products. I've worked as a consultant, I wrote some books — effectively, I really like coding. And since I started on a developer job 20-something years ago, I realized that in order to do good coding, I have to learn how to do good testing, how to do good product management and a bunch of other things. My interests seem to be going around in a spiral: I tend to learn a lot about doing some coding thing, and then that leads me to making more complex product so I need to learn more about how to test it well. That leads me to figuring out how do I reduce the amount of things I need to do, so I need to learn more about product management, and then it gives me more capacity to do more development and start new products. It's kind of going on in a spiral, and every time I touch one of these subjects, I end up writing a book about it — I guess, a way of doing a memory dump so I can free more random access memory for myself.

Alexis:

I love that. I love the way you are describing that. And I love the fact that it's a virtuous spiral that is leading to more books, because I already enjoyed reading your books. Of course, one of those books that I'm using a lot is Impact Mapping. Can you tell us a little bit more about what led you to that book? And probably what is impact mapping?

Gojko:

What led me to the book is I was CTO of a company that basically ran into a wall and spent all the money that it could spend. And it did that in the worst possible time — kind of 2008, 2009 — when it was almost impossible to get any good investment, and we ran out of money. I was a minority investor in that company as well, so I didn't take any salary. And I was left almost without the money to pay the rent next month. That's how stupid I was. And we were incredibly, incredibly efficient in terms of software production. It was by far the best team I've ever worked with, even till today, in terms of technical competence. We were doing things that became buzzwords later before they had a name — continuous delivery before people knew the buzzword, cloud-based deployments back then, almost 100% automated testing. The code quality was wonderful, but we delivered no value.

Because we were really efficient, we efficiently burned through our budgets. As CTO of that company, I was really embarrassed when it came to the point that I had to admit to myself what we're doing is wrong. Up until then I really focused on the technical quality of the product. I realized that there's a lot more, and as a technical person, I need to engage a lot more with product people — not in a sense of not trusting them, but in a sense of being able to more efficiently challenge their ideas and help them make better decisions, and help facilitate a discussion between technology and product. That led me to a lot of research and trying to figure out what we did wrong. I started studying the emerging discipline of product management in software and how people deal with assumptions. That's roughly around the time when the Lean Startup came out, and the software world really started awakening to how much we waste on stupid work and stupid products.

One of the really wonderful things about software for me is it's almost like magic. You literally turn ideas into products. You sit and drink coffee and turn something you have in the back of your head with some magic words — we don't use Abracadabra, we use const value, and for each, and things like that — but that's magic, create products out of nothing. But at the same time, if what we build is missing the point, then you can spend a ton of cash and it just vaporizes. The research I did to figure out what we did wrong led me to learn about a technique called Effect Mapping that the IT agency in Sweden was developing. I just saw how incredibly wonderful that is for facilitation. The reference book was in Swedish — there was an English version, but it wasn't that popular. I have very high respect for those people, but I don't think the book was accessible to the average software developer or the average software stakeholder. So I decided to write a book that would make this technique more approachable to people, especially doing iterative software delivery. That's basically the story of the book.

Alexis:

Excellent. I love the story. People always love to talk about their successes and how great they were, but it's always interesting to learn about something that didn't really work well in the end, and what you can learn from that.

Gojko:

Yeah. I think there's so much wasted potential today in what we do as an industry. If you look at how much software gets produced and how much energy and effort people spend building these things, and then you look at the results — most of it is just mediocre, most of it doesn't go anywhere, a lot of it is kind of pointless. And it's very difficult to even know in the short term if what we're delivering makes sense or not.

One of the best examples: a few years ago there was a project at the British Broadcasting Corporation — a personalization project for the video player — that was shut down after a few years when they spent something like 75 million pounds. It was shut down because it delivered no value. Because this is publicly funded, the National Audit Office got involved to figure out how can you possibly spend so much money on software and deliver no value. The conclusion was: they could do it because it was Agile. Every month what they delivered, somebody was evaluating to say, 'Is this good? Is it bad? Is it valuable?' And the stakeholders were deluding themselves. Somebody in the company told some developers, 'I want this feature.' They delivered the feature and asked, 'Is it valuable?' They said, 'Well, yeah, that's what I asked you to do.' It's completely pointless — running around in circles with no way to actually understand if we're going in the right direction.

I think Impact Mapping is the easiest solution I found to that problem. It's not the best solution; there are probably better solutions out there, but they're very academic, very difficult to apply. The most popular process for goal-driven requirements engineering in academia is something called i*. The basic book on i* is six or seven hundred pages. It might provide a wonderfully precise way of measuring value, but I don't think any of the people I ever worked with would have time for it. Impact Mapping you can explain in 10–15 minutes to business stakeholders, and one afternoon later they will already have an impact map. That's why I love the practice — it's fast, collaborative, and really helps people solve an actual problem.

Alexis:

Can you explain impact mapping in a few minutes for us?

Gojko:

Absolutely. Impact mapping is a visualization technique that helps developers, business stakeholders, product representatives, analysts, UX people — people from different backgrounds — have a really good conversation on how the proposed deliverables connect to value, and how do we know we're going in the right direction. It helps people visualize the big picture for what needs to be achieved and creates a good way of measuring whether we're going in the right direction.

Impact mapping does that by connecting business goals through impacts — changes to the user's or customer's behavior — to the deliverables. It's this middle layer that helps us measure change in the short term. Behavior changes are observable on a shorter timescale. So if we change some software and people start staying longer on the website, or they interact better with their friends, or they can administer Linux systems easier, or create larger server farms faster, then we're delivering value. Behavior change can be measured in the short term, with a trial population of users. It provides a leading indicator of value. That's why it's so important.

Michael Jackson — the consultant architect, not the singer — wrote in his book on Problem Frames, probably 20+ years ago, that one of the biggest problems in software delivery is creating a connection between the problem machine and the solution machine. Impact mapping creates a connection between the problem world and the solution world through these impacts and behavior changes, allows us to measure that what we're doing makes sense, and allows us to focus on solving problems instead of just delivering solutions.

Alexis:

That sounds really easy said this way. And I think it's exactly why the approach is so useful — once you start asking yourself the questions, it really helps you connect the impact you want to achieve with the solution you want to build.

Gojko:

One of the books I really love — I read it a few years ago and I'm sorry I've not discovered it longer ago — is The 4 Disciplines of Execution. For people that have been doing good product management or doing delivery in a good way, there's nothing revolutionary new in the book, but they've explained things so well it's amazing. They boil down the difference between organizations that are excellent at executing their plans and those that are not, into four big differences.

The first discipline is focus on the wildly important — keep your eyes on the ball. Impact mapping helps with that, because you have this one goal at the center of the map. I've worked with organizations where once we start creating an impact map and have 50–60 ideas in a backlog connected to a single impact, and the first two epics deliver the impact, then we can just say, 'Look, we don't have to do the other 48. We focused on the goal, not on delivering the solution. We've delivered the results, so let's move on.'

The second is focus on leading metrics of value. Every organization can very easily measure at the end if an initiative succeeded or failed — six months after you finish you'll know. But those measurements are irrelevant for knowing what you should do next week. If you only measure the results six months later, like the BBC iPlayer project, four years later you wasted 75 million pounds — that's game over. We need leading indicators of value. Impact mapping provides this glue layer with the impacts that we can start measuring against in the short term. There's a wonderful story from Mark Schwartz in The Art of Business Value about a project at US Immigration Services where they looked at how many cases a human caseworker can process per day. That's a leading indicator of value. Every time they delivered a piece of software, they measured if humans were processing more cases per day. If yes, we're delivering value; if not, what we delivered is incomplete or pointless.

The third discipline is to create a team scoreboard — a way for the team that delivers to know whether they're going in the right direction, not having to wait on external feedback. They have a wonderful quote: 'If you're not keeping score, you're just practicing, you're not playing.' For a lot of organizations, we throw some software against the wall, we have no idea if it delivers any value or not. There's wonderful research from Microsoft by Ronny Kohavi where about a third of initiatives actually moved the numbers in the right direction, about a third had no statistical impact, and about a third actually damaged the numbers they were supposed to improve. Microsoft is a pretty good software development company, and they don't get things always right — because the business people are not clairvoyant.

The fourth discipline is creating a good cadence of accountability — reviewing the plans as we're going along very frequently, and being honest about whether we're delivering value or not. Impact mapping really helps connect all these things together.

You said it was easy. I think there's a nice distinction we need to start making between simple and easy. Impact mapping is simple — we can explain it in 15 minutes. I don't think it's incredibly easy to do, but it's much easier to do than a lot of other very complex bureaucratic things.

Alexis:

Yeah, that's true. It's simple to understand, it can be hard to get to a map that you really like. The thing is, it's easy to start — you can have something really fast, it will not be perfect, but if you accept that you will keep that map and continue to improve it, you have something you can work on. It really helps with prioritization.

Gojko:

One of the things that helped me a lot was reading How to Measure Anything by Douglas Hubbard. He talks about how lots of people discount metrics that are not perfect because they don't totally eliminate uncertainty. He says good metrics don't necessarily need to eliminate uncertainty — that's really difficult — but good metrics help reduce uncertainty. Impact mapping is one of these things where it will reduce uncertainty, and the more you do it, the more it will reduce uncertainty.

Alexis:

When we scheduled the call, you told me that you were available before a certain time in the day, because after that you were programming. I'm very interested in collaboration and in close collaboration like pair programming. Is it something that you are always doing, pair programming? Or is it for a specific product you're working on?

Gojko:

I work on two products at the moment. One is relatively successful and more stable — we've been developing it since 2013. There are two people working on that product: me and a colleague, David. We pretty much pair program all the time on it because that allows us to share the knowledge of what's going on, create a better product, keep each other honest, and not cut corners. It genuinely leads to much better design, because we have two pairs of eyes looking at something instead of one. We developed this product so that it stands on its own — it doesn't require almost any support. That allows me to travel around when there's no Corona and the planes are flying, and it allows David to do his own things in his time.

It's very important for us that the quality of the product allows us to work at a sustainable pace. Because there's only two of us, we cannot spend time fielding customer support calls or fixing bugs. So what comes out has to be really, really good. Pair programming is absolutely critical for that. Having said that, I honestly enjoy programming more on my own. Programming is one of the best things I can do to lift my spirits up. Pair programming can be brutal — you're always having to explain everything you're doing. I find I can't get really immersed in the problem, can't get into flow, if I'm pair programming. From a product development perspective, it's the right thing to do; from an enjoyment perspective, I also like spending a long period of time on my own, listening to music and quietly being immersed in a problem.

The other product I'm building is a very young one — I literally launched it commercially less than six months ago, in October. It launched as a beta in April last year. It's a video editing tool for people who are not video editing professionals and want to very quickly create a video from assets such as images or screenshots. For developers and techie people in particular it's really good, because it allows you to convert a Markdown file into a video, which means you can have video under version control. It helped me a lot doing stuff for the previous product — that's how I came up with the idea. Because there are only two of us, we have to do programming, support, sales, product management. One of the things I ended up doing was creating videos for users to learn how to use the product. Every time we changed something small on the screen, I had to re-record everything again. Doing a five-minute demo video took me two or three hours.

So I started looking for ways to automate that. I could automatically compose screenshots into video and even integrate with text-to-speech engines that have improved significantly over the last five or six years. They can do English better than I can — I can't get rid of my accent. Basically you get a Markdown document, you compile it, and it gives you a video. Then I realized, when I automated this for the other thing, there's a product here. So I extracted that into a separate product and launched it. For that, I'm programming on my own, and I enjoy that immensely. I can spend 10 hours immersed in a problem and not notice how much time has passed. If I work on my own, I enjoy it a lot more — but pair programming creates a better product.

Alexis:

This is excellent. So the first product is MindMup, right?

Gojko:

Yes, the first product is MindMup. It's a mind mapping tool mostly used by schools and universities. We have some project management cases and people using it for describing testing plans and outlining books and writing, but it's mostly used in educational settings.

Alexis:

And the second one is Narakeet?

Gojko:

The second one is Narakeet. Yes, exactly. Thank you very much for investigating so much.

Alexis:

I'm really excited about Narakeet because I wanted to have a short video to explain something. And now that I know that I can even just create a slide in Google Slides and start from there, I'm really excited about it.

Gojko:

Thank you very much. It started as a bunch of shell scripts actually to get everything edited. I have this flaw in my mind where if I see something that I do five times, because I'm lazy in a good way, I cannot resist the urge to automate it. This thing actually started as a shell script and then evolved into a nice web service for people.

Alexis:

I have a question for you. When we are in close collaboration with someone, it's sometimes a little bit difficult to get things across in the right way. How do you deal with potential conflict? How do you deal with not being on the same page when you work so closely with people?

Gojko:

I have two techniques I tend to apply to resolve situations like that. One — I don't know who I stole this idea from, but I think I stole it from Michael Bolton, the tester, not the singer — is that it's much easier for people to complain than to tell you what they want. So if I'm working with people and I can't really get them to say what they actually want, I throw something I know they're going to complain about. I propose something idiotic, and then we get to a good conversation that actually makes sense.

The other technique that really helps me clarify things is to offer realistic examples. Examples of how something is supposed to work, examples of how we might want to use something, are concrete enough for people to really understand that there's an additional case here, or we've not covered everything, or we need to discuss something in a better way. Examples are a wonderful technique. This goes back to Jerry Weinberg's work on exploring requirements from 1989, or even longer — giving people something concrete that everybody can agree on. In a complex organization that delivers a product, you have people from lots of different backgrounds, and they all use different sources of truth and different forms of explaining information. UX designers use wireframes, developers use code, testers use testing scripts, business people use PowerPoints. It's really difficult for all of them to agree on anything. But everybody can talk about realistic examples.

Alexis:

Excellent. Is this the root idea that led to writing the book Specification by Example?

Gojko:

I think so, yeah. Spec by Example came out of a slightly different journey. I was working for a company where they had lots of database developers who only looked at Oracle PL/SQL code, and application developers who looked at Java back then, and business analysts who wrote long documents that nobody was reading. I was really trying to figure out how do we avoid the long testing cycles, and how do we avoid getting stuck in something that we deliver where at the end it turns out it was the wrong thing. That led me to discover Fit and FitNesse around that time. I started thinking about it from a perspective of test automation, but I realized there's so much more to this — it's actually a good communication technique. Test automation really becomes secondary once you have a good understanding.

As I told you earlier, once I remove a bottleneck with me doing code, I realize something else is a bottleneck. In that case, testing was the bottleneck, so I had to learn how to do testing. That led me to this whole idea of what was back then example-driven development or acceptance test-driven development. Behavior-driven development as a phrase didn't exist yet. I think Dan North came up with that phrase around the same time. When XP became popular in the early 2000s, developers were the first to jump on the train, and lots of organizations removed the bottleneck from development. Then they all realized: well, the next bottleneck is testing. As Jerry Weinberg says, once you solve your number-one problem, your number-two problem gets a promotion.

Alexis:

Yeah, it's excellent. I love the idea of looking at the whole process and looking at the bottlenecks. You remove the first bottleneck on development, you have a bottleneck on testing. You solve the bottleneck on delivery. Then you realize that you are not delivering the right product. And you go back to the beginning saying, 'Okay, what is the missing link between the users and the value they want and the definition of the product itself?'

Gojko:

Yeah. I think it's not cyclical, I think it's an upward going spiral. You solve one problem and then it takes you to another problem. Our industry is very cyclical, but the cycles are quite long. If you look at what's happening now in the technical infrastructure space, in essence we're almost back to the time of mainframes. In the 70s and early 80s, before the PC revolution, people were renting CPU cycles from mainframes with timeshares. Now you have people renting CPU cycles from Amazon, Google or Microsoft, either using virtual machines or serverless functions. It's a much better mainframe and much more accessible mainframe, but it's timeshare — we're coming back to that.

Really interesting: after this timeshare, there's going to be the new equivalent to the PC revolution where we go back to client-server software in some new way. My best guess is it's going to be client-server software on very small devices like IoT. We're going to end up in really silly situations and some wonderful situations. There was an outage at Amazon in the US East 1 region a few months ago — Kinesis brought down a bunch of other services. There were people locked out of their homes because they had smart locks that were talking to the Amazon cloud. That's ridiculous. So after the mainframe, we're going to go back to smarter clients. The cycles are slow and people don't really notice that much.

Alexis:

Yeah. During the PC revolution people were mocking the IBM person who said we will probably need five computers in the world. People were mocking that, but from a big mainframe perspective, we are probably on our way to have five big computers in the world.

Gojko:

There are three computers, maybe four, that really matter. I don't know enough about the Asian market. We have Amazon, Microsoft, and Google. Unfortunately, IBM missed the game. It's incredible how IBM totally missed mobile and the web and the cloud. Oracle is trying to build their own cloud, but I don't know anybody who's using that. You effectively have three computers that matter — and maybe Alibaba in China, I'm not sure about that market. We're coming back to three or four computers effectively, and everybody else having dumb terminals that connect to that.

Alexis:

Yeah. And the smart computer at the edge — that's exactly that edge revolution. The example you mentioned about not being able to go back to your home: that's exactly what you don't want when you have a car. The intelligence should be in the car, and some of the data should be in the car, because you want the car to be able to brake or find its way without needing to even connect to the network.

Gojko:

Things are so connected that it's ridiculous now. Two or three years ago, Amazon S3 went down for a couple of hours and it took down half of the internet with it — Reddit and a bunch of other services. Everything is connected to everything else now. That's amazing, because anywhere you go in the world you carry all the world's knowledge in your pocket. But because everything is connected to everything else, a crucial service going down for a couple of hours might mean cars stop working — and that's ridiculous.

The reason I mention this: I think we're having the same type of cycles in the software development world as well. We unlock one bottleneck as a community and that changes the context, and then we go and unlock another bottleneck. At some point it comes back. So I fully expect at some point that programming will become the bottleneck again, and then we'll have to come up with much, much better techniques for programming or better languages or better ways of doing things — whether that's because everybody settled on JavaScript, the worst possible language you can think of in terms of language design but incredibly productive, runs everywhere. Now we have these monstrosities like TypeScript trying to fix it, and WebAssembly trying to allow compilation of other things. Maybe when it comes back to that, we'll have better languages finally to work that run everywhere.

It's a cyclical thing. It's worth reading stuff that happened in the previous cycle. When I was trying to figure out how to improve the developer-testing cooperation at this large company, I was reading stuff people were writing about in the 80s and 70s. There's lots of good material there. People today chase the current fad and always look at whatever next shiny thing gets invented. Software industry is not really old, but it's already gone through a couple of these cycles. It's really worth looking at what people were writing about in the previous cycle to figure out what ideas can we take from that and apply in the new context.

Alexis:

Yeah, I agree. If you look at Frederick Brooks or Melvin Conway, you can see those things — oh yeah, they exactly describe the problem I have now, and it was 40 or 50 years ago.

Gojko:

Fred Brooks said the most difficult problem in software is deciding exactly what to build. Look at where most people are now, or at least people I have worked with as a consultant. The bottleneck is not in programming, the bottleneck is not in testing, the bottleneck is in product management for a lot of people. So we came back to the most difficult thing being deciding what to build.

Alexis:

Exactly. It's really an interesting conversation. I'm really grateful you accepted to join the podcast today, Gojko. Is there anything else you want to share today?

Gojko:

Well, I don't know. Let's leave it at this, I think. It was a really enjoyable talk. Thank you very much for inviting me.

Alexis:

With great pleasure. Thank you, Gojko.

Thank you for listening to this episode of Le Podcast. Go to blog-alexis.monville.com for the references mentioned in the episode, and to find more help to increase your impact and satisfaction at work. Drop a comment or an email with your feedback, or just to say hello. Until next time, to find better ways of changing your team.