People are fleeing in terror intensely simulating labor activity having seen you cross the horizon? The inefficiencies of the contractor are missing deadlines and backsliding on their agreement? All people are crazy incompetencies out there, and you just can’t take your eyes off of the whole development cycle? Yes, the situation is not easy. It is possible that the second side of the conflict also has something to say, though!
Almost 10-year experience in the field of software development & implementation has taught us that a professional relationship is not white and black, you can and should find an approach to any client, and focus on the results if you want the idea to get off the ground.
Nevertheless, with some customers, we had chemistry almost from the first phone call, and as a rule, this was the beginning of a long and fruitful relationship that led to more than one joint project to be released. While someone else made us wade through thorns up to the stars synchronizing our common actions step by step and establishing an effective dialogue.
There may be tons of pitfalls in IT development. But today we’d like to talk about its one of the most important participants - product owner. Who are they and how can they affect the effectiveness of the business plan implementation?
Product Owner: Introduction
It is worth opening any manual of flexible development - and you’ll face them - professional knights in shining armor - the eyes, the ears and the voice of the Customer. They understand the general idea of the project, are responsible for the vision of the final product and its value to the user.
You can talk for a long time about the project, what it should be or not, but here the main thing is that almost everything depends on the actions of the product owner.
And now we ask you to imagine the situation when the product owner somehow stalled the development and it took days, weeks and even months to make it great again. That’s where our story begins.
Image 1. Here is the task, let’s go... Go, go, go!
Once, he swoopes in the developers’ life with a cool project and a chic longread that mostly explains what, how and when should be done. At first, that’s more than enough. But the project is gaining momentum, and the gears of a perfectly calibrated mechanism are beginning to come across circumstances. Some points need clarification, the others have been forgotten at all (since only to Cassandra the gift of total foresight is given, no one ever believes her, though), somewhere our specialist saw an opportunity to optimize the functionality - there are just too many things it could be.
Solution: Good communication. The ideal product owner is ready to discuss current issues with the developers every single day during periods of high activity, after that, as a rule, it is enough to meet once or twice a week. They are able to hear and listen to the team, clarify, concretize and prioritize their actions, and are not afraid of any deviations from the original plan, guided by the principles of efficiency. Again, the ideal owner of the product.
Image 2. Imaginary friend
After all, only some of us can afford to keep their own duties in mind and do them well. While the others are frequently overloaded and are duty bound to spend their time on extraneous questions - and there is nothing to be done about it. But you have to find the way because ignoring the problem won't make it go away.
In one of our projects, for example, the product owner was so busy that he could not answer our emails not only for days, but sometimes for a whole week. As a result, the process was hampered: ready-made features were not approved, questions had a way of snowballing, and we could not take new tasks in order to somehow brighten up the painful moment of waiting.
Our project manager did her best to stay in touch with the product owner via email and the messengers. But it wasn’t a real solution. At best, the product owner replied: “Yes, yes, today you will receive your answers.” The time zone difference added a bit of drama as well: since the Customer’s team was in the USA, “today” automatically turned into “tomorrow”. Of course, we had meetings, but by that time the list of questions had become so huge that it was simply impossible to discuss everything.
Solution 1: Castling. In fact, the problem was solved quite easily. Since our product owner was involved in many projects, it was decided to offload him a little and give our project to another specialist who was able to pay more attention to our team.
Of course, the most specific issues were still resolved with the previous product owner for a while. But one thing is obvious - right after this forced castling, the project accelerated significantly. 15 minute daily meetings do wonders, whatever you say.
Solution 2: Delegation. It is true that overall workload of a project is quite common. And in a similar situation, another product owner we collaborated with decided to delegate the part of his duties to his subordinate. And this is also a good option, except for one thing - the deputy’s lack of appropriate authority (and some experience, cause being a deputy means you want to learn something new from this leadership) to make critical decisions. Nevertheless, such a move helped to significantly reduce the team’s stress during the development process: most of the issues were resolved fairly quickly, features were clarified, bugs were fixed, and the caravan went on. What more could one ask for?
Image 3. Mr. Late
What if your product owner is the fairest in the land providing mission, vision and values of the project, being ready to detail and prioritize tasks, and open for dialogue, but ... Let’s wake up and think about what to do if the product owner is regularly late for meetings, such as one of our partners. There were plenty of reasons for those endless delays and, admittedly, most of them were objective. Thus, there were many force majeure circumstances when he just ran late at some previous and also urgent meetings. That explanation did not brighten our days, though.
Solution: In general, the situation was not critical. It was always possible to shift something in the schedule. Plus, since nobody likes a meeting that drags on with no purpose, writing a meeting agenda facilitated our interaction greatly (when it finally came to interaction).Plus, we could discuss some issues within 20 minutes of waiting and provide a final version.
Image 4. What are you guys doing here?
Sometimes it is difficult for a product owner to overcome their natural distrust, especially when it comes to working with an outsourcing company whose developers million states away are so busy out doing stuff all the time (what if it’s a fake and they are playing solitaire more than working on a project???). In this case, only time can help, which, as you know, not only heals all wounds, but also allows the team to demonstrate their competence.
Solution: To speed up this process, with one customer we had to release step by step every week: it brought him comfort and wasn’t a problem for us at all. In another case, a business trip to the client’s head office was very helpful. At first, the product owner tried to work in a primary school teacher mode: walking around our guys and looking into the monitors, making sure that they were doing their tasks properly. But continuous communication and joint hard work did their job - and we did not raise the question of confidence again.
Image 5. ...And I’m a tech proficient, among other things
It’s no secret that a competent product owner should understand the technical component of the project. In an ideal world, their previous experience in development is even preferred. Nevertheless, the division of responsibilities is a fundamental principle of any team work. Roughly speaking, the encoder encodes, the business analyst analyzes, the project manager manages, and the product owner ... owns :) You should not be embarrassed that some technical aspects are a little out of your league, it's just not your showtime.
This is a subject close to the previous problem of trust. Once, a client had a preconceived belief that IT people, to put it mildly, are... not the most intelligent people. And that at certain points he'll be the perfect man to solve any technical issue.
In such circumstances, it is a bit difficult to show your competence, because when you work for a powerful man... sometimes the collar can get a little tight. Our product owner constantly demanded to provide him an access to various databases, he intended to write queries himself, since our statistics or reports seemed “incorrect” to him.
Solution: Of course, in that situation, we provided access to the product owner. But. Soon after, a series of questions followed: “And what is this?”, “And how does it work?”, “And where should I click here?”, Because the database was rather complicated, the tables had a huge amount of numbers and, of course, it was difficult to work having no specific background.
In global terms, it is important, both in words and deeds, to deliver the information to the client that IT people are not only about code, but also about deep business analysis of the product, development strategy and guarantee of its successful functioning after release. Moreover, in the end, a job is not just a job for us. The beginning of a new project is akin to adoption. It is important for us to get your idea off the ground, make it competitive and as effective as possible. So that we can be proud of what we did.
Image 6. This is how I roll
Sometimes the line between the objective factors affecting product development and the subjective preferences of the customer is blurred. One product owner we collaborated with was an excellent specialist - he described the features pretty well, provided clear and detailed comments, and quickly responded to our requests. But there was one thing that seriously hindered the plan effectiveness: little by little all the features began to adapt to the tastes and preferences of the particular person ignoring the jointly developed and approved strategy for the project implementing. “Something is uncomfortable for me here”, “And here I would like to ...”, “But somehow I don't like it ...” - those were the mantras increasingly heard from him.
Solution: Of course, your project is your child and you always want it to be exactly the way you imagine it. However, it is worth considering the opinion of other participants in the development. Just imagine that your child needs to get from point A to point B by scooter, but suddenly you are told that it’ll be better to use a bicycle, and don’t forget about the helmet! No, not the blue, but the red one. And it might also be worthwhile to include a couple of stops in the route to increase the endurance. And one more thing - your child doesn’t want to be a football player, but dreams of ballet dancing. Now live with it :) We mean, everything isn’t very much without teamwork in the development.
In the case mentioned above - after a while, the Customer was forced to delegate the responsibility to a more objective candidate.
Image 7. Guess what I had in mind?
There’re definitely those moments, like, when the customer cannot clearly imagine how their system will function. In such cases, a lot is expected from the development team that has to formulate a clear concept and strategy for its implementation, which is not bad for competent specialists. But only if the client is ready to accept someone else’s vision of the problem.
In our practice, there were cases when the product owner was entirely for the development strategy, shared our desire to do cool stuff and create the most demanded platform. But this desire was not always accompanied by the information on how exactly this will happen. He could give us a small sketch: "What I would like." But when we came for details, sometimes the answer was “I don’t know what exactly I want, but you think it up.” It was not always easy to work with.
Solution: In that specific situation, we were very lucky: our techlead was pretty much immersed in the business domain, which made it easier to articulate and fulfill what the product owner wanted from us. But this fact did not shield us from various controversial issues during the acceptance stage. Indeed, when even the client himself cannot clearly explain how and what he expects in the end, then “surprises” cannot be avoided.
Image 8. I’m not sure I understand you
Any outsource company, sooner or later, gonna go down the road of cultural differences. And it’s not even a matter of diametrically opposing mentalities - pitfalls are often hidden behind the smooth surface of seemingly common backgrounds. For example, the eternal contrast between American friendly style and restrained Slavic expression is an old true story about misunderstanding. Or concise (and so professionally neutral in some countries) answer “Got it” missing a healthy dose of small talks, all the attention and etiquette issues may not only mislead, but offend your Partner.
Solution: What your client really needs is to be talked to in the language they understand. This concerns not only words, but also the manner of communication. There is a huge number of positive aspects in this approach, because close acquaintance with other cultures only enriches us spiritually and makes us open to the world.
Image 9. Just call me The Slasher
This case is probably the most difficult one. After all, there’s always a possibility for a graceful end to any situation. So long as both sides are ready to be engaged in dialogue and compromise for the common good. But what to do when there is a little bit... conflicting helmsman in the project?
Once we happened to cooperate with a very complicated product owner. Indeed, much more could be said about their pros and cons as a person and a specialist, but the main distinguishing feature that significantly influenced the development process was their short temper and uncompromising nature. Their craving for conflicts was especially intensified during online meetings in conversation, oddly enough, with other representatives of the Customer. As a consequence, working hours used to turn into holy wars about every little thing, and we could only get popcorn and stock up on patience.
Solution: the conflict died down and flared up again for several months until our “problematic” product owner showed himself as a true professional. He made a truce with his colleagues, and they agreed to leave our meetings, appointing another, more neutral product owner. After such a wise decision, the atmosphere in the team became much calmer.
On this, our tale of a difficult client comes to an end. Surely, you have your own stories about the obstacles on your way to successful teamwork and how you overcame them. What is the moral of this fable? There are no unsolvable situations. We will work with you even where others file for divorce, referring to “unmendable differences”.