In this episode of Semaphore Uncut, we talk to Gojko Adzic, specialist in agile and lean quality improvement. We talk about how to make truly valuable software products: addressing real needs rather than all requests and establishing quick feedback loops by observing behavior change. Gojko also shares how he has kept his passion for software alive. We hear how he made space to learn and experiment and how he guards his autonomy.
Gojko is a frequent speaker at software development conferences. He is also the author of Specification by Example and other books.
Key takeaways:
- A developer-customer communication anti-pattern
- Solve for needs, not features
- Behavior change: a rapid feedback loop
- Data over opinion
- Books for budding product designers
- Keeping the passion alive
- The joy of autonomy
- Even ‘failed’ experiments produce learning
Listen to our entire conversation above, and check out my favorite parts in the episode highlights!
You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.
Edited transcript
Darko (00:02): Hello and welcome to Semaphore Uncut, a podcast for Developers about building great products. Today, I’m excited to welcome Gojko Adzic. Gojko, thank you so much for joining us. Feel free to go ahead and introduce yourself.
Gojko: I’m Gojko; I mostly develop software these days. I just launched a new product literally 10 days ago. I’ve been developing software professionally for 20 years. For the last seven or eight years, I’ve been mostly building my own products. Before that, I was a consultant, worked with lots of very large investment banks, large telecoms companies. I helped them design tests, and develop better products. When I was a consultant, I specialized in Agile and Lean quality. Everything from testing to product management and bridging the communication gap between developers and other roles. I think that’s kind of my niche.
I was always approaching that from kind of a developer perspective. Still, that journey has taken me on to learn a lot more about things that happen as part of the software process, not just development. And I wrote many books about that. Probably the most popular one is Spec by Example. Some other books I wrote, Impact Mapping, Bridging The Communication Gap, Humans vs. Computers. My last book, Running Serverless, is about deploying to serverless platforms that got published about a year and a half ago.
A developer-customer communication anti-pattern
Darko (02:01): I saw you speaking at several conferences, and there are lots of recordings on YouTube that our listeners can check out, and there are, of course, the books, you kind of gave the intro to this of bridging the gap. Can you share, based on all these years thinking about this subject, what advice can you give to developers in terms of communicating to business and how to be more successful in that area?
Gojko: One of the things I guess is interesting that’s happening now is, we’ve become, as an industry, much better at getting people who build to talk more directly to people who need the software. Now we’re a lot better with developers communicating more directly and with fewer indirection levels to customers. But then, we’ve also somehow gotten to the point where almost the customers are expected to provide the solution’s design.
For many organizations, close collaboration between developers and customers means doing whatever the customers told developers they want. And I think that’s very dangerous and that’s very, very wrong. As an industry, we have lots of research and lots of failed projects, and lots of books about why that’s wrong.
Solve for needs, not features
The first thing that I think somebody who’s been a developer and mostly been in a technical role rather than trying to do this communication/analysis role is not to really trust what people tell us they want but to really figure out what do they need. I think there’s a massive difference between what people say they want and what people actually need.
Because we are so much fast in building things in software than in the real world, people think it’s all, “Well, I just want the button here. I just want something there. I just want this kind of report.” And what we end up doing as an industry is delegating the responsibility for solution design to people who are really not solution designers. And that’s one of the core problems I think of so much unsuccessful software and so much mediocre software out there.
So as developers, we really need to understand what people actually need and figure out ways of extracting that information from them. Because I think if they knew how to communicate that, they would have communicated that in the first place. But it’s much, much easier to come up with a shopping list of features than to actually explain what people need.
Behavior change: a rapid feedback loop
Darko (06:10): You also mentioned that you spend a lot of time in product design role. So what are maybe some tips that you could give to developers that can improve in this area?
Gojko: It is probably the best tip I can give to somebody who is just starting out on that position is to focus on behavior changes. That was one of my biggest lessons about 10 years ago, from a horrible failure. We spent an insane amount of money delivering something that, in the end, had no value.
We need to understand where value can potentially come from. And we need to figure out ways of understanding whether that value is being realized or not. And that’s very difficult to do with software because if we look at revenue, if you look at market share if you look at any kind of usual value indicators people will talk about, they come on a very, very delayed cycle. Maybe six months later or a year later you know if it’s a good idea or not.
There are lots and lots of models around value. One of the models that I think is incredibly useful for especially delivering software online, where you can observe and test things sooner, is looking at customers’ or users’ behavior changes. And what I’d suggest to people who are just starting out is for any piece of work you get given or any piece of work you can think about, try and understand what is the expected behavior change out of that. Then you can very soon after you deliver something, try to measure, did that behavior change happen or not? And is it even going the right direction, or is it not going the right direction at all?
Data over opinion
One of the best stories about that, that people can read online is 40 Shades of Blue. 40 Shades of Blue is this famous episode when the head of design at Google a guy called Doug Bowman, came up with the idea to change the color of the links on the Google homepage. The engineers tried to understand why. And they said, “Well, what’s this going to change? How is somebody going to work differently or behave differently as a result of this?” And said, “Well, this color is going to be much more noticeable. So people will click more on the links.”
And Google engineers that night, deployed 40 different shades of blue. You have data. If they had kept [the designer’s favorite] color and expanded it to a hundred percent of the users for a whole year, Google would have lost something like $250 million on people clicking fewer times.
My number one advice for people in that position is to understand what the behavior change is and try to understand how much something should change. Once we have a change, we have a direction, how much do we need to go in that direction? Does this need to be 500% more or 5% more? A completely different solution might be needed. And then when you do stuff, really, really measure whether it’s going that direction or not.
Books for budding product designers
A couple of book references might help dig deeper into this. There’s a lovely book by Mark Schwartz called The Art of Business Value.
Four Disciplines of Execution is a book about organizations that are really, really successful executing their plans: they talk about behavior change as one of the most powerful ways of measuring leading indicators.
Another book I love about this is What Customers Want by Anthony Ulwick. In the book, he explains very nicely why customers can’t really even explain what they want, and when they say what they want, that’s not necessarily true and how to understand what they actually need.
One of my books as well, Impact Mapping here. Impact Mapping is a lightweight visualization technique that uses this idea of behavior changes to connect the deliverables we expect to create with the business goals and then show what’s a good way to roadmap and plan out a larger piece of work.
Keeping the passion alive
Darko (14:47): When reaching a certain level of expertise in the organization that you’re working on. And then what do you do next? Do you get a bit bored? Do you then progress maybe, and maybe read all the books you mentioned and try to progress, help your organization in that area, or what are maybe some alternatives that you could do to light that fire again? Can you maybe share a bit on that?
Gojko: The answer is personal for everybody. I got a bit kind of bored about 10 years ago so. I at least got stuck in corporate politics and stuck in doing over and over the same type of stuff and really stopped being interesting. Yes, you can find interest in other ways of working or find interest in building slightly different things. But for me, the two things that really allowed me to rekindle the fire and find the joy of programming again were working on open source stuff and launching my own products.
If you launch your own products, you can actually work on stuff that’s interesting for you and important for you personally. I strongly recommend anybody who’s stuck in a career and doesn’t really enjoy what they do anymore to make it enjoyable again.
First, we built this mind mapping tool that millions of children use worldwide in schoolwork, and we didn’t set out to build a product for children. We set out to build something completely different, but on the way, we discovered one thing, we discovered another, things change, and that’s really interesting, it’s very dynamic.
The joy of autonomy
And building products for yourself means there’s nobody to tell you that something’s not possible. Nobody to tell you that something’s not allowed. It’s really up to you to do these things, and I find immense joy in doing things like that. And I think anybody who’s bored at their work, maybe should try something like that. I know quitting to do your own stuff is a very high-risk thing, so maybe don’t quit immediately, but start it as a side thing. Start it as an open-source thing, find some ways to build things that are interesting for you, and play with interesting technology, and you will be able to find the passion again.
I think we realized as long as we focus directly on consumers where individual contribution or an individual user value is relatively low, we can say no.
So lots of people, especially in the early days of a product, have feature requests. Some of these feature requests make sense, some of these feature requests make no sense at all. If you have a very high value of a single customer, then that customer can insist on certain things.
For us, the lucky thing was we were focused on consumers that in average, give us $2.99 a month. So if somebody says, “Oh, I insist you build this otherwise I’m not going to use you.” Well, $2.99 is very easy to give up. Again at the same time, listening to what people really need helps you build a good product and we didn’t set out to build a product for schools, but we ended up building a product for schools. So it was kind of an intersection of something that we felt passionate about and felt where we can make a big impact and people wanted it.
Even ‘failed’ experiments produce learning
Darko (25:46): What you said previously is that you built many things. We can call them failures. We can call them experiments. I would say they’re experiments because you learn a lot along the way. I would say, for the majority of people, you need to have those failed experiments.
Gojko: I think having that kind of learning is really, really important. I think sometimes building a side thing that you know you’re going to throw away allows you to just keep the learning and incorporate it into something else.
Once you have a relatively successful product, big experiments on it, especially technology experiments, tend to be costly. If you start using an experimental database and it turns out it’s bad, then that’s a bit risky. But doing it on a side product is something you can very easily escape from and keep the learning. It’s unfortunate that companies very rarely invest in building learning side projects and side products. One of the things I’ve tried to do in a few places was to deliberately build side products. That would be open source or something where people can experiment.
And that’s also a way to let engineers play with new technology. Where everybody wants to play whatever the corporate technologies today have kind of jumped out a bit of, kind of the super megatrends, but there’s always some new interesting framework or some interesting tool people want to play around with. You never really know what will be important three years from now or five years from now.
Darko (29:45): Gojko, thank you for this interesting discussion. And hopefully, the situation will change, and you can continue doing great talks that you are doing worldwide.
Gojko: Yeah. Thanks very much!
