Intro to Product Thinking: Building Human-Centric Tools

Intro

Julian Wood: Welcome to GOTO Unscripted, we're here at the wonderful Amsterdam and as part of the GOTO conference. And I'm here joined by the lovely Flavia Naezer. Welcome to GOTO Unscripted, how are you today?

Flavia Naezer: My pleasure, Julian, I'm fine.

Julian Wood: Excellent.

Flavia Naezer: Welcome to Amsterdam.

Julian Wood: Thank you very much. You're the local, I'm not the local. So tell us, you're doing a talk today which is part product and part tech. What's your history and how you've become this excellent person to talk about product and the human part of tech?

Flavia Naezer: Let me think a bit. So I have a tech background, I think I studied computer science, and for the better part of 10 years of my first career I wrote a lot of code and with this Java, of course, then.

Julian Wood: You don't have to apologize, Java is good.

Flavia Naezer: Java is great. So, whenever I wrote code I always wanted to find out for whom am I writing this code, who does it help, who does it add value. And I think this kind of thinking brought me very close to design and design thinking and why we are doing this. So my career shifted from writing code to knowing why we are doing something like that. And I think I stumbled across this role called the product owner which combines these two and actually things it makes about building products and I think that's where I get energy from. So making a product, knowing for whom you make it, what value does it bring and, of course, combining my study tech to build a product. It's so amazing to be in tech all these years, how much it has changed, how much you can do with it. So it's a fascinating field to be in. Another love of mine is design and I love working with designers. I love working with user research and combining all of that to bring a product which is valuable. It's amazing. That's the talk about how we combine for a very tech product, internal developer platform. You wouldn't directly think product thinking but it applies and it applies really useful, so I'm excited.

Julian Wood: I think that's actually very important. I think people building internal developer platforms when it's not your direct customer face often forget about the customer component of it and forget that any platform that's even targeted at developers is targeted for humans to use. To use, it's got to be easy, it's got to be accessible. I like the idea of having your product focus but from a people-centric perspective even if it's not for something internal. Is that something that you see as a blocker that our companies are building internal tools or internal things and they're not considering the product part of it enough?

Flavia Naezer: I don't see it enough that I don't know if it's a blocker, but if I look at teams who are building tooling for engineers, for instance, they don't necessarily share the product mindset. I don't know why it is but I think that's changing because last year I came across this white paper written by Abi Noda and Nicole about DevEx and the three core dimensions of DevEx where they actually put the engineer in the equation. I think software productivity has been focused on tools for a long time from Agile to DevOps and now you see, okay, we can optimize software all we want but also the happiness of the developer, the happiness of the engineer plays a huge role in how they face work and how they think about work. And I think the moment you bring the human in the equation that's where product thinking I think automatically enters. I remember the first days of UX, UX used to be similar, user experience. So I compare it a bit to that and I think now the paradigm is shifting to also thinking about the user for internal facing products and I'm very happy about it. It feels like the early days of UX to me, the DevEx movement.

Building What Customers Need, Not Just Cool Tech

Julian Wood: Then when engineers are building applications and whether all services and whether they are intern or they are external, a lot of organizations think we're building for the customer, we're going to work back from the customer from what they need ,but I know in practicality that doesn't really often happen. So what sort of advice would you give engineers and builders or even other product owners to properly understand their customers and what they actually need to build rather than just playing with the cool toys?

