Sure. I'm a Product Management and UX Consultant right now. I like to coach both those teams into helping them find better processes to make better products. Right now, I feel like we spend a lot of time doing coaching and training for developers but we don't really spend enough time doing it for product managers and UX, in their very new fields. So there's a lot going on in them.
Sure. So when I come to these Agile conferences especially, we have so many talks about building a great culture and learning and a lot of it is geared a lot towards developers or Scrum teams and Agile teams. We have very few tracks that talk about what we're building and why we're building it rather than just how.
What I like to focus on and what I like to do at conferences like these is give people an idea about what you have to go through to actually build a winning product because we can optimize our development teams to be more productive and run faster and work better but if we're just feeding bad ideas into them, you're going to get bad ideas coming out no matter what, no matter how fast you go. Your users won't want it.
I'm very passionate about that front side saying, how can we find out if the market wants this before we spend all this money building it?
Shane: So, how can we?
By a couple different things. I think the first part of it is actually spending time experimenting and testing our ideas and getting them out to market a lot faster. Even teams that do work in Scrum, for example, they're very waterfall with their product approach. I actually call it scrummerfall because it's a weird dichotomy.
They say, "Okay. We're going to practice Scrum." But they don't understand that at the end of every spring, we should be releasing to customers for feedback. Instead, we let all of our backlogs pile up. We let all of our features pile up. We still spend six months building it before we release it to customers.
What we try to do in -- when we do the product management correctly and when we try to test it, we say, "Let's build very small things and concentrate on one feature, concentrate on testing before we even think about features”. Make sure we have enough information from our users and get that out to them as fast as possible. We want to shorten those cycle loops. So that's one part of it.
The second part of it too is making sure that we're approaching what we're building from an analytical mindset. We want to make sure that there's a reason that we're creating something and there's a problem to be solved there and users actually have that problem. We're not making that problem up. We're not biased by our own opinions.
We make sure that users have those problems. We make a hypothesis with it. We have a direction to go in when we're building and we're expecting some kind of outcome. We lay that out before we even get started.
Shane: Starting with the end in mind?
Yes. Crazy concept, right?
3. Crazy concept. “Iterating to learn”?
Yes. So my talk this time was on prototyping, which, I think, is a really neat tool. I did it with my partner, Josh Wexler, who works at the Occom Group. What we try to do is explain to people that you can built a culture of learning by getting fast feedback. One of the best ways to learn is by prototyping.
You sketch out your ideas very quickly and we did five-minute exercises where people sketched an app, showed it to somebody, interviewed them, we taught them proper interviewing techniques, and then got immediate feedback. When you ask the room about, "What did you learn through this?"
They said, "Well, I learned that I was leading the conversation with my customers by accident. I was telling them what they should want instead of them telling me what they need. So through this, I was learning a lot more about what they actually need and if we're building stuff on the right direction. I learned I was designing for iPhone when this person has an Android."
So when you put these things on paper, it's great because you just crumple it up and throw it out if it's bad. But you learn really fast if people are going to like it or not.
Shane: But one of the things that I've heard is that if you're just drawing on paper, it's not real.
Yes. See, it depends on what you want to learn. So you have to learn in stages, right? The first idea of learning is not necessarily -- you're not looking for these really cool interactions when you're drawing on paper. You're making sure that everything is there and the users can kind of use it as you would expect them to.
We talked them through. We say, "Pretend this is an app. We know it's not an app but click on it. What are you thinking? What are you saying?" You can learn a lot through that. You can learn that, "You know what, your copy was way too long." Some people -- you don't have to have perfect copy on paper but people said, "These instructions were too long."
They learned the flow the app was too long in this five-minute session. For one of it, they said, it was about recording a video for patients who are diagnosed with Alzheimer's. So their family can record them and then have their memories on it. So after they've recorded the video, they said, "Oh, there was all these other stuffs afterwards. It was too long. I don't feel like I should use it. I thought I was done."
That type of insight is really invaluable to get as fast as possible at the beginning. Usually, we don't get that kind of information until we spend six months building it and launching it to customers.
Yes. I started working with an IT team last year and I was teaching them continuous improvement. So it wasn't so much product stuff but we were doing the Toyota kata process. We used it to improve Kanban, we used it to improve our processes. I said, "Why don't we do this for products?" because it's the same type of thinking that I've always done with the experimentation and the learning mindset, but it gave it a much better format and a much better grid for doing it.
The way that you apply it with kata is that is that you say, "Where's the goal? Where are we going?" That's something that we don't talk about enough, I think, in product management. So where are we going towards? Where do we want to take the first step to be? Then it allows us to work through an experiment cycle.
Say, what do we want to learn? How are we going to learn it? What are the outcomes that we expect and what did we learn at the end? So you run little small experiments to get you closer to your goal. You're continuously learning about it. So we can use those in products too. You can say, "I want to learn if my customers actually have this problem, how am I going to do it?" You go out and interview 20 people, what do I expect to learn?
I expect to learn if this problem is strong enough to continue, great. What do I do next? I want to learn if this UI is engaging. I'll measure it by this. I'll go out and I'll talk to more people or I'll run a test online, an A-B test. By the end of it, I should have learned this.
When we work that way, we can actually improve our products and make them so much better in these small little steps. Too often, we just say, "We're going to build the future and there's all this unknown space out there that we haven't really engaged in or we don't know enough about to build it."
This allows us to work through that unknown, learn more about it in steps so that we have a better understanding of where we're going. Then we can actually navigate ahead with assurance that we're going in the right direction instead of taking a leap into stuff that we're not sure about.
Shane: Cool. Possibly, this links to the other thing that you mentioned earlier, the learning mindsets.
Yes. Yes. So what I've seen a lot in companies, especially when we get into products, is that sometimes we suffer from a lot of biases, more than often, we suffer from a lot of biases. We have these problems, especially when we are the product the managers or the people in charge of creating the features where we say, "We're the expert. We know what to build. We're going to go out there and just build it."
We get into this do, do, do mentalities where we're constantly acting but we're never actually taking this time to stop and say, "You know what, I'm not sure. I don't know what the answer is. Let me learn about it and actually incorporate in that." So when you start practicing continuous product improvement or continuous improvement, that helps shift people into a habit of just learning.
That learning mindset really separates people from just the executers, who can execute tassk, from the innovators and the people who come up with things that customers actually want and want to buy because they take the time to learn about their customers, to learn what they want and need.
Shane: Melissa, thanks so much for taking the time to talk to InfoQ today. This has been really enlightening. Well, enjoy the rest of the conference.
Thank you very much.