Innovation Week 2017 - Product Discovery Chat

Hello? Hello? Okay, for the people that are... For the people here and the people online... We're gonna start in about five minutes... We're gonna start in about five minutes... Give people a bit of time to... Give people a bit of time to... ...beers and... Five or ten minutes, so take it easy, guys, there. Five or ten minutes, so take it easy, guys, there. Okay, for the people that are... For the people here, for the people here, for the people here, and the people online, we're gonna start in about five minutes, give people a bit of time to come, finish their beers, and five or ten minutes, so take it easy, guys. Five or ten minutes, so take it easy, guys. It's not good, so you can just hold it. So you can just hold it. Okay, for the people that are online, we're going to start in about five minutes, give people a bit of time to come, finish their beers. Five or ten minutes, so take it easy guys there. Five or ten minutes, so take it easy guys there. It's not good, so you can just hold it. So you can just hold it. Okay, for the people that are... For the people here, and the people online... For the people here, and the people online... We're gonna start in about five minutes to come, finish their beers, and... Five or ten minutes, so take it easy, guys, there. Five or ten minutes, so take it easy, guys, there. Hello? Hello? We're gonna start in about five minutes to come, finish their beers, and... Five or ten minutes, so take it easy guys there. Guys, online and here in the room, I think we can get started. See who's there, see if we've got enough chairs. Okay guys, come. Channel members, Alex, Honza, Pavlina, take your seats please. So guys, all I am here in the room, I think we can get started. See who's there, see if we got another chair. We're missing one. Okay guys, come. All members, Alex, Honza, Pavlina, take your seats please. Hello, hello. The Gronzos Shoup. So guys, all I am here in the room, I think we can get started. See who's there, see if we got another chair. We're missing one. Good sticker on your beer at least. Thanks. Okay, so let's get started. So first of all, thank you all for coming. This is the second Product Tank Prague meetup. Who have you attended the kickoff like a month ago? A big thanks to 2Fresh for hosting this event and for getting the food and drinks. And thank you very much Veronica and all the people helping here from 2Fresh. Check them out if you don't know them. They do awesome stuff. Also thank you Tiden Innovatzi. This was actually the reason why we decided to do this meetup in this week. Because it's Tiden Innovatzi here in Czech Republic. And we are partnering with them and they are promoting us as well. So that's great stuff. So for the people that don't know Product Tank Prague. Product Tank Prague was a product tank. is a series of meetups set up by Mind the Product Conference in London and Los Angeles or San Francisco, I'm not completely sure. So they're setting up product tanks in cities around the globe. There is at the moment 50,000 members part of this community in about 100 cities in Prague, across city number 100, which is really cool. And we're planning to host meetups like this almost on a monthly basis with a break during the summer. So check us out. Check us on meetup.com, Productank Prague, where you signed up as well. And check us out on Facebook, where you will continue the discussion, meet some other people, post, ask questions, and get some valuable information. So that's about Productank Prague. Enough about this. And we have planned to be very good. Just me, myself, I'm a product manager at LMC doing labs and mobile application and I'm trying to help companies as well doing product discovery and product management better. That's enough for me. Why we're here tonight is I think most of us are able to build products. We are very capable in doing so and we have the newest technologies and the newest ways and the newest methods how to build products better. We're now doing agile, we have frameworks, we have multiple different Cool technologies to get our product built faster. The issue however is how to decide what you're actually going to build and how are you going to decide what you're going to build next. Building is easy. Deciding what to build, that's the difficult part. I'm using a presentation that was done by Teresa Tortes on producttalk.org. Check them out or check the website out. She's sort of framing product discovery in this particular way. If product discovery is deciding what to build, that means if you do it correctly, if you do product discovery correctly, it should give you the answers faster to a number of questions. Questions are, are we meeting stakeholder needs? So there has been development in the last years. Now we have agile. We are able to show something to stakeholders faster, saying, hella, is this what you want? Is this what's going to make us more business? So to answer this question faster, we should do product discovery well. Are our users able to use it? Is it actually, are we building something or are we trying to build something that the users are actually able to use? This is where human-centered design, UX design, prototyping, all of those new methods and new methods, all of those discovery methods come in. Then, are we actually building something our users want? Here, methods from the last time or the last years, like Lean. are coming in and we are able to put something in the face of the user saying, are you willing to buy this? Or we can do experiments. We can say, we have an idea about a product, this is a fake, like a mock of the product, are you willing to buy it? So we have the technologies and methods there now to do so. Then, are we solving a problem actually users care about? I mean, they're willing to buy, maybe. but is it actually solving a problem the users really, really, really care about? And this is where methods nowadays like jobs to be done, customer activity cycle come in and we are able to find out if it's actually, actually solving the real problem. All with one purpose. Are we at the end working towards a desired outcome? Is actually all those activities of doing user research, putting a prototype in front of a user, is it working towards what is the goal of the company? So here's methods like OKRs or radical focus come in play, where we're trying to say, OK, all the validation we do, all the discovery we do, at the end of the day, we are doing it because we want to make more money and do our business better and build better products. So this is sort of an area where we will be exploring tonight with the panel. what is happening there in their practice, what they have seen used, what they have done themselves, what works, what doesn't work, and hopefully we can learn something from them and we want to learn from you as well. The panel tonight is going to be Honza Habig on that side, product and service builder for Rockaway part of his time and he's running his own project One Proof as well. In the middle... Pavlina Loženska, maybe known from age one as a marketing manager, afterwards Zoot, and now here as a designer of change at Too Fresh, so playing a home game. And here, Alex Michalichova, after Skype and Avast, AVG, but it was AVG, now it's Avast, sorry. And now product manager at Lyftago, and trying to get people from A to B. in the best way possible. I'm inviting you, you'll get mobile phones, I'm inviting you to use Slido for sending some questions to the panel during the conversation. I will try to either answer them during the conversation or in the Q&A after if we still have enough time. So check it out, Slido, and use the hashtag PTPrag. for dropping your question. And I think the panel will decide at the end of the evening who had the most interesting question. And we have some tickets to win there. One is on Thursday there's going to be a very interesting presentation by Sudira Van Goury from Amazon. As a product manager there, she's going to present there. So we've got a ticket for this and we've got a ticket for Fuck Up Night, which is on Thursday as well, I think. That's on Thursday as well. So we got tickets to win, so drop your questions and get a ticket. So that's it for this. I will leave this and then I will move here. Okay, just a quick warm-up question for you, all three of you, just to see if everything works. Honza, you are a big fan of tea, right? Yeah. I mean, yeah. So my... You drink a lot. Are people able to hear the panel members without a microphone? I can shout at him. I need to pass on a microphone for everything because of the streaming. Okay, cool. So as a tea lover, what is the job you hire a cup of tea for? Not a milkshake, but a cup of tea. What is the job you hire it for to do? Nice one. I didn't saw that coming. Well, for me, tea... I hire it for the post, because if you make tea, it needs the right temperature, it needs the right amount, it needs the right time for the infusion, and you have to just steep it at the right time. You can't do this if you do ten other things. The job I hire tea for is to make a pause, stop working, so I have fresh mind after and also the caffeine, you know, that just kicks in and that's great. And then there is a taste and then there is culture. Those are the micro jobs, you know, if you want to speak in JTB stuff. We'll get that later. Okay. Okay. Thank you very much. For Pavlina, a very quick starting question. We all know you still believe in unicorns. If you would be the product manager of a unicorn, what is the one feature or one feature you would either improve or create immediately based on either user feedback or in your own gut feeling? Very quickly. I mean, if you look at... At the unicorn culture you would know that if unicorns fart, they fart glitters. And I believe that we need more glitters in our life. We have made a lot of customer talks and they have proved that sprinkles make everything better, so definitely farting sprinkles. Okay, thank you very much Pavlina. Then a more tricky one for Alex, or maybe not tricky at all actually. When is the last time you used Uber and what is the thing you like most about Uber? Thank you. Actually, it's not that tricky because I love using other products which are similar to ours. And what I liked about it, probably I love the UX and the design they use. UX, maybe not that much UX, okay. We have better UX, I think. But I'd probably say that it's super intuitive and this is what I like. And also if you use their, I think it's Uber Black, you can join your Spotify on the car. Try that. So thank you very much, Alex, as well. So now a question for all of us. I think we're going to go sort of like top down here and sort of think about discovery on a high level and see where we end up on the lower level and validation methods and stuff like this later. A question I want to ask you all is from your, like, personal experience and from your, but in general, like what have you seen change in the last two, five, ten years? Two years on the job, maybe much longer on the job, new in the job as well. So what have you seen change in the last two, five, ten years if it comes to working with users and customers while doing discovery and developing your products? And the sub-question is like in general would you say it actually improved? how you build products nowadays compared to five years, ten years ago or not. So what changed in how you work with users and customers and relate it to the methods you are using, the way you are communicating, whatever. So maybe start with Alex. Thank you. Well, I cannot say what actually has changed in the last ten years. Ten years ago I was in high school. Not much. I probably cannot say what has changed. I can maybe give a remark on the fact that all of those frameworks and methodologies we use right now, they're all underlined with focus on the customer. So if something has changed from the past, I think that was a good thing. But when it comes to using those frameworks or... What's my experience in the last two years? It was definitely to work with the customer. So talk to the customer, actually try to figure out whether what you're doing is on the right track. Try to figure out whether the problem you are solving is the problem they are solving as well. And I don't know, at Lyftago we are not necessarily... do user testing every single time. We often look at data. We are very data driven, so that's a great thing. I think every company should be data driven right now. What I love are funnels, user funnels. So we are checking the conversion of the users, try to find holes in that and try to fix them. And as well, what we've been doing is to communicate via surveys, via testing in the companies and see actually on-hand experience of the user with your product. So if at least any of those things are part of any frameworks, then I'm very happy. And also what is super important to me is the deep knowledge of the user. I'm always checking in what situation he's using your product. I'm always checking what his motivation is, why he wants to use your product. And then think about how to make him coming back and how can he actually return back to your product and be happy about it. And when you have all of those things... Yeah, yeah, yeah, I'm sorry. I'm just super happy about that. So, yeah. Save some stuff for later because we'll get into some of those topics in more detail. Great, great stuff. As they said, I come from a marketing background, so for us what has really changed the game has been data. You know, like 10 years ago you couldn't collect, you couldn't predict, you couldn't work with it in such a detail, in such a speed. and it has changed now that when you're prototyping it can be much more beautiful you can get it to the customer faster you can get the data back real time and that's i think what's changing and a second thing i think what changed is like 10 years ago maybe like 15 we didn't have facebook we didn't have all those things and what you could do is is make a shitty product put it on tv and then just put like really big money into tv and people would start probably buying it but nowadays you have to completely change your marketing strategies suddenly you're listening to your customers uh you're um listening to what they are saying and you're trying to solve their problems and provide them with a product that will solve their problem you are not having a monologue you're having a dialogue you're actually listening to them and this is um i mean I come from an agency that's using human-centered design on everybody, so I can't agree more with Alex that the user needs to be in the center of everything and you have to be asking a lot of questions all the time and basically coming back all the time. Wow, so there's nothing left for me, thank you. What I really like about the change that happened, I wasn't in product 10 years ago and maybe not even five years ago, but it's the evangelism. So if you don't do user testing today, you are weirdo, at least in the community. And that's a good thing because it's cool to make good products now. That's what I like about the change. Also, the tools we have are much better. We are much faster in building also. That's also a bad thing, kind of, sometimes. And I will look forward to what will the future bring, because I see a lot of tools that help you dig through the data and just giving you the right stuff right away, so you don't have to do the repetitive work. Thank you. Good popelka. Good popelka. Sit. It doesn't work like that. Okay, thank you very much all three of you. The only thing I'm missing was actually the answer to my sub-question, which is, we all love data, we all love using those methods and tools. Okay, so we all love data, we all love those tools. Nobody answered the question if this is actually delivering at the end of the day better products. Okay, sorry for this. It's mostly getting me out of my... So, the panel members, raise your hand if it actually is delivering, if it's actually helping at the end of the day. Is it actually delivering a better Lyftago, a better marketing campaign, or a better portfolio company in Rockaway, using those methods and those changes? It is. Okay, no problem. A question for the audience, maybe, like... Do you think you're doing stuff different nowadays than you did like five years ago if you are on the job at least five years or two years ago? Raise your hand if you think that something changed or you got better in doing your job and better in not so... Okay. Much better. Much better. Just a bit better. Super better. Just better. Okay. Okay. Thank you very much. So there is apparently something happening there and that's a cool thing. Actually, I think I had the answer to this question because I wanted to ask you if this is at the end. Because product discovery makes a promise. Product discovery makes a promise, as we said, that at the end of the day we're delivering products better. So my question for you was indeed, in Rockaway, in your portfolio companies, are there better companies and businesses being delivered now than there were five years ago? We weren't there five years ago, so I don't know. Well, the investment strategy changed, so it's really hard to answer. Before, Rockaway Capital was investing more into early stage and seed stage startups. Now it's more like bridges and series A, whatever that means. So the businesses we invest in right now are... more mature. So actually it's hard to answer that question because before there were businesses they had only little traction and now we onboard businesses they had a lot of traction and they just need the money to grow so there is no simple answer to that, sorry. Okay, but it doesn't mean that those companies are actually stopping discovery or stopping inventing new parts. Okay, that's fair enough. Okay, thank you very much. They say the customer or the user is king. So if the customer is king, then who are the princes and who are the princesses? So who else is there to keep into account? And Hansa is pointing to you. So we'll start in the middle this time. So if the customer is king, who are the princesses and princesses to take into account as well? And there are some questions from the audience, like how, for example, Marco, how to deal with a very sales-driven organization. If sales says build this, no question about it. Or how do you go about convincing your stakeholders or your company that actually the customer is king and that you should listen to them? So kings and queens and princesses. Maybe I will be answering the question about the sales driven company and product discovery which can maybe lead us back to this. I think what you both need to know, your sales department and your product department is to know your customer better. We have mentioned it 10 million times before and we will mention it in kind of a spoiler what's going to come. And you need to know your customer better, your sales department. If they know all the things you are actually researching, they will make better decisions, they will make better presentations, they will maybe do better ads and so on. So I think the kind of key in the middle is not to say... either sales or product or development or somebody else because i think that everybody needs to come together and just right now i'm working on a study what's keeping uh people from innovating and i've been talking for last few weeks with startups for with corporations and so on and What is one interesting point that's coming back and back, and no matter if you talk to economia or small startups, is just that sharing is the key and allowing it to share. And maybe like product manager shouldn't be the only person who has this all wisdom to come up with a feature. Sometimes it's your developer who has the greatest idea. And the fact that it's not written maybe in his job description doesn't mean that he's not the guy who... who shouldn't come up with that. And maybe it's some girl from support team and that's a fine thing. I think when it comes to creating product, everybody should be equal and everybody should be given a voice. And it's the same way you treat your customers, that you listen to them, you should treat your teams. And that's, I think, what is blocking us from creating better products. Yeah, maybe I can add something. This is exactly what we were solving at LiftEco. We have a lot of stakeholders or business owners, as we call them. And it's like there are managers from sales, marketing, supply. For example, supply manager is taking care of our drivers. And this is exactly as you said. I love to listen to these people because they are closest to the customer. They are listening to them on a daily basis. They know what their problems are. And I'm super happy to hear opinion of a girl who's working in the customer support because she's actually talking to those people. So exactly, I wouldn't say kinks. princes, princesses, I don't know. It doesn't matter. I think everybody has the same voice. Of course, the customer is the king, but I think everybody should have the same say to the product because everybody can end up building a great thing. Without a microphone, but yeah. But if everybody has the same voice, I mean, how are you dealing with this as a product manager? I mean, are you saying yes to everyone or maybe or not now or no? I love no, really. But, no, I'm not saying that this is about the prioritization, what I said. What I meant was that everybody can have a good idea. That's what I meant. So, can I pass the mic? Well, my opinion is I agree with most of what you said, and I'd like to build up on that because If the people who are in direct contact with your customer or even, as you said, the development team have an idea, then your job as a product manager is actually to explore that, if it makes just a little sense. The team will respect you if you explore, if you show them, well, I had a look at this question of yours and the customer says this and this is what we found. And maybe it's not exactly as we had in mind, but we might build these two other things that we come up during the interviews. The problem with product manager is that you are not the boss of everybody. They have to trust you. The people have to trust you, but they don't report directly to you in most of the cases. So as I said, your job is to find out. Okay, thank you very much. It sort of automatically leads to the next question. Like if you say everyone is involved, everyone has an opinion, everyone has ideas, and they're all valuable, and everyone is talking to you. Someone said like ideas are cheap and plenty. So how then do you go about with the obvious next step, which is prioritizing all this backlog of ideas, the most nonsense ones, the best ones? What makes an idea a good idea? How do you go about this at all? These are two different questions first of all. First question you asked was how to prioritize business owners requirement or business requirement or any idea how to prioritize that one or other one or okay any idea how to prioritize that? Yeah, that's the biggest question of all. So maybe it's easier if you think about, and this is part of the framework which is on productorg.org, which is putting ideas, opportunities, experiments into sort of like a logical structure where you would experiment to find out if a hypothesis is true, to find out if an opportunity is actually, if you're able to meet one to achieve some goal. So maybe ideas are not like, okay, make this button blue. That's an idea, of course. But another one could be, let's build a complete new... part of the product. So, yeah, still question is like how do you separate those from each other and then how you prioritize to decide what you work on next and what you're going to build next basically. So first of all, the idea can be a solution and idea can be a problem definition. That's the first thing I'd say. If you have a problem definition, the solutions can be many and you choose one which is not the riskiest one, I'd say, in the end. But you are always validating the idea. So if we are talking about those ideas as solutions to your problem, you always validate it via a trillion of methods, whatever you choose. So it can be via, I don't know, user testing, it can be checking the data, it can be talking to the customers on the street, it can be anything. So basically you are just collecting evidence to support your assumption. in the end and then it actually can tell you about your assumption that not that it's wrong but maybe you should just tweak it somehow or maybe it's going to just support it and at that point that idea can be something to something good to look at and at that point you should prioritize that at that point you should maybe prioritize it because you have enough of evidence which are supporting your assumption at the very beginning I didn't say a good idea. I say idea which has enough of evidence, enough of data, enough of it has some some KPIs which which which Thanks to which you can actually validate that idea in the end of those Amazing answer I would say Maybe I will go back to the second question you asked and Alex managed the first one. You asked about exploration and execution and I think that's always a big question and I read recently that you should dedicate 80% of your time to exploration and I think that's a great idea actually. I've been seeing talking to all those startups and so on that everybody is so fascinated by execution. everybody wants to develop those features and so on and nobody's really like going back and talking to the users and so on and and it's great if you have a chance to actually go back there and you know if and constantly or testing it's not like one day that you dedicated to testing it's like during all those phases like understand empathize you're already testing some hypotheses then you have you go to the field and you talk to the user and you already test and and constantly basically you never stop testing and that's the idea of it there's no kind of a yeah we assigned this agency for testing for one hour a week and that's that's done and i totally agree and it's actually the guys from silicon valley product group that are saying that 80 of the time of a product team or should be spent on product discovery. So the product manager together with the UX designer, partially the tech lead, should spend time on product discovery. So my question for the audience, like who of you guys is spending at least 10% of their time on doing product discovery? Like coming up with ideas, validating ideas, more than 10% only? Okay, quite a few. More than 25%. You guys don't count. More than 50% of their time on product discovery. Okay. They should sit here. Next time. Yeah, yeah, yeah. So maybe you. Can you introduce yourself and can you sort of explain what you do and how you actually manage to be able to do and spend so much time on discovery and why you think it's useful, not useful, and what you're learning from it. Hey, I'm Daniel. I'm co-founder of ProductBoard and we are an early stage startup. You measure progress of a startup not by MRR, more about how you learn about your market, how you learn about the problems you are solving. This is what we basically optimize everything for. So every feature we are building, we are always... thinking about, okay, what we want to learn, you know, what are the hypotheses we want to validate. So it's mostly about this, about the mindset that we built everything to learn something more. Thank you very much, Daniel. One of the concepts here to look into is this concept called dual-track agile, where you actually start separating the building process from the discovery process. And if done right, yes, you can actually afford spending 80% of your time. on doing product discovery because you would only end up building, in ideal case, the stuff that is validated and that makes sense at the end of the day. Related to this is for those companies that are not doing this and that are not doing continuous discovery like Pavlina mentioned, there's an interesting thing happening at the moment which is called design sprints. where we think, OK, we'll lock ourselves up in a room for either three or five days, I believe, and try to come up with something useful and tested and validated at the end of the day. Is anyone here doing design sprints? Just a few. Maybe Honza. Do you think it makes sense? Is it useful? Can it replace doing continuous discovery or not? Or is there something to learn there? It's useful and it can't replace continuous discovery. Thank you. No, actually, I would like to talk more about the underlying concepts because you can have a methodology, but if you don't understand the concept, then you can bet on methodology to solve your problems. So basically, if you get the concept right, the concept behind the methodology then it's it's useful and design sprints are good for solving reasonable chunks of problems in defined time so you have a deadline and you know what to do every day and you focus all your energy on solving specific problems so in in that matter it works but again it's more about the concept not that much about the methodology for me Okay. Let me get back to my questions. Maybe now we're getting sort of on a lower level down to sort of methods and tools we are using. One of my favorite things, which is becoming a bit of a controversy, is personas. Because we like to sort of put our customer, our user on the wall, we like to stick a face on it, have something to discuss while doing product management and product development. So, who here has a sort of definition of what their ideal or what their user is in the form of personas? We have some demographics, some... much less than I expected actually. Because... Okay, can you tell me how you use them actually? And for what purpose? Yeah, I'm Steve from Democracy 21. Yeah, and we use them to just have them in mind when designing anything, just to know who we're designing it for. Motivation of the user? Yeah, I think the motivation and their limitations maybe, and mainly the problems that they're solving, that they're trying to solve. So just to have that in the back of our heads when coming up with ideas. Okay, thank you very much. Alex, what's your opinion about personas? We don't use personas. I'm not saying it's bad to use personas if you have a product for it, right? So if you are making t-shirts, you probably want to know your persona, and you want to know that it's a 14-year-old boy who loves hip-hop, right? For example, in our case, I don't see how I could get any... information about motivation of that user when I know that his name is John, he's 25 and I don't know, he's coming from this and that city and he drives this and that car. Doesn't tell me anything basically. And what I rather check with the, not that personas, but I prefer to check the profile of that. of that person or of the user, which means that actually, for example, at Lyftago we have several profiles of users, which are, we have drivers. then we have passengers, then we have some corporate, or we have companies and some employees. So this doesn't really tell you about the persona itself, but it actually tells you about the motivation of that person, in what probable situations they are, and based on that you actually build a product. This is how we do it, and so far it worked for us. My obvious question is for you, Hansa. Is there a way, you think, to get the motivation of a user or the motivation of a customer for potentially using your product? Is there maybe better than personas a way? And I'm pointing in a particular direction. Yeah, I see jobs to be done coming. Well, sure. I mean, personas are great. I think it's a good tool for synchronizing the team. For example, when we were redesigning Colonial, we had personas based on user testing. And we had really like the real people. And a lot of people from the team actually were present when we were testing behind the mirror. And there was this woman, I think her name was Zdena, and she was missing frozen duck in Colonial. And it's great, every time you are solving a specific problem of the user, you can talk to the rest of the team and you can say, well, then I will miss this. What are we going to do about that? So for me, it's a great tool for synchronizing the team. And about jobs to be done, I wouldn't combine those two because the For me the purpose is something different. As I said, the purpose of personas for me is to sing the team about the needs of your customers and jobs to be done is more about the motivation. They might work well together, but I wouldn't mix them up together maybe. Maybe I can add from my previous job, we use personas. And it was not because we believe that if you put some demographics on the paper, it will actually help you solve some problems. It was about thinking the team because the average age of my team was 25, but let's say the average age of our customer was maybe 40. And suddenly you have people who can't relate to people who are fed ugly and I don't know, whatever. let's say i'm coming up with those things very hypothetically uh so so it's it's good to kind of give it a give it an idea exactly what honza was saying it's you suddenly see a person in front of you. And I think the key is, like what Alex says about the methodologies or anything, just don't take it as a religion. If you have written down that it's a 35-year-old woman, that doesn't mean that this T-shirt can't be bought by somebody who's 55 and suddenly fell in love with hip-hop. I mean, you know, whatever. And that's the thing, like, it really helped. us to imagine what we are dealing with and not to forget maybe some features maybe some ideas and every time we came up with a campaign that was based on snapchat we looked back and we said what about mrs vlasta because she obviously doesn't use snapchat and that was like a good thing good good stop for us really But yeah, we were exploring the motivations as Alex was saying with her approach and this is what helped us maybe develop some key features and for example when we were developing with Too Fresh a Christmas campaign we started talking to different people like really in general like what is it about Christmas that is stressing you out? What is it about Christmas that makes you happy and so on. What was an interesting thing is that everybody, when we asked them what do they want for Christmas, everybody answered I want something. Something small, something sweet, something cute, something to wear. And suddenly we had an idea and that united them all. That was kind of a motivation around it. So I hoped. Okay, thank you very much. I think we ended up sort of in methods to use and jobs to be done and personas and stuff like this and talking to users and talking to users and talking more to users and sticking stuff on post-it notes like you see all over the place and it's all very cool. But somebody said like don't listen to what users say but look at what users do. And I think Alex is touching it a bit on looking into data and stuff like this. So my question is, what happened to old-fashioned quantitative research, data analysis, surveys, and God forbid, maybe even using your gut feeling or your common sense as a product manager? So is there a moment where you say, OK, forget it and don't stop listening to the users and decide it based on data or your gut feeling? Because I think a good product manager needs to have a... developed gut feeling. So maybe Alex, in practice, how do you handle it? What user says, it's actually good to listen to user, but one user can have one bad experience. But you see from data that the rest of them didn't have that bad experience, right? So, first thing is, when you want to validate something, it's good to actually check what the user says, but as well check it with your data, check it with your funnel. That's one thing. And what happened to those surveys and everything, I'm still doing them because it's the quickest possible way how to get some data from the market and get some feedback from the market. So I'm not saying that you shouldn't listen to the user. What maybe it's probably important to mention, but I believe everybody knows that usually what we say, that the customer doesn't know what he wants. He usually can, well, at least our customers often they give us like solutions suggestions, which it's nice to have, but your user usually can describe the problem, what he's solving, but he cannot actually give you the best solution. So I'd say that. I just wanted to pass the mic. No, no, no. When just to ignore the user and when to follow your gut feeling, farmer's instinct, or old-fashioned quantitative research? Fine. In terms of using the qualitative and quantitative research, I really like the approach that first you do quality. to see what's in there and what you should explore. And then you use quantity to see the magnitude of the problem. That's what works for me. And regarding basically letting people design your product, that's obviously totally bad approach. No, but seriously, you can't let people design an iPhone, right? It's about some vision of the product, how it should work, and you can't really see all this in the data and you can't really see this from the qualitative research. It's about the visionary on the team that has the experience of building something really delightful. I think that's kind of... If you look at Google, they have lots of lots of failures because they just make small incremental changes. So they take Facebook and make a Google Plus with circles and that's it. There is no vision of how it should work. There is no big idea of someone who would say, well, this has to be somehow completely different. You can't do only these incremental changes and believe it will work. You have to have the vision. Sometimes that's also in the people on the team. You can't rely on the user in these terms. You know what I'm saying? I think I do. Incrementalism. I don't know, I didn't prepare a question for this, but maybe I don't know who to ask as well. Maybe back to Alex or... No, let's get to Pavlina first. A bit of a trick question. Because maybe at the end of the day it's not about building better products at all. Maybe it doesn't even matter. I mean, you're from marketing, so maybe actually it doesn't matter what the product is or what the product does. Like an example from NotIT is, for example, Red Bull or energy drinks. I mean, little energy drink... Tastes better, it's proven. It's three times cheaper than Red Bull. And at the end of the day, it's water and sugar, which doesn't work anyway, or just a very short moment of time. But it sells like crazy. So it's a quote, quote, bad product, but it sells like crazy. So why are we spending all our budget and money on doing discovery, building, where we could just market the shit out of everything, basically? Skype is not necessarily, sorry to say, Skype is not necessarily a good product. There's better products out there, but it's the most used product. So, anything to say about this? Pavlina? Maybe. I read a quote today, it was on Twitter, so it's stupid, but whatever. That you are not selling a product, you are selling a better version of themselves to the people. And I believe that a lot of people put... product and marketing into different boxes. But I think they are all created together. And if you have a great product, it will help it market itself. And you don't have to push people something they don't want. And I kind of... Dave, what was the question again? Why are you spending and wasting your money on building better products where you can just market them? No, so you can't market them if they're stupid. that's that's what i wanted to say basically because uh it's not what the users want and what what we are doing is is going back to the user you are going back to the customer and trying to understand them and you are not only trying to understand that in a way what kind of feature they want but you are trying to understand them in a way how you should market it to them what story they want to hear. I think this is what you're taking from customer research. When you're looking at them as people, you're looking at them as the kind of problems they're trying to solve and what is actually the job that they want to solve by that. And sometimes it's buying a better image. Sometimes it's something that you are buying with Red Bull. With Red Bull you are not buying energy. You're buying this great adrenaline-fueled... lifestyle and that's what the product is. I hope I was understandable. Alex? Nobody knows what you're buying on Skype. That was a spectacular answer. Okay, thank you very much. Nobody knows what they're buying if they're using Skype, but okay. Nothing. I'll get back to you. So let's get back from that level, back to practicalities and daily work. So I'll get back to you, Alex. Which is maybe what people are interested in is the actual validation methods like your toolbox, Alex's toolbox, what is in there and what are the favorite validation methods you're using. Somebody says validation of hypothesis, validation of ideas should be done as quick and as fast, so that's the same, as quick and as cheap as possible. Sorry. To find out if actually something makes sense. Quick and cheap. So, building a prototype, a full-blown prototype is actually quite expensive. Even asking users, in my opinion, is quite expensive. Sticking a fake door page somewhere on the web is cheap. So, in this context, what's in Alex's toolbox? What are the things you like to use? Do you think you are cheap and fast? Yeah, that's correct. As I said at the very beginning, I love to use data, I love to use funnels. The quickest way how you can actually make a decision, or at least start to make it, is by checking the funnel, checking the conversion of the user, and you can create whatever funnels you like. So that's the basis. I think that's the quickest and the cheapest. And I don't know, for me, those two things, checking the data, checking the funnels probably. But on the other hand, I love to talk to customers as well in that way. So that if those customers, like for example, what we do is, or what we've done in the past, was call in some drivers. They don't mind coming. They actually want to help you. They kind of hated the other dispatching companies. Yes, because they like us. And actually at that point they want to really help you to kill the competitors and everything. So definitely talking to customers. I think it's super fast and super quick just to pick up the phone, try some numbers. I mean, that's easy. So for me, all of those three probably. That's the best. That is a lot. Trust me. What do you consider cheap and fast? Cheap and fast. Well, it's looking for the solutions the customers make for themselves. That's always a great part because it shows you that they have a problem that nobody is solving. But it's not that common. I saw that once and I'm not completely sure that it would work. But that's this thing and if I'm completely lost. I'm totally lost. Then I'm looking for... It's called Bright Spot philosophy. It's really easy. So we are looking for the stuff that works. And you are trying to build up on that. So if you totally don't know what you are doing and you don't know where to start, then you start looking for what works in the process or in the product, what are the good parts. and how you could build upon that and that's that's one tool i really like to use when i have no idea what i'm doing which is okay i can't say it's often right it it that never happens okay um i don't know if we should close this off this is sort of the topics i have prepared for you guys unless you want to give um Already now one sort of takeaway or we're going to go for Q&A first, so what you guys prefer. And we have some questions prepared for the audience as well. I prefer B&A. B&A, okay. Okay, we got some questions actually to get some interaction going from the panel towards the audience. And three of you lucky people are sitting on a chair that has a small sticker of a heart on the front side of the chair. So could you check? Who's sitting on a heart? It's a bit awkward question, but please look between your legs. And be honest, there are three. Or they fell off. No one. Yes, exactly. It was on the floor? Okay, then look on the floor now. But we got a winner. To introduce yourself and to be prepared for a question of the panel members, actually. Okay. Yeah, this is definitely on my chair. Okay, so my name is Art and I work for Lusk, which is a hiring app. And so, hey, and yeah, I'm a product owner, I guess. That's an easy question. Well, I think that, all right, sorry, just so that I repeated correctly. Yep. Maybe come here, yeah, there could be a motion as well. So my question was how do you define a problem and how do you define the importance of it? Okay, so how do we define a problem? I think that's a really philosophical question. So I'll skip to the second one, which is how do we decide this is a problem worth solving? So we gather feedback. all the time, basically a lot of the stuff that you were talking about, like we do, so from sales team, ideas from the team, just, you know, anything that comes our way, you know, we, if it sounds like cool, you know, we have a board, so we're gathering it there. And then we just kind of try to, based on, you know, what our long-term vision is and all criteria, like what are some, you know, customers that, for instance, are important for us or that we think that strategically might be putting us in positions which are useful, then based on these various criteria we just prioritize and that basically builds our priority list and those are important problems for us. Does it work? Yeah, I think... But I think that it's an ongoing thing. So we constantly re-evaluate that. I think that's the really important part. This is a living document that we have. And every time, we don't have a set period. But every once in a while, we're like, this doesn't look right anymore. Let's look at it again. So does that answer your question? Thank you very much. Maybe one question of the audience. In this case, for Pavlina, directly. Biggest difference in dealing with customers between B2B and B2C? Like in Zoot you were very B2C, focused on consumers, and TooFresh you're basically providing a service for companies. How do you go about that? I don't believe in dividing B2B and B2C because there's always a person on the other side of the table. And no matter if you're dealing with a company, there is this marketing manager or, I don't know, CEO of that company. And he has his motivation, he has his issues, he has his problems. And that's what you should be looking for. So I think when you're dealing with a B2B business, you should approach it as if you were looking at a B2C business. and doing the same customer research and motivations and all that stuff we've talked about. I hope it answers your questions. If not, we can talk later. Okay, maybe one for Alex. The last argument over feature priorities you had with the team. So, last one. And how did you solve it? Well, that was, lately actually we focused majority of our workforce to build a product for corporate segment and we were arguing whether to continue working on it or move ourselves back to regular passengers, regular customers and we actually agreed it was not a horrible argument that we were swearing and so on. Nothing like that was happening. But we actually agreed that we need to work on tuning of the product after a while, after we get some data from the market. Thank you very much. Maybe one for Honza, because you've seen multiple teams, products, companies. If it's about the setup of a correct product team or discovery team almost, What do you consider to be the required roles and people involved in doing product discovery? Is it a product manager by himself or something else? What have you seen work, what have you seen fail in the companies you know? Okay, thank you for that question, I guess. Wow, that's a tough one. Let me check. That obviously depends on the size of the team. Who should be involved is always the product manager. Depending on the size of the team, I would vote for as many people as possible to be involved. If they can't be directly involved, that's always good. It's also fine if you give them the information you extracted in some... I would say maybe snackable form. Maybe the highlights from user testing, you can just make a short video of that. That's always good if you have stakeholders, for example managers, that are a few levels above you. I'm sorry. The question is where did the division... Okay. Practically... I'm just trying to find a really easy example. That's probably Product Board actually. Why it was impressive what they did was they spent an incredible amount of time on really exploring the market. and actually how the product should be built. So when I first saw the product, for them it was far from beta, but it was solving most of my problems as a product manager at that time. And actually this was an easy process and it wasn't fast process, but they spent a tremendous amount of time on testing prototypes and really looking into the the big questions that were behind that. That was impressive from my point of view. So they really put a big effort in that and that's this amount of effort I never never saw that in any other project. But that doesn't mean that that you can't do that. I saw projects where people started solving their own problem and they were basically well equipped to solve it. I saw projects where they had no idea and they just hit it. I hope that answers the question. Thank you. Alex, maybe something about the setup of who's involved in discovery in Liftago, the team or if there is a team as such? We don't necessarily have We haven't created an actual discovery team. We don't have anything like that. But we have just people who are interested in that. I remember when we were doing some user testing, some developers came to join to watch. We are really data-driven companies, so a lot of people are checking data themselves. And a lot of people are interested in building their own reports and stuff. So I think it's kind of like collaboration. mainly in start-up, because LiftEgo is a start-up, so all of us, we are kind of interested in doing that all together, I'd say. Okay, thank you very much. This is a question which has been voted up, and the questions that we covered is enough. The question was how to convince stakeholders about the importance of working better with users. I mean, it's a quite generic question, but... Of course, we have mentioned data, we have mentioned money. we have mentioned all of that but what has worked for us repeatedly is involving them in the process it's not like coming once a month or one in six months to a board and showing them the results but once you get stakeholders on your team and they will start working with you then actually you will have the power to get the innovation going and even though when you're outsourcing to an agency like we are we always require a stakeholder to be a part of the team, because this is the only way how we can create something that works with the DNA of the company, that can be brought back to the company and can actually survive the company. And so this is what I would recommend. Always get somebody to work with you and not be the weird guys in the cellar. And sort of the second top question is... How does company vision affect your daily product decisions? Do you take part in forming the vision yourself? I think in startups where the CEO or COO or CTO is very often the product manager of the product, in bigger companies that's typically not the case. So maybe back to Honza, in those companies where is the position of the product manager? being in a very important position actually part of or how far is he or she away from the board is he part of setting company direction company vision mission or is it a very hierarchical structure so where do you see what is the position of a product manager within a company and how much influence does he or she have in what company in a good company What have you seen fail in that company? I will get back to what I said before. The difficult position of product manager is that basically not a lot of people answer directly to him and it's about the trust in the team. into that person. So in ideal company, everyone should be interested in building the right product. That's obviously sometimes really hard to achieve. So actually, I don't know. I would like to choose, I don't know, some middle company or big company or small company. I'm not sure. Okay, so. in general uh what what what works best uh what worked best for me uh was if the if the product manager was involved even in the in the board meetings when the big strategic decisions were made because a lot of those people uh haven't had the insight he he has and also the uh it was also important from the from the side of the product manager to prepare the snackable content, as I said before, for these people when the decisions were made. Because that's why he's hired. He should understand what's a good idea and what's not. So for me, product manager should be connected as possible. as much as possible to the highest levels obviously, but he should also talk to the people on the other levels. So even, I don't know, if we talk to the people when building a new colonial, when we were talking to the people in warehouse, that's something that's really revealing too for you. It's a lot of work for product manager to do this job. I would like to ask you Alex, if there is a difference in new product development or product improvement. If you have worked on completely new parts or parts of the product. And if you see a difference there between new product development and discovery for new product development and discovery for enhancing, improving your existing product. I don't know if I have a good answer for that, but I don't see any difference. More about that. So, recently we decided to invest our time to corporate segment. We've built, we literally took our app, but we actually... pushed it to the web, and we created a product that helps companies to order caps for their employees and so on. Whether the discovery process was different, I don't think so, because Always we went to the company we described the features it's or they actually told us what kind of features they'd like or what problems they want to solve with the product It's exactly the same thing as they are doing with the product which we have right now Customers comes to us or send us an email feedback Whatever they tell us what they are doing without product what they cannot do with our product and they like to so I think that the discovery process and Actually like call development of it was was more or less the same you agree I think this wraps it up for us from our side. I think we've covered the most burning questions from Slido. For people that are not using Slido, I want to give the option to ask some questions now directly to the panel. So any questions? Or everybody's thirsty and wants to go for a drink. I think that means a yes. Okay. Please introduce yourself. Hi, I'm Bob Marwan and I'm Senior UX Designer at MSD. And actually I have a question. What was your biggest failure during product discovery? What you discovered and doesn't work for you? Anyone specific? Sorry. Okay. Let's start with Pavlin in the middle maybe. Or Alex on the side. Failing product discovery. We wanted... this is kind of like typical fuck up which happened. We tried to help passengers to order a cab, but not from pedestrian zones. And we checked the map, which we used, and the map was showing, okay, in this area there is a pedestrian zone, so you cannot order from here, you have to walk 50 meters on the right, and you can order a cab from there. Which was amazing, because we actually blocked whole Brno. And it was because we realized that actually those maps, they don't show you whether taxis or tracks or something can actually go that way. So we blocked the majority of the Brno. Drivers started calling us, like, what's happening, like, why they cannot actually approach that area. So that was probably poorly done, discovering that way and validating how we should actually build a product or a feature. So yeah, we decided not to do it after all. I mean, if that answers the question. It was fucked up, so... She doesn't want to answer that. The biggest fuck up. For me, the biggest fuck up were my side projects, because most of them failed, and they failed because I didn't put enough energy into that. So I was working on something, kind of, but not full time, and I wasn't that convinced. I did that in my free time. and that brought a lot of energy. So my biggest fuck-ups were my side projects, because all of them failed, actually, because I wasn't able to devote the time they needed. And maybe they were not that bad ideas, but I just, yeah, these were my biggest fuck-ups. Satisfied with that answer? I'm under an NDA, so I can't be very precise. uh but uh let's say it was every time i jumped to conclusions too soon without actually going back to the field and maybe trusting it because if you ask a person what kind of tv they're watching they would usually answer chat and the reality is as we all know it's nova so every time i kind of trust it without validating it so that was my biggest fails Thank you very much. Any other questions from the audience before we go for drinks? Okay. I think then I want to wrap it up and thank you, Honza, Pavlina, Alex, a lot for participating and answering some easy, some maybe tougher questions. And thank you, the audience. Who has got at least something out of this talk? Something to apply, something to use in doing product discovery, hopefully better. I learned to burp silently. You should never take a beer when you are on a panel. That's what I learned today. Okay, cool. So thank you very much. I mean, this is what Product Tank is about and we're trying to get better and as product people all together. So we're planning to do a next one even in June. Hopefully, so watch out for the announcements. A different topic. We have sort of different tracks defined in Product Tank on organizational topics, on innovation topics, and on evolutionary topics, like how to become a better product manager. So keep an eye open on Facebook and on Meetup. And we hope to see you on any next event. And catch us, the speakers, or me, or anyone after, and go for a drink. And thank you very much.