Flavia Naezer: I think it's very easy to play with toys because the toys are really cool I think. So I think get out of the building, talk to the people. I think I wouldn't start building anything without knowing whom you're building for and what they want. So that's what we did last year at NN. So when I came in and got the assignments there was nothing in terms of research on what is the current engineering experience. So we just gathered a bunch of engineers, they were in the same building, you didn't even have to get out of it, but we talked to them and engineers really love to share about the cool toys but also the friction, the pain points. And actually, we didn't write code for a very long time. We talked to engineers, we talked to, we found out, okay, does this resonate, did some surveys and coding came much later. But I think that's the product thinking toolbox, so it's broader, you can do a discovery phase and say that it's discovery and say that you're exploring, it's big, and come to a challenge on what you want to solve and we explored I think six-ish months. The only code we wrote was to see if Backstage could be an option. So we did some spikes and see, okay, is this kind of technology that could help us with the program? But I think that's the code we wrote. And we have engineers in the team and engineers can do this too, they can go out and talk to other engineers. Yeah, it's a different way of thinking and I think we bring that. So our team, to give you a little bit of idea, is placed in the infrastructure department of the company which is not used to going outside and asking, so that makes it interesting. And the boss, he even welcomed us saying that we were different and I think he knows very well why we are different and how we are different, and this is what we bring. So all we brought was user research, this is what people think, this is what they say about your services. You don't need to like it, but this is what they say about it. What do you think about it? Can we improve something there? And I think that mindset is a very nice mindset to have. It's not easy to do, but if you start with the user, they're just people, just talk.

Julian Wood: Do people challenge maybe the time it takes to do that? Because you want to be a product team, people are working in an Agile or DevOps kind of way and they're having, you know, two-week, three-week sprints, one-week sprints, and want to be really iterative to get things out. If you had to say to someone, "Can we pause for a month or two to do our user research, I can imagine some product owners or people thinking, "Oh, that's crazy." So, how do you, sort of, cross that challenge?

Recommended talk: Combining Product Thinking & Spotify’s Backstage • Flavia Naezer & Vijai Ramcharan • GOTO 2024

Flavia Naezer: That's a nice one. I think in a corporation, if you say it like that, you will be challenged because the idea is to start sprinting. For me, you can start the first sprint only if you know what you want to be doing, and we actually didn't know that. So we brought it as we wanted to first understand in this huge complex product for whom we want to solve what we are going to solve, and the only way we can do it is to run a pilot to see what needs and pain points there were. We, of course, have a very big strategy we want to also build on, so talking. So we sold it as we are doing discovery and exploring the product. The model I used for this is the Double Diamond from the Design Council, and it at least, I think, talks about the phases before building software. And I think having a model like that and talking about it helps because it's also something people don't recognize that sprints can come later, but you have to understand what you have to build.

Julian Wood: So what are some of those phases that people should be thinking about before they're doing the discovery process?

Flavia Naezer: So the Double Diamond is something I use a lot for communication and the left diamond talks about doing the right thing and it has a diverging and a converging phase. So it talks about discovery which is divergent, basically everything goes. Every day is different, your product is growing and growing and growing. And then you say, "Hey, that's something we want to solve." So then you start converging to a point and building to a vision. And those phases can take anywhere between a couple of weeks to a couple of months. And I think there are very good artifacts you can use to communicate how that phase is going because that's what management also is looking for. Okay, you can't keep saying for six months that you have been exploring. What we did is to show, have reports, and have results published. This is what we interviewed, this is what came out of it, this is a service blueprint, this is how it looks like, you know, and it's huge, we need to slice it. And so actually talking about artifacts in the design phase and coaching a bit on that helps talk about it. And we actually started sprinting last month, so last month was our first sprint. And then we said, "Hey, okay, now we are going to sprint because now we know what we want to build." And I think Scrum is awesome in knowing and in sprinting to software delivery.

Cadence in Exploration and Design

Julian Wood: But I suppose even in the discovery phase if organizations are used to having a two-week cadence and maybe they've got reporting mechanisms and things around that, you could still, sort of, not sprint in the way of software coding, but your design decisions and whether you are meeting with 5 of your potential customers or 10 your customers the first week and building documentation I think you could probably follow that methodology of the time-based thing but you're doing your design phase not, you know, sprinting onto the keyboard straight away.

