Founder of Rottie Consulting LLC, Gabriela (Gabi) Vandermark, discussies Lean Product Development with an emphasis on Product Owners. Rottie provides consulting services to a variety of industries specializing in IT Project Management & Delivery, Technology Leadership, Organizational Change Management, Leadership Coaching, and International (South American) Relations.
Download PDF Transcript of Podcast
Related Podcast: Taking Ownership of the IT Project
Note: This is a transcription of an interview. It has not gone through a professional editing process and may contain grammatical errors or incorrect formatting.
Transcription of Interview
Joe: Welcome everyone! This is Joe Dager, the host of the Business901 Podcast. With me today is Gabi Vandermark. She is an IT Consultant at her company, Rottie Consulting. Her appreciation for operation excellence was realized at Nationwide Insurance and since then, has been working with clients primarily in the banking and manufacturing industries, with significant international business experience in Brazil and Chile. Gabi, I would like to welcome you and could you fill in any gaps in that introduction and give us that elevator pitch on your company, Rottie Consulting?
Gabi: Thank you, Joe. Rottie Consulting is just me for now. I started about two years ago, and I am on my own, working with many different companies here in town, Columbus, Ohio but also helping companies enter the South America market. I find that there is a little bit of challenge in that sense and with my background, the fact that I speak the languages, I’m able to help them succeed in some of their projects.
Joe: I have to ask you, the nearness of Portuguese to Spanish, but I was sure Portuguese was kind of difficult to learn?
Gabi: I was born and raised in Brazil. I lived there until I was about 18 when I decided to come to the United States and go to college. Portuguese is my native language, and I learned Spanish a little bit in school and over the last couple of years working with this current client. We had implemented a system in Chile, I’ve improved my Spanish since.
Joe: Well your talk at the Center for Operational Excellence at Ohio State this Spring centers around Lean Product Development and it seems that everything is either Agile or Lean these days. Can you add some definition to your interpretation of that?
Gabi: I typically try to work from multiple methodologies. I try to learn a little bit from everything and apply what makes sense to the current situation I’m in. Typically when I go into a client, and they say, “I want to do Agile…” I have to ask them to take a couple of steps back and start talking about what’s the problem you’re trying to solve. Not everything needs to be Agile or Lean; we really need to focus on the business problem. Maybe Agile is the right solution; maybe Lean is the right solution, maybe a combination of the two, but the most important thing is really understanding the problem you’re trying to solve. And Nationwide, when I worked with them, Agile was the solution for us. I had a large group of people that worked really hard, but every time we would release something to production, our business partners would always look at us like we haven’t done anything, and I’ve realized that we weren’t delivering value, and Agile was all about that – focusing on delivering value and what’s the most value for the business. So for us, it was the solution.
Joe: I had the pleasure of previewing your slides before your presentation and you discuss something that popped out of me that was different. When you talk about waste in Lean Product Development, you mention Reusable Knowledge. Is that a major waste? Reusable, what does that really mean?
Gabi: Reusable Knowledge is actually the focus that you should have in Product Development. Lean Manufacturing, the focus is on removing waste, but in Lean Manufacturing, you already have a product developed, and a product identified. You’re really just finding a way to produce that and deliver that to your customer in the fastest, cheapest, quickest and most quality manner. For Lean Product Development, you’re discovering. You go from an idea all the way to market launch and to do that, you need to reuse knowledge because it’s a set of experiments. It’s that iterative process where you need to learn as you go so that you can ultimately come up with a product that is ideal for the market. In Lean Product Development, the focus is really on Reusable Knowledge. How do you share the knowledge that you gain through your iterations of that product with your entire team so that everybody can benefit from that, and even more important is how can you share that knowledge that it can be validated and complimented by other people’s ideas.
Joe: Reusable isn’t something that is stale; the existing knowledge over in a file cabinet that you’re reusing. It’s something that you’re creating.
Gabi: Correct and the key here is collaboration. One of the important things in Lean Product Development and Agile, in general, is how do you collaborate with your team? If you’re all collocated, it becomes not easy but it becomes a little bit more natural. You can implement visual management systems where you expose your information on boards and stickies and make it very visible to the people that are there. In my case, when I work with international projects, it becomes a little bit more challenging because we’re not physically together, but collaboration and communication are the keys to that reusable knowledge, so it doesn’t become stale.
The way I do it typically, I find ways of translating the visual management that you would think of – whiteboards and stickies to an online version. Not to plug anything but Trello is one of the tools that I use. It’s very easy to use; anybody can jump in there, and there’s a lot of flexibility to build the boards that you need. For my projects, when I’m working with people in South America where communication and collaboration are key to making sure that that knowledge that is gained, one, is spread out to the team, and two, it doesn’t become stale as you mentioned.
Joe: Much of a consultant’s role is relationship and trust building; when we do it virtually, that’s sometimes very difficult to do. How does working internationally as a consultant different for you than let’s say working with a client in Columbus and only in Columbus?
Gabi: Yes. There is nothing like a face to face interaction, a handshake, or a hug, or whatever the culture accepts and requires, that face to face interaction is absolutely important, but you also can’t afford to travel every day to another country to see your client or see your customer. What I typically do is I combine the two. You have to find ways to build a relationship up front with some face to face interactions and then maintain it throughout with whatever online tools we can find. Video chat, I spend most of my day on video chat. When conversations need to happen, that if I was around somebody, I would maybe call them into my office, shut the door, a one on one conversation. I typically choose to do a video call. There is that face to face. It’s not as warm as being in there with someone, but you can still see their facial expressions, and it gives you a little bit more of a sense of being close to that person.
But upfront, it’s important to be together and especially when you’re going through sessions where you’re designing something or you’re starting a process. A lot of times in Lean Product Development, I would always suggest to a client to start with a vision. The vision not only for the product, especially for the product but also for the team that’s going to be building that product. In those sessions where you’re defining a vision and maybe defining an identity for that team, it definitely needs to be face to face.
Joe: In developing a team, you’re just not ending up with an existing team, let’s say in Brazil that you have to work with and then six months into the project, you meet them most of the time, you’re at the very beginning. You’re trying to meet that team in some capacity as visually or face to face if possible.
Gabi: Absolutely, yes. Typically what we do is we identify who the team is, who are the members of that team, and plan a first meet and greet in person to validate that that team makeup makes sense. A team is one of the most important things for Product Development or any sort of project. You want people that are dedicated and you also want to explain to them the ‘why.’ Why are we doing this? Why are we putting in a brand new URP system that’s going to change your entire life? There have to be ways to you connecting with that team to explain the why. They may not like the why but understanding the why will at least help them deal with that change and be focused on the project. Definitely upfront, a face to face interaction as quick as possible with enough information on my back pocket about what we’re about to execute. Because also meeting the teams without having enough information, just to sit in front of them and say I don’t know, I don’t know, I don’t know – that’s not worth it. When I do meet the teams, I need to be prepared to answer a lot of their questions about what we’re about to do.
Joe: Do you find that limiting the size of teams is important, even more internationally?
Gabi: I think the makeup of the team is more important than the size. Having the right people doing the job that one, they’re good at, and two, they like to do, is more important than the size. I do tend to try to build smaller pockets of teams, if I have a large number of people, so that they become self-organized in their little groups and it’s easier to spread that knowledge and reuse knowledge. But when I do break into smaller groups, I have to find a way to bring collaboration amongst them. When I was at Nationwide for example, I had three different teams. Two in the US, one offshore, and collaboration communication was a constant job for me or a constant task for me to bring those three teams together to make sure that they were talking amongst themselves, because all three of them were touching the same product. That becomes kind of my role, as the quarterback of bringing everybody together and making sure that collaboration exists.
Joe: What do you find is your biggest challenge?
Gabi: Typically my biggest challenge is understanding from outside of the team. In the beginning when you start a project, you know what you’re trying to do, you get the right people on the team, there’s a little bit of resistance – with any change that will always happen, but if you have the people doing what they like to do and what they’re good at doing, the teams itself will eventually evolve and become self-organized, and people that can’t fit into that makeup will either leave or find something better to do. Now the biggest challenge then becomes when you have a team that’s excited and ready to do the work but the external factors don’t understand how that work is being done or sent some expectations that are unreasonable.
I’ll take the Nationwide exam once again, I lead my team through a transformation to use waterfall methodology to build our software and that didn’t work for us and we decide to transition to Agile. We did it, our team was excited about it, it took about six months to get a point where we were self-organized and introducing advanced techniques into the team but the external factors, the other teams or the other managers and people outside of our team had a hard time understanding how we operated because it was new to them. So that then became my job – not looking away but kind of looking outside of my team and doing a little bit of education and training and really communicating what is it that we’re doing and how does that work for me. Because we were no longer producing those massive requirements documents or our output looked different than what they expected, and they couldn’t understand how that could be a sign of success.
Joe: Does Agile make a product owner’s role more difficult or easier?
Gabi: Typically in Waterfall, the role of a product is not very apparent. You have a project manager that’s leading the project from beginning to end, you do have interactions with the business, but there’s not a specific role identified as the product owner. In Agile, you have a product owner and really this role comes from Lean where they define an entrepreneurial system designer and you can think of that person as kind of a visionary, someone that really understands the product and not only the product but also the customer, the users that are going to be interacting with that product. And as a product owner, you’re not just a product backlog manager or user story writer. You should be interacting with your customers, users, and all of your stakeholders to really get a good grasp of what that product needs to be and then your role becomes translating to the team.
The difference here is that in Waterfall, that role didn’t really exist so there wasn’t really a product champion coming in. There was business saying I want this, I want this, I want this, but no one constantly interacting with the team to one, prioritize maybe something that yesterday was important but today is not as important because I’ve had an interaction with my users, and I understand better what that functionality really does to them. Prioritizing is a big part of a product owner’s role, but they’re also responsible for the product success in general. How would this product enter the market or be launched in a way that fits the customer needs and that needs to be translated back to the team that’s building that product. The biggest thing though for a product owner is they have to be empowered to make decisions and sometimes, the answer to a decision has to be ‘no.’ And saying no is really hard, especially when you’re in a large organization and you’ve been placed in this product owner role and maybe you know or don’t know that product so well, so a key thing for a product owner is knowing your product and being able to make decisions. Steve Job says, “Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features.” I think that’s key for a product owner.
Joe: I think that’s a great point because it always seems that with Scope Creep and different features and benefits are always there or what we discover while we’re creating a product, it’s very difficult to keep all that in control and is that the product owner sitting there kind of like with his heavy fist of keeping that in control or how does that work?
Gabi: Yes, absolutely, that is one of the key roles or responsibilities of a product owner. When I work with my clients as I mentioned earlier, the first thing that I think is important for anybody to do is really to understand your vision. Someone is setting a direction of let’s build this product or let’s fix this product or let’s introduce a new system. That vision needs to be captured and understood so that we can stay true to that vision throughout the project. Because scope creep will happen, things will change, but the vision needs to be visible so that when things come into our environment that causes us to ask questions, we can go back to the vision and say, is the vision still valid and if it is, let’s say no to the things that take us away from that direction.
In my talk this week, I will share some tools with the group for product owners and one of them is a vision board, a product vision board where you start with a vision statement, a summary of what’s the idea here, why are you doing it and then also capturing what’s the target group, what is the need that you’re fulfilling, the product itself, top features or unique selling points, the value – if you’re talking about an actual that you’re going to launch to market and sell it, what’s the value in comparison to what’s out there, and then talk a little bit about the competition as well. These five different points about your vision and your product needs to be captured and made visible to your team so that when external factors come in that are just distractions, we can go back to this vision board and say, “No, we’re good. We don’t even need to worry about this because here’s our vision…”
Joe: I heard a statement one time that said – and I’m trying to think if it was directed a vision or a product and I’ll use product for right now, is that you really don’t have a product unless you can say no.
Gabi: Correct.
Joe: It ties into what you’re saying there with the vision statement that that vision should really in essence give you the ability to say no, because it’s kind of clearly stated why it wouldn’t be or why not. Is there any truth in that?
Gabi: Absolutely and there are so many distractions and there’s so much information available to us today that its very easy to get distracted and think that I need to change my course, I need to change my direction, and you end up moving away from your original idea and really losing sight of what you’re trying to deliver here. One of the key things with successful people and successful companies is that they focus on what they’re trying to do. Obviously it’s important to know your competition and what’s out there, but you got to focus at what you do best, and that vision board gives you that fallback. It doesn’t mean that you’re not going to get distracted, but you can always run back to that vision board and say, this is where I started, this is what I was trying to achieve. You can change it, absolutely, but that process of changing your vision should come with some analysis and some conscious thought of why, why am I changing? If I’m changing just because my competitor changed, that may not be the right reason.
Joe: Now you work in the role of a consultant/coach I would assume, how do you interact with a product owner? What kind of advice? How do you start out with him? Do you have one on one meetings with him versus the team, or could you describe that role that you play there?
Gabi: Absolutely. when I come in, I played the role of a Scrum master which is analogous to a project manager on the Agile side, and I’ve also played the role of a coach. Either way, in the interaction with the team and the product owner, a couple of the first things that I want to understand is how did that person end up in that role? A lot of companies that have in the past done Waterfall and transitioned to Agile randomly picked people into that role and that role requires a specific set of skills and those skills are very important. It needs to be available to the person. The person that is playing a product owner role not only needs to understand the company they’re in, the customer, the user, the end-user for that product, but also the product and also have the skills to manage a project per se. It doesn’t necessarily have to be the project manager have a PMP or anything like that, but needs to understand how a structured project works and needs to have a little bit of understanding of user experience and usability because you’re talking about a product that ultimately is going to be used by a person.
That product owner, the first conversation is how did you end up here? When I hear of people that have chosen to go into that role or have done it in the past, really enjoyed that role, the results are a little bit better right away. The people that end up randomly in that role and don’t understand the role, that’s where things get a little bit difficult. And the way that I work with that person is then to help them understand the role; everything that’s required. Some of the areas that they can work on, I help them with some tools, some of the tools that I’ll be sharing this week like the vision board for the product. Other tools that can help them understand what they’re about to do, the product canvas to facilitate the development of a new product. I think one of the biggest things for product owners is understanding how to write user stories because that is the means of communication for an Agile team.
Joe: Well, why is that? I mean why don’t we just have a task board? What’s the purpose of a user story?
Gabi: The format of a user story forces you to think of the user from the product perspective. It states in a way that puts you in their shoes, and I think it’s an interesting format, it has helped a lot of the teams that I’ve worked with. I’ve had teams where we don’t follow that specific format and we do have just task cards depending on the type of project. For example this current project that I’m in leading a BI redesign, a lot of the work is database work, it’s hard to frame it in a user story context. We create functional cards that are not described in the exact same format but the point is breaking it down into consumable chunks. Don’t create a card that lasts a month – that’s not the point. The point here is to create cards that are small enough that you can complete in iteration, a sprint, and iterate through this process and product so that you learn as you go, and you improve it as you go.
Joe: Well I think that’s one of the things that I have seen on Trello working with different companies is that people have these cards that actually don’t move? You’re saying that having a well-defined user story and even breaking the user story into individual tasks if necessary but there have to be cards flowing through the iteration?
Gabi: Absolutely. One of the things that I tried to implement with my teams is the concept of labels. We have all kinds of labels. Sometimes our boards will look kind of crazy with so many different colors and stickers, but it’s important to label things. A card that sits on the board for more than a sprint, something is wrong with it. We have to one, be able to identify quickly by looking at that board that that card has been sitting there for a little while. Two, start a conversation on why. Maybe the card is too large and needs to be broken a little bit further. Maybe that card is not that important because nobody has complained about it, nobody is feeling the pain of having that stuck there. Or maybe we don’t have the skills within the team to get that done. Whatever the reason is, it need to be talked about, it needs to be visible and quickly discussed so that we can get through this blocker.
Joe: Would you say that you spend the majority of your time with the product owner or the majority of your time with the team?
Gabi: It depends on the team I guess. I’ve spent a lot of time with teams in the past when the product owners are really sharp. I was able to focus on the team and help them introduce advanced techniques like test drive development and others. But when a product owner is not able to fulfill its responsibilities, then focusing on the team is only going to take you so far. The product owner is a key role in product ownership and truly owning that product is to me the key success differentiator for a team or a company. If I had to choose and the team and the product owner are both a little bit down or in need of help, I would start with the product owner and make sure that that person understands the roles and responsibilities, has the tools that it needs to do its job and maybe even help that person figure out whether that’s the right seat for them, because there’s nothing worse than somebody that hates their job. So, I would start there.
Joe: Do you have any conflict with the product owner? What are some of the things that you like butt heads on, for lack of a better word.
Gabi: I used to work with an amazing person at Nationwide. She was our product owner and her, and I were constantly at it, but it was good conflict. It was conflict that needed to happen. It wasn’t really conflict per se. It was more she would bring her ideas, and she was a true product owner. She knew the product; she knew the user, and she was there for what she wanted. However, she had a hard time understanding the timing of things and the size of the team and the fact that certain things cost money. She and I will always go at it but we found common ground because she truly knew what the product needed to do and I knew my team and was able to find ways through a resource allocation and different methods to get her and her product where she need it. But other times with product owners, the conflict or the challenges come is back to the same point of not truly knowing the product, not truly knowing the users, and not having that empowerment to make decisions. Challenges that I’ve had in the past as a product owner that it’s not around, so when we need that decision quickly made, that person is nowhere to be found, or that person is there but not sure if he or she should make a decision. I would rather have a product owner that knows their stuff and fight for it and maybe I need to do a little bit scrambling to bring in more resources or take resources out, whatever it is, than a product owner that is there but not able to make decisions. They really, truly need to own their product.
Joe: I think that’s well said because if you don’t have conflict, one of you is not learning. When you have conflict, usually you’re both learning. When I think about this, I think about larger products and more elaborate structure and things like that, is there room for little guys in this collaboration and especially across countries?
Gabi: We got to start with the problem you’re trying to solve. So it doesn’t matter how large you are or how small you are. I think that larger organizations have a little bit of a challenge for scaling some of these methodologies, and it takes a lot of top-down support to get things going, so I actually think that smaller guys can do this a lot easier. They have a lot more control and flexibility on what they can do and not do and a lot less people to spread the information to. But ultimately for me is, what is the problem you’re trying to solve? I would never suggest to a customer or a client to start with let’s do Agile or let’s do Lean because I feel like something is wrong right there. You’re starting with a solution. You haven’t even discussed the problem. What is the problem you are trying to solve? Are you having issues with transparency and are you not delivering the value that your business expects from you? Then, once you start putting in terms of business needs or business problems, then you can start talking about, yeah, maybe Agile or Lean will solve some of that for you.
Joe: I think that’s well said because so many people that I talk to in the Lean world, I said how did you become Lean? Was it an ‘aha’ moment, or a book you read? And they go, “You know, I just kind of woke up one day and found out that that’s what I was doing.” And I think that’s a right way to go into it.
Gabi: And it’s applicable. These methodologies will obviously improve the operations of any company but what I find challenging is that if you don’t start with a business problem, then later on when you ask that question, why are you doing this or why did you begin to do this, you can’t quantify or you can’t measure it and you can’t have a sense of accomplishment. You’re just doing Lean or just doing Agile. I think ultimately, we need to be solving business problems.
Joe: What’s the future for Gabi and Rottie Consulting?
Gabi: Well the future right now looks very exciting. I enjoy being an independent consultant. I’m working with a great current client, and I’m also working on a site project where I’m building a product of my own. I’m hoping to release it sometime later in the year.
Joe: And you’ll be able to make sure how good of a product manager you are then, right?
Gabi: Yes, absolutely. I’ll have to act on all of the stuff that I preach,
Joe: What’s the best way for someone to contact you and learn more?
Gabi: Through my Website, Rottieconsulting.com. There’s a ‘contact us’ page there. You can reach me through that. I think it’s really hard not to reach somebody these days. I’m on Twitter, and Facebook, Instagram, LinkedIn – I mean you name it. I’m on Twitter @gabbivandermark.
Joe: That sounds awesome. I’d like to thank you very much, Gabi. I wish you the best with your new product coming up and in your upcoming presentation.
Gabi: Thank you so much.
Joe: This podcast will be available on the Business901 iTunes store and the Business901 Website. Thank you again, Gabi.
Gabi: Thank you so much. Bye-bye!
Lean Sales and Marketing: Learn about using CAP-Do
Lean Engagement Team (More Info)