The video has bad sound for first 10 minutes or so, then it improves.

The user is dead, long live the user!

CAC, JTBD, HCD, Lean, Design Sprints, ODI, Opportunity Solution Tree, Big Data Mining,…

Are you also overwhelmed by the number of frameworks, methods or ‘bestselling books’ to do Product Discovery easier, faster, cheaper and with even better results ? 

Have you become dogmatic about your favorite flavor? Do you think Jobs to be Done is great and Customer Activity Cycle sucks bad ?

We invite you to explore together with us what there is to learn and what are the overlaps between these methods. We’ll be discussing what methods we’ve seen used in practice and what was learned doing so. 

We hope to find-out if and how applying any of these methods will help us doing product Discovery better or if simply using our common sense, gut feeling and having a chat with our users and people around us could be enough.

As part of Innovation Week 2017 and in cooperation with 2Fresh we’ll be talking about the above with an expert panel and we invite you to actively participate in this discussion. 

The expert panel for this event:

• Jan Habich; Product and Service builder - Rockaway 
https://www.linkedin.com/in/janhabich/

• Pavlina Louzenska; Designer of Change - 2Fresh 
https://www.linkedin.com/in/pavlinalouzenska/

• Alex Michalicova; Product manager - Liftago 
https://www.linkedin.com/in/alex-michalicova-53643641

The discussion will be moderated by Dave Ruzius; ProductTank Prague | #innovation & Product Manager @ LMC

The event will be held in English.