Flavia Naezer: Correct. You do have a cadence in exploration and design, only it's difficult because working software is always great to show, great to demo. So you have to come up with artifacts to communicate and they are there and you have to really find them, but user research is something which tends to take time. If you want to do a DevEx survey you are two months down. And yeah, you can say, okay, results will be in two months but you can do other stuff. So the beauty of the Double Diamond is that you don't need to wait for something to finish, you can start a lot of things at the same time. You can actually be diverse and depend on how good your team is in exploration. You can send everybody out on different parts and have them come together and communicate. We didn't communicate cadences. I think what we did is we said we are exploring and knowing what to build the product, and every month we had this reporting to management. And somehow I think management, so this is also having big top-down support at our company, so they know this is good for the company. And we have been building products at this company for a long time now so they also know who we are and what we are capable of. I think that also helps that they trust us with building the product.

Julian Wood: What sort of, kind of, personality skills or tools and tricks even that's not software development tools but sort of personal skills that can developers, or architects, or people learn or understand to make this more successful? Because I think the bigger picture as well is that you can spend a few months doing your design, but then ultimately you know you're going to build the right thing. You can start really quickly and then iterate really quickly, but if you land up on the cycle of building the wrong thing, it's going to, you know, potentially take a longer time. So what are the sort of, you know, personal skills that people can learn to make them better at this?

Flavia Naezer: I think what it starts with is don't be afraid of failure. I think this is...

Julian Wood: So that's very similar in the, sort of, Agile way of being able to iterate quickly, okay.

Flavia Naezer: Absolutely. So that's why it fits really well with Agile. I think design is a discipline, which validates and invalidates hypotheses every time. And if you know that, Scrum has that too, inspect and adapt. So actually, they have a similar language, but you need people who can deal with uncertainty and the unknown. So if you have people in the team who are not afraid of failing or not afraid of not knowing something, you have a great team in place. And typically, you try out something, you make a prototype whether it's a paper prototype, and say, "Hey, would you like to have this?" And if the answer is no then you don't need to build it, right? So that kind of personality you're looking for, so people who not only write code but can also draw a simple prototype and show it and say, "Hey, is this okay?" "It's not okay." So the whole trial and error and finding out what actually works and resonates, and basically having a feedback loop with your user I think that's...I think Amazon calls it customer obsession. It is an obsession and it's an obsession with the customer. And the moment you forget the customer, it doesn't work. The customer always needs to be in the loop. And as a large corporation like NN, it's very easy to forget about the customer, so it feels sometimes like building products for the stakeholders because they are always there telling you what needs to be built, what's priority.

Julian Wood: And they may have the money which is going to pay for it. So...

Flavia Naezer: And they have the money and it's great. And I think Marty Cagan makes such a good point here, you have to build products that customers love and work for the business. So it needs to work for both. Only one voice is a bit higher at big companies, and I think my job is to have the other voice very high and to have a team which appreciates that.

Recommended talk: Lizard Optimization • Gojko Adzic & Dave Farley • GOTO 2024

Applying Jobs-to-Be-Done in Practice

Julian Wood: I think it's very powerful understanding building things for the right customers, but I know, and Simon Wardley is a speaker at this conference as well and the whole Wardley mapping thing where you literally start at the very end and you know what is the ultimate user need. And the ultimate user need is never to, you know, use a website or to access this, it's I want information, I want to book a ticket, or I want to use the Canonica thing of making a cup of tea, or that kind of thing. And that's the actual use case and try to work everything back from that. So I mean, where should people start in terms of how they define what the customer problem is or is that also part of the research?

Flavia Naezer: So I'm going to say a controversial thing now because some people like this framework and some don't, but Jobs-to-be-Done framework is something I use a lot, and knowing what's the job to be done is very hard because it's not always intuitive what you think it is. So for an IDP, the job to be done is not saving time. That's not the job, but actually getting to and defining Jobs-to-be-Done and actually uncovering that, that would be the starting point for me. And once you have them clear, once you have a product challenge formulated you can learn how to slice it and make it small to fit in sprints and all of that. But Jobs-to-be-Done framework is a very good mental model. And I think designers and user researchers know it, in my team, engineers know it too because we are a product team and everybody works together, so they also have learned to appreciate the design frameworks better.

