[00:00:08.010] - Lina Zubyte
Hi everyone. Welcome to Quality Bits, a podcast about building high-quality products and teams. I'm your host, Lina Zubyte. In this episode, I'm talking to Andrea Sipos. Andrea is a product manager, so we discuss how to create valuable products. We also talk briefly about qualitative and quantitative research that can be done, and we even touch on the differences between project management and product management. So I hope this conversation clarifies some of the misconceptions about product and you'll learn lots of great new things and ideas. Enjoy it.
[00:01:05.350] - Lina Zubyte
Hi, Andrea. Welcome to Quality Bits! It's very nice to have you here. Thank you so much for your time.
[00:01:11.990] - Andrea Sipos
Hi Lina, thank you. Thank you very much for inviting me. I'm very excited to be here.
[00:01:17.560] - Lina Zubyte
Me too. I'm excited to learn more about the product and your work and your knowledge. But before we start, could you shortly introduce yourself?
[00:01:28.350] - Andrea Sipos
Yeah, sure. I'm Andrea. I live in Budapest. In Hungary. At the moment I work as a consultant working with tech startups and product managers. I worked as a product manager for eleven years and started freelancing career last year. And when I'm not working, I'm doing a master's program in marketing at a local university here in Budapest. And I work a lot with yarn. I love crochet and weaving, and I love working with things which are not pixels in my free time.
[00:02:10.410] - Lina Zubyte
Nice. It's a useful thing to do because it's enough of pixels that we get in our daily life. So... When it comes to responsibilities and roles, very often I would hear certain roles, like QA, for example, saying, oh, I'm responsible for the whole product. And this podcast is about quality products and teams. And I'm wondering, what are your thoughts about the responsibility of building a high quality product? Who should be responsible about quality?
[00:02:44.980] - Andrea Sipos
I had a very interesting moment lately at the university because we have a course called Quality and Project Management, and they said that from their perspective, the definition of quality is: "Meeting the customer's needs and providing a service which meets or exceeds those needs." When I heard that, I was stunned. Okay, but that's also kind of a definition of product management. I started thinking about this whole thing. And when we talk about meeting users needs, that can mean various things. That can mean that the product they start using provides value in case of software. It's stable, it doesn't break, it's available 24/7. It's easy to use for people who need it. It provides necessary accessibility features. So all those things. And I know that at companies there are different trends. Just what you said, that QA people are made responsible for quality. But you cannot really say that there is one person in an organization or a team who is responsible for quality. Because all bits and pieces that we contribute to product will affect the end result, how the design was made, or how well the research was conducted or how the product decisions were made, how the implementation went, how much attention we paid for details. So all of these things will sum up at the end. And it's not only one person or one team who is responsible for it, but the whole organization.
[00:04:41.290] - Lina Zubyte
Yeah, I really like this description. I feel like we tend to be like, oh, it's mine, and nobody should take it. And sometimes also the product manager may say, it's my product, so I do what I want with it, and I'm responsible for it. Engineers also could say that it's their work, so they actually own it. But somehow when we say "Quality is everyone's responsibility," it's still a challenge in many companies because it's much easier, I guess, to put it on someone and say, hey, if we find a problem, it's your problem, even though we work as a team. So in this case as well, where everyone is responsible for quality, let's say. And we spoke a little bit about customer needs. How would you describe the product manager role? Because in some companies I hear project manager, product manager. What would be the difference between project manager, product manager? How would you describe this role? What activities would this role involve? Because in some companies it's more strategist, in others it's more hands on, a member of the team. How do you see it?
[00:05:56.210] - Andrea Sipos
I can say it's very simple, but also it's usually very complicated. Exactly for the reasons that you mentioned that different companies see it in a different way. But let me tackle the first one. What's the difference between project management and product management? Projects are usually things which are founded or created for achieving a specific goal, on a specific budget, on a specific timeline. And those are usually unique things, unique processes that you do once. Of course you reuse elements from previous projects, like how to organize something or how to run something. But achieving that result, you would only try to achieve once. You introduce a new system to the company or you plan a marketing campaign, or you run a marketing campaign. Those are one of things. But when you do product management, product is more about deciding constantly over and over what is the best or how to create value, the best way for our customers. That is a long term thing that involves a lot of repeatable processes, like lots of frameworks to reuse. But it also for me, specifically about figuring out what to do. If we oversimplify it: during product management, you are focusing on figuring out what is the most valuable thing to do. While in project management, you focus on doing that thing properly and right. Those are two completely different disciplines. The names and the acronyms are very similar, so people mix them. And that's something that I'm struggling on a daily basis. Even I have conversations with my friends like, oh, you're a PM. Yeah, I'm a PM. I have a PM position. Okay, but which one do you mean? Because maybe I'm not that kind of a PM. So when we talk about the traditional definition of product management from the books, product managers are the people who ensure that the product that the team is building is valuable for the users and usable by them. So they have to be able to access that value. And then it's feasible from technology side. So we can make it happen with the existing technology or we can develop the one that is needed to power it and we can do it in a viable way. So while we do this whole thing, we don't bankrupt the business. So we do it in a way that it can be profitable or it's profitable from the start, or it can be profitable on the long run and fits the business needs.
[00:08:48.540] - Andrea Sipos
So as a product manager, you are responsible for finding answers for all of these questions while working with a cross functional product team. A cross functional product team means that you have a team or you work in a team where there are people from different disciplines like designers, researchers, data analysts, software engineers, any kind, front end, back end, native app, QA, anything. And product managers work together with this team. And I like to view it in a way that they are part of the team. Of course, they have some kind of leadership responsibility because they have this responsibility to decide on what needs to be done today and tomorrow and in the next month or next quarter. But they are not explicitly the managers of anybody, usually, so they are not the boss. So they are there and try to lead the team without actual authority. So nobody is working for them, actually.
[00:10:00.650] - Andrea Sipos
But product managers need to convince the team and lead them into the direction that they think is the best. It's a very complex role, but my favorite part about it is when we need to talk to users. Of course you need to do that in order to identify what's needed. And then based on those conversations, we try to understand what are the needs behind what they are saying, what they want to achieve. Then we try to come up with solutions for those features, or maybe complete apps. Depends on the scope of the problem we want to solve. And we try to test those solutions. Can people use them? Does it meet their expectations? If not, why not? What to change? And then we change the product itself and test again. So that's a very interesting and exciting process.
[00:11:02.950] - Lina Zubyte
It is. And also I see lots of overlap with sometimes QA role's ideas that we want to build the right product the right way. We want to also advocate for something that's useful, but as well that is feasible, as you nicely put. And this, I think, aligns really well with the whole team quality approach. One anecdote that I remember from my career is also that one person wanted to switch to a PM role that I knew. And their argument was that you make solutions all the time, so everyone listens to you. And that's exactly not what it is, right? So you have to understand the problem first.
[00:11:50.290] - Andrea Sipos
Yes, exactly. Sometimes I'm actually just jealous because I feel that I'm not creating anything. As a product manager, the outcome of your work is basically the understanding of the market, of the business, of the problems, and then that you distributed that knowledge to your team and helped them creating something. But of course, it depends on the team, how the team works. But usually in a product team, designers and engineers are usually the ones who are closer to the solutions. They plan the UI, they plan the workflow, they plan the interactions, and they actually write the code. And you, as a product manager are there and help with the process, bring your input, orchestrate things necessary in the organization. You try to unblock your team, you try to communicate with others, but you are not the one figuring out how something should work.
[00:13:01.930] - Lina Zubyte
Yeah, exactly. In that case, what we also joked about that this person should become an engineer because they should then create the solutions if they really want to do that. You mentioned that PM role is a lot about understanding what is valuable. So when it comes to building products, how can we best understand that what we are building is actually valuable?
[00:13:29.650] - Andrea Sipos
Maybe the simple answer is of course there are also it depends on the story. But the shortest answer is that you need to test things as soon as possible. A lot of companies, teams make the mistake that they only release something that is completely polished and perfect and then wait for what users say about that. And they don't really involve people in the development process. The best you can do to make sure that you build a great quality product is that you involve your target customers as early as possible in the process. You can run quantitative and qualitative tests. Qualitative tests means that you try to get as many learnings and insights as possible about what people think about your product, why they like it, why they don't like it. So you understand the whys behind or the reasons behind things. Like you test the product by showing it to users and ask them for some kind of commitment. Like you show them the prototype or the MVP or however we call it, something that works. And maybe you ask them to recommend it to a friend or just register and start using or something like that, which requires some kind of commitment.
[00:15:04.680] - Andrea Sipos
And if they are able to do that commitment, then that means that you can deliver some kind of value for them. But you can also run a lot of quantitative tests which is more about evidence that it works on a bigger scale. Because when we test qualitatively, maybe you will talk with five or ten people, that doesn't mean that it will work for hundreds of thousands. But once you achieve something which that five or ten people like, then that is a good indicator, that okay, it's not that bad. We can maybe run some A/B testing or we can set up a bigger invite only user group or we can start like a beta tester community or something like that. And then based on how they use the product, you get the data and see if what you want to achieve actually happens and people come back and people do the actions that you want them to take. So there are various ways. Now, I just told you very few examples, but if somebody is in these shoes you can find lots of lots of ideas how to try to test the value and try to test your product before investing lots of energy and time and money into it.
[00:16:37.230] - Andrea Sipos
I have a good example for this which can resonate with QA and engineers. That testing value is very similar to testing for bugs. Just when you get the product itself wrong: it's very similar to discovering a bug only in production. If you build a feature which nobody needs or people want it differently, that's very, very expensive to discover only after launch, after the product is marketed, after you built up the whole marketing campaign and whatever. But if you discover that value bug, if we can say that early in the process when it's on the drawing board of a designer, that's much, much cheaper to fix it than once it's out there. So it's very important to start that validation as early as possible.
[00:17:41.170] - Lina Zubyte
Absolutely. It's actually one of my selling points about moving the QA process much earlier and shifting quality left. Because when we find a bug in production, it will take lots of time and rework as well reprioritization to get this fixed. But if we haven't even started working on it, it's great we can just fix this bug before it even appears, right? So we actually adjust the idea accordingly. I love collaboration in this part as well and making sure that the requirements are nice. And you said really nicely that it's a lot about testing. It makes me think of a lot of companies going with gut feeling. PMs as well, not always doing the best kind of or best educated work by just guessing. They would just guess what customers need and think that they are representing the customer. Well actually none of us know exactly who our users are. We may have a guessing, we may think that we represent some of them, but maybe not all of them. And talking to them is the best way to understand it. We had one episode of Quality Bits with Nadine Oldorf where we spoke also about building the right product and she mentioned as well continuous discovery. So that a lot of companies don't even do it, they don't really test as much and I really liked your mention of qualitative and quantitative research for that. So if you got to work on a product in a very early stage, are there any kind of principles that you would recommend to guide the product building in the right direction? Apart from of course testing it and doing research?
[00:19:33.990] - Andrea Sipos
The principles I think are very similar. So you still need to spend time with your users and you need to generate as many learnings as possible. But I think when it's an early stage product it can really easily happen that the team is falling in love with the solution, with the ideal solution in their mind and then they just lose sight of the problem that they want to solve. If you have a laser focus on solving the problem and you are not attached that heavily to the solution, then you have better chances to be able to do a pivot or anything that is necessary in the early stage of the product. There are a few products, even well known products, which started very differently from what they are today. YouTube, for example. If I remember well, that was originally some kind of dating site and they had this ability to stream videos properly. And then there was the Super Bowl where there was the incident with Janet Jackson's dress and then they just wanted to put the video up there somewhere and then they started collecting and streaming like videos on YouTube and then it became video platform.
[00:21:08.950] - Andrea Sipos
It had a completely different solution. They even pivoted the problem. So you need to make sure that you focus on the problem. And the other thing that can happen in all the stage product is like that you polish it endlessly and you want to make it perfect. But maybe even a smaller thing or a smaller focus or something which is closer to an MVP or a minimum valuable product can give value also for users. And you can start learning much earlier if you release it sooner. If you work on a digital product like an online course, of course you can do it very complicated way like setting up a perfect studio and lightning and cameras and have perfectly designed slides and cut the video with inserting different images and different camera angles and whatever. Or you can just open up a Zoom call, create a .ppt and then just say what you want to say and of course the end result will be different. But you can deliver value with a much smaller scale and you can validate your idea earlier.
[00:22:30.770] - Lina Zubyte
I really like the idea of validation and shipping the smallest possible product. I feel like often companies cling to that idea of the perfect product, as you said, and trying to deliver this big piece of product. But Sheryl Sandberg has said "Done is better than perfect. Aiming for perfection causes frustration at best and paralysis at work". I feel like a lot of us struggle from perfectionism in general. We want to deliver something that we're proud of, but in a sense we will not be proud of if it's just sitting there and not even out there and not getting any kind of feedback. So with this situation where actually some stakeholders as well in the company may expect a perfect product to come out to the users where they are really concerned about their reputation, how would you tackle influencing the stakeholders to release much smaller piece to the customers?
[00:23:36.870] - Andrea Sipos
There are a lot of elements there. Of course there are environments both like business environments like B2B or specific sectors of B2B, like banking and things like that, where you simply cannot do that. So you cannot release all the time or cannot experiment that heavily because of the regulations or the industry. But when you could, I think it's very related to the culture of the company. There are cultures where experimentation or rapid learning is something that people encourage to do. Like if you think about companies like Netflix, they run hundreds of experiments constantly in the product to figure out what is the best. So basically they are used to this uncertainty that we don't know what will work, but we try. And there are organizations where the environment is less about learning and more about shipping products. That's very hard to change because you need the buy in of the leadership, the C-suit that from now on we will operate completely differently. I think by now there are lots of lots of examples out there in the industry that teams who are encouraged to try and learn and fail and then try again will deliver better results.
[00:25:32.740] - Andrea Sipos
Because if you just look at it like, what happens if you don't try and don't try to fail and don't try to experiment very quickly? Then you are just sitting on an idea that you deliver and then you wait for the results and maybe it turns out it doesn't work. And then what? Then you were doing something which people didn't need and that's a complete waste of time. So even from financial perspective you can save a lot of money by figuring out what works and what doesn't earlier before investing the time and energy of lots of teams in something.
[00:26:17.450] - Lina Zubyte
It reminds me of my favorite quote which is "Ever tried, ever failed no matter. Try again, fail again, fail better." I always found it so inspiring to explain as well this fail fast approach that we're basically learning how to fail better and we have to learn because otherwise we will not progress anywhere. So when it comes to not only new products but these legacy products, what could we do when we get to work there? And maybe we are facing lots of old decisions which we do not necessarily agree with. How would you approach the product like that?
[00:27:03.750] - Andrea Sipos
Yeah, in case of legacy products I think it's very important to differentiate between we do things that way because that's how we used to do it or we do things that way because that's best for the customer. Whenever I start working on a legacy product and that's funny, how do you define legacy product? Because I heard that saying once that every code that is not written by me is legacy and I think it is the same for products. Like every decision that you didn't make but somebody else did is like some kind of legacy for you that you need to deal with and you need to understand. But when I start working on a legacy product and most of the stuff that I'm working on is a legacy product from that perspective then I really like starting with running some usability tests to see how the current state of the product resonates with users. Invite a few people in, show them the app. Go through that, start collecting feedback. I really like looking at our existing feedback pool, the reviews for customers or the messages on the customer service, and just read them through what people want, what people complain about, or what people like.
[00:28:31.120] - Andrea Sipos
And then you have a general idea of where you are with the customers. And starting from that, you can form hypothesis, you can form a few ideas, like what needs to be done, and then go and see where the company is, what are the plans, what were the decisions, what is the strategy, why we don't focus on this and that, and you can start questioning. In some cases, you need courage to change or break things, change the status quo. Just because we did it this way earlier, we don't need to continue that. But here also, testing is very important, whatever ways. I've worked in organizations which were not really up for getting user feedback as quickly as possible because the general knowledge was like, we know what needs to be done, but I did it anyway because I needed it personally and I could prove that it improves the process. So you can always introduce new things, new ways of thinking, if you don't agree with the current one. I think people recognize that change is not necessarily a bad thing, especially if it brings value. So it's always worth a try and you can always bring in your new ideas, even if it's a so-called legacy product.
[00:30:12.050] - Lina Zubyte
I love the mention of courage, and in the previous episode with Rouan Wilsenah, we also spoke that courage is actually one of the extreme programming values. So we have to be courageous to change and to adapt. And this very nicely aligns with the product value as well, to change and adapt. You recently said that you'd like to strengthen awareness of product domain to more people. And one of the things that really struck me was that you mentioned that you would like to share your knowledge to Hungarian market more as well. In the world where we are trying to be so everywhere and reach out to the fandom all over the world, what made you think that you could start with the Hungarian market? And could you tell me a little bit more on that?
[00:31:08.390] - Andrea Sipos
Sure. I think lots of disciplines in tech go through an evolution. First, there are only a few people who are aware of it and practice it, and then they start evangelizing. Teams start to see the value. The companies will see the value and invest to it and hire people in that area. And I think that's what every discipline went through, like product design and UX and data analysis and everything like that went through. One day, it's like why do we do user research, and now every company has one researcher, at least hopefully. So it's an evolution that all of our roles go through. And product management in Hungary is still not very big. Now it's bigger than when I started. I started ten years ago when not many people, not many companies have product managers and there was no accessible knowledge in Hungarian. So the ones who practiced it, we all went to learn from people like Marty Cagan or Jeff Patton. And that was all. We had a few meetups where we experimented with presenting in English or in Hungarian, and it was always like a debate which language we should use. And on that meetup that I had earlier we always presented in English, but I felt that not that inclusive in Hungary, where of course in the tech industry you are trained to speak English, but not everybody who is working in the tech industry is working for a US or a European company. There are lots of Hungarian companies here where people never have to learn English on a working level. So how they will access the knowledge? They won't if you don't translate it to Hungarian. And in case of product management, there is not many materials still. There are a few articles, but that's all. Last year I had product management course in Hungarian and I was overwhelmed by demand. 60 people joined the course and they mentioned that this knowledge was not available in Hungarian before. So I really want to be surrounded with great products, even in the Hungarian market and would like to help people who face this language barrier. So I would like to continue this work. So that course was a great start. It only did just two cohorts. But I would like to communicate more in Hungarian and write more articles, blog posts and just have people building great products even if they are not comfortable speaking English.
[00:34:16.930] - Lina Zubyte
I love it and I think very often we also may think the opposites, right? That we're more maybe inclusive, we speak English in the meetups, so then we can involve more people, which is yes, but also we should spread knowledge in our native languages. Your example made me think also of Lithuanian market, because I'm Lithuanian originally and the fact that I wouldn't even know how to say some things in Lithuanian, some terminology words that we use in tech, as well as very often when we drive change, we work with all kinds of people. So we may need to drive these ideas and influence more in allso our native languages, which could be very helpful for the overall change of companies. However, this podcast is in English, so I also was wondering if you have any recommendations of articles or books that you would like to give our listeners when it comes to building great products.
[00:35:21.590] - Andrea Sipos
I have a few in mind. There are two books which I really like. The first one is classic and everybody is recommending that, so I will do the same. It's called "Inspired." It's written by Marty Cagan. It's basically the foundation of product management. So it has lots of material about how product teams work, what are the necessary, what are the use of discovery techniques, how you can figure out what customers want. And there is another one which is a little bit wider scope. It's the book called "Build" by Tony Fadell. Tony Fadell is the person who led the creation of some iconic products like iPhone and iPod. He doesn't only focus on building products, but also how to manage a career in tech. So it's a pretty wide book from topics perspective, so it covers a lot of things and it's very very useful, I think, for everybody who works in the tech industry. But if somebody wants more frequent content, I can recommend a blog from Teresa Torres and Lenny Rachitsky. I hope I said his name well. These are blogs/newsletters providing really great insights about product management and building products with users in mind. I really love all of these.
[00:37:08.710] - Lina Zubyte
Awesome. Thank you so much. We will add this to the notes of this episode and I feel like it's a good time for us to come full circle and to wrap up the conversation. So I always end the episodes with this one biggest question of all. Likely worth a million dollars, which is, what is the one piece of advice you would give for building high quality products and teams?
[00:37:36.930] - Andrea Sipos
I think it would be that quality takes time, but it's worth it because you need to spend time on understanding user needs. And sometimes it seems that this is a slow thing because you need to research and talk and whatever, but it gets you to write product or the best product faster and the overall time will be much shorter, but you need to invest. You shouldn't say that we don't have time for quality because that's what will sell your product at the end, that this is something that users can love because it's always there for them, it knows what they want and it provides the value that they expect. So you need to spend time on quality, on company level, on team level and on personal level. You should not rush. You should take your time and build things carefully.
[00:38:42.470] - Lina Zubyte
Great advice. I love it coming from a product person as well. Thank you so much for your time. Andrea.
[00:38:50.410] - Andrea Sipos
Thank you. Thank you very much. It was a very great discussion.
[00:38:55.050] - Lina Zubyte
That's it for today's episode. Thank you so much for listening. You can find lots of great resources in the episode notes. And until the next step, do not forget to keep on caring and building those high quality products and teams. Bye.
