For our first episode of the podcast for product managers, the Product Drama Podcast (PDP), we invited Harshil Paliwal to talk about the specifics of internal product launch and business process automation challenges.
Here's what we covered:
- how to help employees see the benefit of work automation?
- how should workplace culture adapt to automation and transformation?
- how to find the right DevOps tools for your team?
- what is the importance of detailed project requirements?
- how to motivate employees to adopt new technology?
- what are the challenges in launching an internal product?
- how to train the team on Git?
… and more.
Harshil also shared her valuable lessons learned as a product manager:
When it comes to motivating people to start adapting new processes in the workplace, show, don't tell. Once you show how easy those tools can be, the team will willingly start using them.
As a product manager, explore and research as much as you can. The requirements have to be crystal clear. Requirements engineering is not boring; it can be fun. Even if you planned everything carefully, something could go wrong. And it's okay.
Click on the video below.
The stuff we mentioned on the show:
View Harshil’s profile on LinkedIn
Anatoly: Hi. This is a podcast about effective remote product development. This is Kate.
Kate: And this is Anatoly. Hi.
Anatoly: And today, we'll talk about the specifics of launching a new internal product.
Kate: Today’s guest is Harshil. She is a product manager at Fitsurance, and Harshil will share her story with us. Hi Harshil
Anatoly: How are you doing?
Harshil: Hi, guys! I'm doing good. Thank you.
Anatoly: So, would you please introduce yourself. Maybe we've missed something?
Harshil: Of course, yes. Hi all! My name is Harshil. I am currently doing my master's in business informatics at Utrecht University. However, before this, I have worked in the industry for four years, during which I managed two projects. I worked as a software developer, and eventually, I moved to the position of product manager. And, yeah, here I am, telling my story. Currently, I am also a part-time product manager at Fitsurance.
Kate: Can you share a little more about the project we will talk about today?
Harshil: Sure. So that project that we built in my previous company was an automation project where we tried to bring in a lot of DevOps tools to automate the whole deployment cycle, to be precise. So it was a closed tool used in the company to make budgets, do forecasting, and all finances. They had many scripts within this closed tool, and we tried to implement a lot of repository management and version control and all those principles into it to automate the whole thing.
Anatoly: Can you share more about the goals of the project? Why did your company start it?
Harshil: So, the main aim of the person who started it was to bring in the culture of automation. A lot of tasks we were doing manually. We had two different teams. One was a full-on built team who used to code, code, code. And one was a full-on support team, which used to deploy all the applications into the production environment. So, just like we had dev tested the product, we had those environments in our company too. But you know what happens across the environments? It is too complicated to maintain consistency. Whenever the person is deploying something, it is an all-day task, and you have to look at so many variables, maintain so many things. Sometimes this is failing, and that is failing, and at times, when you deploy something and it fails, you try to fix it on the spot. So the consistency is lost in that process, and the one thing that is not the same across all the environments is what we wanted to change. We wanted to bring in consistency using automation.
Kate: So, basically, you’re talking about process automation. Sounds very familiar because I remember that you were talking about process automation in our company about a year ago, right? You see, I’m not a technical person, so it’s exciting for me; why is there so much buzz around the process automation thing in the company?
Anatoly: I can share my story. I was running all over the office trying to engage people and “join my side.” I was impressed by some TEDx videos, and I thought: “This is a good thing that we can have with our clients and help them save more money in the long run. It’s a good one when you do a long project, not like a three-month thing, but many, many years, and it starts paying off quickly. The more you work on the project, the more you save.
Harshil: Actually, that is so true. You can’t set a date when this whole automation is complete because it just happens as you move with the processes. So you build a small feature, and then you try to improve that feature and build more features on that existing feature. So, yes, it is like Anatoly said; it can’t be quickly laid. It can be quick, but it just goes for years and years. You can’t just say: “oh, it’s just for two months.” It can’t just happen like that.
Anatoly: Can you share a little bit more about how you guys prepared the requirements? Because it's a long process that involves lots of parties.
Harshil: Oh yes, of course. Requirements engineering is one of my favorite parts of product development. People find it boring, but it's the most fun when you go around and talk to people and understand what their problem is.
So, as I told you, the tool is used to do multiple things like budgeting, forecasting, and different things. So, we had five teams using this tool across one set of teams. And we were forced to select one team for them, and we made a huge excel document, wrote down all the features that needed to be automated, and took around three months. After that, we researched what DevOps tools we wanted to use because there are so many tools these days. For version control, we had Git, Mercurial, SVN, Perforce. Oh my God, it’s overwhelming, and you need to narrow down what you want to use, where you want to use it, and prioritize everything. So, yeah, that’s how we went; we just went to the manager of each team, wrote down the requirements in that big excel sheet, and prioritized our requirements according to the conversation that we had with the managers.
Anatoly: Would you mind sharing what tools you have stopped in?
Harshil: There were some tools that we're compliant with the company, so the company had a list of tools, which we can use, and which the company license allows us for. So we used Git for version control, and then we used TeamCity to build automation. Then we used Nexus for our repository management and Nolio for the ultimate deployment of code into the production environment. So there were the four main tools, and then we explored some more, but then things happened… So, yeah, you keep exploring.
Kate: By the way, you, as a product manager, what tools do you use daily? What tool would you recommend?
Harshil: So the very first tool I recommend is Git. I have used it, and I have tried to train people on it, and it's so easy to learn. I mean, of course, there are some tricks within it, and you’ll get it while you go on the higher levels with it. But even at the basics with it, you have to have Git because you can use its command line, and also it has a very nice user interface GitHub desktop that you can use, and you can manage your whole repository or your whole code on it. It’s just if you follow the rules correctly, like you don’t just merge anything into any of the branches, you can maintain such a nice amount of code consistency across everything.
And another very nice tool is Jira, and Trello is also quite popular these days. Jira can be linked with Git and automate our stories and our code in that way so that every story has a code linked to it, so as you move the Jira, the code moves forward. That was a very nice thing to keep track of.
Anatoly: Yeah, we use Trello a lot on our team.
Kate: I love Trello. It’s so nice-looking. And especially when you drag the card to “done.” It’s so satisfying. But getting back to our requirements, I wonder if there is a common practice to requirements gathering? So how do you guys gather requirements? Maybe you can share some of your experiences?
Anatoly: I don’t think that there’s a standard. But I guess that's exactly what Harshill mentioned: we try to involve all the parties, including management, to achieve the same goal. That’s how it works for many companies.
Harshil: I agree with Anatoly on this one. There are so many business domains, and then you have to interpret their requirements into the technical domain. That alone creates a lot of branches within the requirements themselves.
So, let’s say we wanted to bring in the culture of automation that was their requirement, and then within the team, they had their technical aspects that you need to take care of. So, you know, this is just basic: talk to as many people, gather as much information as you can about the tool, about how the teams are working, and then move on from there.
Anatoly: Can you please share a little more information about how the tool's implementation went? How long have you been planning to spend on it, how long did it take to implement it? Maybe, some funny stories around that?
Harshil: There are so many stories, but the one thing you have to know is that: when you say the day you’ll implement it, it never happens. The date gets pushed because things happen and projects get delayed. For the implementation, I learned that it is not easy to motivate people to accept new ways of doing something they have been doing for so many years. So, this is something that you have to keep in mind even before you start a project. You have to take the steps very carefully to motivate those people that you know. There will come a time when you have to change this, so you can start preparing for this from now on. For example, for the first team that implemented the whole automation flow, I had to train people on Git. I gave so much training on Git. My condition was, “even if at 2 am you wake me up from sleep and you'll ask me to train you on it, I’ll start to speak and train you on it. It was so good and tiring.
It took around a year and a half to get from requirements to build the tool and integration phase.
Anatoly: So true. I mean, you usually, even if you try to estimate very carefully, you’re still over those estimates. For me, it’s just either requirements change while you’re doing the projects or something else is changing. Or you were just wrong with your estimations. It happens that it just takes more time.
Harshil: The worst thing is that if the person responsible for all these leaves, like the DevOps expert, is like, “oh, I’m resigning, I have another good opportunity.” And you like “What”?
Kate: I think this is like the risk section when you have to manage all these risks, yes? And also, consider all these potential risks when planning something: your roadmap and project.
Anatoly: Yeah, but the key people usually don’t leave, and this is actually kind of a tricky situation when the main expert is living. So, you’ve done your job, what’s next? Let's make it the main topic of the discussion: how to make people use your product? Especially when it’s an internal product. What did you do?
Harshil: Well, I wish we could have done to make our implementation phase easier. So, as I said, we had five different teams, and what we did, we tried to build the whole system, and then we went to the team, and we were like, okay, now learn these four tools and implement them and try to change processes. Try to adapt to our automated process. And it's not easy. What we could have done when we started the project was: first we implemented Git, then we implemented TeamCity, the Nolio, then Nexus. So, we could have identified two key people in that team often and would have trained only those two people instead of going ahead and saying: “oh, all these ten people are going to listen to us.” No, it doesn’t happen. You can change one person to change 10 people. It is a different kind of job. So, yes. This is something we could have done, and that is for sure going to be the next step when I’m through with my current product that I’m working on. So yes. That is how the implementation went. But it was like a lot of time me running around people’s desks and saying: “oh, you just install this, use these permissions” When you’re in a big company, not everything is accessible to you. You need to have many permissions for all those criteria that your system must fulfill before you get an account even to use that tool. All these formalities come in the way of integration, so it is a bumpy road. Building the tool is easy; integrating is hard.
So, you were running between teams and making people or forcing people to use the tool. And they were saying “no, no.” Oh, they would say “yes,” and when you were leaving the office, they were like: “ah, come on.”
Harshil: See, what will happen if you want to remain consistent? The first thing you’ve to do is push it on Git. But the past practice was that they copy folders from one environment to another, and then they will be done with it. So, they will be like, “if I can do this, why do I need to learn Git?”
"To maintain consistency."
“Yeah, but this guy sits just next to me, and I'll tell him what’s different.”
“No, things don’t work like that.”
“Why doesn’t it work like that. It’s so simple right now. Why do you want to make it complicated?"
Kate: So how to stay calm, and continue explaining. How did you manage all this motivation?
Harshil: That’s where managers come in. So the one thing that went wrong was with the person who started all of this. He wanted to implement all of this and hired me to do it. But he left the company midway, as he was promoted to a higher position and moved to the UK, and I was in India when all that happened. And the team was like: “okay, we were doing this while he was here because he told us to, and now he’s not here anymore, so why do we want to do it?”. So I went to my bosses, and I was like, you know, this is why you hired me, and this is why I’m doing this. But I built that thing, and nobody’s using it. So please say something to them or give me some authority to push them to do this. And then in their yearly goals, it was written that: “you have to help Harshil to implement this as nicely as possible.” And that is when they were like “okay.”
So the situation was that I used to run around them and say to give me one hour in their time slot in their calendar. So after the goals were set in their calendar, they were like, “Harshil, would you like to have a meeting regarding your DevOps thing?”
Anatoly: How could we avoid this situation and approach the solution to the problem? I mean, the two teams started using the tool without a manager. What do you think, what should be different?
Harshil: The first thing, it has to be a proper authority to motivate people to continue to do their tasks because that is how it is. If there’s no force behind you, then you won’t just move forward in that direction. So, that is one thing that you have to be sure that you have that kind of managerial support. And the second thing is that not everybody is enthusiastic about technology, but in every team, you will find one or two people who want to try new stuff. Identify those people and make them work with you. So, if you have, like in the build phase, contact those technical enthusiasts, they will have a welcomed product, and they would have been like: “now it’s done, now I can use it, and automate my things.” This is something that you have to identify and do.
Kate: How to motivate people to use new tools? How to not be afraid, how to try something new? Maybe you have some experience from your previous projects or current projects?
Harshil: It’s more of “show, don’t tell.” The moment I showed them how easy things were, like “oh, okay.” Before, we had lots of presentations where we showed what would be automated, using big terms like DevOps and repository management and stuff like that. But the moment that I showed them that with the click of a button, you could deploy your code using TeamCity and Nolio. This is how easy it is for you. You need to sit and click the button and wait for the screen to turn green, and this is all you have to do. So show, don’t tell. Because people are in their jobs, dealing with their complexities, and you don’t want to bring any other new complexity in their life. You want to say that it's something easy and you should try to use it.
Anatoly: So, lessons learned. If we sum up, what are the three main lessons that you learned as a product manager while you were launching this internal product?
Harshil: The first important lesson is to explore as much as you can. The requirements have to be crystal clear because there were times when we rewrote the code so many times, so I was thinking that “I am doing the same things for six months, and the year and a half past now, what am I doing? I am writing the same code and just changing it”. So that is the one thing. I know that requirements engineering can be boring for some people, but it’s not. It’s fun. If you look at it and define very crystal clear requirements, it will help you. The second is to make it easy and show, don’t tell. Show them how easy the tools are for them. And three is something that can go wrong. It just happens. It happens to everybody, and it will happen in the future, no matter how much you plan. The lesson that I learned is that it's okay if something goes wrong.
Kate: I have a question. Could you please recommend any resources: what you read, listen to, and watch regularly?
Harshil: The best thing to do is attend the page on Linkedin called IIBA (International Institute of Business Analysis). They have many webinars where people come in, share their experiences, listen to their tips, and so on. And another, before I came into all of this, I did many courses and training that helped me a lot. But, you know, talk to people, that is all I would like to say. Talk to your senior managers. People are so intimidated by their senior directors and managers. But when I approached one of them and asked to have a video conference, he agreed. In the video conference, he said that there are 25 people in your team, and nobody came and asked me for my advice on how to move forward, and I would love to give some advice. If you want to be a product manager, talk to your manager. They are waiting there to guide you and see you grow.
Anatoly: That was a fantastic talk. So, thank you for joining us today, and see you guys all in the next episodes.