Julian Wood: So you're building a developer portal using Backstage in a very, very common platform. What would the job to be done for implementing backstage be just so people can have an example of, you know, understanding from the tech side to the people side of what the actual job to be done would be?

Flavia Naezer: That's a nice question. So we came up with two jobs to be done, so people, so we have engineers in product teams who are building customer-facing products. We are an insurance company, we are a bank. So they joined the company to build an app or they joined the company to make some kick-ass website to do an insurance flow. They're not looking at doing heavy lifting or the cognitive load that comes with all infrastructure. And so that was a simple job to be done. They wanted to use the latest technologies to build customer-facing products which bring value. That's what the engineers were looking for.

The second job to be done was we didn't know where to find people. So it's like, which software do we have and who is behind it? So, basic search, that was another job to be done. I know there are a lot of engineers at this company, but I don't know who they are, whether they are good, why they chose a certain technology. So community and knowledge sharing, that's another one which comes across a lot with interviews because we have a siloed organization. We have a bank revenue insurer, we have pensions. And people, of course, don't speak to each other, they don't even need to meet each other, but there is a lot of goodness built at one place which can be used by another. And actually, engineers are very curious about that. So they kept saying, "I don't know if there is an API already for this at the company. Where can I find it?" So those two, the exploration part, I think that comes naturally with engineering, they were Google or...but at the company, so having a Google-like service at the company, that was one of the jobs they were looking to get done and to save time as well. And the second one was to, don't worry me about all this other stuff like me building software which is for our customers. So those two we could boil down.

Julian Wood: Excellent. Thank you for that because I think sometimes the jobs to be done from an external customer can be quite clear but the internal customer, because it's internal and isn't, you know, necessarily revenue-generating. This kind of thing can be complicated to understand. So I appreciate that. I think one of the issues I see sometimes with internal teams is they build platforms and they don't quite realize that they're actually products. And so they don't treat them like products, and so products need, you know, marketing, and sales, and engineering, and all the kind of functions as a product, but you know, people will build a platform and just expect developers to come and use it or they will force developers to come and use it. So how does one evolve the product thinking for it to be successful within an organization?

Flavia Naezer: That's a great question. I think we are an example of an organization which doesn't do it well. And when you talk to engineers they tell you that, like most of the engineers, they feel that the central IT is only pushing them services, which they don't know and not caring about the use cases they want to use it for and not advising them properly. And most often, they go around it. So the phenomenon when you see that a lot of people are not actually using your platform but going around it and building stuff because like you said, software is so great these days. There are so many options to do something with that. So this is a very general phenomenon happening everywhere. So the moment you see that people are going around it, I think you as a product team need to ask again, "Hey, how are you solving this problem?" Because apparently I'm offering you a service which can solve this but you're not using my service, so you're using something else." I think this is the brilliance, Jobs-to-be-Done people will get their job done with or without you. And if the platform teams are curious to their users and ask them how are they actually fixing that problem instead of asking why aren't you using my product, how are they fixing their problem, they will tell you what they are using and how you could have made your products resonate with them.

Julian Wood: Maybe that's the question, when people even go to the Jobs-to-be-Done framework, it starts the question, well, how would they do the job without the tool that I'm building to see if they can, you know...

Flavia Naezer: Exactly, that would be where I would start. Because this company, it's a huge company and people have built up all kinds of castles around the platform to solve their problems. Each of our departments has a lot of their own platform-like services on the platform, and that's, I think, a very natural way of working if you don't have product thinking.

Recommended talk: Platform Strategy • Gregor Hohpe & James Lewis • GOTO 2024

Julian Wood: I think someone I've worked with closely, Gregor Hohpe, he's done his enterprise integration patterns, done a lot of work. And he's written a book recently about platforms and products, and one of the things he spoke about which I liked is if people aren't using your product in ways you didn't expect then you didn't actually design your product correctly, that your product needs...sorry, your platform needs to be flexible enough that people can build on top of it and do crazy things that you never expected. So, how does one design for that when a platform can be, you know, very broad? You know, the more niche and more lockdown it is the less people are going to be able to do it. So how do you have, sort of, the expanse of thinking to make a platform that's useful for broader things?

Flavia Naezer: I think Gregor Hohpe is wonderful in how he thinks about platforms. I think my team is a big fan of Gregor. I think you need to have a combination of both. So you should have an open thing where people can build on and do their thing and experiment and try out things, but also build some journeys and specific experiences for specific people because not everybody is looking to explore around your platform.

Julian Wood: Because there are particular jobs to be done.

Flavia Naezer: There are particular jobs to be done. So we have, for instance, in the last five-ish years, I have quite an agreement on how we want to build our web applications. So the JavaScript, Reacts, Serverless Stack, I mean, when we have that agreement, why would you want every engineer to go through what's possible on AWS? We already knew that, and if you can deliver that as an experience and as a specific journey and keep the platform open, then you have a combination impossible because you'll never serve all the users, but at least try to serve some. That's, I think, the key point here. With the IDP, I'm also not looking upfront to serve all of NN engineers, that's a huge group. And not everybody is... We are local, we have all the platforms you can think of on this planet. I think we have it in-house. But my intention is to deliver specific experiences for specific jobs to be done. And how specific you make it, how better the user experience will be and that's why people will use your product. And I think platform design should be able to accommodate this. So it should be composable, modular, and all those great things, but the product can be very narrow and very tailor-made for a persona or a customer segment.

Julian Wood: I like that distinction between having an open platform which you then build particular products on to solve different jobs to be done. I think companies often create, you know, I think they need to create the one platform that their whole organization is going to run on. And my thinking is when we, you know, work in an Agile way and, you know, even microservices and everything needs just fast iteration as you said before, probably your organization needs multiple platforms that maybe multiple different teams will look after for jobs to be done. So what's your thinking on, you know, having one big platform to rule them all versus, you know, multiple platforms?

Flavia Naezer: I think after looking at my company I don't have the notion that we can have one platform. I think we should have fewer than we have today. That could be good for...

Julian Wood: And actually, there's always too much.

Flavia Naezer: There's always too much, and we have too much and I think that's a strategy we are going for that we want to standardize on what we want to do. So I think we'll have less flavors on things we have and some good decisions being made, but yes, these platforms will be there and they can remain next to each other. And basically, for me, it starts with whom are you serving and what other use cases are they looking for? And if you have that in mind, it's okay if you have a private cloud, public cloud, or low code and more stuff behind it. But that mindset of who are the teams using your platform and how are they using it, knowing that and bringing that I think is important to consider next to all the finances. And that's considered anyway, so how much does it cost to host this? That part is in the equation. The other one not so much. So I think that makes a complete picture for me.

Recommended talk: Building Modern Apps with Serverless & Feature Flags • Jessica Cregg & Julian Wood • GOTO 2022

The Art in Software

Julian Wood: Interesting. With your background being in art and design, I think that's a fascinating mix because there you have these ideas of software developers being, you know, very, very technical, very unarty, very, you know, unless you're doing front-end, design very un-designy. And I'm probably the world's worst artist. I can basically draw stick figures, but I think in software development there's a very creative path to it and a very much, you know, design thinking, and creative, and artistic kind of things that may be expressed in code rather than in pictures, or poetry, or that kind of thing. So how does one encourage the software industry to bring in more of this sort of artistic element to delight people?

Flavia Naezer: I think it's a great segue. I have been an artist all my life and I've also studied computer engineering.There was nothing in the study which felt that it was not creative. I think computers is an extremely creative profession and I see that in lots of people. How can I solve this problem in a creative way? I think in large companies, the engineers are just seen as people who code and not people who actually solve a business problem. So if you can also bring the IT teams closer to the business, and that's where I have been very privileged in my career to be in those small innovation-like projects where you just had three people and the business problem was very well known. Oh, we want a different way of doing car insurance, and then it's like, oh, we can maybe use serverless this and that. So that's where the creativity comes from, where you can design the solution for somebody's needs. That's where it becomes creative. So I would encourage engineers to understand the business problem and actually say come up with three, four ways of solving that problem. And I think then you have a very creative team who is not... I think Marty Cagan calls it the feature team. So you don't want to have a feature team, you want to have an empowered team. And an empowered team comes with which can make its own solutions. And I think that's where creativity is at its max in software.

And the second suggestion would be to have a designer in the team. I think the designers are creative people, and it's a kind of energy that it brings to the team. And they are always organizing team activities, and those team activities are extremely creative. And the software engineers feel, oh, maybe that's too much for me, but when they go there they really have fun. So having different people in the team, the diversity of design and software engineering together I think is hugely creative. I don't think I can be in a team anymore without a designer and without engineers together, so I really like that combination and that's a boost of creativity always, yeah.

Julian Wood: I suppose that becomes not as a tech design but an organizational design of co-locating people with different skill sets together in maybe not necessarily an immediate team but even within a smaller organization or something to be able to help each other out to have different skill sets to solve a problem.

Flavia Naezer: Absolutely, absolutely. I think at NN we made a start with a template, a team template which looks like this having UX design and engineering the same thing with products so that that triad... Actually having a dedicated designer and engineers, yeah, that makes a huge difference to team dynamics and the conversations that happen. There's a lot of art. We have gone to so many museums in the last months. It's awesome. And the other way round as well, so designers, our designer was actually excited to do some JavaScript, and he wanted to build a website. So it works also the other way round because it's contagious the other way round as well. And I think it's creativity that binds these two very big disciplines together and I think the purpose of solving something, a business problem or a user problem, yeah, that's huge.

Julian Wood: I suppose it ties back to the very beginning and even your talk that the closer your engineers get to the customers or what they're building for it they're going to have more empathy for what they need and it's going to be more creative rather than just being a, sort of, feature factory of writing, you know, functions in code.

Flavia Naezer: Absolutely, absolutely.

The Impact of Generative AI on Creative Problem-Solving for Engineers

Julian Wood: And with the whole explosion of, you know, AI and generative AI, what are your thoughts? I know it's a broad question on, you know, the creative part of that, and problem-solving for engineers, and you know, what do you sort of think in the future when you think of all the crazy gen AI stuff that's been on us recently?

Flavia Naezer: I think it's fantastic. I see it as a co-pilot. Anything which adds, so it's like you have another person in the team and that's AI. And you can use it in so many ways. I don't think there goes a day where we haven't used some of the gen AI features, whether it's writing code. I think engineers use it a lot in the team, the designers as well, and also together, yeah. I think it's such a boost to what we can do and, of course, there are downsides, and we have to be careful, and the bias, and all of that. But in terms of additives, how much it adds to our skills, yeah, I think it's fantastic. Having a reviewer next to me to read my code, it's...

Julian Wood: Well, certainly explain my code the way I write it. Something needs to help.

Flavia Naezer: And our user researcher used it for generating summaries because they do like these long interviews with engineers, and they have to relay it back and look back and push forward. I mean, I think you guys have an idea of how much effort it takes to make a decent summary. So at least having a summary made for you is a great start and then you edit it so that even the user research time goes down a bit. So, yeah, absolutely fantastic.

Julian Wood: Excellent. Well, Flavia, thanks so much for your time. I think this is one of the ways that GOTO as a conference is so good because it's not just all about the technology, and, you know, writing code, and all this kind of thing, but they're very much a people aspect. And, yeah, your thoughts and ideas on the creativity part of it I think is inspiring and I think will, you know, move our industry forward so that we can even create cooler things for people, so thank you very much.

Flavia Naezer: Thanks a lot, Julian, appreciate it.